AD Server Transfer auf N100

Mit meinem neuen N100 basiertem Board, das als neuer Domain-Controller arbeiten darf, endet die 5-Jahres-Mission meines E3940 Systems.

Ein kritischer Punkt ist immer die korrekte Übertragung der Active Directory Rolle, und diesmal geschah das “geordnet” und nicht einfach durch hartes Umschalten.


Ein neuer N100 4-Kern max-3.4 GHz Prozessor löst nun den max-1.8 GHz Intel Atom x5 in meinem Wohn/arbeitszimmer ab. Ich erwarte mir vom Sprung von 14 auf 7nm und von dder Verdoppelung der Maximalleistung schon einiges an Geschwindigkeitzugewinn.
Auch darf der neue Knecht mit 16 GB RAM werken, während sein Vorgänger nur 8 GB vertrug.

Active Directory Server umbenennen

Unter dem Namen SVR01 spreche ich schon lange mein “Primärsystem” an, das rund um die Uhr läuft. Blöd ist nur, wenn man einem neuen System diesen Namen geben will und daher war mein Idee, das alte Gerät im AD Verband umzubenennen, und das neue System mit dem somit wieder freiem Namen frisch als Server aufzunehmen.

Der alte Server SVR01 sollte auf SVR99 umgenannt werden, während mein zweiter Domaincontroller SVR02 “zur Sicherheit” mitlief.

Die vorgeschlagene Prozedur war einen “zusätzlichen” Namen dem Server hinzuzufügen mit:

1netdom computername oldname.domain.tld /add:newname.domain.tld

Dann einen Reboot durchführen und den neuen Namen als Primärnamen zu deklarieren mit:

1netdom computername oldname.domain.tld /makeprimary:newname.domain.tld

Und nach einem weiteren Reboot kann man den alten Namen per:

1netdom computername newname.domain.tld /remove:oldname.domain.tld

entfernen.

Tatsächlich funktionierte das auch so. Allerdings traten gleich nach der netdom Ausführung mehrere Fehler in diversen MMC Modulen auf, die dann ihren Server nicht mehr finden konnten.

Doch aus diese Probleme lassen sich per Reboot “gesundstreicheln”.

FSMO Rollentransfer

Die 5 FSMO-Rollen (Flexible Single Master Operation) können jeweils nur von einem Server ausgeübt werden, alle anderen leiten die Anfragen an den “Master” weiter.
In meinem Fall liegen alle gemeinsam auf einem Server, da alle andere Maschinen nur bei Bedarf eingeschaltet werden.

Ich fand es schon vor 20 Jahren seltsam, dass Microsoft die UIs zur Übertragung einer Rolle an so unterschiedlichen Orten versteckt hat:

  • Die Rollen für den “RID”, “PDC” und “Infrastructure” Master findet man unter “Users and Computers” FSMO Domain Roles

  • Die “Domain Naming” Rolle ist unter “Domains and Trusts” versteckt. FSMO Naming Roles

  • Und der “Schema” Master Dialog befindet sich im MMC Snap-in “Active Directory Schema” FSMO Schema Role

Doch dieses Schema-Snap-In ist auf Standard-Installationen gar nicht zugänglich. Man muss erst regsvr32 schmmgmt.dll zur Registrierung aufrufen und kann dann in einer leeren mmc.exe Sitzung unter “Add/Remove Snap-in” das Schema-Snap-in einfügen.

Man hätte das auch per ADSI-Edit manuell setzten können, doch wenn möglich, sollte man immer den “offiziellen” Weg gehen. Wer weiß schon, was Microsoft im Hintergrund mit jeder neuen Version verändert.

Workfolder neu einrichten

Mit dem neuen Server waren natürlich auch meine Workfolder weg. Sie waren natürlich noch da, und zwar am alten Server, und als Kopie auf meiner lokalen Maschine, doch eben nicht mehr “synchronisiert”.

Beim Aufsetzen der Workfolder fing wieder das elende Spiel mit den Zertifikaten an. Man musste eines mit dem richtigen Namen erstellen, dann für das HTTPS Protokoll für die Workfolders freigeben und sicherstellen, dass ihm auch am Client vertraut wird.

Meine Umstellung fiel zufällig genau auf die Woche, wo mein altes Zertifikat ausgelaufen war und ich mich wirklich lange wunderte, warum alle Verbindungen abgebrochen wurden.

Wie toll wäre es hierfür ein Testprogramm zu haben, dass einem genau sagt, warum die Synchronisation nicht funktioniert. So musste ich zwei Stunden herumraten, doch am Ende klappte auch das wieder.

Server Backup

Der letzte Schritt war die Neueinrichtung des Server Backups. Das war auf der bestehenden Platte nur möglich, wenn die alten Backups gelöscht wurden, doch da ich ohnehin alles doppelt gesichert hatte, war das auch noch zu verkraften.

Fazit

Mein neuer kleiner ITX Server ist erstmals kein originaler Intel Atom mehr, denn von denen gibt es keinen leistbaren in der neuen Fertigungstechnik. Dennoch überzeugt der N100 auf Anhieb und rechnet dann auch wirklich doppelt so schnell die Windows-Update Hashes durch.

Größter Pluspunkt ist, dass ich jetzt endlich einen funktionierenden Grafikkartentreiber am Server habe.
Ich brauche am Domaincontroller zwar keine UI-Power, aber die Fixierung auf den Microsoft-Basic VGA-Treiber, weil ansonsten Blue-Screens flogen, war schon ziemlich nervig.

Ich bin jedenfalls mit dem Update zufrieden und freue mich, dass der Active Directory Transfer diesmal so problemlos funktioniert hat.

Mal sehen, ob ich in 5 Jahren dann wieder einen solchen Hardwarewechsel durchführe, oder ob das dann schon ein Roboter für mich erledigt.

📧 📋 🐘 | 🔔
 

Meine Dokus über:
 
Weitere externe Links zu:
Alle extern verlinkten Webseiten stehen nicht in Zusammenhang mit opengate.at.
Für deren Inhalt wird keine Haftung übernommen.



Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!