Daim

Ich habs geahnt. ;) Garantiert. Ja, gibt es. Die Datei nennt sich Adprep.log. Aber wenn ADPREP nicht oder "nicht sauber" durchgelaufen wäre, hätte man den Windows Server 2008 nicht als DC hinzufügen können. Der Fehler liegt definitiv NICHT am ADPREP. Das hat damit überhaupt nichts zu tun. Yusufs Directory Blog - Debug Protokollierung Nur durchhalten, wir sind ja bei dir. ;) Gernerell kannst du dich auch mal durch diese Seiten durchhangeln. Yusufs Directory Blog

Wie hast du das verifiziert? Wenn das ADPREP vorher in der Domäne nicht ausgeführt wurde, kann ein Windows Server 2008 nicht als DC zur bestehenden Domäne hinzugefügt werden. Auf dem Windows Server 2008 kann man dann nur seine eigene Domäne erstellen, quasi eine neue Gesamtstruktur. Nein. Entweder ADPREP wurde vorher ausgeführt und der Windows Server 2008 wurde als zusätzlicher DC zur bestehenden Domäne hinzugefügt oder mit dem neuen Server wurde eine neue/eigene Domäne erstellt. ADPREP kann jederzeit ausgeführt werden, es geht dabei nichts "kaputt". Der Assistent meldet dir dann, dass es evtl. bereits ausgeführt wurde. How to disable the Knowledge Consistency Checker inter-site topology generation for all sites

Hola, melde dich mit dem erstellten Benutzer an einem Client an, wo das Adminpak installiert ist. Falls es nirgends installiert ist, kannst du es von einem Windows Server 2003 aus dem Verzeichnis "%windir%\system32\adminpak.msi" installieren. Danach startest du die MMC "Active Directory-Benutzer und -Computer" und versuchst einen Kontakt in der OU zu erstellen. Kein Wunder, denn das Leserecht im AD haben bereits "Authentifizierte Benutzer".

Bei diesem Test wird überprüft, ob der Knowledge Consistency Checker (kurz, KCC) weitere DCs erreichen kann und seine Replikationsverbindungen zu erstellen. Das konnte er nicht. Das könnten Konnenktivitäts und/oder DNS-Probleme sein. Führe mit DCDIAG gezielte DNS-Tests durch. Die Hilfe zu dem Tool verrät dir wie das funktioniert. Diesen Fehler kann man vernachlässigen. Denn bei diesem Test schaut das DCDIAG ins Eventlog des DCs und überprüft ob in den letzten 60 Minuten Fehler im Log protokolliert wurden. Wenn der erste Fehler behoben ist, verschwindet auch diese Meldung.

Na, also sooo unverständlich habe ich es doch nicht geschrieben, oder? Zitat:

Hello, versuche es mal mit diesem Befehl (alles in einer Zeile): dsquery * domainroot -filter "(&(objectCategory=Person)(objectClass=User))" -attr sn givenname sAMAccountName memberof -Limit 9999 > C:\Dsquery.txt Du kannst auch weitere bzw. andere Attribute des Benutzerobjekts abfragen. Welche Attribute hinter den einzelnen Feldern im Benutzerkonto stecken, erfährst du z.B. auf der folgenden Seite: http://msdn.microsoft.com/en-us/library/ms677980(VS.85).aspx

Die Namen der FSMO-Rollen haben sich noch nie geändert und sind seit Windows 2000 immer gleichgeblieben. Die Namen haben sich auch zu Windows Server 2008 Zeiten nicht geändert.

You are welcome. :) Auja... noch ein Meenzer. Wir hatten gerade vor 10 Tagen im Malakoff-Park ein Boardtreffen veranstaltet. Das nächste Mal bist du dabei. ;)

Ahoi, nicht so förmlich... wir sind hier per "du". ;) Wie denn? Ein GC sollte immer und jederzeit existieren. Technisch gesehen, wird ein GC in einem "Single-Domänen Forest" für die Benutzeranmeldung nicht zwingend benötigt.

Bonjour, na von der zweiten R2-CD natürlich. ;) Da die DCs ohnehin auf R2 aktualisiert werden sollen, führe das ADPREP /FORESTPREP direkt von der zweiten R2-CD auf dem Windows 2000 Schemamaster aus. Danach führst du das ADPREP /DOMAINPREP /GPPREP auf dem Windows 2000 Infrastrukturmaster in der Domäne aus, in der du das Inplace-Upgrade durchführen möchtest. Wenn das ADPREP von der zweiten R2-CD ausgeführt wird, aktualisiert man das Schema auf die Version 31. Das Schema einer puren "Windows Server 2003" Domäne hat die Version 30. Wenn du das ADPREP gleich von der zweiten R2-CD ausführst, sparst du dir einen Schritt, in dem du eben das ADPREP /FORESTPREP nur einmal ausführen musst. Ansonsten ist das korrekt, würdest du nur die erste R2-CD installieren, würde das ADPREP von der ersten R2-CD reichen. Erst wenn du auf einem DC die zweite R2-CD installieren möchtest oder auf einem Memberserver die R2-Features nutzen wolltest, musst du vorher das ADPREP /FORESTPREP von der zweiten R2-CD ausführen. Wenn du ohnehin auf R2 aktualisieren willst, dann ist das korrekt. Führe ADPREP gleich von der zweiten R2-CD aus. Korrekt. Das Risiko ist dabei geringer. Bei einem Inplace-Upgrade kann eben mittendrin was schief gehen.

Servus, dü fügst im ersten Schritt die neuen Maschinen als "zusätzliche Domänencontroller der bereits bestehenden Domäne" hinzu. Dazu muss in den TCP/IP-Einstellungen der neuen Maschinen ein bereits existierender DNS-Server als primärer DNS-Server eingetragen werden. Es ist empfehlenswert auf jedem DC dann auch noch das DNS zu installieren. Dabei sollte die Forward Lookup Zone AD-integriert gespeichert sein. Danach regelt die AD-Replikation für dich den Rest. Im zweiten Schritt gilt es dann noch die Daten, Dienste sowie Verweise von den "alten" auf die neuen DCs zu übernehmen. Alles weitere entnimmst du bitte aus den folgenden sowie weiterführenden Links: Yusufs Directory Blog - Einen zusätzlichen DC in die Domäne hinzufügen Yusufs Directory Blog - Den einzigen Domänencontroller austauschen

Dann dürfte ja der Fehler nicht mehr auftauchen. ;) Installiere dir die Windows Support Tools und führe einen "Gesundheitscheck" des DCs mit DCDIAG sowie NetDIAG durch. Dann könntest du noch die AD-Replikation mit REPADMIN tiefergehender untersuchen. Yusufs Directory Blog - Troubleshooting mit REPADMIN Jedoch bin mich mir sicher, dass die Lösung in meiner vorherigen Antwort steckt. :) Nein. Kontrolliere erst mal den Zustand des DCs und überprüfe das Eventlog ob noch weitere Fehler erscheinen. Kontrolliere weiterhin das DNS, denn für eine ordnungsgemäße AD-Replikation ist ein funktionierendes DNS notwendig. Das kann schon möglich sein.

