Daim

Dann überprüfe es doch... Dabei sollte ein Blick in die MMC "Active Directory-Benutzer und -Computer" reichen. OK, wenn du also auf beiden DCs in die DNS-MMC schaust, enthalten beide die gleichen Einträge. Na wer sagts denn... genau das ist dein Problem. Es fehlen der RID-Master und der Infrastrukturmaster. Installiere dir die Windows Support Tools und führe ein DCDIAG sowie NetDIAG aus und kontrolliere was dir noch an Fehler angezeigt werden. Überprüfe auch über die GUI, was bei den beiden fehlenden Rollen angezeigt wird. Ansonsten verschiebe diese beiden explizit mit "transfer" über NTDSUTIL erneut auf den anderen DC. Siehe auch: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben

Servus, hat denn bereits die AD-Replikation stattgefunden? Befindet sich die Forward Lookup Zone in AD und sind die DNS-Informationen ebenfalls auf den neuen DC repliziert worden? Hat der neue DC in seinen TCP/IP-Einstellungen den bereits bestehenden DNS-Server eingetragen? Ist der Träger der FSMO-Rollen online und von dem neuen DC aus erreichbar? Wer der Träger der FSMO-Rollen ist, bekommst du z.B. mit NETDOM aus den Windows Support Tools, dass du in dem Ordner "Support/Tools" auf der Windows Server 2003 findest, heraus. Der Befehl lautet: Netdom query fsmo.

Na klar tuen sie das. Wenn sie das nicht täten, hätte der SBS kein AD ;) .

@bestman007 Beachte in diesem Artikel insbesondere den SBS-Part: Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2

Servus, das kommt wie so oft daher, dass die eine Produktgruppe sich nicht ausreichend mit der anderen Produktgruppe unterhält.

Servus, es ist schon fast ein Gesetz, die GPMC auf der aktuellsten Admin-Workstation (XP oder Vista) zu installieren und von dort aus die GPOs zu bearbeiten. Die GPMC ist bei der Administration von GPOs Pflicht!

Servus, überprüfe dein Vorgehen nach diesem Artikel und versuche es anschließend erneut (Überschrift: Moving a Windows domain controller installation): How to move a Windows installation to different hardware

Warum das denn :confused: Lies dir meine erste Antwort erneut durch, denn so wie ich es beschrieben habe läuft es. Es ist lediglich darauf zu achten, dass die FLZ bereits AD-integriert gesspeichert ist. Dann brauchst du auf dem neuen DC nichts im DNS zu konfigurieren. Dein Hauptproblem ist das DNS. Läuft DNS nicht, dann läuft das AD nicht. Ich würde den DC erneut herunterstufen und es diesmal so machen, wie ich es hier in dem Artikel beschrieben habe: Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen Natürlich muss auch sichergestellt sein, dass zwischen den Standorten nichts geblockt wird und alle benötigten Ports offen sind. Yusuf`s Directory - Blog - Active Directory Replikation durch eine Firewall

Erstelle bei einer gespeicherten Abfrage eine "Benutzerdefinierte Suche". Dort kannst du dann im Reiter Erweitert deinen Filter angeben und diese Abfrage kannst du dann abspeichern. Lies dir mal diesen Artikel durch, dort habe ich es anhand gesperrten Benutzerkonten beschrieben (unter der Überschrift "Beispiel LDAP-Abfragen"): Yusuf`s Directory - Blog - Gespeicherte Abfragen

Buenos tardes, da es sich um einen weiteren DC handelt und deine bestehende Forward Lookup Zone hoffentlich AD-integriert gespeichert ist, musst du dich lediglich gedulden. Denn erst wenn die AD-Replikation stattgefunden und abgeschlossen wurde, befinden sich die DNS-Informationen anschließend auf dem neuen DC. Zu konfigurieren brauchst du auf dem neuen DC nichts weiter, als das in seinen TCP/IP-Einstellungen eben ein bestehender DC/DNS-Server eingetragen ist. Evtl. solltest du noch für die Aussenstelle im AD einen Standort samt Subnetz erstellen und den DC dorthin verschieben. Somit kannst du auf die Replikation Einfluss nehmen.

Servus, hast du die DCs mit DCDIAG (das sich in den Windows Support Tools befindet, auf der 2003er CD im Ordner Support/Tools) überprüft? Falls nicht, bitte durchführen. Insbesondere den DC der die Rolle des Infrastrukturmasters innehat würde ich genauer überprüfen. Auf welchen DCs dieser Domäne ist der GC aktiviert? Auf allen? Im DNS ist auch alles soweit in Ordnung? Schau dir dazu die Hilfe (Internet) zu DCDIAG an und führe diverse DNS-Tests durch. Des Weiteren solltest du natürlich die Eventlogs der DCs kontrollieren.

Hola, wie alles im Leben ist es immer einfach, wenn man weiß wie es geht ;) . Das geht mit beidem und unter anderem mit DSQUERY. Die Abfrage mit dsquery lautet: dsquery * domainroot -filter "(&(objectCategory=person)(objectClass=user)(!memberof=CN=GRUPPE,CN=Users,DC=DOMÄNE,DC=TLD))" -limit 1000 Der Filter für eine gespeicherte Abfrage wäre folgender: (&(objectCategory=person)(objectClass=user)(!memberof=CN=GRUPPE,CN=Users,DC=DOMÄNE,DC=TLD)) Du musst natürlich das "CN=GRUPPE.." durch den Gruppennamen deiner Gruppe ersetzen und wenn sich die Gruppe nicht im Standardcontainer USERS befinden sollte, so musst du dann noch das "CN=USERS" anpassen.

Buenos tardes, wenn möglich, solltest du auch die Gesamtstruktur auf den Gesamtstrukturfunktionsmodus "Windows Server 2003" stellen. Damit profitierst du z.B. von der verbesserten AD-Replikation. Siehe: Yusuf`s Directory - Blog - Die Linked Value Replikation (LVR) Ansonsten: Yusuf`s Directory - Blog - Domänen- und Gesamtstrukturfunktionsmodus

Wenn sich der Schaden als ein irreparabler "Defekt" darstellt, stufst du einen DC "mit Gewalt" herunter (DCPROMO /Forceremoval). Danach führst du auf dem anderen DC ein "non-authority Restore" durch und entfernst den anderen DC (der mit Gewalt heruntergestuft wurde), mit NTDSUTIL oder ADSIEdit aus dem AD. Zuletzt stufst du den anderen Server erneut zum DC. Wichtig ist wie immer, eine aktuelle und vorallem funktionierende System-State Sicherung zu besitzen.

Servus, siehe auch: Yusuf`s Directory - Blog - Welcher DC ist der Anmeldeserver ?

Moin, beachte die rote Schrift in diesem Artikel: Yusuf`s Directory - Blog - Dateizugriff überwachen

Servus, um welche Größe handelt es sich denn? Von wievielen Benutzer- sowie Computerkonten reden wir denn? Du kannst eben im ersten Schritt die Benutzer-, Gruppen- sowie Computerkonten in die neue Domäne migrieren und benennst dann im zweiten Schritt die Konten um. Der Zugriff auf das Profil ändert sich nicht und bleibt weiterhin bestehen. Lediglich der Profilordner wird nicht umbenannt, was ja auch nicht weiter tragisch ist. Genau daran hälst du dich am besten. Natürlich wäre es besser wenn sich die Benutzer nur an XP oder Vista Clients anmelden würden. Oder du siehst zu, dass es nur noch eine Sorte an Clients (Vista) gibt. Die Probleme sehe ich zwar auch, aber diese kann man lösen. Teste es vorher in einer Testumgebung aus.

So ist es. Der zweite kann die DB nicht öffnen.

