Daim

Erst einmal beschreibe uns "Glasklar" dein Vorhaben, also was ist die IST-Situation und was ist das Ziel. Deine Anmeldung die 35 Minuten dauert ist ein DNS-Problem. Daher erkläre uns was Sache ist.

Na ganz so drastisch würde ich das nicht formulieren. Denn schließlich kommt es auch darauf an, was alles auf dem DC noch an Applikationen installiert ist und ob es sich dabei evtl. auch noch um einen File-/Printserver etc. handelt. Eine Reparaturinstallation kann schon zielführend und schneller sein als eine Neuinstallation. Es kommt halt auf die Maschine an. Wenn es sich um reinen DC handelt, würde ich eine Neuinstallation vorziehen anstatt eine Reparatur durchzuführen.

Servus, na du erstellst doch in der MMC "Standorte und -Dienste" ein AD-Standort mit dem [und jetzt kommt das entscheidende] zugehörigen Subnetz (Punkt 4 in deinem verlinkten Artikel). Danach verschiebst du das DC-Icon an den neuen AD-Standort und bereinigst anschließend noch das DNS. Nach einem Neustart bzw. neu Starten des NETLOGON-Dienstes registriert sich der DC an seinem neuen AD-Standort im DNS (Punkt 12 in deinem verlinkten Artikel). Aha... wieso soll er das denn nicht können? Das wäre ja sonst noch schöner. Natürlich kann er das. Entscheidend dabei ist das Design in der MMC "Standorte und -Dienste" und vor allem das DNS. Natürlich ist das Routing dabei die Voraussetzung. Das muss selbstverständlich vorher stehen. Jedes Subnetz das du in der MMC "Standorte und -Dienste" erstellst kann nur genau einem AD-Standort zugewiesen werden und einem AD-Standort können jedoch mehrere Subnetze zugeordnet werden. Wenn du das Routingtechnisch in der Zentrale hinbekommst, dann funktioniert es auch dort. Ansonsten musst du den DC physikalisch zu seinem neuen Subnetz transportieren. Yepp, noch früh am morgen. Trink noch ein bisserl Kaffee. ;) Joaha.. jetzt aber. Jetzt wirfst du hier einiges durcheinander. Jeder DC benötigt das Subnetz zu dem er nunmal gehört. Wie dein Netzwerk aufgebaut und designed ist, können wir dir hier ja schlecht verraten. Das ist deine Aufgabe das IP-Technisch korrekt aufzubauen und dann im AD in der MMC "Standorte und -Dienste" dementsprechend abzubilden.

Servus, du willst den einzigen bestehenden DC austauschen. Dann reicht DCPROMO alleine nicht aus. Hier wird dir geholfen: LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen

Servus, ja, kann man machen. Aber bevor --> ich <-- einen DC repariere, installiere ich die Maschine neu. Falls du dich zu einer Reparaturinstallation entschließen solltest, führe vorher eine Sicherung durch, mindestens vom Systemstatus mit wbadmin.

Servus, der Powershell MVP "Dr. Tobias Weltner" stellt kostenlos ein eBook als PDF mit satten 567 Seiten zum Download zur Verfügung. Have Fun. Master-PowerShell | With Dr. Tobias Weltner - PowerShell.com

Eine Zwangsabmeldung erfolgt egal in welchem Szenario nie.

Servus, wenn du das Kennwort änderst, wird der Benutzer nicht zwangs abgemeldet, wäre ja noch schöner. Was würde dann mit der wichtigen Worddatei passieren an der der Benutzer gerade arbeitet und woran viel Geld hängt? Nach dem ändern des Kennworts erhält der Benutzer aber "nach einer Zeit" keinen Zugriff mehr auf die Netzwerkressourcen.

