Daim

Wie überprüfst du das, dass sich die Clients nicht am RODC authentisieren? Hast du denn auch meinen letzten Absatz, aus meiner ersten Antwort sichergestellt?

Existieren in der Domäne neben dem RODC noch Windows Server 2003 DCs, dann muss auf den 2003er DCs noch das Compatibility Pack installiert werden. LDAP://Yusufs.Directory.Blog/ - RODC Compatibility Pack

Servus, das stimmt nicht! Ein Subnetz kann nur einem einzigen AD-Standort zugewiesen werden! Subnetz 1 ist in deinem Fall zwei AD-Standorten zugewiesen und das geht nicht. Vermutlich verwendet ihr Supernetting, also anstatt eines /24 ein /23 Subnetz. Mal prinzipielkl wie ein Client "seinen" DC findet: Bei der Authentifizierung eines Clients ist das DNS und das Design im Snap-In "Active Directory-Standorte und -Dienste" entscheidend. Falls AD-Standorte eingerichtet werden sollen, darf das erstellen der jeweiligen Subnetze und das verknüpfen an den entsprechenden Standorten nicht vergessen werden. Natürlich müssen dann noch die DC-Icons an ihre AD-Standorte, in der MMC "Active Directory-Standorte und -Dienste" verschoben werden. Die Vorgehensweise wie 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. Auf der Gegenseite geht der DC der die Anfrage eines Clients erhält wie folgt vor: - Der Domänencontroller reicht die Clientanfrage an seinen NETLOGON-Prozess durch, der dann die Client-IP in seiner Subnet to Site Mapping Table nachsieht und dann das treffende Standort-Objekt heraussucht. - Der Netlogon-Prozess des DCs übergibt an den DC die folgenden Infos: 1. Den Namen des Standorts, in der sich der befragte Domänencontroller befindet 2. Den Standortnamen, in dem sich der Client befindet 3. Ein Flag das angezeigt wird, wenn sich der angefragte DC im gleichen Standort befindet (Bit gesetzt) oder ob der DC ausserhalb des Standortes ist (Bit nicht gesetzt). Diese Informationen werden dann an den Client gesendet, der sich nun die Informationen näher anschaut: - Wenn sich der Domänencontroller an dem gleichen (oder nächstgelegenen) Standort befindet (gesetztes Bit), nimmt der Client bevorzugt diesen DC. - Wenn sich kein DC an dem Standort des Clients befindet, entscheidet das Design in der MMC "Standorte und Dienste", an welchem DC sich der Client authentifiziert. Er verwendet der einen Domänencontroller der am nächsten zu seinem Standort ist. Dabei ist z.B. die Einstellung der Verbindungskosten entscheidend. - Nachdem der Client einen Domänencontroller ermittelt hat, wird dieser Eintrag des DCs zwischengespeichert. Falls sich der DC nicht an dem Standort des Clients oder an einem optimalen Standort befinden sollte (Kosten), leert der Client nach 15 Minuten den Zwischenspeicher und verwirft somit den zwischengespeicherten DC. Der Client versucht dann einen nächstgelegenen DC, idealerweise an seinem eigenen Standort zu finden. LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort Was aber bei einem RODC sichergestellt werden muss, dass das Kennwort der Benutzer- UND -Computerkonten des RODC-Standorts zum RODC repliziert werden. Neben den Benutzerkennwörtern müssen auch die Computerkontokennwörter der Clients am RODC-Standort durch die Kennwortreplikationsrichtlinie (Password Replication Policy, kurz PRP) zum RODC repliziert werden, wenn der RODC eigenständig (wenn keine WAN-Verbindung zu einem beschreibbaren DC existiert) die Benutzer authentisieren soll. Denn auch Computerkonten müssen sich in der Domäne authentisieren. LDAP://Yusufs.Directory.Blog/ - Die Installation eines RODC

Servus, die Migration ist von seitens Microsoft der einzig supportete und vernünftige Weg! LDAP://Yusufs.Directory.Blog/ - Einen Domänensplitt durchführen

Servus, der Helpdesk vergisst also *immer* den Haken "Benutzer muss Kennwort bei der nächsten Anmeldung ändern" zu setzen? Oder fehlt dem Helpdesk lediglich das Recht den Haken zu setzen? Wenn der Helpdesk das ständig vergisst, müssen ernsthafte Gespräche mit den Helpdeskmitarbeitern geführt werden!

