David Server zum Domänencontroller hochstufen

  • Hallo,


    Ich betreue ein Netzwerk welches folgendermaßen aufgebaut ist.
    Ein Windows 2003 Standard Server als Domänencontroller und ein Windows 2008R2 Standard Memberserver als David FX12 Server.
    Der 2003 Server ist in die Jahre gekommen und ab Juli 2015 wird der 2003 Server von Microsoft ja nicht mehr mit Patches versorgt.
    Jetzt überlege ich den David Server mit dcpromo hochzustufen. Allerdings würden dabei alle lokalen Gruppen die die David
    Installation angelegt hat ja dann nicht mehr existieren.


    Meine Frage: Stand jemand hier schon vor dem Problem? Geht das überhaupt? Bei Exchange Servern weiß ich, das nachträgliches herauf- oder herunterstufen zum Domänencontroller ein absolutes no go ist.

  • Gegen das Hochstufen zum PDC spricht eigentlich nichts.
    Eine lokale Gruppe DVG-Server wird wahrscheinlich schon existieren.


    In David müsste es genügen, die eingerichteten David-User der neuen Windows Sicherheits-ID zuzuordnen.
    Das bedeutet: im David-Administrator den Benutzer markieren und mit Benutzer / Login den neuen Namen zuweisen.
    Dann haben die User ihre bisherigen Archive weiter im Zugriff.

  • Wir sind hier in einer Windows-Domäne. Der DavidServer ist MITGLIEDSSERVER in der Domäne. Da ist nichts mit lokalen Gruppen. Die DavidAuthentifizierung greift zu dem jetzigen Zeitpunkt schon voll und ganz auf die AD zurück. Ebenfalls sind die User schon dem AD-User zugeordnet (SID's).


    Also absolut kein Unterschied, welcher Server nun der DC ist.

  • Wenn ich den Text eingangs richtig verstanden habe, dann wird doch der derzeitige Primary Domain Controller (PDC) abgeschaltet. Wenn der W2008 Server seine Active Directory Struktur nicht mit dem PDC synchronisiert hat [also als Backup Domain Controller fungierte], dann gibt es nach dem Abschalten keine funktionierende AD mehr. Die Clients haben zwar die Usernamen noch zwischengespeichert, aber nach einem Wechsel zwischen wie Anmeldevorgängen kann "Ende" sein. Da wird eine neue AD-Struktur benötigt.


    Der Memberserver könnte die Usernamen allerdings zwischengespeichert haben, aber sicher bin ich mir da nicht. Ich müsste erst mal in einer Testumgebung ausprobieren, was bei so einem Wegfall des PDC noch da ist. Aber da fehlt mir momentan doch etwas die Zeit zu, weil die neuen Azure-Funktionen der recht stürmisch aufziehenden Microsoft Wolken ja auch erst mal gelernt werden müssen.

  • NoHopeNoFear: Er will ja gerade den PDC löschen respektive abschalten. Dann gibt es keinen Domaincontroller mehr in der Domäne.


    Neuanlage der Domäne auf dem David-Server als Primary Domain Controller ist ein Weg, hochstufen des David-Server zum Secondary Domain Controller der zweite Weg.
    Zu beachten dabei ist, dass der Windows 2003 Server noch ein 32-Bit System ist. Es wird dafür also der etwas aufwendige Weg einer Migration des DomainControllers in eine 64 Bit-Umgebung mit ADPREP32 und einigen dazugehörigen Utilities nötig. Sobald der David-Server als SDC mit allen Benutzerkonten synchronisiert ist kann er zum PDC hochgestuft und dann der alte Server abgeschaltet werden.


    Wenn weniger als ~ 5 User in der Domäne laufen dann ist die Neuanlage des PDC mit neuer Domäne name-neu.local der einfachere Weg. Vorher sollten auf den Clients die persönlichen Daten der Domänen-User gesichert werden.

  • ??
    da der TE ein admin ist unterselle ich ihm einfach mal dass er weiß wie man ein AD migriert. das ist auch bei weitem nicht so komplex wie du es hier darstellst (außerdem schreibt er nicht von löschen sondern migrieren).
    kiste hochstufen (ja, adprep dauert 3min), warten bis gesynct ist, rollen umziehen, licensing server ändern, DNS im DHCP server ändern und fertig. dauert 15min bei 2 servern.
    was an der erstellung einer neuen domäne einfacher sein soll erschließt sich mir nicht, der aufwand ist wesentlich höher als bei einer migration und viel unangenehmer für die user.


    PDCs gibt es seit windows 2000 übrigens nicht mehr...

  • kiste hochstufen (ja, adprep dauert 3min), warten bis gesynct ist, rollen umziehen, licensing server ändern, DNS im DHCP server ändern und fertig. dauert 15min bei 2 servern.


    Das möchte ich so nicht unkommentiert stehen und gelten lassen.
    Denn in der täglichen Praxis sieht es meistens anders aus. Auf dem alten Domaincontroller sammeln sich im Laufe der Jahre nicht nur Daten, sondern auch jede Menge Fehler. Die werden bei einer Migration zu einem neuen Server mitgeschleppt. Da kann es locker mal zwei Tage Arbeit erfordern, bis die Liste der Fehlermeldungen vernachlässigbar klein geworden ist.
    Ich arbeitete bei einigen Installationen mit einer Firma zusammen, die Software für Apotheken liefert und wartet. Die Erfahrungen deren EDV-Teams bezüglich der Server-Migration von W2003 nach W2008 waren so schlecht, dass sie grundsätzlich keine mehr vorgenommen haben.


    Dass ich immer noch PDC zum Domaincontroller sage liegt einfach an einer Gewohnheit aus nunmehr 15 Jahren PDC, BDC, SDC und DC, AD und ...
    Namen sind in der EDV-Welt recht kurzlebig. Irgendwann interessieren die immer neuen Namen für minimale Unterschiede einfach nicht mehr, solange im Kollegenkreis sowieso jeder weiß, was gemeint ist.
    Aber ich werde mich diesbezüglich vielleicht bessern. Denn in den nächsten Tagen werde ich mich mal intensiv mit Microsoft Azure, der Migration von W2008 zu W2012, Office 265 und mal zur Abwechslung Exchange auseinandersetzen. Und spaßeshalber mal eine AD-Migration zwischen zwei virtuellen Servern durchziehen.


    Azure? Noch nie gehört? Das ist aber eine Bildungslücke. Ich sehe da einige Marktchanchen für Kommunikationsserver in der Wolke. Wozu Geld für lokale Hardware ausgeben, wenn die Mitarbeiter eines Betriebes sowieso fast alle irgendwo in der Welt unterwegs sind? Da wäre es ja Stromverschwendung, die Hardware lokal zu betreiben!

    6 Mal editiert, zuletzt von Arno ()

  • ich migriere seit 10 jahren AD server, wenn das system vernünftig eingerichtet ist dann ist auch eine migration kein problem.
    allerdings erleben wir immer wieder wie heftig bei sowas gepfuscht wird - und erleben immer wieder wie kunden mit dem pfusch letztendlich übers ohr gehauen werden weil absolut unnötige arbeiten (neue domäne) abgerechnet werden.


    die migration von 2k3 auf 2k8 war technisch überhaupt kein problem, wenn das korrekt durchgeführt wird ist das in 15min erledigt. das gleiche gilt für 2k8 nach 2k12 was durch das automatische adprep auch noch wesentlich einfacher geworden ist.

  • OK, aber wenn ein Domaincontroller innerhalb von 10 Jahren von mindestens vier verschiedenen EDV-Betrieben gewartet wurde, dann sind einige nicht dokumentierte "Tretminen" im Betriebssystem anzunehmen. Ich denke da zum Beispiel an die Folgen wechselnder Virenschutz-Systeme, von denen noch ungelöschte Policies übrig sind. Ein Neu-Aufsetzen der Domäne halte ich dann beim Serverwechsel für sehr empfehlenswert. Ich halte das neu-Aufsetzen der Domäne vor allem dann für sinnvoll, wenn es beim Server-Betriebssystem eine Virusinfektion gegeben hat. Moderne Schadcodeprogramme verändern gezielt Policies und Schutzeinstellungen. Diese Veränderungen alle zu finden wird kaum möglich sein. Wer aus Zeitnot oder Sparsamkeit eine Servermigration vornimmt muss sich bewusst sein, dass er bei der Migration zumindest ein Teil der vom Schadcode veränderten Einstellungen mit überträgt. Der neue Server ist dann von Anfang an anfällig für neue Schadcode-Infektionen.


    Werden durch den Neuaufbau einer Domäne die Client-User gezwungen, ihre Daten einem neuen Login zuzuordnen, dann hat das sehr vorteilhafte Effekte:
    Denn bei den PCs kleiner oder mittelständischer Unternehmens ist davon auszugehen, dass sich im Laufe von Jahren etliche Botnetz-Viren und ähnliche Nettigkeiten in den Benutzerverzeichnissen eingenistet haben. Die User müssen nicht mal eMail-Nutzung betreiben. USB-Slots, DVD-Laufwerke oder Internetverbindung sind als Einfallstor völlig ausreichend.
    Wenn nun die Benutzerverzeichnisse dieser PCs nach Kopie benötigter Daten sorgfältig gelöscht werden, dann sind anschließend zumindest die Dateien aus den Temp-Verzeichnissen oder heute aus den Application Data Verzeichnissen gelöscht. Und genau darin verstecken sich die meisten Adware-Programme und Trojaner. Bis jetzt nistet sich nur ein kleiner Teil solcher Schadcode-Programme versteckt ins Betriebssystem ein.


    Kaum ein Mittelständler und fast gar kein Kleinbetrieb betreibt genug Aufwand, um sich vor Botnetz-Viren, Adware-Programmen und Trojanern zu schützen.
    Und 100%-gen Schutz gibt es gar nicht. Schon ein einziger mit einem Botnetz-Virus infizierter PC kann genügen, um über's LAN in kurzer Zeit den ganzen Betrieb anzustecken.


    Der Microsoft-Suppot sagte zu einer Infektion mit einem Erpresser-Virus sinngemäß folgendes:
    "Sie haben keine Chance, solche Viren vollständig aus einem System zu entfernen. Die verändern Betriebssystem-Dateien meistens so, dass trotz aufwendiger Bereinigung des Systems neue Viren nachgeladen werden. Die einzige Möglichkeit zur Behebung des Schadens ist eine vollständige Neuinstallation. Vermeiden Sie dabei die Nutzung von Tools wie Windows Easy Transfer. Die Viren-Grundbestandteile würden sonst mit kopiert."

    27 Mal editiert, zuletzt von Arno ()

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!