Daim

Bonjour, wenn es um das Thema AD geht, gibt es kein Pardon ;) . Zum einen: Unter Windows Server 2003 MÜSSEN nicht unbedingt die FSMO-Rollen verschoben werden. Das passiert auch automatisch beim herunterstufen des DCs. Dieser verschiebt dann selbstständig die FSMO-Rollen auf einen bestehenden Windows Server 2003 DC. Es ist lediglich darauf zu achten, dass je nach Umgebung der GC nicht mit dem Infrastrukturmaster zusammen auf einem DC sein sollte, es sei denn, es ist auf allen DCs dieser Domäne der GC aktiviert. Das steht aber in dem zweiten (und weiterführenden Links), den ich oben gepostet hatte. Zum anderen: Der globale Katalog wird nicht verschoben, sondern auf einem weiteren DC aktiviert. Der GC ist nicht zu vergleichen mit den FSMO-Rollen. Meine geposteten Links reichen völlig aus und sind aktuell.

Servus, dazu muss zum einen die globale Richtlinie, idealerweise in der Default Domain Controllers Policy unter: Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Überwachungsrichtlinie\<Verzeichnisdienstzugriff überwachen> aktiviert sein. Zum anderen gilt es dann in der SACL des Containers bzw. OU die gewünschten Optionen auszuwählen. Das ganze ist unter Windows 2000/2003 leider noch sehr spärlich gelöst. Dieses Verhalten wurde (unter anderem) im Windows Server 2008 verfeinert. Früher (Windows 2000/2003) wurde lediglich protokolliert, wer welches Objekt bzw. Attribut verändert hat. Die eigentlichen Werte (alter Wert/neuer Wert) blieben aber einem verborgen. Dieses Verhalten wurde im Windows Server 2008 geändert und man bekommt nun detailliert in der Ereignisanzeige die veränderten Werte zu sehen. Trotzdem gilt auch dabei: Eine Protokollierung ist vom Betriebsrat/Datenschutzbeauftragten zu genehmigen!

Servus, wenn der Windows Server 2003 R2 der erste R2-DC in der Windows Server 2003 Gesamtstruktur werden soll, so musst du das ADPREP von der zweiten R2-CD auf dem Schema-Master, mit dem Schalter /FORESTPREP ausführen. Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 Alles weitere, erfährst du von hier ;) : Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen

Buenos tardes, in dem jemand diesen Client startet und du dich von deinem Arbeitplatz im Eventlog mit dem Client verbindest. Dazu startest du das Eventlog auf deiner Admin-Workstation, klickst auf AKTION und wählst die Option "Verbindung zu anderem Computer herstellen..." aus. Das wird dir aber nichts bringen, denn den Grund wirst du nicht finden... Genau so würde ich das machen. Aber bevor du den Client erneut in die Domäne nimmst, lösche unbedingt vorher das Computerkonto-Objekt aus der Domäne.

Servus, ja, in den meisten Fällen ist das der Fall. Es tauchen noch die SIDs von längst nicht mehr existierenden Benutzern auf. Das kann aber auch bei dem bekannten Problem im Fall von: Wenn der Infrastrukturmaster und der GC auf einem DC liegt. Wenn in diesem Szenario dann nicht ALLE DCs der gleichen Domäne ebenfalls GCs sind, kann dieses Verhalten ebenfalls auftauchen.

Doch, dass hätte auch reichen sollen. Aber der Hinweis von zahni ist wichtig!

Obwohl du zuerst den Client aus der Domäne genommen und anschließend das Computerkonto-Objekt aus dem AD entfernt hast? Das ist merkwürdig... Du hättest sicherstellen müssen, dass das Computer-Objekt auch auf ALLEN DCs der Domäne entfernt wurde. Bedeutet, etwas Zeit verstreichen lassen für die Replikation.

Servus, wenn das hier "BTM011008" also der Client ist, bei dem das Problem besteht, dann würde ich das auch so sehen.

