Daim

Servus,

Weiß jemand um Inkompatibilitäten dieser Dienste?

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

Servus,

auch weiterhin betrifft die Funktionsebene der Domäne oder des Forest ausschließlich die Replikation der Domänencontroller

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

BEHRENS1 ist der alte Server, repadmin wurde vom neuen aus ausgefuehrt - den alten moechte ich ja nicht mehr haben !

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.

theoretisch kann ich den dann ja rausnehmen?

Wo "rausnehmen"?

Servus,

So wie es aussieht übernimmt er ja die ganzen Attribute beim Exportieren.

das kommt halt darauf an, was du in deinem Export-Befehl angibst.

Was zu Probleme beim Importieren führt, da es ja eine neue Gesamtstruktur ist mit einem anderem Namen und anderer OU Struktur.

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.

hatte entdeckt, dass der alte DC noch auf dem neuen als Globaler Katalog eingetragen ist, kann ich aus dem Active Directory Standorte SnapIn einfach den alten Server herausloeschen?

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.

Welche theoretische Gefahr besteht denn die Replikation über die Registryeinstellung mit "corrupten-Partnern" zu erlauben?

Das du "veraltete", nicht mehr existierende Objekte erneut im AD hast.

Kann ich vorab noch weitere Überprüfungen durchführen?

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,

2. ehemaligen DC aus der Domäne entfernen, damit Computerkonto usw. entfernt wird

dabei wird aber das Computerkonto nicht entfernt, sondern lediglich deaktiviert. Entfernen musst du es schon per Hand.

3. Neuen Server in Domäme aufnehmen (mit Namen und IP des Alten)

Werfe trotzdem nochmals einen Blick ins DNS und WINS.

Kann das funktionieren?

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,

Nach dem Befehl repadmin wird in der Ereignisanzeige Verzeichnisdienst kein neuer Eintrag erstellt. Kann man das ganze ein wenig gesprächiger machen.

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

Nur wurde der Upgrade PDC nicht empfohlen.

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.

Sicher ist eine Migration nicht auf die leichte Schulter zu nehmen. Genauso wenig sollte man denken, dass ein "einfaches" Inplace Update die Lösung aller Probleme ist.

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.

Mit guter Vorbereitung und wenn man sein System kennt, dann sind beide Wege möglich.

Logo, dass zweifelt ja auch keiner an.

Ich würde allerdings lieber die Migration machen als das Inplace Update.

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.

Und die angeführten Gegenargumente zu meiner Ausführung überzeugen mich nicht wirklich.

Müssen sie auch nicht. Dem OP sollen nur die Möglichkeiten aufgezeigt werden.

Und wenn man in der Realität guckt, dann werden so gut wie keine Konten deaktiviert oder sogar gelöscht. Glaub es mir einfach.

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.

ES kommt zu guter letzt immer auf den Admin/Berater an welcher Weg gegangen wird und jeder hat so seine Vorlieben.

Der Berater "berät" den Kunden. Entscheiden tut der Kunde.

Allein diese Punkte reichen aus, um ein Inplace zu vergessen.

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.

Hinterher hat man viel zu viele Baustellen, wenn man auf einen Fehler läuft.

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.

Die Systeme die immer sauber administriert werden gibt es leider nicht.

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.

Deswegen sollte man vernüftig planen und nicht mit wildem Aktionismus drüber installieren.

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.

Und so groß ist die Herausforderung auch nicht.

Das sehe ich ebenfalls anders. Es gilt nicht nur die technische Herausforderung zu beachten (salopp gesagt: das ADMT zu bedienen), sonden auch die organisatorische.

Der ADMT Guide ist eine gute Hilfe und wenn man das Szenario in der VM durchspielt, dann sollte es am produktiv System keine Probleme geben.

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! ;) ),

Bei einem Inplace Update schleppst du auch den ganzen "alten" Kram mit.

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.

Mach dir ein virtuelles Abbild deiner Umgebung und spiel die Migration durch. Du wirst sehen, dass es mit ADMT einfach geht, wenn man die Vorbereitung sauber durchführt.

Also das ADMT zu bedienen bekommt man sicherlich schnell in den Griff. Aber eine Migration als solches ist schon eine große Herausforderung.

Zuerst in "AD Benutzer und Computer" rechtsklick auf die Domäne und auf Domänenfunktionsebene heraufstufen.

 

Dann AD Domänen und Vertrauensstellungen aufmachen und auf selbiges einen Rechtsklick und hier die Gesamtstruktur heraufstufen.

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 dieser DC nun herabgestuft wird, gehen dann die Freigaben bzw. andere Einstellungen welchge auf dem DC sind verloren ? Danke im voraus.

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.

vielen Dank für deine Antworten

Nicht dafür. ;)

werde das jetzt erstmal in ner Virtuellen Maschine testen.

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,

Nun haben wir uns überlegt den W2K3 Server zu einem PDC zu machen und damit gleichzeitig eine neue Domäne einzurichten.

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.

Danach möchten wir die User des alten NT Server nach und nach in die neue Domäne umziehen lassen.

Ja, dass könnte man mit ADMT erledigen. Aber wenn ihr ein Inplace-Update durchführt, bleibt euch das erspart.

Kann es da zu Problemen kommen ?

Du musst natürlich vorher klären, ob die Applikationen Windows Server 2003 tauglich sind.

Bzw. kann es Probleme geben wenn zwei PDC's im gleichen IP-Netz arbeiten ?

Nein, dass funktioniert. Du musst nur die Dienste wie z.B. DHCP richtig konfigurieren.

Derzeit läuft im gleichen Netz noch ein Samba PDC Server und da hat es keinerlei Probleme gegeben, sollte doch eigentlich so funktionieren oder sehe ich das falsch ?

Das funktioniert, wenn man es richtig macht. ;)

Ahoi,

in meinem Standorte und Dienste Snap-in tauchen leider nicht ALLE verbindungen automatisch auf.

so soo...

Hast du denn irgendwelche Probleme?

bei dem DOM1 werden die 2 DCs der anderen domänen richtig automatisch generiert aber sich selbst setzt er dort nicht automatisch rein.

Warum sollte denn der DC aus DOM1 ein Verbindungsobjekt zu sich selbst haben?

Manuell kann ich aber die Verbindung hinzufügen.

Du erstellst manuell ein Verbindungsobjekt von welchem DC zu welchem DC?

bei DOM2 bekomm ich seine 2 DC´s automatisch generiert aber nicht den DC aus der anderen Domäne ( DOM1 ) wenn ich die dann manuell suche, finde ich diese nicht.

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.

nslookup und ping funktioniert soweit.

OK. Erscheinen Fehler im Verzeichnisdienstprotokoll der DCs?

Wenn ich aber den ordnerinhalt von _msdcs.**.*** lösche dann müsste er doch eigentlich die einträge neu erstellen wenn ich den netlogon dienst neustarte oder?

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.

auf dem DC in der DOM1 macht er das auch soweit aber diese domäne hat er auch als gesamtstruktur genommen.

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.

bei dem anderen bleibt der ordner leer.

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.

könnt ihr mir einen ansatz sagen wo ich da schauen könnte. ich komm da so langsam nicht mehr weiter

Ich komme nach deiner Schilderung aber auch nicht viel weiter.