Daim

Auf jeden Fall. Behalte das Eventlog der DCs im Auge. Danach überprüfe erneut jeden DC mit DCDIAG. You are welcome.

Dann löse erst das Problem mit der EventID 13568. Lies dir dazu den folgenden Artikel durch: LDAP://Yusufs.Directory.Blog/ - Dateireplikationsfehler mit der ID 13568 Anschließend schauen wir was übrig bleibt.

Servus, SYSVOL-Probleme sind "ecklige" Probleme. Dann kontrolliere mal das Dateireplikationsprotokoll und poste mal lediglich die EventIDs. Überprüfe ansonsten auch noch das DNS- sowie Verzeichnisdienstlog. Eine generelle Überprüfung der DCs solltest du auch mit DCDIAG (das sich in den Windows Support Tools befindet) durchführen.

Du meinst den Parameter "+IS_REDUNDANT_SERVER_TOPOLOGY_ENABLED". Ja den kenne ich. Du bist also der Meinung, damit hat man zwei BHS je AD-Standort pro Verzeichnispartition die gleichzeitig die AD-Replikation zwischen den AD-Standorten durchführen?

Nur damit es keine Missverständnisse gibt. Natürlich kann man händisch mehrere BHS definieren, aber die Arbeit eines BHS erledigt immer nur der ein und der selbe. Wenn aber der aktuelle BHS ausfällt, muss der KCC nicht lange nach einem geeigneten BHS suchen, sondern, er nimmt sich einen aus den händisch defenierten BHS.

Salut, so pauschal ist das nicht korrekt! Wenn es sich um einen Single-Domänen Forest handelt (eine einzige Domäne in der Gesamtstruktur), benötigt man keinen GC damit sich die Benutzer anmelden können.

Servus, der KCC läuft standardmäßig auf jedem DC alle 15 Minuten. Dabei überprüft dieser Prozess die Replikationstopologie innerhalb und zwischen den AD-Standorten. Bei etwaigen Änderungen (z.B. Veränderungen die in der MMC "Standorte und Dienste" durchgeführt wurden oder ein DC wird entfernt) passt der KCC die AD-Replikation und somit die Verbindungsobjekte an. KCC and Topology Generation Aber warum konfigurierst du manuell einen Bridgehead (BHS)? Du kannst zwar den DC bestimmen, der in jedem AD-Standort als BHS für die AD-Replikation zwischen den AD-Standorten deklariert wird, aber somit "pfuschst" du dem ISTG ins Handwerk. Idealerweise überlässt du die Auswahl eines BHS dem AD.

Buon giorno, ich steige mal mit ein in die Diskussion und fasse das ganze hier noch einmal zusammen: - Es wurde ein DC, nennen wir ihn DCON03, in der Vergangenheit ohne ihn mit DCPROMO herunterzustufen direkt neu installiert und mit dem gleichen Computernamen "DCON03" erneut zum DC gestuft. Die alten Einträge im AD blieben also erhalten. - Dieser hatte vermutlich(?) auch eine oder mehrere der FSMO-Rollen inne. Folgende Vorgehensweise solltest du durchführen: 1. Verschiebe alle FSMO-Rollen auf den z.B. DCON01. Wenn das Übertragen der Rollen online nicht möglich ist, verschiebe diese "mit Gewalt". LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben 2. Aktiviere auf jedem DC den GC. LDAP://Yusufs.Directory.Blog/ - Globaler Katalog (Global Catalog - GC) 3. Auf jedem DC sollte das DNS installiert und die Forward Lookup Zone sollte AD-integriert gespeichert sein. Auf DCON01 trägst du in den TCP/IP-Einstellungen den DCON02 als primären DNS-Server ein und sich selbst als zweiten. Auf DCON02 führst dud as gleich in umgekehrter Reihenfolge durch. Du trägst in den TCP/IP-Einstellungen auf DCON02 den DCON01 als ersten- und sich selbst als zweiten DNS-Server ein. Das ist die sogenannte Überkreuzeinstellung. LDAP://Yusufs.Directory.Blog/ - Welcher DNS-Server sollte eingetragen werden ? 4. Nun solltest du DCON03 mit DCPROMO herunterstufen. Falls das nicht möglich ist, installiere DCON03 neu und bereinige die Metadaten des AD. Dabei hälst du dich an diesen Artikel: LDAP://Yusufs.Directory.Blog/ - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen Wenn die Metadaten des DCs aus dem AD entfernt wurden, kannst du ihn mit dem gleichen Computernamen und mit der gleichen IP-Adresse erneut zum DC stufen, ohne das es zu Problemen kommt. 5. Anschließend stufst du DCON03 erneut mit DCPROMO als zusätzlichen DC zur Domäne. LDAP://Yusufs.Directory.Blog/ - Einen zusätzlichen DC in die Domäne hinzufügen Führe das soweit erstmal durch, dann sehen wir weiter. Dabei kann auch nichts "kaputt" gehen. Wenn die beiden anderen DCs ordnungsgemäß funktionieren, auf beiden das DNS installiert ist und beide DCs an die Clients als DNS-Server verteilt werden, ist ein reibungsloser Betrieb weiterhin möglich. Das kannst du ja auch vorher testen, in dem du den DCON03 einfach mal ausschaltest und schaust was passiert. Im Idealfall passiert einfach nichts und alles funktioniert in gewohnter Weise.