Nee... ich weiß natürlich auch nicht alles. Vielleicht ein bisserl mehr als andere ;) . Dieses "...und macht erstmal weiter" bedeutet aber in deinem konkreten Fall, dass du anfängst mit ADMT zu migrieren. Genau dabei wirst du aber dann Probleme bekommen. ...wenn nicht, sogar noch höher. Dann wäre das Tool ja nutzlos. Denn das Benutzer-Profil, das meistens lokal auf dem Client liegt, hängt natürlich auch vom Computerkonto ab. Wenn nur die Benutzerkonten migriert werden könnten, dann könnte man x-beliebige andere Tools dazu verwenden, wie z.B. CSVDE, LDIFDE etc. Damit habe ich auch recht schnell neue Benutzer erstellt. Nenee... das ADMT macht schon mehr. Genau das richtige Werkzeug, für eine Migration. Teste das mit einem Test-User an einem Test-PC aus. Ich "meine" der Benutzer wird aus der Quelle entfernt, bin mir aber gerade nicht sicher. Wie gesagt, wenn ich recht der Annahme gehe, dann wird der Benutzer aus der Quelle entfernt. In der Ziel-Domäne wird ein neues Benutzer-Objekt mit einer neuen SID erstellt und in das Attribut SID-HISTORY des neuen Benutzer-Objekts, wrd die "alte" SID (vom Benutzer-Objekt aus der Quell-Domäne) hinzugefügt. Wenn nun der Benutzer auf eine Ressource in der Quell-Domäne zugreifen wollte, zückt das neue Benutzerkonto sie "alte" SID aus der SIDHistory und erhält somit Zugriff. Im übrigen ist diese SID-History Variante nur für den Übergang, genauer, während einer Migration gedacht und nicht für die Ewigkeit. Klar, wenn das Benutzerkonto samt Computerkonto in die neue Domäne migriert wurde, spielt für diesen Benutzer, die alte Domäne bezgl. der Authentifizierung (Domänenanmeldung) keine Rolle mehr. Während der Migration, die ja auch in größeren Umgebungen Monate dauern kann, befindet sich nun der Benutzer in der neuen Domäne und muss aber noch auf die Freigaben in der alten Domäne zugreifen. Das erschlägt man eben durch die SID-History. Jawollja, jeden Tag immer etwas mehr ;) .

Servus, gib doch dem neuen Server vorübergehend, während der Migration eine IP-Adresse aus dem Bereich 172.16.x. Wenn die Migration angeschlossen ist, kannst du die IP-Adresse dann ja ändern. Wie willst du auf dem neuen Server das AD installieren ohne DNS? Das DNS ist für das AD elementar. Das kannst du auch machen. Eieieiii.... dann hast du aber das Prinzip von ADMT noch nicht verstanden. Genau das ist doch der Vorteil von ADMT. Du migrierst im ersten Schritt das Benutzer- und im zweiten das Computerkonto. Somit bleiben dir also alle Profile erhalten. Der Benutzer schaltet dann seinen Client aus der alten Domäne aus, baut ihn in der neuen Domäne auf, fährt den Client hoch und meldet sich mit seinen Benutzerdaten an. Alles sieht für den Benutzer dann so aus, wie vorher. Bei der Migration mit ADMT legt das Tool einen neues Benutzerkonto in der neuen Domäne an und fügt die SID des alten Benutzerkontos aus der alten Domäne, an das neue Benutzerkonto der neuen Domäne als SIDHistory hinzu. Das Benutzer- sowie Computerkonto wird in der neuen Domäne während der Migration mit ADMT automatisch erstellt.

Irgendwie stehe ich immer noch drauf ;) . Hast du zufällig was mit WSUS zu tun ? Da gab es doch mal ein Spiel mit "Mister X" den es zu erraten gilt... cool :D .

