Daim

Salut, das geht nicht! Man kann kein Inplace Update von früheren Vollversionen auf den 2008 R2 Server Core durchführen. Erst der x64 2008 Server Core kann auf 2008 R2 Server Core per Inplace Update aktualisiert werden. LDAP://Yusufs.Directory.Blog/ - Windows Server 2008 Core Genau, entweder du verwendest eine Antwortdatei oder eines der Tools die im Internet kostenlos zur Verfügug stehen. LDAP://Yusufs.Directory.Blog/ - Tools zum konfigurieren des Server Core Schau hier ganz unten: LDAP://Yusufs.Directory.Blog/ - Windows Server 2008 Core Ja, am Ende des DCPROMO-Assistenten noch bevor das Heraufstufen beginnt, bekommst du eine Zusammenfassung über die getätigten Einstellungen gezeigt die du dann in eine TXT-Datei exportieren kannst. In dieser TXT siehst du dann, wie die Antwortdatei aussehen muss. Schau dir den Link an, dann weißt du es.

Servus, wenn du dir die Mühe zum aktualisieren der Treiber nicht machen möchtest, könntest du den DC virtualisieren und dann die VM auf Windows Server 2008 aktualisieren. Somit hättest du weniger Probleme mit den Treibern.

Entferne den Vollzugriff. Das ist quark. Versuche es doch einmal so wie ich es vorgeschlagen habe. Funktioniert es dann?

Salut, kannst du uns noch die Infos geben, was du bisher versucht hast? Du kannst z.B. im ADSIEdit die Sicherheitseinstellungen einer Verzeichnispartition aufrufen und dem Benutzer im unteren Bereich, die entsprechenden Replikationsberechtigungen erteilen.

Servus, ja, wenn du auch eine Domänenaktualisierung durchführen möchtest wie du es ja vor hast, führst du eine Schemaaktualisierung für die Domäne und für Exchange durch. Nein. Halte dich an den folgenden Artikel. Wenn du keine update.exe findest, verwende die setup.exe. How to completely remove Exchange 2000 or Exchange 2003 from Active Directory

Servus, eine Offlinedefragmentierung wird automatisch und sebstständig nie durchgeführt. Nur die Onlinedefragmentierung findet automatisch statt.

Dann verweise das Systemhaus an diesen Link von der Exchange Produktgruppe: http://www.mcseboard.de/ms-exchange-forum-80/w2k3-domain-w2k8r2-exch2003-exch2007-2-160535.html#post989511

Aha? Und was führt dich zu dieser Annahme? Denn: You Had Me At EHLO... : Updates to the Exchange Supportability Matrix

Salut, du kannst dein Ziel mit der Abfrage von "whencreated" erreichen, wie bereits von olc genannt. Der Filter den du benötigst um alle Objekte zu ermittelt die ab dem 01.01.2010 erstellt wurden, lautet "(&(objectCategory=person)(whenCreated>=20100101000000.0Z))" Mit CSVDE oder der AD-PowerShell kannst du einen Export in eine CSV-Datei durchführen und anschließend in Excel zur evtl. Weiterverarbeitung importieren. Siehe auch: LDAP://Yusufs.Directory.Blog/ - Erstellungsdatum eines Benutzerobjekts LDAP://Yusufs.Directory.Blog/ - Gespeicherte Abfragen

Ja, dass ist am Anfang vielleicht etwas verwirrend, ist aber so korrekt. :)

Bonjour, ich verstehe zwar nicht ganz deine Ausführungen, aber kontrolliere mal ob auf beiden DCs die beiden DNS-Anwendungsverzeichnispartitionen "DomainDNSZones" und "ForestDNSZones" existieren. Bist du dir sicher, dass die Quelle des EventIDs 1801 "ActiveDirectory_DomainService" ist und nicht "NTDS KCC"? Event ID 1801 Source NTDS KCC

Servus, der DC hat die ausgehende- und eingehende AD-Replikation deaktiviert. Die entscheidende Frage ist warum? Denn alleine und "einfach so" passiert das nicht. Auch nicht, wenn ein zweiter DC crasht. Erst wenn z.B. der DC zurück geimaget wird, kommt es vor das der DC die Replikation blockiert. Das solltest du auf den Grund gehen. Kontrolliere das Eventlog und führe DCDIAG durch. Nichtsdestotrotz kannst du die AD-Replikation folgendermaßen aktivieren. Installiere die Windows Support Tools auf dem DC und führe REPADMIN aus. Die eingehende AD-Replikation aktivierst du mit diesem Befehl: REPADMIN /Options -DISABLE_INBOUND_REPL Die ausgehende AD-Replikation aktivierst du dann mit diesem Befehl: REPADMIN /Options -DISABLE_OUTBOUND_REPL Aber überprüfe und versuche herauszufinden, warum die AD-Replikation deaktiviert war. Das manuelle deaktivieren vom Admin schließe ich mal aus.

Wie immer also. ;)

Das ist standardmäßig so. Denn in der Default Domain Controllers Policy ist die folgende Policy mit den Ereignissen "Erfolgreich/Fehlgeschlagen" aktiviert. Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Überwachungsrichtlinie\"Kontenverwaltung überwachen"

