Daim

Und außerdem kann ich mich nur wiederholen:

Servus, im Eventlog taucht also die EventID 1988 nicht mehr auf? Denn darin stehen normalerweise die herumlungernden Objekte. Diese könnte man dann mit ADSIEdit entfernen. Um zu überprüfen ob mehrere herumlungernde Objekte existieren, führe REPADMIN aus. Der Befehl lautet: REPADMIN /Removelingeringobjects /advisory_mode Anschließend könnten weiterhin 1988 EventIDs erscheinen, jedoch mit anderen herumlungernden Objekten. Dieser Vorgang muss so oft durchgeführt werden, bis alle herumlungernden Objekte eliminiert wurden. Zeigt ein REPADMIN /Showreps den Fehler 8606, ist das ebenfalls ein Indiz für herumlungernde Objekte. JSI Tip 7926. The Directory Services event log on your Windows 2000 domain controller records event ID 1083 during Active Directory replication? LDAP://Yusufs.Directory.Blog/ - Lingering Objects (veraltete Objekte) LDAP://Yusufs.Directory.Blog/ - Active Directory-Replikationskonflikt

Servus, 1. muss ich Necron zustimmen. Der Begriff "dringend" im Betreff ist hier nicht gern gesehen. Wenn es so dringend ist, rufst du entweder Microsoft oder einen Dienstleister an. 2. So lange seitens Microsoft keine Lösung präsentiert wurde, wende dich in erster Linie an den PSS. Aber eine Lösung kann auch sein, die dich nicht zufrieden stellt... 3. Die Zeit innerhalb einer Gesamtstruktur ist gerade in Bezug auf Kerberos elementar! Der DC der innerhalb einer Gesamtstruktur für die Zeit zuständig ist, ist der DC der die Rolle des PDC-Emulators innehat. Man kann den PDC-Emulator der Root-Domäne gegen eine externe Quelle (entweder aus dem Internet oder Hardware-Uhr) abgleichen lassen. Auf der Firewall müsste der Port 123 offen sein, wenn mit einer Quelle aus dem Inet abgeglichen werden soll. Der PDC-Emulator muss aber nicht seine Zeit mit einer "externen Quelle" abgleichen. Die tatsächliche Zeit ist nicht zwingend notwendig. Sie sollte nur innerhalb einer Gesamtstruktur synchron sein. Alle DCs holen sich ihre Zeit dann vom PDC-Emulator. Die Clients sowie Memberserver synchronisieren sich ihre Zeit mit ihrem Logon-Server, also dem DC bei dem sich der Client anmeldet/authentisiert. Wenn Du am w32time nichts gemacht hast, hast Du eine komplette Zeitsynchronisation. 4. Wie bereits erwähnt, wende dich weiterhin an den PSS und wenn dort nichts heraus kommt, können wir hier weiter unser Glück versuchen.

Servus, auhaa... Windows 2000 DC worauf SQL läuft. Erstens solltest du zusehen den Windows 2000 gegen eine neuere Version auszutauschen und zweitens ist es nicht empfohlen, SQL (genauso wenig wie Exchange) auf einem DC zu betreiben. Ein Server der einmal verseucht war, ist nicht mehr vertrauenswürdig! Du weiß nicht, was bereits angestellt wurde. Es ist schon zwingend, den Server und dann gleich mit neueren Serverversionen und das sogar auf verschiedenen Maschinen (DC und SQL) zu installieren. Da es der Haupt DC war, der ausgefallen ist und auf dem wir das Image aufgespielt haben, vermute ich das die Server jetzt nicht richtig syncron laufen. Aber an dem AD wurde mindestens 1 woche vor dem Absturz nichts verändert.... Das Imagen eines Datenbankbasierten Servers wie es ein DC, SQL oder Exchange darstellt, ist nicht supportet [1]. Es befinden sich noch weitere DCs in der Domäne? Dann hast du ein USN-Rollback geschaffen. Suche im Internet danach. Da DCDIAG die Meldung bringt "Der Quellserver nimmt zurzeit keine Replikationsanforderungen entgegen.", ist es ein Indiz dafür, dass das AD auf eine nicht unterstützte Variante wiederhergestellt wurde. Daher hat das AD die Replikation blockiert. Da der geimagte DC auch noch der FSMO-Rolleninhaber ist, könnte es sogar sein das es doppelte SIDs in der Domäne gibt. Du solltest also zwingend die Umgebung genauer inspizieren [2]. Oder wenn du nicht ganz Fit in dem Thema bist, holst du dir idealerweise einen externen Dienstleister. [1] LDAP://Yusufs.Directory.Blog/ - Images als Sicherung? [2] Schau dir den Link ganz unten an: LDAP://Yusufs.Directory.Blog/ - Der RID-Master und sein RID-Pool