Servus, um welche Informationen handelt es sich denn und in welcher Dateiform liegen die Daten vor ? Prinzipiell geht das per Skript, ADSI, CSVDE oder LDIFDE.

Das hätte ich dir auch sehr ans Herz gelegt, nicht deine produktive Umgebung "zu schroten" ;) . Wir können uns immer und jederzeit gerne unterhalten, aber warum im April? War da was? Steh ich gerade auf dem Schlauch? Wo ist der nächste Arzt?

Servus, wenn das der erste Windows Server 2003 DC in der Gesamtstruktur ist, musst du im ersten Schritt das Active Directory-Schema aktualisieren bzw. auf Windows Server 2003 vorbereiten. Dazu führst du das Tool ADPREP von der Windows Server 2003 CD aus. Falls die neue Maschine ein Windows Server 2003 --> R2 <-- sein sollte, beachte bitte, dass du das ADPREP von der zweiten R2 CD verwendest. Denn das ADPREP bei R2 befindet sich auf beiden CDs. Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 Du führst das ADPREP mit dem Schalter /FORESTPREP auf deinem 2000er Schema-Master aus. Anschließend führst du ADPREP mit dem Schalter /DOMAINPREP auf dem Infrastruktur-Master in der Domäne aus, in der du den neuen Server hinzufügen möchtest. Danach füge den neuen Server als "zusätzlichen Domänencontroller einer bereits existierenden Domäne" hinzu. Deine Forward Lookup Zone (FLZ) im DNS sollte auf deinem 2000er DC idealerweise AD-integriert gespeichert sein und "Nur sichere" Updates zulassen". Wenn die FLZ im AD gespeichert ist, erleichtert dir die Replikation das Leben ein wenig. Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen In den TCP/IP Einstellungen des neuen Servers trägst Du als ersten und einzigsten DNS den bestehenden 2000er DC ein. Erst wenn die Replikation stattgefunden hat, kannst du die DNS-Server Einstellung verändern. Siehe: Yusuf`s Directory - Blog - Welcher DNS-Server sollte eingetragen werden ? Somit hast Du das AD und DNS auf Deinen neuen DC "gesichert". Dann solltest Du die 5 FSMO-Rollen auf den neuen DC noch verschieben: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Zusätzlich solltest Du den neuen DC zum GC deklarieren. Dieses kannst Du in dem Snap-In "Standorte- und Dienste" in dem jeweiligen Standort, auf Deinem Server - in den Eigenschaften der NTDS-Settings den Haken bei "Globaler Katalog" setzen. Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC) Welche Dienste noch übernommen werden sollten bzw. was noch alles zu beachten ist, bevor der 2000er DC evtl. aus der Domäen genommen wird, erfährst du aus diesem Artikel: Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen Und noch der Hinweis, dass wenn möglich jede Domäne zwei DCs haben sollte. So wie Sunny61 es bereits geschrieben hat, ist das entscheidende das SMB-Signing. Der Link mit dem Hinweis zu Dos oder 9x Clients, wäre allerdings dieser: Gruppenrichtlinien - Übersicht, FAQ und Tutorials

