Daim

Servus, hmm... ich interpretiere "Inter-Site Verbindungen" als standortübergreifende Verbindungsobjekte und nicht als Site-Links, also Standortverknüpfungen. Sind Standortverknüpfungen gemeint, sehe ich das auch anders. Oder man deaktiviert umständlich und je nach Anzahl an DCs an dem Standort, mit REPADMIN die Replikation. Das muss man doch immer. Und nicht alles was möglich ist, ist sinnvoll. ;) Genau, wenn man Einfluss auf die Replikation haben möchte, ist man natürlich mit mehreren Standortverknüpfungen bessser bedient. Also mit den bisherigen Angaben schon, aber ich bin mir gar nicht sicher ob der OP soweit und an die vielen "es kommt darauf an" gedacht hat, wie wir es hier gerade tun. :cool:

Von hier aus würde ich behaupten, lass die Finger davon. Um so weniger der Admin in die Belange des AD eingreift, desto sicherer ist es das alles funktioniert. ;) Warum solltest du noch händische, für die dann DU zuständig bist und nicht das AD erstellen? Es gibt doch überhaupt kein Grund dazu. Es sei denn, du siehst irgendeine Anforderung als nicht erfüllt. Denn wie ich es bereits geschrieben hatte, wenn etwas im Argen liegen sollte, dann ist "Karneval in Rio" im Eventlog.

Salve, ja, aber nur wenn beim installieren der Domäne, also beim installieren des ersten DCs die Vorraussetzungen erfüllt werden. Ich kann es gerade nicht prüfen, aber schau doch mal in die DFS-Managementkonsole.

Servus, wenn du keine Hand angelegt hast, ist das normal und korrekt so. Denn die AD-Replikation (genauer der KCC) erstellt anhand eines Ringentwurfs automatisch eine effiziente Replikationstopologie innerhalb eines Standortes (Intra-Site) und eine für die standortübergreifende Replikation (zwischen den Standorten – Inter-Site). Diese Ringtopologie versucht zwecks Fehlertoleranz mindestens zwei Verbindungen zu jedem Domänencontroller zu erstellen mit maximal 3 Hops zwischen den beliebigen DCs. Ein "Full Mesh" gehört also nicht dazu, dass also jeder DC mit jedem anderen repliziert. Gerade in größeren bzw. weltweiten Umgebungen wäre das eher negativ. Behalte das Eventlog im Auge. Wenn etwas im Argen liegen sollte, meldet dir das schon das Eventlog.

Also dann... dann... setzen, sechs! ;) Ja, auf alle Fälle ist ein komplexes Kennwort natürlich vorzuziehen. Aber wenn das Konto wirklich überall im Einsatz sein sollte, ist unser Wunsch mit dem komplexen Kennwort sicherlich auch eher schwierig. ;)

Wenn du dir den Link aus meiner ersten Antwort durchgelesen hast, weißt du ja jetzt bescheid. ;) Warum sollte es denn so sein? Der eine Admin konfiguriert es auf diese Weise und der andere Admin auf jene. Fakt ist, jeder der mit GPOs zu tun hat, sollte natürlich wie überall sein Handwerk verstehen und die Werkzeuge bedienen können. Demjenigen der "Jugend forscht" betreibt, kann man ohnehin nicht helfen. ;) Wenn du das eben einmal verinnerlicht hast, ist es dir egal ob die Kennwortvorgaben unter den Benutzer- oder Computerkonfigurationen eingestellt werden. Du willst doch nicht allen Ernstes das wichtigste Konto der Domäne, den Domänen-Admin aus der Kennwortrichtlinie nehmen? Solltest du aber. :p Wenn nicht, schau dir halt die Kontooption "Kennwort läuft nie ab" genauer an.

Servus, kannst du das noch bitte weiter erläutern? Wo hast du eine Weiterleitung auf externe(?) DNS-Server eingerichtet?

