Daim

Salut, das macht man auch nicht. Man vergibt keine IP-Informationen per GPO. Dafür ist das DHCP gedacht. Damit GPOs wirken, müssen die IP-Informationen bereits "stehen" (Henne - Ei). So gehört sich das auch. ;) Eine Weiterleitung auf den anderen DC? Das macht keinen Sinn. Du solltest auf diesem DC im DNS eine Weiterleitung auf den Router oder DNS-Server deines ISPs einrichten, aber nicht auf den anderen DC.

Servus, diese beiden DCs sind also die einzigsten DCs in der Domäne. Dann musst du kontrollieren, welcher von beiden DCs das "gesunde" SYSVOL-Verzeichnis besitzt. Diesen DC deklarierst du als autoritativen DC, in dem du in der Registry den Schlüssen "Burflags D4" setzt. Auf dem anderen DC setzt du dann noch den Schlüssel "Burflags D2". Wie du genau herausfindest, welcher von beiden DCs das funktionierende SYSVOL-Verzeichnis hast und wo genau die Registry-Schlüssel gesetzt werden müssen, erfährst du aus dem folgenden Artikel: LDAP://Yusufs.Directory.Blog/ - Dateireplikationsfehler mit der ID 13568

Bonjour, standardmäßig hat jeder "Authentifizierte Benutzer" (also alle Domänen-Benutzer) das Leserecht aus das AD. Nun könntest du gezielt über eine Objektdelegierung einem Domänen-Benutzer die entsprechenden Schreibrechte z.B. auf ein einzelnes Attribut delegieren. Siehe: LDAP://Yusufs.Directory.Blog/ - Objektdelegierungen einrichten LDAP://Yusufs.Directory.Blog/ - Der Objektdelegierungsassistent LDAP://Yusufs.Directory.Blog/ - Delegierte Berechtigungen im AD verstehen

Es kam so rüber, wie du es geschildert hattest. Lies dir das nochmals durch. Tue das.

Servus, wie jetzt? Du hast die DCs aus der OU "Domain Controllers" in eine eigene OU verschoben und in der gleichen OU befinden sich auch die Clients? Ein langsames Anmeldeverhalten wie z.B. vom DNS und von GPOs hervorgerufen. Prüfe als erstes ob die betroffenen Clients einen internen DNS-Server in ihren TCP/IP-Einstellungen eingetragen haben. Als nächstes führe ein rsop oder gpresult aus und überprüfe die GPOs, die auf den User der sich an dem Client angemeldet hat wirken. Ansonsten kannst du noch das USERENV-Logging aktivieren um zu sehen, was genau bei der Anmeldung passiert. How to enable user environment debug logging in retail builds of Windows

Servus, dann mal ran an die Arbeit: Migrating Windows Small Business Server 2003 to New Hardware

Salut, warum das denn? Existieren etwa noch NT-BDCs in der Domäne? Wenn nicht, stufe den Domänenmodus hoch. LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus

Servus, das ist bekannt, dass das subinacl aus dem Ressource Kit nicht korrekt arbeitet. Daher gibt es das Tool auch einzeln zum Download.

Die Kennwortrichtlinie auf Domänenebene wird der OP schon im Einsatz haben, denn er schrieb: Aber die Richtlinie greift bei den bestehenden Benutzern erst, wenn sie ihr Kennwort ändern. Daher ist es empfehlenswert wenn die Kennwortrichtlinie konfiguriert wird, gleich die Option "Benutzer muss Kennwort bei der nächsten..." zu aktivieren.

Das SP2 für Windows Server 2003 kann schon das Problem sein. Kontrolliere das hier einmal: faq-o-matic.net Gut gedacht, schlecht gemacht, hin & her: Scalable Networking Pack

