Verzwickte Sachlage mit einem Prozessleitsystem und 2 Domaincontrollen W2K SP2

[sturmi 10]

Hallo liebes Forum,

 

 

es ist Weihnachten, und wie immer habe ich ein Problem.

 

Also, ich habe an meinem Arbeitsplatz die Aufgabe der Wartung von einem Automatisierungssystem, welches die Energieversorgung sicherstellt.

 

Hierbei handelt es sich um eine in einer Automatisierungsnetzwerkstruktur eingebette Prozessleitsystemanwendung, die aus 2 DCs (W2K Server SP2), 6 Memberservern (W2k Server SP2) und sehr vielen Clients (W2K Prof. SP2) besteht.

 

Ich habe nun das Problem, dass das Leitsystem zwingend SP2, bzw. SP3 vorschreibt, da es zur Visualisierung den IE benutzt. Es ist keinerlei Update möglich, und auch nicht freigegeben. Der Hersteller entwickelt das System nicht mehr weiter, und möchte einfach nur, dass wir ein neues System kaufen. Das wollen wir aufgrund der Kosten von 400K sowie der damit verbundenen Produktionsstillstände nicht. Leider komme ich jetzt langsam in die Region, wo ich keine Hardware mehr bekomme, die mit SP2 läuft. Die meisten Treiber setzen mindestens SP4 voraus.

 

Als halbwegs intelligenter Mensch habe ich mir gedacht, ich virtualisiere einfach die Server und Client-Welt. Gesagt getan, Open Suse als Host, und mit dem VMWareKonverter von den bestehenden Rechnern VM-Images gezogen. Läuft auch sehr stabil.

 

Jedoch möchte ich die Domaincontroller lieber nicht virtuell laufen lassen.

 

Mein Plan sah jetzt so aus, einen W2K SP4 Server (da ich ja ein ADPREP für 2K3 oder 2K8 nur durchführen kann, wenn SP4 installiert ist) ohne Leitsystemapplikation in die Domäne zu stellen, alle Rollen auf ihn zu übertragen, und dann die Leitsystemrechner zu virtualisieren.

 

Leider stellte sich heraus, dass ich keinen SP4-Server promoten kann, wenn die anderen DCs auf SP2 laufen. Er wehrt sich mit dem Hinweis, dass meine Rechte nicht ausreichend sind (Access denied während dem DCPromo-Vorgang, mit der Aufforderung, einen anderen Account einzugeben).

 

Wenn ich das Ganze mit einem SP2/3-Server probiere, klappts. Also erst promoted, dann das SP4 aufgespielt. Kaum habe ich das getan, klappt die Replizierung auf den SP4-Server nicht mehr, mit dem Hinweis "Access denied". Netdiag und DCDiag sagen auch, dass der Rolleninhaber zwar bekannt, aber nicht erreichbar ist.

 

Jetzt bin ich also genauso schlau wie vorher. Meine letzte Idee, um die DCs wenigstens von der Automatisierungsapplikation zu trennen, ist zwei virtuelle DCs aufzusetzen (mit SP2 oder 3), die "nur" DCs sind, und nicht noch Leitsystemaufgaben inne haben.

 

Aber interessehalber wollte ich mal fragen, ob jemand weiß, warum ein SP4-Server nicht mit SP3/2 DCs repliziert werden kann.

 

Was hat sich denn mit dem SP4 geändert, was das verhindert?

 

Und natürlich bin ich auch für neue Ideen, andere Lösungsvorschläge aufgeschlossen.

 

 

Danke fürs Lesen, und eine besinnliche Weihnachtszeit!

 

 

Gruß

 

Christian

 

Nachtrag:

 

Wäre es denkbar, zuerst die Rollen auf den neuen SP3-Server zu übertragen, den alten Server dann zu demoten (Danach testen, ob das Leitsystem noch ordnungsgemäß funktioniert) und dann ein Update auf SP4 durchzuführen (um danach bei Erfolg mittels ADPREP die Vorbereitung auf W2K3 oder W2K8 durchzuführen). Muss ich, ausser ständiger Backups um ein Rollback zu ermöglichen, noch etwas beachten?

Ist es von Bedeutung, wenn danach die DCs auf SP4 und die Clients auf SP2 laufen?

 

Gruß

 

Christian

[NilsK 2.803]

Moin,

 

aus verantwortungsbewusster Sicht gibt es nur eine Aussage: Jedes Gefrickel, das dazu dient, die Installation eines aktuellen Systems zu vermeiden, ist unprofessionell. In sofern glaube ich nicht, dass dir jemand quasi per Reverse-Engineering die Stellen raussucht, an denen SP4 etwas geändert hat, damit du an diesen Stellen etwas manipulierst.

 

