Daim

Huhuu, Off-Topic:Pff... du bist ja auch so viele Jahre älter als ich. Das bedeutet, du gehst viiiieeeeellll früher in Rente als ich und dann hole ich dich ein. :D

Servus, wenn im AD-Schema nicht "gepfuscht" wurde, ist das Ausführen von ADPREP eine sichere Angelegenheit. Das funktioniert dann ohne Probleme. Und wenn es doch zu Problemen kommen sollte, funktioniert am Ende die bestehende Umgebung weiterhin. Denn es werden lediglich an diversen Attributen sowie Klassen Änderungen vorgenommen und neue Attribute sowie Klassen werden hinzugefügt. Die Funktionalität ist auch bei einem fehlgeschlagenen ADPREP weiterhin gegeben. Auch wenn es fehlschlagen sollte, ist das kein Beinbruch und lässt sich beheben. Aber wie immer vor einer solchen Aktion, sollte die Basis kontrolliert (Eventlog, DCDIAG, Repadmin) und eine funktionierende System State Sicherung durchgeführt werden. So dramatisch ist das doch garnicht. Genau! Aber im Falle des ADPREPs hält sich das Risiko sehr in Grenzen. Nein, dass ist nicht möglich und es gibt auch kein "Trick 17". Wenn du deine Hausaufgaben machst, funktioniert das ohne Probleme. Viel Erfolg und du weißt ja wo du uns findest. :cool: P.S. ...und das ist mein 4.000 Post!

Man könnte es ja auf den UPN umstellen und die E-Mail Adresse dafür verwenden. Und hier wette ich: Seine Mail Adresse kennt jeder, denn heutzutage kann ja keiner mehr ohne E-Mail leben. :cool:

Genau, das Feld "Anmeldename" ist dann leer. Aber DAS fällt den Benutzern sicherlich eher auf. Klar ist, sie müssen dann wissen was ihr Anmeldename ist. Nein, es erscheint nichts.

Servus, siehe: LDAP://Yusufs.Directory.Blog/ - Alte oder deaktivierte Computerkonten mit der AD-PowerShell löschen LDAP://Yusufs.Directory.Blog/ - Computerkonto löschen

Ahoi, erstens würde man das bereits beim alleinigen ausführen von DCDIAG angezeigt bekommen und zweitens, sollte man nicht blind die AD-Replikation wieder aktivieren. Denn die AD-Replikation deaktiviert sich in solch einem Fall nicht aus "Spaß an der Freude". Es sollte vorher ein ausführliches Troubleshooting mit auswerten des Eventlogs erfolgen. Ein heißer Kandidat warum sich die AD-Replikation deaktiviert ist z.B. das rücksichern eines Images.

Servus, kontrolliere doch mal dein Vorgehen nach diesem Artikel: LDAP://Yusufs.Directory.Blog/ - Offline zur Domäne beitreten Evtl. fällt dir etwas auf, was du "anders" gemacht hast.

Salve, mit "Daten und Dienste" meine ich genau solch einen Fall. Aber gut das wir das verdeutlichen. Ja, wenn mehrere DCs in der Domäne existieren und sich auf dem DC "nur" die DC-Dienste befinden, sollte direkt DCPROMO ausgeführt und somit der DC zum Mitgliedsserver heruntergestuft werden. Genau, wobei es sich im Falle des OPs für mich so anhört, dass es sich bei ihm um eine überschaubare Umgebung handelt und somit sich das neu aufbauen der Replikationstopologie im Rahmen halten würde. Man muss zwangsläufig warten, denn sonst würde DCPROMO das einem melden.

Für mich hört sich der OP so an, als das er lediglich im Falle einer Migration nicht zu jedem Client gehen wollte um die Migration durchzuführen. Aber der OP wird hoffentlich wissen, was er meint und was er möchte. :cool:

Servus, wenn lediglich dein Ziel ist den "alten" DC auszutauschen, dann fügst du den neuen Server als zusätzlichen DC zur Domäne hinzu. Danach übernimmst du alle Daten und Dienste vom alten DC und schaltest diesen erstmal für ein paar Tage aus. Wenn dann noch alles funktioniert und nichts fehlt, schaltest du den DC wieder an und entfernst ihn mit DCPROMO aus der Domäne. Wie man einen Server als zusätzlichen DC zur Domäne hinzufügt, erfährst du hier: LDAP://Yusufs.Directory.Blog/ - Einen zusätzlichen DC in die Domäne hinzufügen An was du noch alles denken solltest, erfährst du hier: LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen Was denselben Domänennamen anbetrifft: Bevor eine Vertrauensstellung vom Local Security Authority (LSA) Prozess erstellt wird, prüft dieser die Eindeutigkeit folgender Auflistung: - Den NetBIOS Namen der Domäne - Den Fully Qualified Domain Name (FQDN) der Domäne - Die Security Identifier (SID) der Domäne Diese drei Punkte müssen eindeutig sein, da ansonsten keine Vertrauensstellung zu Stande kommt. Und wenn du doch mit ADMT in eine neue Domäne mit anderem Domänennamen migrieren solltest, musst du an den Clients - sofern du alles richtig geplant und durchgeführt hast - auch nichts machen. Aber die einfachste Variante mit der du am wenigsten zu tun hast und die am schnellsten durchgeführt ist, wenn du den neuen Server als zusätzlichen DC zur Domäne hinzufügst.

Servus, dann noch eine Korrektur zur Ergänzung von mir. Du wolltest Domänenfunktionsmodus schreiben, nicht wahr. ;)

Servus, was den GC und die Benutzeranmeldung anbetrifft, kommt es immer (wie so oft in der IT) auf die Umgebung an. Denn in einem Single-Domain Forest (eine einzige Domäne in der Gesamtstruktur), kann sich der Benutzer auch dann anmelden, wenn kein GC zur Verfügung steht. Eher ist dann der Fehler im DNS zu suchen oder wie es bei dir der Fall war, an der Firewall.

Nein, ist nicht normal. Lies nochmal, es ist genau umgekehrt. Der Haken bei DNS ist nicht gesetzt und man kann es auch nicht während dem DCPROMO-Vorgang setzen.

Servus, nein, ist nichts bekannt. Die AD-Replikation ist nicht "merkwürdig", sondern da steckt ein ausgeklügeltes System dahinter. Die AD-Replikation (genauer der KCC) erstellt anhand eines Ringentwurfs automatisch eine effiziente Replikationstopologie innerhalb eines Standortes (Intra-Site) und eine für die standortübergreifende Replikation (zwischen den Standorten – Inter-Site). Diese Ringtopologie versucht zwecks Fehlertoleranz mindestens zwei Verbindungen zu jedem Domänencontroller zu erstellen mit maximal 3 Hops zwischen den beliebigen DCs. Ein "Full Mesh" gehört also nicht dazu, dass also jeder DC mit jedem anderen repliziert. Gerade in größeren bzw. weltweiten Umgebungen wäre das eher negativ. Um so weniger der Administrator in das Geschehen der AD-Replikation eingreift, desto sicherer ist es, dass alles ordnungsgemäß funktioniert. :p Soll bedeuten, wenn du nicht "Hand anlegen" musst, überlasse alles dem AD. DCs werden nicht einfach abgeschaltet, sondern ordnungsgemäß mit DCPROMO heruntergestuft. Und nein, Probleme bekommst du damit keine.

Salve, cool, will ich auch haben. Wo gibt's das denn? Bevor du antwortest solltest du dich vergewissern, welche Version du tatsächlich einsetzt. Denn einen "Windows Server 2009" gibt es nicht!

Dann hast du etwas übersehen. Lies im folgenden Artikel (ganz unten) nach, wann welches Limit greift. Evtl. fällt es dir dann auf: MSXFAQ.DE - Beschränkungen