Salut, so sollte natürlich ein Backup nicht aussehen. Elementar bei einem DC, ist der Systemstatus (System State) den es zu sichern gilt. Das reicht bei weitem nicht aus. Wenn das so einfach wäre, könnte das ja jeder "schnell" mal machen ;) . Diese Meldung erscheint z.B. auch (unter anderem) bei einem Client, an dem ein Drucker im AD veröffentlich wurde, oder eben auch an DCs. Es gäbe da noch weitere Punkte. Ob das Objekt, in diesem Fall der DC noch weitere Unterobjekte erhält, muss man nicht unbedingt ADSIEdit, einen LDAP-Browser oder den Active Directory Explorer verwenden. Im Snap-In Active Directory-Benutzer und -Computer einfach unter ANSICHT die Option Benutzer, Gruppen und Computer als Container aktivieren. Danach werden die Computerobjekte als Container dargestellt und falls diese weitere Objekte enthalten, kommen diese somit zum Vorschein. Das macht bei dir aber keinen Sinn, da der DC ohnehin gecrasht ist. Das soll lediglich zur Erklärung diesen. Du würdest diese wie ich bereits geschrieben habe sehen. Aber wie gesagt, macht das bei dir keinen Sinn, da der DC noch an vielen weiteren Stellen im AD steht die es zu entfernen gilt. Bei weitem nicht. Die händische Entfernung der Leiche aus dem AD muss durchgeführt werden. Erst danach ist die Leiche auch im Jenseits begraben ;) . Hast Du Dir diesen Artikel auch genau durchgelesen: Entfernen von Daten aus Active Directory nach fehlgeschlagener Domänencontroller-Herabstufung Hier kannst Du Dir über NTDSUTIL einen Webcast anschauen: 7WTT TechNet Webcast: Active Directory - Wartung Ihres Verzeichnisdiensts mit NTDSUTIL (Level 200) Du kannst den DC auch auf folgende Variante entfernen: - Öffne ADSIEdit und verbinde Dich mit der Domain-Partition - Navigiere zum Contaier "OU=Domain Controllers" und lösche dort die Einträge des nicht mehr existierenden DCs - Ebenfalls in der Domain-Partition, löscht Du alle Einträge des DCs auf folgendem Pfad "CN=Domain System Volume,CN=File Replication Service,CN=System,DC=<DeineDomäne>,DC=<TLD> - Dann verbindest Du Dich mit der Configuration-Partition im ADSIEdit und entfernst alle Einträge des nicht mehr existierenden DCs (z.B. CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=<DeineDomäne>,DC=<TLD>) - Entferne alle Einträge vom DC, die im DNS und WINS existieren Es sollte aber darauf geachtet werden, zwei DCs in der Domäne zu betreiben.

Servus, Container (CN) kannst du entweder mit CSVDE, LDIFDE oder per Skript erstellen (bitte danach mit der Suchmaschine deines Vertrauen im Internet suchen). Mit CSVDE oder LDIFDE könnte das in etwa so aussehen (bitte die Eingabe nochmals genauer überprüfen, dies ist nur ein Ansatz):

Servus, ist das zufällig ein Exchange Server? Dann wäre das keine so gute Idee. Denn der Server auf dem ein Exchange installiert worden ist, sollte nachträglich nicht mehr verändert werden. Was soviel bedeutet, der Serevr sollte nach der Exchange Installation weder zum DC herauf- noch heruntergestuft werden. Das wird von Microsoft nicht supportet, auch wenn man es technisch lösen kann. Stufe den anderen doch zum DC und siehe zu, dass ein weiter Server zum DC gestuft wird. Denn wenn möglich, sollte jede Domäne zwei DCs haben (und wenn der zweite lediglich eine VM wäre). Im Prinzip ist das recht einfach. Du stufst einen anderen Server als zusätzlichen Domänencontroller deiner bereits existierenden Domäne hinzu. Anschließend aktivierst du auf diesem den GC und verschiebst die FSMO-Rollen. Das DNS muss ebenfalls dabei installiert werden und im idealfall, befindet sich deine FLZ im AD. Denn dann erledigt die AD-Replikation für dich den Rest. Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen Was noch alles zu beachten ist, wenn der erste DC ausgetauscht werden soll, erfährst du aus diesem Artikel: Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen

Dann beende doch mal den DNS-Dienst auf deinen DCs (bitte nur in einer Testumgebung!) und schau mal, was die AD-Replikation so macht... ;) .