Ich kann verstehen, dass der Umstieg auf ein komplett neues System eine beträchtliche Hürde darstellt. Mit dem uralten Softwarestand von Windows 2000 SP2 arbeitest du aber in einer Umgebung, die mindestens fahrlässig veraltet ist (wir reden hier von einem sieben Jahre alten Stand!).

 

Da du nun aber offenbar dem Zwang nachgibst, mit einer veralteten und nicht supporteten Umgebung zu arbeiten: Warum schreckst du dann ausgerechnet vor dem Virtualisieren deiner DCs zurück? Das ist nicht nachvollziehbar. Zusätzlich verstehe ich nicht, warum die DCs nicht mit SP4 laufen dürfen - da muss doch deine Applikation nicht laufen, oder?

 

Gruß, Nils

[sturmi 10]

Hey und Danke für die Antwort.

 

Nunja, verantwortungslos würde ich es nicht direkt nennen, das System ist in sich eine Insel, ergo keine Verbindung zum Internet. D.h. die Gefahren sind meines Erachtens überschaubar.

 

Es gibt mehrere Gründe, warum wir nicht aktualisieren wollen. Wir würden aufgrund der Umstände (Pharma-Betrieb) mindestens einen 6-Wochenstillstand für eine Riesenfabrik verursachen, ausserdem ist der Hersteller derart arrogant, dass es mir persönlich widerstrebt.

 

Nun zum Problem. Momentan ist es so, dass die DCs zeitgleich noch Aufgaben des Leitsystems übernehmen, sodass für die bisherigen DCs definitiv kein Update in Frage kommt. Aus diesem Grund habe ich mir vorgestellt, dass ich die DC-Funktionalität auslagere, damit ich die DCs updaten kann.

 

Leider schlägt das allerdings fehl. Ich habe mir vorgestellt, einen neuen SP4-Server in die Domäne zu heben (klappt), und dann zu promoten. (schlägt fehl).

 

Ergo habe ich ihn als SP3 promoted, was funktioniert hat. Nach dem Patch auf SP4 findet allerdings keine Replikation mehr statt. (DCDIAG sagt bei allen Rollen, dass der Inhaber zwar bekannt sei, aber nicht erreichbar. AD-Zugriff nicht mehr möglich, Access Denied. )

 

Jetzt habe ich bei Google einen Beitrag gefunden, der besagt, dass die beiden SPs unterschiedliche "Sicherheitsstandards" benutzen, und dass eine Kommunikation nicht möglich sei.

Zusätzlich habe ich einen Beitrag bei MS gefunden, der besagt, dass die Richtlinie "Annahme der Clientidentität nach Authentifizierung" ab SP4 dazu gekommen sei.

 

Wie dem auch sei, nach dem SP4 nicht gefunzt hat, habe ich ein bisserl kalte Füße bekommen (weil das Wartungsfenster aufs Ende zuging), und ich habe erstmal den Ursprungszustand wiederhergestellt.

 

Ich hätte jetzt zwei Ideen:

1) Virtualisierung der DCs mit SP2. (Das Problem ist ja, dass die Server 5-7 Jahre alt sind, und neue Hardware Treiber hat, die mindestens SP4 vorraussetzen. Was das Gefuddel betrifft, ist die Herstellerfirma m.E. noch eine Stufe besser. Die nehmen, wenn sie neue Rechner aufsetzen müssen, W2K SP2, bügeln das SP4 drauf, installieren dann die Treiber, und deinstallieren dann das SP4 wieder. DAS nenne ich Gepfusche, und das führt auch zu gewaltigen Problemen in den Nachbarbetrieben, die diese Praxis verfolgen. Das will ich unbedingt vermeiden, will dieser Fa. aber auch nicht noch mehr Geld in den Rachen werfen.

 

2)

Aufsetzen des neuen DCs mit SP3. Übertragung aller FSMOs auf den neuen Server. Demoten des "alten" DCs. Patchen des neuen auf SP4. Wenn Funktion gegeben, ADPREP um den Schritt zu W2K3 machen zu können. Allerdings weiß ich nicht, wie W2k Prof. Clients mit SP2 auf das SP4 bzw. einen W2K3 Srv. reagieren.

 

Deshalb wollte ich mal fragen.

 

Bezüglich der DC-Virtualisierung. Ich habe eigentlich keine Skrupel (wie man schon lesen konnte. ;-)), aber ich denke mir, es könnte etwas viel für die virtuelle Kiste werden, wenn DC, Leitsystemapplikation und SQL Server auf einer Mühle laufen. Also wollte ich sie trennen. Und am besten hätte mir eine Möglichkeit gefallen, die es mir ermöglicht, wenigstens die DCs auf echten Kisten installieren zu können, um im Zweifel auch auf aktuelle BSen umzusteigen.

 