Servus, im ersten Schritt entfernst du alle DCs der Domäne "stuttgart.xyz.local" nach dem Artikel, den Zweckoptimist genannt hat. Im zweiten Schritt entfernst du dann die Subdomäne nach diesem Artikel: How to remove orphaned domains from Active Directory

Mit dem folgenden Befehl erhälst du eine Auflistung, wieviele Kontingente bereits verbraucht wurden: Dsget Partition „DC=Domäne,DC=DE“ -topobjowner 0

Servus, sieht dein Befehl so in etwa aus: dsget quota "CN=Hans,CN=NTDS Quotas,DC=Domäne,DC=DE" -acct -qlimit Falls nicht, schreibe was du erreichen möchtest und poste dein Befehl.

Servus, aber die Clients bekommen schon beide DCs als DNS-Server mitgeteilt? Die DCs haben sonst keine weiteren Probleme, sprich, im Eventlog von beiden DCs werden keine Fehler protokolliert (Verzeichnisdienst- und DNS-Log)? Das DCDIAG das sich in den Windows Support Tools befindet meldet keine Fehler? Einen Timeout gibt es so in der Art nicht. Bei einem langsamen Anmeldeverhalten handelt es sich zu 99% um ein DNS-Problem. Abgesehen davon sollten sich in den meisten AD-Umgebungen alle FSMO-Rollen auf einem DC befinden und auf allen DCs sollte der GC aktiviert sein. Siehe auch: LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben

Servus, du musst halt alle Daten sowie Dienste auf den neuen DC verschieben. Dabei kannst du dich an den folgenden und die darin verlinkten Artikel halten: LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen

Servus, es befinden sich also mehrere Netzwerkkarten im Server. Damit nun lediglich nur eine IP-Adresse im DNS registriert wird, muss im ersten Schritt, im DNS-Reiter der IP-Konfiguration der einen LAN-Verbindung, die dynamische Registrierung der IP abgeschaltet werden. Im zweiten Schritt muss in den Eigenschaften des DNS-Servers, das Abhören des Dienstes an der einen IP-Adresse verhindert werden. Denn ein DNS-Server registriert sich auch die IP-Adressen, an denen er abhört.

Servus, ja, sogar ganz einfache: LDAP://Yusufs.Directory.Blog/ - Wie stellt man sicher, dass ein Benutzer sich nur an einem Client anmelden kann?

Der ESXi hat kein darunterliegendes Windows Betriebssystem.

Bonjour, du meinst wohl, dass du in "Standorte und -Dienste" auf dem 2003er DC den globalen Katalog aktiviert hast. LDAP://Yusufs.Directory.Blog/ - Globaler Katalog (Global Catalog - GC) Du solltest noch die FSMO-Rollen auf den neuen DC verschieben: LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben Alle Dienste (evtl. Netzwerkapplikationen) die sonst noch auf dem DC laufen, müssen auf den neuen DC verschoben werden. Weiterhin verschiebe die Daten sowie Drucker auf den neuen DC und konfiguriere ggf. das LoginSkript dementsprechend. Siehe auch: LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen Na alles von dem 2000er DC zu übernehmen, damit der Betrieb weiterhin gewährleistet ist. Wenn du der Meinung bist das alles übernommen wurde, kannst du ja den "alten" DC für eine Woche ausschalten und wenn keiner der Benutzer schreit, schaltest du den DC wieder an und stuft diesen mit DCPROMO zum Mitgliedsserver herunter. Dann versuche es doch einmal mit dem "echten" Domänen-Administrator und kontrolliere ob es erneut auftritt. Ansonsten kontrolliere das DNS und werfe einen Blick ins Eventlog. Je nachdem wie intelligent diese Geräte sind, kann es hierbei zu Problemen bei der Authentifizierung am AD kommen (wie es bei dir der Fall ist). Für solche Fälle kann man das "abgespeckte" AD Namens ADAM bzw. AD LDS verwenden. Siehe auch: faq-o-matic.net Adam und Eva

Servus, mit "Update Schema now" werden lediglich die Schema-Informationen aus dem AD auf dem Server in den Cache geladen. Das ist ja gerade das "gefährliche" an ADSIEdit. Jede durchgeführte Änderung ist direkt aktiv. Daher muss man während dem Arbeiten mit ADSIEdit sehr vorsichtig sein.

Wie bitte? Schlimm soll IBM sein? Nie und nimmer. Das Wort das auf IBM zutrifft muss noch erfunden werden, aber "schlimm" ist definitiv zu milde ausgedrückt.

Servus, das kann man schon, nur wandelt sich dann der SBS zu einem "Fahrstuhl-SBS" und fährt alle 60 Minuten "rauf und runter". LDAP://Yusufs.Directory.Blog/ - Die Besonderheiten eines Small Business Server`s (SBS)

Aber nur mit einer Windows Server 2008 Lizenz ist es nicht getan. Dann kommen noch CALs für 2008 hinzu.

OK, dass würde ich auch nie anzweifeln. ;) Das Attribut mS-DS-CreatorSID ist ein "system only" Attribut. Du hast die Möglichkeiten die ich in meiner vorherigen Antwort geschrieben habe. Wie gesagt, es ist "system only" und ein händisches bearbeiten ist nicht möglich.

Nicht mehr so wie du es erlebt hattest. Dann kommt es eben auf die VPN-Verbindung zu dem Standort an, wie die Performance ist. Aber keineswegs dauert es dann erneut 20 Minuten. Das geht definitiv schneller.

Servus, das Verhalten kenne ich. Aber zuerst, man darf eben nicht alle DCs einer Domäne gleichzeitig ausschalten. Das macht man einfach nicht. Wenn es aber aus Wartungsgründen sein muss, sollte man in den TCP/IP-Einstellungen der DCs einen anderen DC der evtl. an einem anderen AD-Standort steht und der das DNS installiert hat, als primären DNS-Server eintragen. Falls kein weiterer zur Verfügung steht und tatsächlich alle DCs der Domäne heruntergefahren werden müssen, musst du mit diesem Verhalten leben.

Servus, so garnicht. Ich zitiere aus dem folgenden Artikel: LDAP://Yusufs.Directory.Blog/ - Clients in die Domäne hinzufügen Dann lies dir den o.g. Artikel durch und --> delegiere <-- dem Benutzer das Recht, Clients zur Domäne hinzuzufügen. Das funktioniert so nicht. Entweder du veränderst den Wert "10" für alle oder du delegierst ihm das Recht dann so lange, bis er sein soll erfüllt hat und entfernst ihm das Recht wieder. Existieren Clients die der Benutzer damals zur Domäne hinzugefügt hat nicht mehr in der Domäne aber das Computerkonto im AD schon, kann der Benutzer nach dem Entfernen des Computerkontos einen weiteren Client zur Domäne hinzufügen.