Daim

Servus, LDAP://Yusufs.Directory.Blog/ - Clients in die Domäne hinzufügen

Servus, wenn in der Domäne zwei DCs existieren, sollte man es tunlichst vermeiden und beide DCs gleichzeitig neu starten. Dann dauert der Startvorgang bis sich der Admin anmelden kann > 10 Minuten. Es sollte der zweite DC erst dann neu gestartet werden, wenn der erste hochgefahren ist.

Sonst hätte ich es nicht geschrieben! Jetzt stell dich nicht so an, sonst mache ich es für dich. ;)

Ja, dass ist soweit in Ordnung. LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen

Salve, das ist ein Irrtum! Es kommt auf die Umgebung an. In einem Single-Domain Forest kann sich der Benutzer auch ohne GC anmelden. Das wird auf vielen Seiten nicht korrekt dargestellt.

Moin, yes, Sir. LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus Na das wird aber auch Zeit. ;)

Servus, ja, aber er möchte doch den Domänennamen nicht mehr sichtbar haben, so wie ich den OP verstanden habe. Mit deiner Variante wird "lediglich" das Feld "Anmelden an" ausgegraut, aber der Domänenname der eben nicht erwünscht ist, ist weiterhin sichtbar. Dann kommt noch hinzu, dass die Benutzer den nicht erwünschten Domänennamen auch noch im UPN angeben müssen. Die Variante geht aber schon in die richtige Richtung. ;) Zuerst blendet man das Feld "Anmelden an" mit einer ADM aus. Das ist der Registry-Schlüssel: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\<NoDomainUI> Reg_DWORD mit dem Wert 1. Nach dem das Feld ausgeblendet wurde, müssen sich die Benutzer zwingend mit ihrem UPN anmelden. Eine Anmeldung mit dem sAMAccountName funktioniert dann nicht mehr. Danach trägt man in der MMC "AD-Domänen und -Vertrauensstellungen" -> Rechtsklick auf "AD-Domänen und -Vertrauensstellungen" -> Eigenschaften einen alternativen Benutzerprinzipalnamen ein. Anschließend konfiguriert man in den Benutzerkonten diesen Suffix als UPN. Diese Vorgehensweise wäre die Einzigste, um den "alten" Domänennamen bei der Benutzeranmeldung auszublenden. Und statt die Domäne umzubenennen, kannst du auch eine Migration durchführen. :cool:

Servus, existieren mehrere DCs, vielleicht an verschiedenen AD-Standorten? Evtl. bist du dann nur zu ungeduldig oder es liegt ein AD-Replikationsproblem vor? Dann würde dir das jedoch das Eventlog melden.

Servus, existiert zufällig im DNS eine Forward Lookup Zone mit einem Punkt "."? Falls ja, lösche diese. Denn somit meint dein DNS das er ein Root-Server ist und "alles weiß". Nach dem Löschen kannst du anschließend unter Weiterleitungen einen Forwarder eintragen. Die bedingte Weiterleitung gibt es schon ab Windows Server 2003. ;) Das nehme ich an.

Servus, sorry, aber deine Aufgabe ist wirklich alles andere als herausfordernd! Mit Hilfe des Internets und ein wenig "rumprobiererei" bekommst du das auch alleine hin. Du solltest z.B. nach "Standortleiter" das Komma weglassen. Und lass nach "dsadd user" nach dem ersten Anführungszeichen das Leerzeichen weg. Dsadd user

Hättest du es mal selbst getestet, würde es dir schnell selber auffallen. Mit dem Slash wird das Komma maskiert. Damit wird in der Übersicht (im Attribut name) der Benutzer in der MMC "AD-Benutzer und -Computer" so dargestellt "Wurst, Hans". Ist in der Hilfe und tausendfach im Internet zu dsadd beschrieben. Den Parameter kannst du aber, wenn du dich an meinem Beispielbefehl hälst weglassen.

Servus, du kannst die Delegierung mit dem Kommandozeilentool DSACLS skripten. Das hat auch den Vorteil, dass die delegierten Rechte sich zum einen "einfach" dokumentieren und zum anderen, leicht wieder entfernen lässt. Mit dem folgenden Befehl (ungetestet) solltest du das Recht zum erstellen von Gruppen in der angegebenen OU delegieren können: Dsacls "OU=<OU>,DC=Domäne,DC=TLD" /I:S /G <Domäne>\<Gruppe>:CC;group; Für die zweite Anforderung ist es notwendig, das Schreibrecht für das member Attribut in den Gruppenobjekten zu delegieren. Der Befehl (ebenfalls ungetestet) könnte so aussehen: Dsacls "OU=OU,DC=Domäne,DC=TLD" /I:S /G <Domäne>\<Gruppe>:WP;member;group Danach kann die <Gruppe> in den einzelnen Gruppen die unterhalb der angegebenen OU existieren, Benutzer hinzufügen. LDAP://Yusufs.Directory.Blog/ - Objektdelegierungen einrichten

Servus, du vergisst scheinbar ein Leerzeichen nach "dsadd ou". Versuche es mal damit: Dsadd OU "OU=Hamburg,DC=Deutschland,DC=ag" Auch beim erstellen des Benutzers musst du nach "dsadd user" ein Leerzeichen hinzufügen. Der Befehl würde z.B. so aussehen: Dsadd User "CN=Dikmenoglu\,Yusuf,OU=Hamburg,DC=Deutschland,DC=ag" -samid Yusuf -upn Yusuf@Deutschland.ag -pwd Pa$$w0rd! -disabled no

Salve, genau, einen DOS-Befehl gibt es nicht. Hmm... vielleicht? ;) Schau dir den folgenden Link an. Die DNS Variante ist richtig prickelnd. Wenn du das konfiguriert hast, kannst du anschließend den Benutzer anpingen und erhälst die IP-Adresse des Clients zurück. LDAP://Yusufs.Directory.Blog/ - Wo ist der Benutzer angemeldet?

Die Kennwortrichtlinie wird unter den Computerkonfigurationen in der Gruppenrichtlinie und nicht unter den Benutzerkonfigurationen konfiguriert! Die Benutzerobjekte können mit den Kennworteinstellungen nichts anfangen. Die Kennwortoptionen werden nur von Computerobjekten verwertet und befinden sich unter: Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Kontorichtlinien\Kennwortrichtlinien und Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Kontorichtlinien\Kontosperrungsrichtlinien Bis einschließlich Windows Server 2003 kann mit Bordmittel nur eine Kennwort- und Kontosperrungsrichtlinie innerhalb einer Domäne auf Domänenbenutzer wirken. Damit die Richtlinien auf Domänenbenutzer wirken, müssen diese zwingend auf Domänenebene verlinkt werden. Wenn stattdessen die beiden Richtlinien auf eine Organisationseinheit (OU) verlinkt werden, wirkt sich das lediglich auf die Computer die sich in dieser OU befinden aus und die Kennwortvorgaben gelten somit nur für die lokalen Benutzerkonten, die sich auf diesen Computern befinden. Die Kennwortrichtlinie sollte in allen Serverversionen stets in der Default Domain Policy konfiguriert werden!

Servus, kannst du das bitte ausführlicher beschreiben, in welcher GPO du welche Einstellungen vorgenommen und wohin du die GPO verlinkt hast? Kommt die GPO auch am Client an (prüfe das mit RSOP oder gpresult)?

Servus, http://www.mcseboard.de/active-directory-forum-79/passalert-betaphase-145443.html

LDAP://Yusufs.Directory.Blog/ - Einen zusätzlichen DC in die Domäne hinzufügen Das bedeutet, du hast mit dem Windows Server 2008 bereits eine neue Domäne erstellt, die so lautet wie die SBS Domäne? Dann deinstalliere die Domäne und stufe den DC mit DCPROMO herunter. Anschließend stufst du den Server nach dem o.g. Link, als zusätzlichen DC in der SBS Domäne. Ich würde aber vorher den Server direkt neu installlieren. Das geht so nicht. Du musst die "andere" Domäne deinstallieren und den 2008er als zusätzlichen DC zur SBS Domäne hinzufügen. Beachte den Link.

Was um Himmels Willen hat eine Testdomäne in einer produktiven Umgebung zu suchen? Oder bist du auch einer derjenigen, der tagtäglich eine Test- und keine produktive Umgebung betreut? Dann entferne mit NTDSUTIL ähnlich wie du den DC entfernst hast, die Domäne aus den Metadaten. How to remove orphaned domains from Active Directory

Servus, warum fügst du den Windows Server 2008 nicht als zusätzlichen DC zur bestehenden SBS Domäne (nach vorheriger AD-Schemaaktualisierung) hinzu und entfernst dann den SBS? Somit hättest du die wenigste Arbeit. Und ja, neben einem SBS können weitere DCs existieren.

Die man sicherlich auch hätte beheben können. ;) Es kommt auf die Umgebung an. Entweder in eine neue Domäne migrieren (mit ADMT oder Quest, wenn es was kosten darf) oder alle durchgeführten "Jugend forscht" Schritte (falls noch bekannt), rückgängig machen.

Das stimmt nicht. Wenn das Attribut pwdLastSet als Wert 0 enthält, muss der Benutzer bei der nächsten Anmeldung ein neues Kennwort vergeben. Dann hat das der Client noch nicht "mitbekommen". Der Benutzer sollte sich erneut an der Domäne authentisieren. Danach überprüfe das erneut.

Dann existieren (wenn du das DC Objekt aus dssite.msc entfernt hast) auch keine Reste mehr. ;) Wie bereits geschrieben, führe noch das DCDIAG aus und halte das Eventlog im Auge.

Servus, die Option ist schon die richtige Stelle. Funktionert es denn bei anderen Benutzern (was es sollte)? Kontrolliere mal z.B. mit ADSIEdit ob in den Eigenschaften des Benutzers bei dem es nicht funktioniert, dass Attribut userAccountControl einen Wert von min. 65536 hat. Als diese Option in dem Benutzerkonto aktiviert wurde, befand sich zu diesem Zeitpunkt der Benutzer im Netzwerk?

Aktiviere in der MMC "AD-Benutzer und -Computer" unter Ansicht die "Erweiterten Funktionen". Danach navigiere zum Container "DFSR-GlobalSettings oder File Replication Service" und kontrolliere ob in den darunterliegenden Containern noch Hinweise zu dem DC bestehen. Falls ja, entferne diese. Überprüfe desweiteren in der Kommandozeile mit NETDOM QUERY FSMO ob sich alle FSMO-Rollen auf einem bestehenden DC befinden und führe sicherheitshalber auch DCPROMO aus. Halte in der Ausgabe Ausschau nach FAILED Einträgen, die natürlich nicht erscheinen sollten.