Daim

Servus, nein, es gibt keine prinzipiellen Probleme mit diesen beiden Rollen zusammen auf einer Maschine.

Servus, es betrifft nicht "ausschließlich" nur die Replikation der DCs, sondern je nach Funktionsebene stehen dann auch weitere Funktionen zur Verfügung.

Moin, kann der XP-Client den DC per IP und per Namen anpingen? Wie sieht es mit diesen beiden Richtlinien aus:? Yusufs Directory Blog - Asynchrones Startverhalten beim Windows XP

Hast du denn den alten DC auch aus den Metadaten des AD gelöscht? Das denke ich nämlich nicht. Dazu führst du das NTDSUTIL aus. Den entsprechenden Artikel hatte man dir schon in diesem Thead bereits verlinkt. Einen weiteren findest du hier: Yusufs Directory Blog - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen Denn wenn du den alten DC bereits gelöscht hättest, wäre in "Standorte und Dienste" unterhalb des alten DC-Objekts das "NTDS-Settings" Objekt entfernt worden. Da aber scheinbar das Objekt noch existiert, hast du NTDSUTIL nicht oder "nicht richtig/zu ende" durchgeführt. Das DC-Objekt des alten DCs selbst in "Standorte und Dienste", muss dann noch händisch entfernt werden.

Wo "rausnehmen"?

Servus, das kommt halt darauf an, was du in deinem Export-Befehl angibst. Dann musst du natürlich deine exportierten Daten an die neue Umgebung "anpassen". Bemühe doch mal die Suchmaschine deines Vertrauen und lies dich in Sachen CSVDE ein.

Ja, wenn der "alte" DC bereits heruntergestuft oder nicht mehr im AD existiert, kannst du das DC-Objekt in "Standorte und Dienste" löschen.

Selam Yavuz, da wird eine Firewall blocken. Kontrolliere auf beiden Servern die lokale Windows Firewall oder falls du eine eigene Firewall installiert haben solltest, deaktiviere bzw. deinstalliere diese.

Das du "veraltete", nicht mehr existierende Objekte erneut im AD hast. Mehr Möglichkeiten als die in meinem Artikel aufgeführt sind gibt es nicht. Du kannst natürlich auch diesen DC, der in deinem Fall auch noch der einzigste DC in der Subdomäne ist, mit Gewalt entfernen und bereinigst anschließend noch die Metadaten des AD. Dazu entfernst du zuerst den DC und anschließend noch die Domäne aus den Metadaten. Oder du wendest dich an den MS-PSS.

Servus, dabei wird aber das Computerkonto nicht entfernt, sondern lediglich deaktiviert. Entfernen musst du es schon per Hand. Werfe trotzdem nochmals einen Blick ins DNS und WINS. Klar. Aber alles was auf diesen DC verwiesen wurde (Login-Skript), muss angepasst werden

Es sollte sichergestellt werden, dass das DNS ordnungsgemäß funktioniert. Dann könntest du noch den folgenden Registry-Schlüssel setzen, falls du es damit noch nicht versucht haben solltest: "Allow Replication With Divergent and Corrupt Partner" Aber wenn dann die AD-Replikation stattgefunden hat, entferne diesen Schlüssel wieder.

Servus, dann müsste auf dem DC in dem Verzeichnisdienstprotokoll die EventID 1988 protokolliert werden. Es gilt die Lingering Objects (LOs) zu entfernen. Im ersten Schritt sollte man sich die veralteten Objekte anzeigen lassen. Die LOs kannst du dir mit dem folgenden Befehl (bei aktiviertem Strict Replication Consistency) anzeigen lassen: REPADMIN /removelingeringobjects <veralteter DC> <GUID eines “aktuellen” DCs> <Verzeichnispartition worin sich die veralteten Objekte befinden> /Advisory_Mode Falls herumlungernde Objekte existieren, werden für jedes Objekt die EventID 1946 auf dem DC protokolliert. Anschließend führst du dann den REPADMIN-Befehl erneut aus, aber diesmal ohne den Parameter /Advisory_Mode.