Servus, nicht "nur". Du könntest die Kennwotvorgaben zwar auch in einer eigenen Richtlinie konfigurieren, doch es ist empfehlenswert diese in der DDP zu konfigurieren. Dann nämlich ist es egal, ob du die Kennwortvorgaben in der Richtlinie oder direkt in den Attributen vornimmst. Wenn du Windows Server 2008 (und höher) im Einsatz hast, kannst du mit Bordmittel PSOs in Verbindung mit Schattengruppen auf OUs einsetzen. LDAP://Yusufs.Directory.Blog/ - Password Setting Objects erstellen und verwalten Hast du denn überhaupt eine Kennwortrichtlinie im Einsatz? Wenn ja, in einer eigenen Richtlinie?

Servus, du suchst ADMT, mit dem du die Computerkonten in die neue Domäne migrieren kannst.

OK, aber ob die Anzahl an DCs gerechtfertigt ist, können wir von hier aus nicht beurteilen. Trotzdem sagt mir mein südländisches Gefühl das mich selten trügt, dass es hier Potential zur Optimierung gibt. ;) Die Benutzer an den Standorten können sich auch an entfernten DCs über das VPN authentisieren. Aber jetzt wo du auf min. Windows Server 2008 aktualisieren möchtest, ist der RODC sicherlich eine Option. Ist das VPN *wirklich* so oft zum Zeitpunkt der *Benutzerauthentisierung* down? Wohl kaum...

Bonjour, wenn die bestehende Hardware noch vertrauensvoll funktioniert, können die ja auch noch weiter betrieben werden. Nicht jedes Unternehmen kann sich den Luxus leisten und nach drei Jahren nach dem die Hardware abgeschrieben wurde, die Maschinen komplett ersetzen. Du schreibst "Migration", aber wahrscheinlich willst du die bestehende Domäne behalten und "lediglich" die bestehende Domäne auf Windows Server 2008/R2 aktualisieren. Dann würdest du nämlich eine Domänenaktualisierung und keine Migration durchführen. Wie wäre es damit: LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen Erstmal nichts. Du könntest dann "nur" nicht von den Vorteilen profitieren, die dir der höhere Domänen- bzw. Gesamtstrukturfunktionsmodus bietet (z.B. AD-Papierkorb). Dann würde ein Inplace Update infrage kommen. Empfohlen ist es jedoch, die Domänenaktualisierung mit einer "anderen" Maschine/VM durchzuführen. Schau dir meine o.g. Links an. Du könntest z.B. mit einem kostenlosen P2V Konverter eins-zwei Server virtualisieren und mit diesen in einer abgeschotteten Testumgebung die Domänenaktualisierung durchführen. Du solltest darauf achten, dass nach der Aktualisierung das Eventlog sauber ist und DCDIAG keine Fehler meldet.

Servus, das gibt es auch nicht "out of the Box". Nein. Suche mit der Suchmaschine deiner Wahl nach "Server undelete".

Norbert wollte nur darauf hinweisen, vernünftige Hardware die angebracht ausgestattet ist zu verwenden. :) Nicht das deine DCs 128MB RAM haben. ;) (deshalb der Smiley von Norbert)

Sorry das meine Glaskugel versagt hat und mir nicht mitteilen konnte, was du genau mit "versteckt" meinst. Tue das.

In dem du z.B. mit ADMT migrierst. Oder wenn du "Luxus" haben möchtest und das Werkzeug was kosten darf, dann nimmst du Quest. Du installierst in der Gesamtstruktur münchen.ag mit einem Server die Subdomäne berlin.münchen.ag. Danach migrierst du die Benutzer-, Gruppen- und Computerkonten in diese Subdomäne. Wenn du allerdings damit keine Erfahrung hast, solltest du über einen Dienstleister nachdenken. LDAP://Yusufs.Directory.Blog/ - Eine Domänenmigration durchführen

Moin, doch, dass geht schon. Die DomäneB muss als Subdomäne in die Gesamtstruktur von DomäneA z.B. mit ADMT migriert werden.

Salve, nein, geht natürlich nicht. Denn -fn und -ln sind ja Parameter und keine Werte. Wenn du -fn angibst, erwartet dsmod als Wert bei diesem Parameter eben einen Vornamen und bei -ln den Nachnamen.

Klar, denn employeeType ist doch auch kein DSMOD-Parameter. Wenn du dir die Hilfe zu dsmod mit "dsmod /?" angesehen hättest, wäre es dir auch schnell selber aufgefallen. Für deine Aufgabe ist dsquery im Zusammanhang mit dsmod nicht geeignet. Verwende ADFIND und ADMOD, damit kannst du das lösen. Free Tools Auch mit der PowerShell bekommst du das gelöst.

Das ist natürlich schlecht. Die IST-Situation sollte man schon analysieren können. Also die AD-Domäne heißt jetzt anders und nicht der FQDN im DNS. OK, wenn das ohne Neuinstallation der Domäne durchgeführt worden ist, ist die Domäne verloren. Wenn die Domäne neu installliert wurde ohne die Konten zu berücksichtigen, müssen alle Benutzer (und alle Profile) händisch in der neuen Domäne erstellt und die Clients zur neuen Domäne hinzugefügt werden. Du führst also eine Neuinstalllation durch. Was und wie er das durchgeführt hat wäre interessant gewesen. Dann wurde klar gepfuscht! Von hier aus denke ich auch, dass es die zielführendere Vorgehensweise ist, die Domäne neu zu installieren (wenn möglich). Denn wer weiß was der Vorgänger noch alles angestellt hat und wovon ihr noch nichts mitbekommen hat.

Servus, der LDAP-Name deines gesuchten Attributs lautet "employeeType", ohne Bindestrich. Versuche es damit. Employee-Type Attribute (Windows)

Unfug ist, nur wegen dem Namen weitere Domänen zu erstellen. Das kostet unnötig Ressourcen, Verwaltung und Serverlizenzen. @LukasB Genau, die Idee ist nicht gut. Nicht alles was in der IT möglich ist, ist sinnvoll. ;) Im Troubleshooting-Fall kann das einem eher das Leben erschweren. Man könnte ein "Disjoint Namespace" einrichten, wenn die Voraussetzungen die in dem Link beschrieben sind erfüllt werden und das dem Anspruch des Kunden entspricht. Ob danach aber alles ordnungsgemäß in der Umgebung funktioniert, sieht man dann. Das Ziel ist ja scheinbar, die Server in ihrem FQDN zu unterscheiden. Das kann man aber bereits mit dem Computernamen der Server erreichen. Z.B. bekommt der Fileserver der in Berlin steht den Computernamen "BEFSRV01", der in München "MUFSRV01" usw.

Servus, das bekommst du nur mit Subdomänen hin, was völliger Unfug ist!

Servus, was *genau* wurde denn umbenannt? Denn unter Windows 2000 kann man weder den NetBIOS- noch den DNS-Domänennamen umbenennen, geschweige den Computernamen vom DC. Es kommt darauf an, wann *was* durchgeführt wude und von wann die Sicherung ist. Prüfen ob noch was zu retten ist.

Das freut mich zu hören, dass ich mir die Mühe nicht umsonst mache. ;) Das denke ich auch. Wobei es sich eben nicht um den Schemamaster handelt, sondern um die Rolle des PDC-Emulators. Die Rollen kann man ja schließlich trennen. Das bedeutet, "nur" weil sich die Schemamasterrolle auf einem 2000er DC befindet heißt das nicht automatisch, dass der PDC-Emulator ebenfalls sich auf demselben DC befindet. Prüfe auf welchem DC sich die Rolle des PDC-Emulators befindet und verschiebe diesen ggf. auf einen neueren DC. Und merke dir für die Zukunft, sobald der erste DC mit dem neueren OS zur Domäne hinzugefügt wird, verschiebe die FSMO-Rollen auf diesen DC.

Servus, befindet sich die FSMO-Rolle "PDC-Emulator" auf einem DC, der mindestens unter Windows Server 2003 läuft? LDAP://Yusufs.Directory.Blog/ - Der PDC-Emulator