Bonjour, warum, wenn ohnehin keine Windows 2000 DCs existieren? Stufe den Domänenfunktionsmodus herauf. LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus Hier das gleiche. Stufe den Gesamtstrukturfunktionsmodus auf "Windows Server 2003". Hast du mal anhand dem Fehlercode der dir oben links angzeigt wird im Internet danach gesucht? Welche Rollen fehlen "angeblich" denn und welche sind verfügbar bzw. werden mit NETDOM QUERY FSMO angezeigt? Was genau meinst du mit "...wieder nicht Authentifizieren"? Und hast du den neuen Server mit dem gleichen Computernamen wie es der "alte DC 2" hatte zum DC gestuft? Wurde der "alte DC 2" aus den Metadaten des AD entfernt? Bitte formuliere klar und deutlich was bereits durchgeführt wurde und was nicht funktioniert. Dabei ist dir das Eventlog und DCDIAG behilflich. Gecrashte FSMO-Rollen werden mit Gewalt mit NTDSUTIL übernommen. Deine Vorgehensweise kannst du anhand des folgenden Artikels (ganz unten) überprüfen: LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben

Servus, kontrolliere die Werte der einzelnen Konnektoren inkl. der globalen Einstellung. Da liegt der Hase im Pfeffer begraben,

Servus, ich kann dir das Migrationswerkzeug von Quest ans Herz legen. Das kostet zwar ca. 13€ pro Benutzer (bei entsprechender Anzahl wirds günstiger), aber das Werkzeug ist sein Geld wert.

Zusätzlich zu der Antwort von Necron. Es ist keineswegs eine gute Idee ein Image von einem Server, der eine transaktionale Datenbank ausführt (DC, Exchange, SQL...) zu imagen. LDAP://Yusufs.Directory.Blog/ - Images als Sicherung? LDAP://Yusufs.Directory.Blog/ - Zwei wichtige IDs eines DCs: DC GUID und InvocationId

Nimm es mir nicht übel, aber wenn das der einzigste DC der Domäne ist und es sich dabei um eine produktive Umgebung handelt, solltest du dir umgehend Hilfe beiziehen. Denn für "Jugend forscht" ist eine produktive Umgebung kein geeigneter Ort (wobei viele Umgebungen keine produktive Umgebung haben ;))! Genau DAS ist doch das Problem. Der DC weiß nicht das er ein DC ist. Das kann an seiner AD-Datenbank, DNS und an vielem mehr liegen. Daher hole dir dringend einen Dienstleister der sich damit auskennt zur Seite.

Servus, ich hoffe du bist jemand der weiß was er tut und machst nicht deinem Nickname alle Ehre. ;) Der Fehler 1054 hat leider viele Ursachen. In den TCP/IP-Einstellungen wird sicherlich als erster DNS-Server der DC selbst stehen. Gehe auch mal die Kommentare auf EventID zu diesem Fehler durch und kontrolliere, ob etwas auf dein Szenario passt: Event ID 1054 Source Userenv Deshalb sollte man in jeder Domäne min. zwei DCs betreiben. Du wirst doch sicherlich eine System State Sicherung vom DC haben?

Dann stimmt aber generell "etwas" nicht. Denn für die Benutzeranmeldung werden die FSMO-Rollen nicht benötigt. Für die Benutezranmeldung reicht es aus, wenn ein DC auf dem das DNS läuft erreichbar ist. Ja, für das erstellen eines AD-Objekts wird eine RID benötigt. Doch jeder DC hat einen RID-Pool von 500 RIDs und wenn dieser (ab Windows 2000 SP4) zur Hälfte verbraucht wurde, ordert der DC vom RID-Master einen neuen RID-Pool von 500 RIDs an. Daher sollte ein DC auch wenn mal der RID-Master nicht erreichbar wäre, immer genügend RIDs zur Verfügung haben. Es sei denn natürlich, es findet ein Massenimport oder ähnliches statt. Dann ist es klar, dass wenn der RID-Master nicht erreichbar wäre das Erstellen der Objekte fehlschlägt. Siehe auch: LDAP://Yusufs.Directory.Blog/ - Der RID-Master und sein RID-Pool

Wohin hast du die Kennwortrichtlinie verlinkt? Auf eine OU? Die Benutzer melden sich auch sicher an der Domäne an? Also bei den Clients steht in der Anmeldemaske im Feld "Anmelden an:" die Domäe drin? Kann der Benutzer eigenständig sein Kennwort wechseln? Wie sieht das Eventlog des DCs aus?

Bonjour, naja, dass ist aber kein "muss".