Moin, ja, dass geht. Wenn eine Notes-Datenbank nicht auf dem Domino-Server gespeichert wird (z.B. auf einem Fileserver), ist der Zugriff auf eine Notes-DB lediglich einem Benutzer gestattet. Es können keine zwei Benutzer zeitgleich auf die gleiche DB zugreifen. Genau solch eine Meldung würde der zweite Benutzer, der versucht eine bereits geöffnete DB zu öffnen, erhalten.

Hmm... sicherlich gibt es dort ebenfalls Dritt-Anbieter Tools die man raussuchen müsste. Adhoc fällt mir dazu ein, es z.B. über ein Logonskript zu realisieren. Siehe: Yusuf`s Directory - Blog - Anmeldungen protokollieren

Moin, welche Meldung erhälst du, wenn du NETDOM QUERY DC eingibst? Werden dir die FSMO-Rollen in der GUI angezeigt? Falls ja, verschiebe die FSMO-Rollen auf einen anderen DC. Falls du keinen anderen DC haben solltest, installiere dir in einer VM einen weiteren DC und verschiebe auf diesen dann die Rollen. Ansonsten "seize" die Rollen mit Gewalt auf einen anderen DC. Dabei darf dann aber der Ursprungsträger der Rollen nie mehr online gehen. Das AD solltest du natürlich dann auch von den nicht mehr existierenden DCs bereinigen - wie bereits hier erwähnt - mit NTDSUTIL/Metadata cleanup.

Ja, dass Tool ist bekannt. Wenn du geschrieben hättest das es auch Dritt-Anbieter sein kann und evtl. auch noch etwas kosten darf, dann hätte man dich mit etlichen Tools nur so zugeschüttet. Z.B. gibt es jede Menge an AD-Tools aus dem Hause Quest, NetPro...usw.

Soll ich nun darauf antworten, dass du anscheinend meine Antwort nicht GENAU durchliest und ich mir meine Antwort hätte gleich sparen können oder soll ich schreiben, dass ich dir bereits dazu den passenden KB-Artikel gepostet habe wie man nicht mehr bestehende DCs aus dem AD entfernt? JA, mein Tipp ist: Lies dir meine erste Antwort und den geposteten Link durch. Denn es bringt nichts das du den DC nur aus "Standorte und Dienste" entfernst. Die DCs müssen ganz aus dem AD entfernt werden. Dann löst sich der Rest von alleine.

Aloha, du kannst auch mit DSQUERY die DCs einzeln abfragen und den Wert mit w32tm dann in unsere Zeiteinheit umrechnen. Die Abfrage würde so aussehen: dsquery * domainroot -filter "(&(objectCategory=Person)(objectClass=User)(sAMAccountName=*))" -attr samaccountname lastLogon -Limit 0 Umrechnen lässt sich der Wert wie folgt: w32tm /ntte <Wert>

Buenos dias, das stimmt. Um mit ADMT zu migieren, wird eine Vertrauensstellung und eine Namensauflösung benötigt. Wendet man aber "Trick 17" an, dann funktioniert die Migration mit ADMT aber auch ohne eine Vertrauensstellung. Dazu muss das Admin-Kennwort in beiden Domänen gleich lauten. Ich würde folgendes versuchen: Führe auf dem "scheinbar" gesunden DC das DCDIAG und NetDIAG aus den Windows Support Tools, das du auf der Windows Server 2003 CD im Verzeichnis Support/Tools findest, auf dem DC aus und überprüfe ob dir Fehler angezeigt werden. Falls das der Fall sein sollte, versuche diese zu fixen. Wenn die Fehler behoben werden können oder gar keine Fehler gemeldet werden, installiere eine VM und füge diese als zusätzlichen DC (samt DNS) zur Domäne hinzu. Wenn alles klappt hast du dann einen weiteren DC in der Domäne. Du könntest zwar auch den "veralteten" DC zum Leben erwecken (Stichwort: Lingering Objects [1]), aber ich denke mein aufgezeigter Weg ist der am Zielführendsten. [1] Yusuf`s Directory - Blog - Lingering Objects (veraltete Objekte)