Das ganze bitte noch einmal auf deutsch. Das ist doch nur eine "Information". Viel wichtiger ist das nach der EventID 13501 die ID 13516 protokolliert wird. Denn erst dann, fungiert der DC als ein DC. Verzeichnisdienst: NTDS KCC 1272 Die folgende Verzeichnispartition wird nicht mehr von dem Quelldomaincontroller repliziert, weil kein Verbindungsobjekt für den Domänencontroller existiert. Das ist auch nur eine Information und kein Fehler. Der KCC der standardmäßig alle 15 Minuten auf jedem DC läuft, berechnet eben ständig die AD-Replikationstopologie und passt diese bei Veränderungen automatisch an. Beide EventIDs sind Infos und keine Fehler! Elementar für die AD-Replikation ist das DNS. Der Browser-Dienst spielt keine Rolle. Von einem DC zum anderen muss ein Ping auf die IP-Adresse und auf den FQDN funktionieren. Führe mal ein DCDIAG sowie NetDIAG aus. Beide Tools findest du in den Windows Support Tools.

Servus, was bedeutet das genau? Im Eventlog müsste dann ja auch "Karneval in Rio" sein.

Servus, du musst natürlich alle Dienste und Daten die auf dem "alten" DC laufen, auf den neuen DC übernehmen wie z.B. Samba, DHCP, Drucker, Dateien etc. Siehe auch: LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen

Du möchtest über DHCP dein Netzwerk absichern? Das ist der falsche Ansatz. Ein Sicherheitsfeature hast du damit ohnehin nicht in den Händen. Das ist genau so falsch wie wenn man glauben würde, dass man ohne DHCP mit manueller/statischer Konfiguration "sicherer" sein würde. Die Vergabe der IP-Adressen hat nicht im geringsten mit Sicherheit zu tun. Wenn du die Netzwerkkommunikation mit fremden Systemen unterbinden möchstest, benötigst du IPSec, 802.1x oder unter Windows Server 2008 das NAP.

OK, du kannst einen weiteren/zusätzlichen Windows Server 2003 zu einer SBS-Domäne als DC hinzufügen. Von welchen zwei Netzwerken redest du?

Allerdings! Denn es kann in einer SBS-Domäne NUR einen SBS geben, keine zwei. Für Migrationsszenarien können für eine kurze Zeit (7 Tage, mit einem Patch 21 Tage) nebeneinander betrieben werden. Nach Ablauf der Zeit wandelt sich der SBS zu einem "Fahrstuhl-SBS". Siehe: LDAP://Yusufs.Directory.Blog/ - Die Besonderheiten eines Small Business Server`s (SBS)

Servus, wie jetzt? Befinden sich etwa zwei SBS-Server in EINER AD-Domäne?

Huhuu, Off-Topic:Da mich schon meine Plattform nervt (und dabei ist die besch...eidene Suche nur das kleinste Übel), dachte ich mir, änderst du mal den Titel. Evtl. tut es dann nicht mehr ganz so weh... ;) @d.pabst Das musst du aber noch genauer erläutern. Was meinst du damit? Bei einer vernünftigen VPN-Anbindung benötigt man, je nach Anzahl der Clients, keinen einzigen DC vor Ort. Die Authentifizierung funktioniert problemlos und ohne performanceverlust über die Leitung an einem DC, der in der Zentrale steht. Die Clients finden ihren DC über das DNS. LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort Dann führe zum Test mal diese Befehle aus: Für die Inbound-Replikation (eingehend): REPADMIN /SYNCALL <FQDN DC> <Verzeichnispartition> /e /d /q Für alle Verzeichnispartitionen: REPADMIN /SYNCALL <FQDN DC> /A /e /d /q Für die Outbound-Replikation (ausgehend): REPADMIN /SYNCALL <FQDN DC> <Verzeichnispartition> /e /d /q /P REPADMIN /SYNCALL <FQDN DC> /A /e /d /q /P Achtung: Die Parameter sind "case sensititve". Lies dir meinen Artikel in diesem Post durch, wie ein Client "seinen" DC findet. Dann verstehst du auch, dass sich an dem AD-Standort kein DC befinden muss. Da ihr ausreichende Leitungen habt, sollte die Anmeldung der Benutzer kein Problem sein. Es kommt halt darauf an, was alles über die Leitung geht und wie ausgelastet sie ist.