Danke schonmal für deinen Beitrag (der nicht ganz frei von berechtigter Kritik ist. ) ;-)

 

 

Gruß

 

Christian

[djmaker 95]

Kurze Frage

 

Was hindert dich daran 2 neue virtuelle DCs mit SP 2 zu installieren und anschließend die beiden vorhandenen DCs zu demoten? Du könntest anschließend die virtuellen DCs updaten.

 

PS: ein DC ist ein DC ist ein DC . . . und kein Applikationsserver.

[NilsK 2.803]

Moin,

 

genau wie Thomas verstehe ich immer noch nicht, warum du nicht einfach zwei virtuelle DCs mit SP2 einrichtest und gut ist. Es gibt in deiner technischen Umgebung keinen Grund, ausgerechnet die DCs nicht zu virtualisieren. Dass du mehr als einen VM-Host brauchst, sollte dir hoffentlich klar sein (auch wenn deine Ausführungen anderes befürchten lassen).

 

Danach könntest du die vorhandenen beiden DCs demoten. Ziel sollte sein, dass die krökelige Software nur noch auf Memberservern und Clients läuft, aber nicht mehr auf den DCs. Dann sollte es problemlos sein, die DCs auf einen vertretbaren technischen Stand zu bringen.

 

Als dritten Schritt solltest du prüfen, ob wirklich das ganze Netzwerk auf W2000SP2 laufen muss. Muss es wahrscheinlich nicht, vermutlich geht es nur um die Server- und Clientkomponenten der Software. Die Auswirkungen ließen sich durch Konsolidierung der Komponenten und evtl. Terminaldienste auf wenige Maschinen eingrenzen, sodass wenigstens der Rest auf aktueller Basis laufen könnte.

 

Zu deiner Gesamtargumentation: Win2000 SP2 ist sieben bis acht Jahre alt. Das Problem schiebt ihr also schon so lange vor euch her. Ihr betreibt das Netzwerk der "Riesenfabrik" also schon sehr lange auf einem technischen Stand, der bekanntermaßen nicht okay ist (sonst hätte es danach ja keine SPs mehr gegeben; schon gar keine, die Minimalstandard für praktisch alles Weitere geworden sind wie SP4) und der darüber hinaus vom Hersteller seit Jahren (!) nicht mehr supportet wird. Wenn man nun noch dazunimmt, dass der weitaus größte Teil der Angriffe nicht "aus dem Internet", sondern von innen kommt, erhält man vielleicht eine Ahnung davon, was ich als fahrlässig bezeichne. Nur zum Vergleich: Würde das Unternehmen mit seinen sonstigen Anlagen oder etwa mit den PKWs der Manager auch so umgehen - keine Wartung, keine Reparatur, kein TÜV?

 

Schöne Grüße und fröhliche Weihnachten,

 

Nils

[LukasB 10]

Es gibt mehrere Gründe, warum wir nicht aktualisieren wollen. Wir würden aufgrund der Umstände (Pharma-Betrieb) mindestens einen 6-Wochenstillstand für eine Riesenfabrik verursachen, ausserdem ist der Hersteller derart arrogant, dass es mir persönlich widerstrebt.

 

Ich will mich hier mal grundsätzlich NilsK anschliessen, und dir sagen dass dein Versuch hier so nichts werden kann.

 

Du hast im Moment eine unprofessionelle Frickelumgebung, auf welcher Software von einem extrem inkompetenten ISV läuft - es ist nur eine Frage der Zeit bis dir das ganze um die Ohren fliegt.

 

Wenn du jetzt anfängst an diesem sowieso instabilen Konstrukt rumzubasteln, dann bist nachher du schuld wenn es dann auch tatsächlich auseinanderbricht.

 

Ich seh auch nicht ein wieso ein Applikationswechsel einen Stillstand von 6 Wochen bedeuten sollte - ist alles eine Frage der Planung.

 

Nun zum Problem. Momentan ist es so, dass die DCs zeitgleich noch Aufgaben des Leitsystems übernehmen, sodass für die bisherigen DCs definitiv kein Update in Frage kommt. Aus diesem Grund habe ich mir vorgestellt, dass ich die DC-Funktionalität auslagere, damit ich die DCs updaten kann.

 

Dir ist klar das ein demoten diesen DCs das Leitsystem je nach Applikation ebenfalls kaputtmachen kann?

[sturmi 10]

Hallo und einen schönen ersten Weihnachtsfeiertag!

 

Ich weiß, dass die Sache nicht gut ist, egal wie ich sie anfasse. Ich habe das Problem, dass ich nicht der Mensch bin, der entscheidet, ob eine neue System-Applikation gekauft wird. Ich weiß aber, was das bedeutet. Die 6 Wochen beziehen sich nicht nur auf den Server und Applikationstausch, sondern viel mehr darauf, dass die I/O-SPS-Ebene auch getauscht werden müßte, da mit den neuen Systemen nicht mehr kompatibel.

 

Wir haben bisher auch nicht einfach geschlafen, aber wir sind eigentlich völlig abhängig von der Herstellerfirma des Leitsystems. Das Ding ist noch nicht allzu alt, und normal ist in der Automatisierung ein LifeCycle von mindestens 15 Jahren. Nach 5-8 Jahren zu sagen, man supportet und patcht die Applikation nicht mehr, ist nicht die feine Englische. Wir bekamen zur Antwort, dass sie wüßten, dass das System nicht toll war, und sie könnten das nun auch nicht mehr ändern. All das hilft mir nunmal jetzt nicht. Diese Streitigkeiten führen nun andere Abteilungen.

 

Ich soll mehr oder minder nur dafür sorgen, dass die Fabrik Wasser, Dampf u.ä. zur Verfügung hat, und dafür steht mir ein recht kleiner Etat zur Verfügung.

 

Eure Kritik kann ich gut verstehen, ich habe halt nicht wirklich eine Wahl. Also versuche ich das beste zu machen.

 

@Lukas

Ja, ich weiß, dass das System auch zum Stocken bringen kann. Da wir keinen Support vom Hersteller bekommen, ist das ein ewiges Try-Error-Spiel. Ich weiß sehr wohl, dass professionelles Handeln und Vorgehen anders aussieht.

 

Nichtsdesto trotz, ich muss irgendwas tun. Klar, wenns schief geht, war ich es. Wenn ich aber nichts tue, und so ein Server morgen stirbt, war ich es auch....

 

Also, vielen Dank erstmal für die rege Anteilnahme an meiner "Frickelhütte". ;-)

 

Ich melde mal, wie es so weiter geht.

 

Gruß und weiterhin schöne Feiertage

[Daim 12]

Salut,

 

dann erstelle dir doch z.B. mit dem kostenlosen VMWare Converter von deiner Umgebung eine VM-Testumgebung und spiele deine Tests in der VM-Testumgebung durch. Die Testumgebung sollte natürlich keine Verbindung zur produktiven Umgebung haben. Aber auch auf die Sicherheit sollte in der Testumgebung geachtet werden, denn sie enthält schließlich alle Kennwörter der Domäne.

 

VMware Converter zur Migration von Workstations zu virtuellen PCs oder zu virtuellen Masch - VMware

 

 

Gruß und fröhliche Weihnachten

[sturmi 10]

Hallo zusammen,

 

wollte mal einen kurzen Zwischenbericht abliefern.

 

Also, ich habe mit VMWareConverter meine Serverumgebung abgebildet, jedoch in abgespeckter Form. (Redundanzen sind auf der Spielwiese ja nicht unbedingt notwendig)

 

Hierbei stellte sich schon einmal heraus, dass es gar nicht so einfach wird, das Ganze zu virtualisieren.

 

Erster Haken ist, dass die Domaincontroller zur Lizensierung des Produkts serielle Dongles verwenden. Nachdem meine neuen Rechner erstmal gar keine serielle Schnittstelle hatten, musste diese erstmal nachgerüstet werden.

 

Danach war es nicht so einfach wie gedacht, die serielle Schnittstelle in die VM durchzureichen. Standardmäßig wird hier für die Schnittstelle der EPP-Modus aktiviert, allerdings ist dies der falsche für den Dongle.

 

Problem Nummero zwei stellte sich beim Demoten des DCs, der zugleich die MasterDB hält. Sobald dieser kein DC mehr ist, galt für ihn natürlich auch nicht mehr die DomainControllerPolicy, sodass ein ServiceUser nicht mehr die entsprechenden Rechte besaß. (klingt alles simpel, aber ich musste erstmal darauf kommen;-)

 

Der jetzige Stand sieht aber vielversprechend aus:

 

DC inkl. der FSMO-Rollen ist auf einen anderen Server verschoben, der SP4 hat.

2 der 7 Server laufen in einer VM, und bisher auch recht zufriedenstellend.

 

Der nächste Schritt soll in meinen Augen ein Upgrade des W2kSP4-DCs auf W2K3 sein. Danach will ich sehen, ob und wie das System läuft.

 

 

Beste Grüße

 

Christian