Servus, dann erzähl doch man welche Informationen zwischen den DCs unterschiedlich sind? Nicht alle Informationen auf den DCs sind identisch. Denn z.B. wird Last Logon nicht zwischen den DCs repliziert. Das bedeutet, wenn der Benutzer vor 10 Tagen von DC1 authentifiziert wurde und von DC2 vor 5 Tagen, so bekommst du an dieser Stelle unterschiedliche Informationen angezeigt. Abgesehen davon, falls Replikationsprobleme bestehen würden, würde dir das schon das Eventlog melden.

Servus, seit das AD mit Windows 2000 eingeführt wurde, gibt es keinen "Haupt-DC" mehr wie zu Zeiten von Windows NT. Zu NT-Zeiten konnte nur der PDC schreiben, aber mit der Einführung des AD wurde das "Multimaster-Prinzip" eingeführt. Nun darf jeder DC in das AD schreiben. Aber bei "manchen" Schreibaktionen, dürfen nur bestimmte DCs diese Aktion durchführen. Damit sind die Träger der FSMO-Rollen gemeint. Es gibt fünf Betriebsmasterrollen. Diese wären: - Schemamaster (existiert nur einmal pro Gesamtstruktur) - Domänennamenmaster (existiert nur einmal pro Gesamtstruktur) - RID-Master (Relative ID) (existiert nur einmal pro Domäne) - PDC-Emulator (existiert nur einmal pro Domäne) - Infrastrukturmaster (existiert nur einmal pro Domäne) Der Client findet duch das DNS (s)einen DC. Die Vorgehensweise wie nun ein Client "einen" DC findet, ist wie folgt: - Der Client fragt im DNS nach, welche DCs es gibt. - Er erhält eine Liste aus der DNS-Antwort und geht diese durch, um einen DC zu finden der funktioniert und auch online ist. Dabei nimmt er bevorzugt einen DC aus seinem Standort. Die DNS-Abfrage die der Client in diesem Moment stellt, wäre: _ldap._tcp.<Standort>._sites.dc._msdcs.<Domäne>.<TLD>. - Erst wenn der Client bei dieser Anfrage (von einem DC aus seinem Standort) keine Antwort erhält oder er noch keine Standortinformationen hat (z.B. nach einer Neuinstallation), fragt er nach einem DC diesmal aus seiner DOMÄNE nach. Die Abfrage lautet: _ldap._tcp.dc._msdcs.<Domäne>.<TLD>. Spätestens bei dieser Abfrage erhält der Client einen DC mitgeteilt. Den genauen Vorgang kannst du hier nachlesen: Yusufs Directory Blog - Domänencontroller am Standort Wenn du den DC mit DCPROMO herunterstufst, werden dabei auch die DNS-Einträge von dem DC entfernt. Wenn du dabei sicher gehen willst, kannst du mit NLTEST das du in den Support Tools findest, dass entfernen der DNS-Einträge händisch nochmals anstoßen. Für das Entfernen der Einträge eines DCs aus der "_msdcs"-Zone, nutzt man einfach das folgende NLTEST-Kommando: NLTEST /DSDEREGDNS: DC01.Domäne.TLD (<--ohne Leerzeichen zwischen dem Doppelpunkt und dem "DC01...") Damit werden die DC-spezifischen SRV-Einträge entfernt. Möchte man auch die GUID-Einträge des DCs entfernen, können weiterhin die Optionen „/DOMGUID“ zw. „/DSAGUID“ helfen. Ein "rumgebastel" mit "künstlich" erzeugten AD-Standorten oder das Herumschrauben an der Priorität bzw. Gewichtung an den SRV-Einträgen des DCs, halte ich für puren Unfug und davon solltest du auch die Finger lassen. Du musst auch noch darauf achten, dass die Clients den heruntergestuften DC nicht noch als DNS-Server erhalten. Das muss dann noch geändert werden.