Buenas noches, was genau meinst du hier mit "ausfällt"? Wie lange ein DC "offline" (also ohne eine Verbindung zur Domäne) betrieben werden kann, ohne das der DC größere Probleme bekommt, bestimmt die Tombstone Lifetime (TSL). Wenn ein DC länger als die TSL keine Verbindung zu seinen Replikationspartner hat, kann er sich nicht mehr ordnungsgemäß replizieren und auf diesem entstehen "Lingering Objects" (zu deutsch, herumlungernde Objekte). Zwar kann man auch dann den DC zum replizieren bekommen, jedoch mit einem hohen Administrationsaufwand. Yusufs Directory Blog - Die Tombstone Lifetime Yusufs Directory Blog - Lingering Objects (veraltete Objekte) Im Idealfall, wenn der DC noch während der Tombstone Lifetime eingeschaltet wird, ja. Wenn der DC länger als die TSL keine Verbindung zu seinen Replikationspartnern und somit zur Domäne hatte, wäre die "schnellere" Variante, die gewaltsame Herabstufung des DCs mit DCPROMO /FORCEREMOVAL. Dieser Befehl muss dann ausgeführt werden, wenn der DC sich nicht mehr ordnungsgemäß mit seinen Replikationspartnern repliziert. Anschließend müssen dann noch die Metadaten des AD bereinigt werden. Yusufs Directory Blog - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen Wenn alle DCs nicht erreichbar sind, steht die Domäne nicht zur Verfügung. Falls alle DCs crashen sollten, existiert natürlich eine aktuelle und funktionierende System State Sicherung, mit der die DCs wiederhergestellt werden können. Starte zuerst den DC, den die anderen DCs in ihren TCP/IP-Einstellungen als primären DNS-Server eingetragen haben. Natürlich sollte wegen der Ausfallsicherheit auf allen DCs das DNS installiert und die Forward Lookup Zone AD-integriert gespeichert sein.

Bonjour, wenn du AD-Standorte erstellt haben solltest, dann sollte natürlich auch das entsprechende Subnetz erstellt und mit dem jeweiligen Standort verknüpft werden. Die DC-Icons sind dann entsprechend an ihren Standort zu verschieben. AD-Standorte müssen einer Standortverknüpfung angehören (im Container Inter-Site Transports - IP). Standardmäßig findet die AD-Replikation standortintern sowie standortübergreifend über "RPC over IP" statt. Dabei steht in den Verbindungsobjekten eines DCs zu seinen Replikationspartnern die sich innerhalb des gleichen Standorts befinden, im Feld Transport "RPC" und in den Verbindungsobjekten zu den standortübergreifenden Replikationspartnern steht dort "IP". Wobei wie bereits erwähnt, bei beiden Einstellungen immer über "RPC over IP" repliziert wird. Wenn alle Daten soweit in der MMC dssite.msc eingegeben wurden, baut der KCC die ideale (anhand der eingegebenen Informationen) Replikatiostopologie auf. Die "automatisch erstellten" Verbindungsobjekte werden dabei auch erstellt. Diese reichen bei einem ordnungsgemäßen Replikationsverhalten vollstens aus. Kontrolliere ob in den Verbindungsobjekten RPC bzw. IP im Feld Transport ausgewählt ist. Des Weiteren sollten Standortverknüpfungen unter "Inter-Site Transports - IP" und nicht unter "Inter-Site Transports - SMTP" eingetragen sei. Es sei denn, SMTP wäre explizit gewünscht. Kontrolliere auch noch, ob nicht ausversehen in den Eigenschaften des DC-Objekts in der MMC dssite.msc als Bridgeheadserver (bei standortübergreifender Replikation) explizit SMTP ausgewählt wurde. In der rechten Spalte unter "Server ist ein bevorzugter Bridgeheadserver für folgende Transporte" sollte entweder nichts oder IP hinzugefügt sein. Im Verbindungsobjekt. Die Domänenpartition wo sich die Benutzer-, Gruppen- sowie Computerkonten befinden, wird ohnehin nur innerhalb der eigenen Domäne repliziert. Die Schema-, Konfigurations- sowie Anwendungsverzeichnispartitionen (wie z.B. DomainDNSZones und ForestDNSZones) werden in der Gesamtstruktur repliziert (auch die Informationen für den GC). Das regelt aber alles das AD. Du musst hier nichts händisch noch einstellen. Wichtig ist eben, dass die Replikation läuft. Nein, denn wie wir jetzt wissen, werden Verzeichnispartitionen auch auf jeden DC in der Gesamtstruktur repliziert. Dann fehlt hier noch das Verbindungsobjekt auf dem DC im Ausland. Auf den anderen beiden DCs ist das soweit in Ordnung. Nun gilt es die Ursache für den DC im Ausland ausfindig zu machen. Gehe dazu meine bereits angemerkten Punkte durch. Wenn die Subdomäne gerade erst erstellt wurde, gibt dem ganzen noch etwas Zeit. Überprüfe auch das Eventlog des DCs im Ausland. Das allerwichtigste ist natürlich, dass das DNS funktioniert.

Servus, da es dir hauptsächlich um das einrichten einer Domäne geht, kannst du dazu dieses Buch verwenden. Active Directory - Das Praxisbuch für Windows Server 2008 von Thomas Joos erschienen bei Microsoft-Press

Servus, ansonsten sieht ein möglicher Befehl für CSVDE folgendermaßen aus: CSVDE -f Benutzer.csv -r "(&(objectClass=user)(objectCategory=person))" -l "DN,lastlogon" Danach bekommst du jeweils einen 64Bit Integer Wert als Zeitangabe angezeigt. Diesen kann man dann mit dem folgenden Befehl, in unsere Zeit umrechnen: w32tm /ntte <Wert>

Servus, schau dir in dem folgenden Artikel, den Abschnitt "Die maximale Gruppenzugehörigkeiten eines Sicherheitsprinzipals" an. Yusufs Directory Blog - Die Grenzen des Active Directory

Ja, ok, ist doch in Ordnung wenn es am Ende funktioniert. Viele Wege führen schließlich ans Ziel. ;)

Also wie bereits vor Jahren angekündigt...

Z.B. so: Gruppenrichtlinien - Übersicht, FAQ und Tutorials Genau.

Servus, ja. Es können aus Performancegründen 999 GPOs auf ein Objekt angewendet werden. Yusufs Directory Blog - Die Grenzen des Active Directory In den TCP/IP-Einstellungen steht auf dem Client ein interner DNS-Server drin und nicht etwa der Router? Naja.. Du könntest das USERENV Logging aktivieren. How to enable user environment debug logging in retail builds of Windows

Das war ich nicht. Du hast Norbert nur nicht verstanden. Wenn alle Daten sowie Dienste auf den neuen DC übernommen wurden, entfernst du den alten DC zuerst mit DCPROMO. Ggf. entfernst du den Server dann komplett aus der Domäne. Anschließend kannst du dem neuen DC, den Computernamen des alten DCs verpassen. Das ist nicht einfach zu beantworten. Das kommt auf die Situation darauf an. Beim bereinigen der Matadaten kann im Prinzip nichts schief laufen, wenn man es natürlich richtig macht und nicht ausversehen den falschen (also den neuen DC) löscht. Vorsichtig muss man dabei in jedemfall sein.

Hola, das liegt doch auf der Hand. Dann können die Benutzer die diesen Drucker installiert und als Standard-Drucker definiert haben, primär darauf nicht mehr drucken. Die Benutzer die den gelöschten Drucker als Standard-Drucker nutzen, merken das fehlen des Druckers sehr schnell. Alle anderen erst mit der Zeit.

Wenn ein DC crasht, kannst du auf diesem natürlich kein DCPROMO /FORCEREMOVAL mehr ausführen. In diesem Szenario müsste dann nur noch dieser DC aus den Metadaten des AD entfernt werden. Man führt das DCPROMO /FORCEREMOVAL nur dann aus, wenn der DC keine Verbindung zur Domäne hat oder etwaige Probleme bestehen, wo das normale ausführen von DCPROMO nicht von Erfolg gekrönt ist. Das FORCEREMOVAL führt man aber auch nur dann aus, wenn der Server nicht neu installiert werden soll.

Servus, es gibt doch bereits eine Gruppe die sich "DNSAdmins" nennt. Damit hat man Adminrechte auf den DNS-Serverdienst. Siehe auch: Microsoft Corporation