Die Operatoren - Konten (und nur diese) können von dem AdminSDHolder - Prozess ausgenommen werden. Dazu muss ein Hotfix installiert werden, der aus diesem Artikel angefordert werden kann: Delegated permissions are not available and inheritance is automatically disabled Dort ist auch erklärt, wie der Schutz für bestimmte Gruppen deaktiviert werden kann. Erkennt der PDC - Emulator eine Abweichung in der Berechtigungsliste ausgehend von der Berechtigungsliste des AdminSDHolder), wird diese dahingehend geändert, um eine Übereinstimmung mit der Liste des AdminSDHolder`s zu erzielen. Wenn Benutzerkonten aus den geschützten Konten entfernt werden, bekommen sie nicht automatisch die Sicherheitseigenschaften angepasst, damit sie erneut die vererbten Berechtigungen akzeptieren. Diese Änderung muss manuell oder durch ein Skript (ein Beispielscript befindet sich im oben angegebenen Artikel) erledigt werden. Werden Änderungen in der Berechtigungsliste des AdminSDHolder - Objekts vorgenommen, werden diese für alle Mitglieder der Dienstadministratorgruppe übernommen. Daher stellt eine Änderung des AdminSDHolder - Objekts ein Sicherheitsrisiko dar und deshalb sollten diese (falls nötig), gut durchdacht worden sein. Falls Änderungen am AdminSDHolder - Objekt getätigt werden, wird dieses im Ereignisprotokoll der Domänencontroller aufgezeichnet, der in etwa wie folgt aussieht: Die Quelle lautet „Security“, als Kategorie wird „Verzeichnisdienstzugriff“ vermerkt, der Typ lautet „Erfolg“ und als „Ereignis - ID“ wird die „ID 565“ gespeichert. Dieses gilt es auf allen Domänencontrollern zu kontrollieren. Wenn eine nicht autorisierte Änderung am AdminSDHolder - Objekt vorgenommen wurde, kann diese aus dem Pfad CN=AdminSDHolder, CN=System, DC=<Domäne>, DC=DE der Domänenverzeichnispartition, wiederhergestellt werden.

Servus, das ist der AdminSDHolder. Die Erklärung: Das Active Directory enthält einen Schutz - Mechanismus, dass Benutzerkonten und Gruppen die Mitglieder von Dienstadministratorgruppen sind, speziell schützt. Der Domänencontroller, der die FSMO - Rolle des PDC-Emulators innehat, überprüft alle 60 Minuten, dass die DACLs dieser Konten mit der Berechtigungsliste eines speziellen AdminSDHolder - Objekts übereinstimmen. Hinweis: Wenn im folgenden Registry - Pfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters der Schlüssel "AdminSDProtectFrequency" nicht gesetzt ist (der standardmäßig nicht existiert), dann lautet das Überprüfungsintervall des PDC - Emulators 60 Minuten. Der Wert kann zwischen 1 Minute (60 Sekunden) und 2 Stunden (7200 Sekunden) liegen. Dieser Prozess soll verhindern, dass die Sicherheitsberechtigung an administrativen Konten geändert wird und somit zu viele Domänenadministratoren oder andere Anwender mit höheren Rechten, administrative Tätigkeiten ausführen können. Der Prozess geht dabei folgendermaßen vor: - Es prüft, welche Benutzerkonten direkt oder verschachtelt in einer der geschützten Gruppen sind und setzt dessen Attribute „adminCount“ auf den Wert von größer 0 - Alle Benutzerkonten, die einen Wert des Attributs „adminCount“ größer 0 haben, werden auf den Standardwert (der den Rechten des Objekts AdminSDHolder entspricht) zurückgesetzt. Das bedeutet, dass die Rechte die man auf der Registerkarte „Sicherheit“ des Benutzerkonto`s sieht, zurückgesetzt werden und auch für alle administrativen Konten gilt. - Der Standardwert basiert auf den Berechtigungen des Objektes CN=AdminSDHolder,CN=System,DC=<Domäne>,DC=<TLD> und dient als Vorlage für alle administrativen Konten. - Damit wird ebenfalls die Vererbung durch darüber liegende OUs deaktiviert Folgende Gruppen (samt den direkten oder verschachtelten Mitgliedern sowie Gruppen) ab Windows 2000, einschließlich Service Pack 3 werden durch den AdminSDHolder geschützt: - Organisations-Administratoren - Schema - Administratoren - Domänen - Administratoren - Administratoren Ab dem Service Pack 4 für Windows 2000 (oder mit installiertem Hotfix 327825 auch mit früherem SP) bzw. Windows Server 2003 werden folgende Gruppen mitgeschützt: - Server - Operatoren - Sicherungs - Operatoren - Konten - Operatoren - Druck - Operatoren - Zertifikatherausgeber Zusätzlich werden die Benutzerkonten „Administrator“ und „KRBTGT“ ebenfalls vom AdminSDHolder Prozess geschützt sowie Benutzerkonten die in Verteilergruppen (auch verschachtelt) ebenfalls Mitglied einer der geschützten Gruppen sind. ... to be continued