Salut, du möchtest die Protokollierung erhöhen? Dann: Yusufs Directory Blog - Die Protokollierung des Active Directory`s konfigurieren

Servus, How to move a DHCP database from a computer that is running Windows Server 2003 to Windows Server 2008

Wie meinen? Ich hatte in meiner zweiten Antwort in diesem Thread empfohlen, im Falle eines Inplace-Update die Domänenaktualisierung mit einer VM durchzuführen. Ich behaupte aber, dass der Arbeitsaufwand bei einem Inplace Update geringer ist als bei einer Migration. Des Weiteren behaupte ich Felsenfest, dass bei einer Migration mehrere Steine im Weg stehen können als bei einem Inplace- Update. Logo, dass zweifelt ja auch keiner an. Also bei mir würde es der Kunde entscheiden. Ich würde ihm nur die Wege aufzeigen, mit all seinen Vor- und Nachteilen, doch letztenendes muss er sich zu einer Variante entscheiden. Müssen sie auch nicht. Dem OP sollen nur die Möglichkeiten aufgezeigt werden. Das ist doch bloß ein banales Beispiel. Ob noch alte Konten existieren wird sicherlich nicht das Entscheidungskriterium für den einen oder anderen Weg sein. Der Berater "berät" den Kunden. Entscheiden tut der Kunde.

Deine aufgezählten Punkte können vielleicht "hier und da" Probleme bereiten, aber das ist immer noch kein Grund ein Inplace-Update vom Tisch zu wischen und eine Migration anzustreben. Abgesehen davon kommt es sehr auf die Größe der Umgebung an. Auch dabei würde es auf den Fehler ankommen. Natürlich können Fehler nie ausgeschlossen werden, aber auch nicht vorher bestimmt werden das welche auftauchen. Wenn ein Fehler auftritt, muss dieser von Fall zu Fall bewertet werden. Naja, zumindest ist es denkbar das zumindest die Benutzerkonten von ausgeschiedenen Mitarbeitern und nicht mehr existierende Computerkonten zeitnah gelöscht werden. Das ist natürlich nur ein Part um die Domäneninformationen schlank zu halten. Natürlich! Aber an der Aussage das bei einem Inplace-Update der geringste Arbeitsaufwand entsteht gibt es nichts zu rütteln. ;) Probleme können beim Inplace-Update und bei einer Migration auftauchen, können aber bei beiden Varianten wie bereits erwähnt, nicht schon im Vorfeld prognostiziert werden. Das sehe ich ebenfalls anders. Es gilt nicht nur die technische Herausforderung zu beachten (salopp gesagt: das ADMT zu bedienen), sonden auch die organisatorische. Das Whitepaper zu ADMT sollte stets, wenn man sich zu einer Migration entschließt, durchgearbeitet werden. Das Whitepaper ist mehr als eine gute Hilfe, denn eine Migration mit ADMT durchzuführen ohne das Dokument gelesen zu haben würde glatt in die Hose gehen.

Servus, es ist so wie es die Kollegen hier bereits erwähnt haben. Im Gruppenobjekt und somit im AD wird diese Information, auf welches Verzeichnis das Gruppenkonto Zugriff hat, nicht gespeichert. Du müsstest die Verzeichnisse z.B. mit den folgenden Tools überprüfen: JSI Tip 9640. How do I print permissions on a folder tree using standard commands? FILEACL Main page SetACL - Windows permission management Showaccs Syntax: File and Storage Services How to use Xcacls.vbs to modify NTFS permissions Oder du exportierst mit CSVDE oder LDIFDE die Benutzer der jeweiligen Gruppen und entferst diese anschließend aus der Gruppe. Anschließend wartest du wer sich beschwert. Wenn es ein professionelles Werkzeug sein darf, dann würde hier sicher der Enterprise Security Reporter von ScriptLogic in Frage kommen.

Hi Franky goes to Hollywood (mit -14 Respekt! ;) ), das hört man oft, aber was wäre denn konkret der "alte Kram"? Denn wenn ein Administrator seinen Job halbwegs ernst nimmt und die Domäne wie es sich gehört administriert, sollten z.B. weder alte Benutzer- oder Computerkonten existieren. Wie ich bereits erwähnt hatte, vom Arbeitsaufwand her die "schnellste" Variante mit dem wenigsten Aufwand. Also das ADMT zu bedienen bekommt man sicherlich schnell in den Griff. Aber eine Migration als solches ist schon eine große Herausforderung.

Das Heraufstufen beider Modis lässt sich auch nur in der MMC "domain.msc" durchführen. ;) Yusufs Directory Blog - Domänen- und Gesamtstrukturfunktionsmodus

Salut, wenn du DCPROMO ausführst, wird der DC zum Mitgliedsserver heruntergestuft. Dadurch gehen weder die Freigaben noch andere Einstellungen verloren. Wenn das DNS installiert und die FLZ AD-integriert ist, wird das natürlich nicht mehr funktionieren.

Nicht dafür. ;) Tue das. Aber auch würde ich dir empfehlen das Inplace-Update für eure produktive Umgebung, ebenfalls mit einer VM durchzuführen. Denn so bekommst du keine Treiber/Hardware Probleme, da wahrscheinlich der NT-PDC nicht Windows 2003 tauglich sein wird. Deshalb installiere (sofern ihr euch für ein Inplace-Update entscheidet) in der produktiven Umgebung in einer VM einen NT-Server und füge diesen als BDC zur NT-Domäne hinzu. Anschließend stufst du diesen BDC zum PDC herauf und führst mit dieser VM das Inplace-Update auf Windows 2003 durch. Nach der Betriebssystemaktualisierung installierst du dann noch das AD.

Salut, das könnt ihr zwar tun, jedoch habt ihr damit die meiste Arbeit. Ihr müsstet dann mit z.B. ADMT die Benutzer- sowie Computerkonten von der NT-Domäne in die neue Windows 2003 Domäne migrieren. Die wenigste Arbeit hättet ihr, wenn ihr ein Inplace-Update der NT-Domäne auf Windows 2003 durchführen würdet. Ja, dass könnte man mit ADMT erledigen. Aber wenn ihr ein Inplace-Update durchführt, bleibt euch das erspart. Du musst natürlich vorher klären, ob die Applikationen Windows Server 2003 tauglich sind. Nein, dass funktioniert. Du musst nur die Dienste wie z.B. DHCP richtig konfigurieren. Das funktioniert, wenn man es richtig macht. ;)

Ahoi, so soo... Hast du denn irgendwelche Probleme? Warum sollte denn der DC aus DOM1 ein Verbindungsobjekt zu sich selbst haben? Du erstellst manuell ein Verbindungsobjekt von welchem DC zu welchem DC? Dann hat vielleicht der andere DC aus DOM2 das Verbindungsobjekt zu dem DC aus DOM1. Denn nicht jeder DC hat ein Verbindungsobjekt zu jedem anderen DC. OK. Erscheinen Fehler im Verzeichnisdienstprotokoll der DCs? Ja, der Anmeldedienst registriert die DNS-Einträge dann neu. Aber was hat das mit deinem o.g. Fall zu tun? Bisher scheint es mir so, dass alles im Lot ist. Diesen Satz übersetzt du mir bitte nochmal ins deutsche. Du kannst in meinem Fall sogar das in türkisch oder aber auch ins englische übresetzen. Wenn es verschiedene AD-Standorte sind, hat denn auch die standortübergreifende AD-Replikation stattgefunden? Falls es Probleme bei der AD-Replikation gibt, erfährst du das auch im Eventlog der DCs. Ich komme nach deiner Schilderung aber auch nicht viel weiter.