Daim

Totsicher! Zum Zeitpunkt als ich den Artikel verfasst hatte, habe ich wie immer das ganze nachgestellt. Das Umbenennen in der GUI konnte auch im "gemischten Modus" durchgeführt werden. Evtl. hat sich das im Laufe der Zeit geändert. Müsste ich noch verifizieren.

Servus, den Absatz den Carsten Zitiert ist, so wie er da steht vollkommen korrekt. Aber ich würde das Umbenennen eines DCs mit NETDOM empfehlen, denn damit wird das umbennen eines DCs auf eine "sanftere" Variante durchgeführt.

Off-Topic:Wenn sich jemand "erbarmt" und mir drei Tickets auf die Bahamas spendiert... herzlich gerne. Exchange rockt aber Sharepoint §$%&$§. ;)

Hi Wini, darauf habe ich aber auch schon in meiner ersten Antwort (siehe Link) hingewiesen. ;) :p

Servus, du solltest schon wissen auf welchem SP-Stand deine Server sind. ;) Jein. Zuerst muss das Exchange-Schema "korrigiert werden. LDAP://Yusufs.Directory.Blog/ - Das Active Directory Preparation Tool - ADPREP Zuerst musst du das Exchange-Schema korrigieren. Anschließend erweiterst du das AD-Schema. Wenn man es richtig macht, nur gute. ;)

Servus, http://www.microsoft.com/learning/en/us/certification/cert-overview.aspx#tab5

Salut, das könnte daran liegen, dass beim Versuch der Anmeldung der NETLOGON-Dienst noch nicht bereit ist. Funktioniert es denn wenn der Benutzer nach dem Starten etwas wartet bevor er sich anmeldet? Aktualisiere auch die Netzwerkkartentreiber. Ansonsten könntest du noch diese beiden Richtlinien aktivieren: LDAP://Yusufs.Directory.Blog/ - Asynchrones Startverhalten beim Windows XP Wie wurden die Clients installiert, per Hand oder geclonet bzw. geimaget? Wenn geclonet, wurde auch SYSPREP angewendet? Das deutet auf ein IP-/DNS-Problem hin. Wird der Client auch jedesmal heruntergefahren oder nur in Standby? Hier solltest du eine WINS-Replikation einrichten.

Das hättest du auch gleich mit aufschreiben können. :-/ Seit Windows Vista benötigt man die "Remote Server Administration Tools". Du siehst auch unter: "Remoteserver-Verwaltungstools\Rollenverwaltungstools\AD DS-/AD LDS-Tools\AD DS-Tools" nach?

Bonjour, das funktioniert mit dsquery aber auch: Dsquery server -forest (DCs werden mit ihren DNs angezeigt) Dsquery server -forest -o rdn (DCs werden mit ihrem RDN "Computernamen" angezeigt)

Servus, welche genau meinst du? Das AdminPak zufällig in dem die MMCs "Benutzer und -Computer", "Standorte und Dienste" etc. enthalten sind? Dann: http://www.microsoft.com/downloads/details.aspx?FamilyID=514bd06e-f3bc-4054-8429-c49f51e2190b&DisplayLang=en Du kannst das AdminPak auch von jedem Windows 2000 Server oder Windows Server 2003 aus dem Verzeichnis %windir%\system32\adminpak.msi installieren. Wenn du aber nur die AD-Snap-Ins (und nicht den Rest der Snap-Ins - DNS, DHCP etc.) installieren möchtest, so kannst Du es auf einem Windows 2000/XP Client auf folgende Art installieren: msiexec /i adminpak.msi ADDLOCAL=FeADTools /qb

Genau. Das Anmeldeverhalten ist gleich. Du kannst es doch simulieren. Einer der Benutzer soll den Router ausschalten.

In der MMC "Standorte und Dienste" oder wie? Mach davon mal einen Screenshot und lade es irgendwo im Internet hoch.

Also wenn in der Standortverknüpfung "DEFAULTIPSITELINK" und in "Ort1-Ort2" beide Standorte jeweils enthalten sind, ist das "doppelt-gemoppelt". Du kannst dann eine Verknüpfung entfernen. "ACS Container" heißt auf deutsch?

Vieles "müsste" sein. ;) Fordere dir den Hotfix und und installiere ihn. Wenn der Hotfix schon installiert wäre, würdest du bei der Installation eine Meldung erhalten.

Servus, nein. Das "DEFAULTIPSITELINK" ist doch eine Standortverknüpfung. Die AD-Standorte die in dieser Standortverknüpfung enthalten sind, replizieren miteinander. Ist dort nur ein AD-Standort enthalten, macht das keinen Sinn. Du kannst diese Standortverknüpfung auch löschen oder umbenennen. Das ist korrekt so. Das AD regelt die Replikationstopologie selbst korrekt. Die DCs innerhalb eines Standortes replizieren im Ring miteinander. Standortübergreifend (zwischen den Standorten) baut der KCC (genauer ISTG) einen spanning-tree auf. Wenn jeder DC mit jedem replizieren würde wäre zum einen ein "Full-Mesh" und wäre zum anderen nicht sinnvoll wie z.B. in weltweiten AD-Umgebungen. Ja, dass macht Sinn.

Nein, dass ist nicht möglich.

Salut, du irrst "etwas". Auch mit CSVDE können nur Konten ohne Kennwort erstellt werden. Weitere Alternativen wären "net user" und natürlich "VBSkript".