Servus, bitte trenn dich von der Begrifflichkeit "PDC und BDC". Seit der Einführung des Active Directory mit Windows 2000 gibt es nur noch DCs. In einer AD-Umgebung hat, im Gegensatz zu einer NT-Umgebung wo lediglich der PDC das Schreibrecht in die Security Account Manager (kurz SAM) Datanbank hatte, jeder DC das Schreibrecht. Da diese Konstellationen auch zu Problemen führen kann (wenn z.B. zwei DCs gleichzeitig das AD-Schema ändern) dürfen eben manche Änderungen nur von bestimmten DCs durchgeführt werden. Diese DCs sind die Träger der fünf FSMO-Rollen. Nichts, denn die Clients haben nichts mit den FSMO-Rollen zu tun. Deshalb können sich auch die weiterhin anmelden und arbeiten, wenn der Rolleninhaber mal nicht zur Verfügung steht bzw. gecrasht ist. Nein. Nein, kein Problem. Aber trag' doch den 2008er dazu. Nein, denn wie bereits erwähnt, dem Client sind die FSMO-Rollen völlig egal.

Microsoft hat das neue "Windows Server 2008 R2 Hyper-V Component Architecture" Poster mit Service Pack 1 veröffentlicht. Neben weiteren Postern ist es hier zu finden: LDAP://Yusufs.Directory.Blog/ - Die Active Directory-, Exchange- und Hyper-V Komponenten Poster

Servus, hast du auch *wirklich* die "Exchange Management Shell (EMS)" und nicht etwa die "Windows PowerShell" geöffnet?

Servus, technisch wäre das möglich, wenn sich die Domäne im Domänenfunktionsmodus "Windows Server 2003" befindet. Ist der Modus höher, kannst du den 2003er nicht mehr zum DC stufen, auch nicht mit einem "Hack"! LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus Erstmals kann der Domänen- sowie Gesamtstrukturfunktionsmodus unter gewissen Umständen sogar zurückgestuft werden, aber *nur* auf den Modus "Windows Server 2008: LDAP://Yusufs.Directory.Blog/ - Den Domänen- und Gesamtstrukturfunktionsmodus zurückstufen Ansonsten sollte ein DC wenn möglich, nichts anderes ausführen. LDAP://Yusufs.Directory.Blog/ - Warum es ein dedizierter DC sein sollte! Das ist doch mit "Kanonen auf Spatzen" geschossen. Warum nutzt du eine teure Enterprise-Lizenz für einen DC?

Guten Morgen Johannes. ;) http://www.mcseboard.de/tipps-links-5/windows-7-server-2008-r2-sp1-rtm-2-174555.html

Servus, gehe einmal diesen Hinweisen nach: System State Backup on Windows 2008 Und wenn du die Lösung danach immer noch nicht hast und es dringend ist, rufe die Microsoft Hotline (PSS) an!

Servus, ich würde es genau so empfehlen, wie du es in deiner Aufzählng erwähnt hast. Einen bestehenden DC kann man umbenennen, ich würde es aber wann immer möglich, vermeiden. Deine Aufzählung umgeht genau das Umbenennen eines DCs und deshalb würde ich dazu empfehlen. Denn das Umbenennen mit NETDOM ist zwar die weniger anfällige Variante (als über die GUI), trotzdem kann auch hier mal was nicht korrekt funktionieren.

Ja, meine Antwort gilt weiterhin! Die durchzuführenden AD Schritte sind die, die ich erwähnt habe.

Servus, wenn es sich um einen "reinen" DC handelt der keine weiteren Dienste oder Daten vorhält, so bist du wie bereits von Norbert vorgeschlagen, ohne einen Restore genauso effizient. Als erstes übernimmst du auf einem anderen DC die FSMO-Rollen (offline). Nach der "gewaltsamen" Übernahme der FSMO-Rollen, darf der ursprüngliche Rolleninhaber nie mehr online gehen! LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben Danach entfernst du den gecrashten DC aus den Metadaten des AD, damit dein AD keine Leiche enthält. LDAP://Yusufs.Directory.Blog/ - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen Anschließend stufst du einen weiteren Server zum DC. Denn schließlich müssen wegen der Ausfallsicherheit mindestens zwei DCs sich in der Domäne befinden.

Kleine Ursache -> große Wirkung. ;) Ja, dass stimmt. Die LDIFDE Meldungen könnten ruhig informativer sein. Aber wenn man einige Male einen Import mit LDIFDE durchgeführt hat, weiß man worauf es an kommt. Dito und danke für die Rückmeldung.