Servus, dürfen denn so viele Benutzer Objekte im AD erstellen? Nein, dass gibt es nicht. Wenn du die Eventlogs der DCs auswertest, halte nach der EventID 624 Ausschau. Denn standardmäßig wird das Erstellen eines Benutzers im Sicherheitsprotokoll auf dem DC der das Objekt erstellt hat protokolliert. Diese Information wird jedoch nicht zwischen den DCs repliziert. Du müsstest also alle DCs in der Domäne überprüfen. Du kannst höchstens in den erweiterten Sicherheitseinstellungen des Objekts überprüfen, wer der Besitzer des Objekts ist.

Das ist keine gute Idee. Besser ist es ab Windows Server 2003 lediglich ein Benutzerkonto im DHCP zu hinterlegen. Nur in ganz wenigen und speziellen Situationen ist es empfohlen, die Gruppe DNSUpdateProxy zu nutzen. Siehe: http://www.mcseboard.de/windows-forum-lan-wan-32/register-ptr-nur-unsicher-moeglich-132474.html#post812233

Servus, das könnten Konnektivitäts- oder DNS-Probleme sein. Kannst du denn vom DHCP-Server per IP und Namen den DC anpingen? Event ID 1059 ? DHCP Server Active Directory Availability

In der IT ist zwar alles möglich, aber das SMB-Signing hat mit deinem anderen Problem nichts zu tun. Korrekt. Vergleiche beide Container und entferne bei gleichem Inhalt, den CNF-Container. Führe vorher eine Sicherung durch!

Servus, zu Punkt 1: In der Default Domain Policy ist das SMB-Signing konfiguriert, was auch in Ordnung ist. LDAP://Yusufs.Directory.Blog/ - Zugriff auf die GPOs verweigert Zu Punkt 2: Der zweite Eintrag ist ein Konfliktobjekt. Das erkennst du an dem "CNF". Wie das Zustande kommen kann, erfährst du hier: LDAP://Yusufs.Directory.Blog/ - Active Directory-Replikationskonflikt Der Container "Microsoft Exchange System Objects" ist ein Systemcontainer, den zwingend Exchange benötigt. Dort verwaltet Exchange z.B. Mail enabled Public Folder etc.

Das hat zumindest auf das Verhalten einer Kennwortänderung keinen Bezug. Natürlich ist es stets ratsam, auf den höchstmöglichen Domänen- sowie Gesamtstrukturfunktionsmodus zu wechseln (sofern möglich), um von den Vorteilen die der neue Modus bietet zu profitieren. LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus

Servus, ja, das ist "per Design" so. Der Knowledge Consistency Checker (KCC), genauer ISTG, wählt an jedem AD-Standort einen Domänencontroller als Bridgeheadserver aus. Der GC spielt doch in deinem Fall keine Rolle! Ändert ein Benutzer sein Kennwort, repliziert der DC auf dem der Benutzer sein Kennwort geändert hat, umgehend das neue Kennwort zum DC der die FSMO-Rolle des PDC-Emulators innehat. Authentisiert sich der Benutzer danach an einem DC der das neue Kennwort noch nicht kennt, fragt der DC bevor er dem Benutzer die Anmeldung verweigert beim PDC-Emulator nach, ob ihm ein neueres Kennwort vorliegt. Falls ja, kann sich der Benutzer anmelden und falls nicht, schlägt die Anmeldung fehl. Der PDC-Emulator hat bei der Kennwortfrage das letzte Wort. Der DC "pusht" das neue Kennwort zum PDC-Emulator sogar dann, wenn der PDC-Emulator an einem anderen AD-Standort steht. Dabei greift der DC auch nicht auf die Bridgeheadserver an jedem AD-Standort zurück. Der DC auf dem das Kennwort geändert wurde, nutzt stattdessen eine RPC-Verbindung zum PDC-Emulator um das Kennwort zu aktualisieren. Der PDC-Emulator repliziert dann das neue Kennwort anschließend über das normale Replikationsverfahren an alle weiteren DCs. Ist allerdings der PDC-Emulator z.B. wegen Überlastung nicht erreichbar oder die RPC-Verbindung schlägt fehl, wird die Kennwortänderung ebenfalls über das normale Replikationsverfahren an alle DCs inklusive dem PDC-Emulator repliziert. http://technet.microsoft.com/en-us/library/cc772726(WS.10).aspx#w2k3tr_repup_how_huzs Aber die Frage ist viel eher: Warum authentisiert sich der Client an einem DC aus einem anderen AD-Standort? Das sollte zuerst geklärt werden. Denn der Client versucht sich standardmäßig "immer" an einem DC aus "seinem" AD-Standort anzumelden. Lies dir mal diesen Artikel durch: LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort

Das weiß ich alles. Lies dir nochmals den OP durch. Fallen nun die Schuppen von den Augen?

Salve, wie denn, wenn der Client keine Verbindung zur Domäne hat und somit das AD davon nichts mitbekommt, dass es den Client in der Domäne nicht mehr gibt. Das Computerkonto bleibt im AD bestehen und muss von Hand entfernt werden.

Servus, die Erläuterung ist nicht ganz korrekt. Ein DC der unter einem neueren OS läuft als der Modus konfiguriert ist, kann jederzeit Mitglied der Domäne sein. Anders ausgedrückt: Im Domänenfunktionsmodus "Windows Server 2003" können "Windows Server 2008" sowie Windows Server 2008 R2 DCs Mitglied sein. LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus

@ craine81 Was bezweckst du mit deinem Crosspost? ADSI Edit Filter setzen - administrator Dir wurden doch nun genügend Möglichkeiten genannt.