Servus, LDIFDE setzt Kennwörter NUR bei einer SSL-Verbindung. Man kann mit LDIFDE die Kennwörter nur von bestehenden Benutzern ändern. Wenn du also neue Benutzer samt Kennwörtern mit LDIFDE importieren möchtest, funktioniert das nicht. Du könntest im ersten Schritt die Kennwortrichtlinie in der Domäne deaktivieren. Damit erreichst du das die Benutzerkonten nach dem Import aktiviert und nicht deaktiviert sind. Somit werden die Benutzerkonten ohne Kennwort schon mal erstellt. Im zweiten Schritt könntest du dann mit einem erneuten Durchlauf mit LDIFDE die Kennwort setzen. Deaktivierst du vor dem Import nicht die Kennwortrichtlinie, musst du nach dem zweiten Schritt in der MMC "Benutzer und Computer" alle importierten Benutzer auswählen (das geht per Bulk-Auswahl oder wenn alle User in einer OU sind mit STRG+A) und aktivieren (nach der Auswahl der Konten Rechtklick und "Konto aktivieren" wählen).

Doch nicht ewig?

Servus, ein weiterer Fall wäre z.B.: Wird ein Mitarbeiter aus welchen Gründen auch immer mit sofortiger Wirkung freigestellt, sein Arbeitsverhältnis (z.B. bei einem Aufhebungsvertrag) jedoch erst in 6 Monaten endet, deaktiviert man in diesen Fällen ebenfalls das Benutzerkonto sofort und löscht es erst wenn das Arbeitsverhältnis offiziell beendet ist.

Genau dort. In der Standortverknüpfung definiert man an welchen Tagen und wie oft repliziert werden soll. Nein, dem ist nicht so, wie du es selbst erlebt hast. Das findet über die ganz normale standortübergreifende (Inter-Site) AD-Replikation statt. Es sei denn, man aktiviert die standortübergreifende Änderungsbenachrichtigung. Dann findet die AD-Replikation so statt, als wäre es ein AD-Standort. Das bedeutet aber auch, es wird öfters zwischen den AD-Standorten repliziert. LDAP://Yusufs.Directory.Blog/ - Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren

Servus, poste bitte die --> genaue <-- Fehlermeldung. Dazu musst du uns mehr erzählen. Stimmen denn die TCP/IP-Einstellungen auf dem Client? Ist als DNS-Server der DC eingetragen? Kann der Client den DC per IP und den Computernamen anpingen? I.d.R. so wie du es versuchst.

Servus, wie soll es anders sein als: Es kommt darauf an. ;) Genau. Entscheidender ist viel eher, ob ein voll geroutetes WAN besteht und jeder Standort direkt mit jedem anderen Standort kommunizieren kann oder ob eine "Hub-and-Spoke" Topologie existiert und jeder Standort nur über die Zentrale mit jedem anderen Standort kommunizieren kann. Das kommt auf die Gegebenheiten an. Existiert eine "Hub-and-Spoke" Topologie, könnte man je eine Standortverknüpfung alla "Standort <->Zentrale" erstellen. Hier würde sich eine Stern-Standortverknüpfungstopologie empfehlen. Man könnte dann noch die Standortverknüpfungsbrücke deaktivieren, denn dann hält sich die AD-Replikation explizit an deine vorgegebenen Standortverknüpfungen. Bleibt die Standortverknüpfungsbrücke aktiviert, erstellen die Standorte auch zu anderen Standorten Verbindungsobjekte. Wenn aber das VPN vom Standort zur Zentrale offline ist, nutzt die Standortverknüpfungsbrücke überhaupt nichts. Das ist unterschiedlich und kommt auf die Gegebenheiten an.

Servus, sollen sich die Benutzer auch an einem RODC anmelden können wenn keine VPN-Verbindung zu einem Standort mit beschreibbaren DCs existiert, so müssen die Benutzer- und Computerkennwörter auf den RODC repliziert werden, die sich an diesem anmelden sollen. Wenn sich nun ein Benutzer gegenüber einem RODC authentifizieren möchte, überprüft der RODC ob er das Kennwort des Benutzerkontos vorliegen hat. Falls das nicht der Fall ist, leitet er diese Anmelde-Anfrage an einen beschreibbaren DC weiter und erhält von diesem dann ein Kerberos-Ticket. Danach stellt der RODC dem Benutzer ein eigenes Kerberos-Ticket aus. Zeitgleich stellt der RODC eine Replikationsanforderung nach dem Kennwort des Benutzers (und Clients) an einen beschreibbaren DC. Der beschreibbare DC überprüft dann, ob der RODC dazu die Berechtigung hat und repliziert ggf. das Passwort-Hash zum RODC. Deine Benutzer werden sich sicherlich mit den "zwischengespeicherten Benutzerinformationen" anmelden. Daher das langsame Anmeldeverhalten. LDAP://Yusufs.Directory.Blog/ - Die Installation eines RODC

Servus handelt es sich auch um zwei AD-Standorte? Wenn ja, wie sind denn die Replikationszeiten an welchen Tagen konfiguriert? Da standardmäßig alle 180 Minuten (also 3 Stunden) standortübergreifend repliziert wird. Wenn es ein Problem mit der Replikation geben sollte, müssten Fehler im Verzeichnisdienstprotokoll protokolliert werden. Kontrolliere das einmal. Auch das DNS ist wichtig. Die EventID 13516 ist wichtig, erst dann ist der DC funktionsfähig. Von da her ist das soweit gut. Du kannst auch auf den DCs das DCDIAG ausführen und kontrollieren, ob Tests fehlschlagen. Zu Testzwecken kannst du auch die Replikation eines Objekts händisch mit REPADMIN anstoßen. Der Befehl dazu lautet: Replikation eines einzelnen Objekts anstoßen: REPADMIN /replsingleobj <FQDN Ziel DC> <FQDN Quell DC> "<DN des zu repliziernden Objekts>"