sturmi

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

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

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

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

Hallo, und erstmal vielen Dank für die vielen Antworten. Wie ich schon eingangs erwähnte, bin ich was diese Dinge angeht, ein absoluter Laie. Dementsprechend frage ich lieber, bevor wir in die Detailplanung gehen.;-) Wenn ich das also richtig verstanden habe, kann das Leitsystem (in Form der Clients) also die Server-Funktionalitäten inklusive der Domain-Accounts nutzen, ohne daß von dem Server-BS eine Gefahr für meine Domäne ausgeht? Ich kann dem Server-BS die gleichen Restriktionen auferlegen, wie einem normalen Client? Und die Domain-Policys gelten für ein Server-BS genauso, wie für einen normalen Client? Und, wenn auf Domain-Ebene ein User nur User-Berechtigungen hat, ändert sich das auf einem Server-BS auch nicht? Wenn das so ist, werde ich die Schweißproduktion etwas einstellen, und meine Planung mit einer gewissen Gelassenheit voran treiben. Ich hatte vielleicht vergessen zu erwähnen, daß ich nicht zum IT-Support gehöre, sondern mich eigentlich um die anlagenseitige Automatisierung kümmere. Aber ich bin gerne wenigstens halbwegs vorbereitet, wenn ich in die Planungsrunde mit der IT-Abteilung gehe. ;-) Also nochmal vielen Dank an alle Leser und Poster, ihr habt mir schon sehr weiter geholfen. Die Links, die da kommen werden, werde ich mir genau anschauen. Ich bin lernfähig, und willig. ;-) Gruß aus dem sich inzwischen aufhellenden Frankfurt. Christian

Guten Morgen zusammen, ich als absoluter Laie muß dieses Board nun leider mit wahrscheinlich etwas banalen Fragen belasten.;-) Also, ich habe folgende Situation: Ich arbeite in einem sehr großen Pharma-Unternehmen, und betreue Automatisierungssysteme, die Anlagen zur Herstellung von Medikamenten steuern. Diese Automatisierungssysteme gehören der neuesten Generation an, arbeiten also mit modernen BSen. Bei uns gibt es natürlich eine Domäne für das sog. Office-Netz, d.h. alle Bürorechner usw. Ein Untersegment, welches durch diverse Schutzmechanismen von dem Office-Netz getrennt ist, heißt Automatisierungsnetz. Dieses ist ein Teil unserer Domäne, verfügt jedoch über eigene DCs und DNSen. Wir planen im Augenblick eine neue Anlage, die aller Voraussicht nach das Leitsystem Siemens PCS7 haben wird. Da wir mehrere Bedienstationen für die Anlage brauchen, ist von Siemens aus eine Server-Client-Konstruktion vorgesehen. Das bedeutet für mich, daß ein Rechner als Server fungiert, und als BS W2K oder W2003 Server benötigt. Der/die anderen Rechner werden mit Windows XP Professional laufen. Jetzt soll unserer Philosophie nach diese neue Anlage auch in die Domäne aufgenommen werden. Dies hat den praktischen Hintergrund, daß sich Mitarbeiter nicht für jede Anlage ein eigenen Benutzernamen/Passwort merken müssen, sondern mit ihrem normalen Domain-Account Zugriff auf die Systeme erlangen. Das Leitsystem selbst regelt dann anhand der Benutzerkennung die Berechtigungslevel. Meine Frage ist jetzt folgende: Gibt es ein Problem, wenn ich einen Rechner mit Server-BS in die Domäne aufnehmen will? Ich kann ihn ja m.E. auch ohne DC-Fähigkeit einbinden. Aber, welche Risiken birgt das für die Funktion meiner Domäne? Diese Domäne ist SEHR groß, und es hängt mehr oder minder die gesamte Produktion in Europa von der Funktion selbiger ab, dementsprechend bekomme ich feuchte Finger bei dem Gedanken daran, daß an dieser Stelle was schief gehen kann. Welche Möglichkeiten in der Domäne Unsinn anzustellen, habe ich von dem Server-BS im Gegensatz zu einem Client? Für Hilfe bei diesen Fragen, die einem versierten "Schrauber" sicher die Lachtränen in die Augen treiben ;-), wäre ich sehr dankbar. Freundlich-Herbstliche Grüße aus Frankfurt am Main, Christian

Hmm, ich hatte solche Probleme auch schon. Gibt es vielleicht irgendeinen Dienst, der mit diesem User gestartet wird? Bei mir stand in den DCOM-Einstellungen ein falsches Passwort, und dann macht der DC auf jeden Fall auch den Riegel zu. Allerdings war das auch ein Serviceaccount, im "normalen" Umfeld kommt sowas ja eher selten vor.

Hallo nochmal, ich weiß, die Antwort kommt spät, aber ich möchte des Rätsels Lösung doch noch posten: Also, es stellte sich heraus, daß der Rechner standardmäßig versucht hat, alle Anfragen auf die Domäne an den DNS weiterzuleiten. Dieser sendete natürlich als Antwort alle DCs zurück, die er selbst erreichen kann. Das davon für den Rechner nur ein einziger zu erreichen ist, wirft natürlich Probleme und Verzugszeiten auf. Als Lösung wurde in diesem Netzsegment jetzt ein eigener DNS eingerichtet, der alle Anfragen für die Domäne auf den verfügbaren DC umleitet. So on, vielen Dank für die Unterstützung.

Ja, das denke ich inzwischen auch. Allerdings will ich natürlich ausschließen, daß das Problem von meiner Maschine kommt. Trotzdem vielen Dank für die Zeit, die du dir genommen hast!

Ich weiß, daß ich hier zu vielleicht nicht so eleganten Mitteln greife, muß jedoch zu meiner Entschuldigung anführen, daß ich kein Domänenadministrator bin, sondern nur in Verantwortung für Teilbereiche wie z.B. diese Anlage stehe. ;-) Nein, die Zeit, die es jetzt dauert sorgt nicht mehr für einen Stop der Anlage, es ist nur für mich störend, denn eigentlich muß eine solche Anfrage rasend schnell gehen, zumal in diesen Bereichen nicht sonderlich viel Traffic auf dem LAN ist. Die Verbindung zwischen dem Rechner und dem DC sind eigentlich hervorragend, die Ping-Zeiten sind mehr wie angenehm. Mittels Traceroute sieht man auch, daß die Wege kurz sind. Ein Hop aufs Gateway, und schon ist der Server erreicht. Ich frage mich deshalb auch, was nun noch die Verzögerung bewirkt.

Hab die Protokolle nun geprüft, und mir fällt nichts merkwürdiges auf. Hab jetzt allerdings die Hosts-Datei bestückt. Mir fiel bei einem NSLOOKUP auf, daß der DNS-Server sämtliche Domain-Controller listet, die zu unserer Domäne gehören, und das sind sehr viele. Da aber nur ein einziger aus diesem Netzsegment erreichbar ist, habe ich in der Host-Datei einen Verweis auf ihn geschrieben, wann immer eine Abfrage auf die Domäne erfolgt. Dies hat dafür gesorgt, daß die Authentifizierung jetzt zwischen 20 und 35 sek. dauert. Das ist leider noch nicht befriedigend......

Guten Morgen, und danke für die zügige Antwort. Ja, das habe ich mir auch schon gedacht, jedoch habe ich das Problem, daß die Automatisierungsseite ihre eigenen IP-Bereiche und Subnetze hat. Zudem erreiche ich aus dem Büronetz weder den Domaincontroller noch die DNS/WINS-Server. Und, um das ganze noch etwas komplizierter zu machen: Da die Firma recht groß ist, und sehr viele Anlagen hat, ist das Automatisierungsnetz in VLANs eingeteilt. (Aus dem ich aber rauskomme, d.h. daran liegts m.E. nicht) Ich denke, es würde mir nicht viel nützen, wenn ich mich an mein "normales" Netz hänge, weil hier die Umstände gravierend anders wären. (Büronetz arbeitet mit DHCP, Automatisierungsnetz mit statischen IPs usw) Gruß Christian

Hallo miteinander, ich habe mal wieder Probleme in der Firma, die mein Wissen übersteigen. Ich arbeite in einem Unternehmen, welches mittels rechnergestützter Leitsysteme Großanlagen zur Herstellung von pharmazeutischen Produkten betreibt. Seit letztem Jahr wurde für diese rechnergestützen Anlagen ein spezielles Automatisierungsnetz eingerichtet, was zwar Verbindung zum normalen Büro-Netz hat, aber über diverse ACLs abgeschirmt ist. Dies soll den Vorteil haben, daß sich Mitarbeiter nicht diverse Passwörter merken müssen, sondern mit ihrem normalen Domain-Konto Zugriff auf die Anlagen bekommen. In dem Automatisierungsnetz ist ein eigener Domaincontroller vorhanden. Seit 2 Wochen habe ich eine neue Anlage zu betreuen, die als Leitrechner einen Windows XP Client nutzt. Diesen habe ich auch problemlos an die Domäne hängen können. Da der Benutzer keinen Zugriff auf die Betriebssystemebene haben soll, meldet sich per Autologon ein Standard-User der Domäne an, und es wird automatisch die Applikation gestartet, die das Bedienen der Anlage gestattet. (Für Insider: Wonderware Intouch 9.0) Die Applikation verwendet die Betriebssystemeigene Benutzerverwaltung, indem sie lokalen Gruppen unterschiedliche Berechtigungen zur Bedienung einräumt. Ich habe nun einfach die die Domänenkonten der Benutzer den lokalen Gruppen zugeordnet. Wenn die Applikation startet, verlangt sie nun eine Authentifizierung. Hier kann der Mitarbeiter seine Kennung, die Domäne und das Passwort eingeben. Soweit so gut. Allerdings dauert die Verifizierung der Anmeldedaten extrem lange. (zwischen 30 Sekunden und 1 Minute) Während dieser Zeit ist der Rechner derart ausgelastet, daß die Applikation nicht mehr reagiert. Dies führt dazu, daß sie ihr Keepalive mit der Steuerung der Anlage nicht mehr aufrecht erhalten kann, und es kommt zu einem Nothalt der Anlage. Wie ihr euch sicher vorstellen könnt, ist dies ein gravierendes Probem. Ich habe schon fleißig im Netz gesucht, und bin natürlich beim Thema Anmeldung auf eine fehlerhafte DNS-Konfiguration gestossen. Nun kann ich meinen DNS-Server auch nicht anpingen, da ICMP per Access List im Router gesperrt ist. Jedoch kann ich mit NSLOOKUP jeden Namen auflösen, also tut der DNS-Server seinen Dienst. Ein Gespräch mit unserer Netzwerkbetreuung ergab leider auch nichts, denn sie konnten in der Kommunikation keine Probleme feststellen. Hat jemand eine Idee, was ich tun kann, oder eine wage Vermutung, wo das Problem liegen könnte? Für das Lesen dieses langen Textes sowie eventueller Hilfestellung möchte ich mich im Voraus bedanken! Gruß Christian

Ja, prinzipiell schon, aber ich kann das nicht glauben! Wenn die CPU nicht mitspielt, wieso hat er dann Probleme beim Starten von ******, bzw. findet div. Dateien nicht? Ist das wirklich charakteristisch für nen CPU-Crash?

Ja, habe ich. McAfee findet nix, auch der kostenlose AntiVir ist ratlos...;-)