Servus, @ Carsten Die Option "Benutzer muss Kennwort bei nächsten Anmeldung ändern" ist ein einzelnes Attribut. Der OP muss das Schreibrecht auf das Attribut pwdLastSet an die entsprechenden Benutzer (besser einer Gruppe) delegieren. @Mini 785 Du musst im Objektdelegierungsassistenten das Schreibrecht auf pwdLastSet erteilen. Mit dem Kommandozeilentool DSACLS, das sich bis einschließlich Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 on Bord ist, sieht der Befehl so aus: DSACLS <OU=die OU,DC=Domäne,DC=TLD /I:S /G Domäne.tld\<Gruppe>:RPWP;pwdLastSet;user LDAP://Yusufs.Directory.Blog/ - Objektdelegierungen einrichten LDAP://Yusufs.Directory.Blog/ - Die Active Directory-Attribute hinter den Feldnamen

Ohne die Umgebung zu kennen und ohne zu wissen was alles auf dem DC laufen wird, lehne ich mich weit aus dem Fenster und sage ja, die Hardware ist ausreichend. :cool:

Da die bestehenden DCs unter Windows Server 2003 R2 laufen, dürfte auch die Hardware dementsprechend älter sein. Du machst dir das Leben wesentlich leichter, wenn du 2008 R2 auf einer neuen Hardware installierst. Je nach Umgebung muss es sich dabei gar nicht um eine nagelneue Hardware handeln, es könnte auch eine bessere Client-Hardware sein. Das ist zwar unschön, wäre aber durchaus möglich wenn es sich um ein KMU handelt. Dein vorgeschlagener Weg würde zwar funktionieren, aber damit hast du letztenendes doppelte Arbeit. Du verschiebst die Dienste sowie Daten von DC1 auf DC2, wobei DC2 am Ende auch noch aktualisiert werden soll. Das ganze soll dann zurück auf DC1? Zu viel Aufwand. Was die CA anbetrifft, siehe: Move a CA to a Different Computer

Eben. Denn wenn der OP mehr Informationen über seine Umgebung gegeben hätte, wäre meine Antwort ausführlicher geworden. Und ausnahmsweise hatte ich diesmal nicht gleich von vornherein meine Munition verschossen.

Hola, welche genau? Das liegt höchstwahrscheinlich daran, dass z.B. der Domänen-Admin in einem geplanten Task, Backupjob oder ähnlichem hinterlegt wurde. Aktiviere dazu in der Default Domain Controllers Policy die folgende Richtlinie: Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Überwachungsrichtlinie\"Anmeldeversuche überwachen". In der Policy musst du die "fehlgeschlagenen" Anmeldeversuche protokollieren. Danach kontrollierst du das Sicherheitsprotokoll aller DCs.

Dann sage ich mal im Namen aller Helfer: Danke schön. So etwas hören wir gerne. :) Aber auch ich koche nur mit Wasser wie jeder andere auch (ich aber mit südländischem Wasser) und wenn du im wirklichen Leben tatsächlich mal ein Individuum triffst, gib mir bescheid. ;) Ich hatte nichts anderes erwartet! :cool:

WINS ist DNS für NetBIOS-Namen. Wenn du keinen WINS-Server hast, macht dein Rechner Broadcasts um NetBIOS-Namen aufzulösen. Du brauchst keinen WINS-Server, es ist aber empfehlenswert. Denn WINS muss "nur" installiert und an alle Computer verteilt werden. WINS verursacht i.d.R. im täglichen Betrieb keine weiteren Aufgaben im laufenden Betrieb.

Exakto Mundo. :cool:

Servus, die Netzwerkumgebung basiert auf NetBIOS - Namensauflösungen und fällt unter den Begriff des "Browsing". Diese baut sich über den Computersuchdienst sowie NetBIOS-Broadcasts auf. Daher muss z.B. für die Netzwerkumgebung das NetBIOS over TCP/IP in den erweiterten LAN - Einstellungen des Servers aktiviert sein. Ansonsten ist es auch heute noch empfehlenswert, unter Windows Server 2008 R2 einen WINS-Server einzusetzen.

Das Ausführen von ADPREP stuft keineswegs den Domänen- sowie Gesamtstrukturfunktionsmodus hoch. Richtig ist, mit ausführen von ADPREP änderst du die Schemaversion, aber wie bereits erwähnt, nicht den Modus. Siehe: LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus

Servus, aktiviere in der MMC "AD-Benutzer und -Computer" unter Ansicht die "Erweiterten Funktionen" und überprüfe ob der erwähnte Container tatsächlich zweimal vorhanden ist. Einer davon sollte mit "CNF" (für Conflict) gekennzeichnet sein. Wie ein Konflikt zustande kommen kann, erfährst du hier: LDAP://Yusufs.Directory.Blog/ - Active Directory-Replikationskonflikt

Servus, du erstellst dir in Excel eine Datei mit den Werten die du ins AD importieren möchtest und speicherst diese dann als CSV oder TXT Datei ab. Das sollte dir helfen: LDAP://Yusufs.Directory.Blog/ - Massenimporte- und -exporte mit CSVDE und der AD-PowerShell durchführen

Off-Topic: He Jungs... müsst ihr mir alles nachschreiben? :D

Servus, erzähl mal etwas mehr über deine Umgebung. Welche DNS-Server sind in den TCP/IP-Einstellungen des Exchange eingetragen? Befindet sich Exchange an einem AD-Standort wo sich auch ein DC (2003 oder 2008?) befindet, auf dem auch der GC aktiviert ist? Was spricht das Eventlog auf dem Exchange?

Wenn es keinen trifftigen Grund für mehrere Domänen in der Gesamtstruktur gibt, ist es stets empfehlenswert ein Single-Domain Forest zu wählen. Denn der Nachteil bei mehreren Domänen wäre: - Bei mehreren Domänen ist der adminstrative Aufwand Updates,Virenscanner usw.) höher, da auch jede Domäne zwei DCs haben sollte. - Dadurch entstehen höhere Hardware- sowie Lizenzkosten. - Jeder DC sollte/muss vor Ort physikalisch geschützt sein. - Jede Domäne muss gesichert werden (Backup). Die Vorteile bei mehreren Domänen wären, wenn man z.B. unterschiedliche DNS-Namensräume haben möchte. Oder unterschiedliche Administratoren sollen "nur" ihre eigene Domäne verwalten und nur dort der Admin sein. Der Vorteil einer Domäne wäre z.B. das man nur eine DNS-Zone/Domäne verwalten muss. Mit einer Domäne hat man eine bessere Übersicht und leichtere Administration. Ich persönlich tendiere gerne zu dem Ein-Domänen-Modell, aber das kommt immer auf die Gegebenheiten darauf an. Evtl. solltet ihr euch dazu einen Dienstleister zur Seite holen. Bei deinen bisherigen Informationen macht es kaum Sinn, eine zweite Domäne zu erstellen. Mit den bisherigen Infos reicht eine Domäne aus!

Salve, von der Domänenbenennung wird es nicht ganz klar. Handelt es sich um eine oder zwei Gesamtstrukturen? Wenn "DOM.Standort1" die Root-Domäne ist, kann "DOM.Standort2" keine Subdomäne sein. Ist es eine "eigene" Domänenstruktur, also ein eigener Tree? Weil das DNS "verkorkst" ist aktualisiert ihr auf Windows Server 2008? Und was macht Ihr wenn DHCP nicht funktioniert? Alles "abreißen" und neu aufbauen? Wäre es nicht sinnvoller erstmal die DNS-Probleme zu beheben. Denn für alle weiteren Schritte, sei es eine Domänenaktualisierung oder eine Migration ist das DNS wichtig. Alles neu aufsetzen? Welche Größe hat denn die Umgebung? Du möchtest wohl eine Migration in eine neue Domäne bzw. Gesamtstruktur durchführen. Zwei DCs ist die Mindestanzahl an DCs die eine Domäne haben sollte. Aber ein DC sollte nur dann vor Ort aufgestellt werden, wenn dieser physikalisch sicher steht. Ansonsten könnte man ab Windows 2008 RODCs einsetzen. Der RODC ist genau für dieses Szenario kreiert worden. Das ist gut und muss auch zwingend so sein, dass jeder AD-Standort sein eigenes Subnetz hat. Natürlich nur, wenn man mit mehreren AD-Standorten arbeiten möchte. Nein, DHCP wird nicht repliziert. Es wird in erster Linie das AD repliziert und wenn die Forward Lookup Zone im AD gespeichert wurde, was empfehlenswert ist, dann wird auch standardmäßig das DNS repliziert. Diese Antwort hatte ich heute hier schon einmal geschrieben. Daher ein "Copy&Paste" an dieser Stelle. Bei der Authentisierung eines Clients, ist das DNS und das Desgin im Snap-In "Active Directory-Standorte und -Dienste" entscheidend. Falls AD-Standorte eingerichtet sind, darf das erstellen der jeweiligen Subnetze und das verknüpfen an den entsprechenden AD-Standort 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 "seinen" DC an "seinem" AD-Standort findet, wird im folgenden Artikel erläutert: LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort ... to be continued

Salve, es ist elementar wichtig, dass der Administrator in der Builtin\Administratoren Gruppe Mitglied ist. Stelle das einmal sicher. Denn "Zugriff verweigert" oder "INSUFF_ACCESS_RIGHTS" ist eindeutig, es fehlen die entsprechenden Rechte. :cool:

Dann mal viel Spaß und vor allem viel Erfolg. :)

Servus, bei der Authentisierung eines Clients, ist das DNS und das Desgin im Snap-In "Active Directory-Standorte und -Dienste" entscheidend. Falls AD-Standorte eingerichtet sind, darf das erstellen der jeweiligen Subnetze und das verknüpfen an den entsprechenden AD-Standort 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 "seinen" DC an "seinem" AD-Standort findet, wird im folgenden Artikel erläutert: LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort

Salve, was die Domäne anbetrifft, führe auf mindestens zwei DCs eine System State Sicherung durch. Damit sicherst du deinen IST-Stand des ADs, noch vor der Schemaaktualisierung. Du sicherst auf min. zwei DCs deshalb das System State, um mindestens eine funktionierende System State Sicherung zu besitzen. Wenn im AD nicht gepfuscht wurde und alles "Standard" ist, gibt es auch bei der Schemaaktualisierung keine Probleme. Aber bevor du beginnst solltest du natürlich die Eventlogs der DCs kontrollieren und DCDIAG ausführen.

Servus, du kannst einen Windows 2000 DC nicht per Inplace Update auf Windows Server 2008 aktualisieren, was ohnehin nicht empfohlen ist. Du kannst aber einen zusätzlichen Windows Server 2008 DC (mit einer zusätzlichen Maschine) zur Domäne hinzufügen und so eine Domänenaktualisierung auf Windows Server 2008 durchführen. Sieh dir einfach den Link den morro gepostet hat an. ;) Vielleicht solltet ihr über einen Dienstleister nachdenken.