Servus, das gleiche bei mir, aber das ist bei den Charter-Zertifikaten schon immer so gewesen. Es gibt neben den eigentlichen Zertifikaten noch zwei "besondere" Zertifikate, nämlich für die "ganz schnellen" Prüflinge. Stand heute meine ich, bekommen die ersten 500 die eine Prüfung erfolgreich bestehen, noch ein zusätzliches Zertifikat. Das lautet "Early Archivier". Somit kann man ganz stolz behaupten, ich war einer der ersten 500 Prüflinge Welteit, die diese Prüfungen gemacht und bestanden hat. Früher waren es nicht 50 sondern mehr.. Dann gibt es noch den "Charter Member". Dieses Zertifikat erhält man, wenn man unter den ersten 1000 (oder 2000) ist. Früher waren es 2000, heute meine ich, sind es 1000. Microsoft hat die Werte runtergeschraubt. Weil man eben dann einer der ersten war, die diese Prüfung bestanden hat, belohnt Microsoft einem das, mit einem extra Zertifikat.

Das war ja auch eher eine rhetorische Frage und um dir noch eine "Chance" zu geben, dich da sauber herauszuwinden ;) . Die AD-Replikation braucht in der Wirklichkeit sogar weniger als eine ISDN-Leitung an Kapazität. Die Einschränkung die man aber dann damit hat, ist die Replikations-Dauer. Die Replikation dauert dann eben länger... Sorry, aber das verwechselst du jetzt aber. Ein WINS-Server ist in jeder Domäne hilfreich - keine Frage. Aber nicht bei der AD-Replikation. Dort ist nunmal das DNS der elementare Dienst bei der Namensauflösung und keineswegs WINS. Was macht jeder DC von der eigentlichen AD-Replikation? Richtig, er führt ein DNS-Lookup durch und warum? Um zwei Dinge sicherzustellen. Das nämlich zum einen die DNS-Namensauflösung funktioniert und zum anderen, der Replikationspartner IP-technisch erreichbar ist.

Servus, warum denn das ? Du musst "lediglich" die Randbedingungen beachten, dann klappt das auch mit dem Nachbarn... Um das mit anderen Worten zu beschreiben: Falls Exchange 2000 auf einer Windows 2000 Maschine laufen sollte und beide Systeme aktualisiert werden sollen, dann muss zuerst Exchange 2000 auf Exchange 2003 upgedatet werden. Denn Exchange 2003 läuft unter Windows Server 2000 aber nicht umgekehrt (Exchange 2000 auf Windows Server 2003), dass geht nicht. Daher muß zuerst ein Exchange Update gemacht werden und dann das Betriebssystemupdate von Windows Server 2000 auf Windows Server 2003. Wenn ein Exchange 2000 Schema in der Gesamtstruktur vorhanden ist, so ist zuerst die Exchange Schema-Erweiterung zu „korrigieren“. Dazu wird die Datei InetOrgPersonfix.ldf benötigt, die sich in der Archiv-Datei Support.cab im Verzeichnis „Support\Tools\" auf der Windows Server 2003 CD befindet. Diese Archiv-Datei gilt es zu entpacken und anschließend mit LDIFDE ins Schema zu importieren. Der Befehl dazu lautet: Ldifde.exe /i /f inetOrgPersonFix.ldf /c "DC=X" "DC=Domäne,DC=TLD". Du musst eben die Bedingungen beachten.

Servus, ich habe zwar deine Situation nicht klar verstanden, aber lies dir doch zuerst diesen Artikel durch und frage dann gezielter: Yusuf`s Directory - Blog - Gruppen

Bonjour, das musst du mir jetzt aber mal genauer erklären.

Dann kann ich das so nicht nachvollziehen, da es bei mir genau so funktioniert. Teste das doch einmal mit einem anderen Benutzer oder erstelle dir einen Test-Benutzer und führe die Objektdelegierung erneut durch.

Bonjour, du hast in der Objektdelegierung die Option "Setzt Benutzerkennwörter zurück und erzwingt Kennwortänderung" gesetzt? Oder wie bist du genau vorgegangen?