OK, jetzt haben wir deine IST-Situation klar definiert. Du möchtest also einen zweiten Windows Server 2003 DC (und warum SP1 und nicht SP2?) zur Domäne hinzufügen. Dann trage in den TCP/IP-Einstellungen des neuen Servers den DC als DNS-Server ein und führe das DCPROMO aus. An entsprechender Stelle gibst du im DCPROMO-Assistenten an, dass der Server als "zusätzlicher DC der bestehenden Domäne" hinzugefügt werden soll. Ist jedoch der neue Server der erste Windows Server 2003 --> R2 <--, so musst du vorher von der zweiten R2-CD das ADPREP /FORESTPREP auf dem Schemamaster ausführen. Erst dann kann der neue Server als DC zur Domäne hinzugefügt werden. Siehe auch: LDAP://Yusufs.Directory.Blog/ - Schemaupdate beim Windows Server 2003 R2

Auhaa... ich hatte es noch im Kopf und habs dann vergessen abzutippen. Aber du hast ja "meinen Hinweis" nachgeschoben. Danke für die Gedankenstütze. ;)

Servus, du möchtest also den 2003er komplett aus der Domäne entfernen. Verschiebe die FSMO-Rollen auf den 2008er DC sowie alle Dienste wie z.B. DHCP, WINS, DNS (<-- sollte ohnehin auf beiden DCs installiert sein), GC etc. Wenn alles soweit übernommen wurde führst du unter Start-Ausführen das DCPROMO aus und folgst dem Assistenten. Nach dem DCPROMO ist der Server ein Memberserver und du kannst diesen nun aus der Domäne entfernen. Anschließend lösche noch das Computerkonto im AD. Siehe auch: LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen

Servus, kontrolliere mal ob UserB Mitglied der Gruppe Domänen-Benutzer ist und ob die Domänen-Benutzer Mitglied der LOKALEN Gruppe "Benutzer" auf dem Client ist.

Das muss nicht sein. Es könnte ja sein das der DC der entfernt wurde garkeine Rollen inne hatte. Das wäre aber das gleiche, wie wenn der Rolleninhaber crashen würde. In diesem Fall könnte man trotzdem (sonst wäre das ja Fatal) die Rollen offline "mit Gewalt" von einem anderen DC übernehmen. Ja, etwas verquer am frühen Morgen. ;)

Ist es auch nicht, wenn das geschilderte von dir zutrifft. Du bist nicht der Schuldige. Du möchtest dem Kunden doch nur helfen. Genau so ist es. Das wäre ein Domänensplitt, wenn man versuchen würde die Subdomäne als alleinige Domäne weiterlaufen zu lassen. LDAP://Yusufs.Directory.Blog/ - Einen Domänensplitt durchführen Na klar doch. Sonst könnte ich mir den Spaß auch gleich sparen, wenn meine Artikel nicht gelesen und genutzt werden würden. ;) Vielen Dank für die Blumen. Das freut mich, aber cooler wäre es wenn du meine Seite im RSS-Reader abonieren würdest. :cool:

Ahoi, wenn das tatsächlich so ist, muss zwingend eine Migration durchgeführt werden!

Aloha, nur weil der Server ein DC ist funktioniert die auf dem DC installierte Applikation nicht? Was ist das denn für eine Software? Dort geht es um die Delegierung. Falls eine im DNS eingerichtet ist lässt du den Haken drin und wenn keine Delegierung existiert (was ich vermute), entfernst du den Haken. Der DCPROMO-Assistent entfernt die Delegierung falls diese existiert und löscht die DNS-Zonen auf diesem Server. Bei diesem Schritt endet der zweite Satz mit den Worten "...auf diesem Server gelöscht". Denke aber daran nach dem DCPROMO die Rollen "AD DS" sowie DNS (bei AD-integrierten Zonen) zu entfernen und falls der DC in seinen TCP/IP-Einstellungen als primärer DNS-Server eingetragen ist, trage dort einen andren als primären DNS ein. Ggf. noch das Loginskript anpassen.

Servus, ja. LDAP://Yusufs.Directory.Blog/ - Wie stellt man sicher, dass ein Benutzer sich nur an einem Client anmelden kann?

Das stimmt allerdings. Ich tippe aber, dass dein hier skizziertes Umfeld nicht auf den OP zutrifft.

Salut, ein Schlagwort wäre die "Netzwerksicherheit" bzw. die "Sicherheit" an sich. Den Hausschlüssel lässt auch keiner draußen an der Tür stecken und verlässt das Haus. Man muss die Benutzer sensibilisieren, dass ihr Login ein "sensibler" Vorgang ist. Das fängt z.B. da schon an, dass sich der Admin der neben dem Benutzer steht, bewußt bei der Kennworteingabe des Benutzers sich weg dreht. Der Benutzer soll merken das sein Kennwort nur er selbst kennt und wichtig für seine Arbeit im Netzwerk ist. Er darf diesen weder irgendjemandem verraten, noch darf es diesen auf einen PostIt schreiben und an den Monitor kleben.

Danke für das Vertrauen. Aber ich koche auch nur mit Wasser. Es könnten noch andere berechtigte Meinungen dazu geben, keinen WINS zu installieren. Berechtigt wären diese in Bezug auf WINS zwar nicht, aber so bildet sich eben jeder seine Meinung und könnte dies hier kundtun. ;)

Das wäre ideal. Das allermindeste wären zwei Maschinen, so das man Exchange auf den DC packt (was aber nicht sein sollte) und in jedemfall den ISA auf eine eigene Maschine packt.

Ahoi, kannst du den NT-BDC denn per IP anpingen? Denn das müsste zumindest funktionieren. Oder führe ein TRACERT <IP-Adresse NT-BDC> durch und überprüfe bis wohin eine Verbindung besteht. Deaktiviere auch zum testen die lokale Firewall auf dem Client, falls eine aktiv sein sollte. Abgesehen davon solltet ihr natürlich die NT-Möhre zügig loswerden, damit ihr den Gesamtstrukturfunktionsmodus hochstufen könnt um von den Vorteilen die der höhere Modus bietet zu profitieren.

Bonjour, ich blicke durch deine Schilderung nicht durch. Du hast bereits einen DC und möchtest einen zweiten Server zum DC wegen der Ausfallsicherheit heraufstufen. Soviel habe ich verstanden. Aber wo läuft jetzt Exchange? Auf einem DC oder einem Memberserver den du zum DC stufen möchtest? Wenn Exchange auf einem Memberserve läuft, darfst du kein DCPROMO ausführen. Auf einer Maschine auf der Exchange läuft darf der Server weder mit DCPROMO zum DC gestuft werden, noch darf dieser im Fall eines DCs mit DCPROMO heruntergestuft werden. Bitte schildere deine Umgebung klar und deutlich.