Servus, dann verschiebe so wie es Nils bereits geschrieben hatte alle DCs an den gleichen AD-Standort oder du konfigurierst die standortübergreifende Änderungsbenachrichtigung. Was für die AD-Replikation nichts anderes darstellt, als wären alle DCs am gleichen AD-Standort. Nur wenn du das konfigurierst, wird halt öfters über die Leitung repliziert. LDAP://Yusufs.Directory.Blog/ - Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren Deine aufgeführten Befehle sind schon ok. Keine "sofortige" bedeutet genau? Aber es findet eine AD-Replikation statt?

Servus, nur aus Neugier; Du nutzt den "Windows Server 2008 R2" der sich noch in der Betaphase befindet bereits produktiv?

Aber das Heraufstufen des Windows Server 2008 zum Domänencontroller wurde fehlerfrei abgeschlossen? Kontrolliere wie bereits erwähnt auch das Eventlog, genauer das Verzeichnisdienst-, DNS- und das Dateireplikationsprotokoll beider DCs. Noch weitere Fragen: Die Forward Lookup Zone im DNS ist AD-integriert gespeichert? Beide DCs befinden sich im gleichen AD-Standort?

Servus, das bedeutet, weder die Benutzer noch die Clients wurden auf den 2008er DC repliziert? Dann hat entweder die AD-Replikation noch nicht stattgefunden oder es existiert ein Problem. Steht denn in den TCP/IP-Einstellungen des 2008er DCs der 2003er als primärer DNS-Server drin? Führe auch das DCDIAG aus. Das Tool befindet sich unter Windwos Server 2003 in den Windows Support Tools und ist ab Windows Serevr 2008 bereits on Bord. Kontrolliere auch das Eventlog.

Servus, dann erstelle dir in der MMC "Benutzer und Computer" eine "benutzerdefinierte" gespeicherte Abfrage und verwende diesen Filter "(objectclass=user)(objectcategory=user)". Anschließend markierst du mit "STRG+A" alle Benutzer und wählst mit einem Rechtsklick die Eigenschaften aus. Nun kannst du im Reiter "Konto" den Haken bei der Option "Benutzer muss Kennwort bei der nächsten" setzen.

Servus, installiere doch mal das AdminPak von einem Windows Server 2003 aus dem Verzeichnis "%windir%\system32\adminpak.msi" drüber.

Du schreibst von RDP-Problemen. Also könnte es sich hier um ein prinzipielles Netzwerk-/Konnektivitäts-/Latenzproblem handeln. Existieret denn für jeden physikalischen Standort auch ein Standortobjekt im AD oder wie sieht das Design in "Active Directory-Standorte und -Dienste" aus? Ist das VPN voll geroutet oder können die DCs der Aussenstellen "nur" über die Zentrale auf die anderen Standorte zugreifen? Wenn das so wäre, solltest du unter "IP" die Option "Alle Standortverknüpfungen überbrücken" das standardmäßig aktiviert ist, deaktivieren. Denn die Fehlermeldungen mit der EventID 1311+1566+1865 werden vom Knowledge Consistency Checker (kurz KCC) verzeichnet. Der KCC läuft auf jedem Domänencontroller alle 15 Minuten und ist für die standortinterne (Intra-Forest) sowie standortübergreifende (Inter-Forest) Replikationstopologie zuständig. Für die standortübergreifende Replikationstopologie ist genauer der ISTG zuständig, der Bestandteil des KCC ist. Die Verbindungsobjekte erstellt der KCC dann automatisch, wenn die Replikationstopologie errechnet wurde. Die Fehlermeldungen bedeuten im einzelnen: - ID 1311 bedeutet, dass der KCC nicht alle Standorte erreichen konnte. - ID 1566 bedeutet, dass der DC sich nicht mit jedem DC in dem angegebenen Standort replizieren konnte. - Die EventID 1865 ist lediglich eine weitere Information über das nicht erreichen aller Standorte. Hier wird angegeben, welcher Standort nicht erreichbar war von dem Standort aus, wo der KCC die Fehler protokolliert hat. Diese Fehlermeldungen deuten in den meisten Fällen auf ein Konnektivitätsproblem hin. Einer der Gründe könnte z.B. sein, dass Site-Links nicht eingerichtet wurden oder eben die VPN-Verbindung "schwankt" bzw. ausgelastet ist.