Einen Tippfehler hast du oben schon. Bei "April Stewart" hast du dich bei "userPrincipalName" verschrieben. Das "i" steht *vor* und nicht *nach* dem "c".

Also ich habe das so, auch ohne Bindestrich, erfolgreich in meiner VM importieren können: DN: CN=April Stewart,OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de changeType: add CN: April Stewart objectClass: user sAMAccountName: april.stewart userPrincipalName: april.stewart@ad2008R2.dikmenoglu.de givenName: April sn: Stewart displayname: Stewart, April mail: april.stewart@contoso.com description: Vertriebsbeauftragte in den USA title: Vertriebsbeauftragte department: Vertrieb company: Contoso, Ltd. DN: CN=Tony Krijnen,OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de changeType: add CN: Tony Krijnen objectClass: user sAMAccountName: tony.krijnen userPrincipalName: tony.krijnen@ad2008R2.dikmenoglu.de givenName: Tony sn: Krijnen displayname: Krijnen, Tony mail: tony.krijnen@contoso.com description: Vertriebsbeauftragter in den Niederlanden title: Vertriebsbeauftragter department: Vertrieb company: Contoso,Ltd. Mach dir mal die Mühe und erstelle eine Importdatei händisch (alles händisch eintippen) und kopiere nicht per Copy&Paste.

Die Leerzeile ist auch wichtig, aber die hattest du ja bereits zwischen den Einträgen. Ja, es handelt sich tatsählich um den Bindestrich und die Leerzeile darunter. Manche meinen, dass nach dem Bindestrich dann keine Leerzeile benötigt wird. Die ist aber so wie der Bindestrich --> zwingend!

Servus Johannes, Exchange 2003 wird in einem Windows Server 2008 R2 AD supportet. Exchange Server Supportability Matrix: Exchange 2010 SP1 Help "Go ahead" würden die US-Boys sagen. ;)

Servus, versuche es einmal so: DN: CN=April Stewart,OU=Personal,DC=contoso,DC=com changeType: add CN: April Stewart objectClass: user sAMAccountName: april.stewart userPrinicpalName: april.stewart@contoso.com givenName: April sn: Stewart displayname: Stewart, April mail: april.stewart@contoso.com description: Vertriebsbeauftragte in den USA title: Vertriebsbeauftragte department: Vertrieb company: Contoso, Ltd. - DN: CN=Tony Krijnen,OU=Personal,DC=contoso,DC=com changeType: add CN: Tony Krijnen objectClass: user sAMAccountName: tony.krijnen userPrincipalName: tony.krijnen@contoso.com givenName: Tony sn: Krijnen displayName: Krijnen, Tony mail: tony.krijnen@contoso.com description: Vertriebsbeauftragter in den Niederlanden title: Vertriebsbeauftragter department: Vertrieb company: Contoso,Ltd. Wichtig ist die Leerzeile nach "-".

Prima! Freut uns zu hören und danke für die Rückmeldung. Weiterhin viel Erfolg!

Servus, du willst doch nicht allen Ernstes einen Hotfix, den du von "irgend jemanden" erhälst, auf deine produktiven Server installieren? Und sei es noch so dringend, dass ist ein NO-GO! Nur ein Hotfix, das du direkt von Microsoft erhälst ist vertrauenswürdig.

Ich kann mich den Worten von Nils nur anschließen. Technisch gesehen sind zwei DCs mit der heutigen Hardware für die Anzahl der Clients ausreichend. Trotzdem würde ich ebenfalls, wenn möglich idealerweise an einem anderen Standort der den DCs physikalische Sicherheit bietet, min. zwei weitere DCs installieren.

Servus, wenn ausreichend Bandbreite zwischen den AD-Standorten existiert, könnte das eine Option sein: LDAP://Yusufs.Directory.Blog/ - Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren Das bedeutet jedoch, dass danach standortübergreifend genauso oft repliziert wird, wie standortintern.

Servus, das kommt auf die Größe der Umgebung an. Aber ich meine herauszuhören, das es sich bei dir um keine allzu große Umgebung handelt, wenn "lediglich" zwei DCs existieren. Wenn es sich um eine überschaubare Umgebung handelt, was dem Anschein nach bei dir der Fall ist, sollten sich alle FSMO-Rollen auf einem DC befinden. Das Trennen der Rollen ist dann nicht notwendig, da die Rollen in solchen Umgebungsgrößen nicht unter Last stehen. LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben