Daim

Servus, genau das sagt das Flag "PASSWD_NOTREQD" auch aus. How to use the UserAccountControl flags to manipulate user account properties Davon würde ich zuerst mal ausgehen. Wenn nicht gerade per Skript - warum auch immer - das gesetzt worden ist. Nein, sonst hätte es doch bereits schon zu Problemen bei deiner Migration von 2000 zu 2003 geführt. Du "kannst" vieles, auch ignorieren... ich würde es aber versuchen zu bereinigen.

Salut, nein, keineswegs. Du musst im ersten Schritt das Active Directory-Schema aktualisieren bzw. auf Windows Server 2003 vorbereiten. Dazu führst du das Tool ADPREP von der Windows Server 2003 CD aus. Falls die neue Maschine ein Windows Server 2003 --> R2 <-- sein sollte, beachte bitte, dass du das ADPREP von der zweiten R2 CD verwendest. Denn das ADPREP bei R2 befindet sich auf beiden CDs. Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 Du führst das ADPREP mit dem Schalter /FORESTPREP auf deinem 2000er Schema-Master aus. Anschließend führst du ADPREP mit dem Schalter /DOMAINPREP auf dem Infrastruktur-Master in der Domäne aus, in der du den neuen Server hinzufügen möchtest. Wie gesagt, bei R2 musst du die Befehle mit ADPREP von der zweiten CD verwenden. Danach füge den neuen Server als "zusätzlichen Domänencontroller einer bereits existierenden Domäne" hinzu. Deine Forward Lookup Zone (FLZ) im DNS sollte auf deinem 2000er DC idealerweise AD-integriert gespeichert sein und "Nur sichere" Updates zulassen". Wenn die FLZ im AD gespeichert ist, erleichtert dir die Replikation das Leben. Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen In den TCP/IP Einstellungen des neuen Servers trägst Du als ersten und einzigsten DNS den bestehenden 2000er DC ein. Erst wenn die Replikation stattgefunden hat, kannst du die DNS-Server Einstellung verändern. Siehe: Yusuf`s Directory - Blog - Welcher DNS-Server sollte eingetragen werden ? Somit hast Du das AD und DNS auf Deinen neuen DC "gesichert". Dann solltest Du die 5 FSMO-Rollen auf den neuen DC noch verschieben: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Zusätzlich solltest Du den neuen DC zum GC deklarieren. Dieses kannst Du in dem Snap-In "Standorte- und Dienste" in dem jeweiligen Standort, auf Deinem Server - in den Eigenschaften der NTDS-Settings den Haken bei "Globaler Katalog" setzen. Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC) Was sonst noch alles zu beachten ist und wie du die einzelnen Dienste übernehmen kannst, erfährst du aus diesem Artikel: Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen Zum Schluss noch eine Empfehlung: Wenn möglich, sollten in jeder Domäne zwei DCs existieren.

Servus, aber HALLO! Das ist in meinen Augen das schlimmste was man machen kann. Wer "so" einen Split einer Domäne durchführt, der hat nach meiner Meinung den Beruf verfehlt. Die ganzen Kennwörter der administrativen- sowie Dienst Konten haben dann beide Strukturen. Ebenfalls SIDs und was weiß ich noch alles... Das ist ein großes Sicherheitsloch. Das muss es aber aus technischen sowie Sicherheitsgründen auf jedenfall! So führt man keinen Split durch, sondern, durch erstellen einer neuen Domäne. Punkt!

Servus, dann sind das sogenannte "multihomed" DCs. Diese müssen ohnehin speziell konfiguriert werden. Active Directory communication fails on multihomed domain controllers Dein Problem ist jetzt folgendes: Der DNS-Server, der an beiden Netzwerkkarten bzw. IP-Adressen horcht, registriert sich beide Adressen als Host Eintrag in seiner Forward Lookup Zone. Standardmäßig ist ja auch die dynamische IP-Registierung im DNS-Reiter der jeweiligen LAN-Verbindung aktiviert. Es stehen also für den DC - zwei verschiedene IP-Adressen im DNS. Das ganze lässt sich auf folgende Art lösen: Man muss verhindern, daß sich das System die eine IP-Adresse (Fernwartung) im DNS registriert. Hierzu wird im DNS-Reiter der IP-Konfiguration der einen LAN-Verbindung die dynamische Registrierung der IP abgeschaltet und in den Eigenschaften des DNS-Servers das Abhören des Dienstes an der einen IP-Adresse verhindert. Denn der DNS-Server registriert sich auch automatisch einen Host-Eintrag für alle IP-Adressen, an denen er abhört.

Servus, was heisst denn bitte schön "auf den neuen DCs will er jetzt die Gesamtstrukturfunktionsebene bzw. die Domänenfunktionsebenen heraustufen" ? Wer will was ? In den Domänenfunktionsmodus "Windows Server 2003" kannst du ohnehin nur wechseln, wenn keine Windows 2000 DC mehr existieren (NT-BDCs lasse ich mal ausser Acht). Abgesehen davon, sollte man ohnehin in den höheren Modus "Windows Server 2003" wechseln - wenn möglich - damit man von den Vorteilen (Replikation, LVR etc.) die der Modus bietet profitieren kann. Die technische Umsetzung sieht dann wie folgt aus: Den Domänenfunktionsmodus bzw. Gesamtstrukturfunktionsmodus kann man während dem Betrieb umstellen. Es sind quasi "drei Klicks" und die Domäne bzw- Gesamtstruktur ist umgestellt. Es ist eben darauf zu achten, dass damit, je nach Ebene, älterere DCs nicht mehr existieren dürfen/können. In einen anderen Domänenmodus kann man nur dann wechseln, wenn alle bestehenden DCs die neue Ebene unterstützen. Bedeutet, möchte man in den Domänenfunktionsmodus "Windows Server 2003", dann dürfen weder NT-BDCs noch 2000 DCs mehr in der Domäne existieren, da ansonsten das heraufstufen nicht möglich ist. Das gleiche gilt für die Gesamtstruktur. Möchte man die Gesamtstruktur auf den Gesamtstrukturfunktionsmodus "Windows Server 2003" heraufstufen, müssen vorher alle bestehenden Domänen in dem Domänenfunktionsmodus "Windows Server 2003" sein. Bestehende Vertrauensstellungen sind davon nicht betroffen bzw. haben mit dieser Umstellung kein Problem und funktionieren weiterhin. Falls mehrere Domänen in einer Gesamtstruktur existieren, dann sollte die Umstellung der einzelnen Domänen respektive Gesamtstruktur "zügig" vollzogen werden. Denn wenn man sich dabei Zeit lässt, können Replikationsprobleme auftauchen. Das Herauf stufen des Domänenfunktionsmodus kann entweder über das Snap-In „Active Directory-Benutzer und –Computer“ oder „Active Directory-Domänen und -Vertrauensstellungen“ erledigt werden (mit einem Rechtsklick auf den FQDN), wobei die Gesamtstruktur ausschließlich im Snap-In „Active Directory-Domänen und -Vertrauensstellung“ heraufgestuft werden kann. Beides lässt sich ebenfalls durch bearbeiten (mit LDP.exe oder ADSIEdit.msc) des Attributs msDS-Behavior-Version herauf stufen. Für den Gesamtstrukturfunktionsmodus ist im Attribut "msDS-Behavior-Version", dass sich im folgenden Pfad befindet <CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=TLD> als Wert 2 einzutragen. Für den Domänenfunktionsmodus ist im Attribut "msDS-Behavior-Version", dass sich im folgenden Pfad befindet <DC=DeineDomäne,DC=Root-Domäne,DC=TLD> als Wert 2 einzutragen. Ins "Nirvana" schickst du niemanden. Der Vorgang an sich, sind im Prinzip drei Klicks die während dem Betrieb durchgeführt werden können. Lediglich die Folgen müssen einem klar sein. Das eben, keine 2000er DCs mehr existieren können. Denn den Domänen- bzw- Forest-Modus wieder zurück wechseln - geht nicht. Einmal gewechselt - immer gewechselt.

Servus, dann ist bis hier hin schonmal alles korrekt, sofern du dich exakt an die Anleitung gehalten hast ;) . Ist auf dem Server das SP2 installiert und falls ja, befindet sich eine Broadcom Netzwerkkarte in dem Server? Falls ja, dann setze mal den Chimney-Registry Eintrag. Siehe: You Had Me At EHLO... : Windows 2003 Scalable Networking pack and its possible effects on Exchange Das musst du etwas weiter erläutern. Die FSMO-Rollen haben mit dem langsamen Verhalten, nichts zu tun. Deine FLZ ist im AD gespeichert und die Replikation hat bereits stattgefunden? Wie sieht denn das Eventlog aus (Karneval in Rio)? Wie seiht denn die Latenz aus, wenn du die IP-Adressen pingst? Gibt es da ebenfalls Packet-Verluste? An vielem... aber Hellsehen kann ich noch nicht :rolleyes: . Ich vermute aber auf der Netzwerk-Ebene (OSI-Layer 3 oder 4). Ist auf dem Server zufällig das SP2 installiert und befindet sich eine Broadcom Netzwerkkarte in dem DC? Falls ja, dann setzte mal den Chimney-Registry Eintrag auf dem DC. Siehe: You Had Me At EHLO... : Windows 2003 Scalable Networking pack and its possible effects on Exchange Ansonsten installiere dir mal die Windows Support Tools und führe mindestens das DCDIAG aus. Weil vielleicht bald Weihnachten ist?

Servus, und da es bisher in dem Thread noch nirgends klar beschrieben steht, muss zuerst das Schema aktualisiert werden, nämlich mit ADPREP /Forestprep von der zweiten R2-CD. Allerdings nur, wenn es bisher noch nicht ausgeführt wurde. Erst dann, kann das mit der Delta-Replikation (DFS-R) funktionieren ;) . Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2

Servus, dann sind aber sehr spärliche Antworten... Vergleiche doch mal deine Vorgehensweise zum hinzufügen des zweiten DCs, mit dieser Anleitung: Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen Steht der DC1 mit seiner echten IP-Adresse in seinen TCP/IP-Settings drin? Was spricht nslookup? Wie sieht das DNS-Log aus? Wann war der kalte Krieg? Existieren die ganzen Unterordner unterhalb deienr FLZ? Ich muss aufhören, so langsam gehen mir die Fragezeichen aus... Installiere dir die Windows Support Tools und führe auf DC1 das DCDIAG aus: http://www.microsoft.com/downloads/details.aspx?familyid=96A35011-FD83-419D-939B-9A772EA2DF90&displaylang=en

Servus, das kannst du z.B. mit CSVDE lösen: Importdateien für CSVDE.exe einfach generieren - faq-o-matic.net csvde zum Import und Export von AD-Daten nutzen - faq-o-matic.net Carlos: Konfigurationsmaske für csvde.exe - faq-o-matic.net Oder mit LDIFDE: Yusuf`s Directory - Blog - LDIFDE - LDAP Data Interchange Format Data Exchange LDIF-Generator für den Import in Active Directory - faq-o-matic.net

Servus, Montag früh, 10:00 Uhr in Deutschland... ich fang mal ganz langsam an... Ist denn überhaupt der neue Domänencontroller auch tatsächlich ein globaler Katalog? Kontrolliere das einmal, anhand dieses Artikels: Yusuf`s Directory - Blog - Globaler Katalog – Sein oder nicht sein

Servus, dass kannst du z.B. durch das DNS herausfinden. Dazu ist allerdings vorher im DNS eine Zone einzurichten. In diesem Artikel steht, wie das geht: Wolfgang on the Road: 72: Wo ist der Benutzer angemeldet?

Was die Domäne betrifft (Konten, DC) - korrekt. Bezgl. des SQL müsstest du noch überprüfen, ob die Applikation das verkraftet oder das ganze neu aufgesetzt werden müsste. Bitte schön und deine Aufgabe, ist jetzt keine unlösbare ;) .

Demnach würde ich Forest B zu Forest A migrieren. Zumal - du hattest erwähnt, dass in jedem Forest nur ein DC und keine weiteren Server existieren würde - der Exchange auf dem DC installiert wurde. Dann sollte dieser DC nicht verändert werden. Denn sobald Exchange installiert wurde, darf - seitens Support von Microsoft - die "Position" des Servers nicht mehr verändert werden. Sprich, einmal Exchange installiert, darf nicht mehr das DCPROMO (sei es zum hoch- bzw. herunterstufen) verwendet werden. Die Konten kannst du recht einfach mit ADMT migrieren. Du hast es erfasst. Die DCs kann man nicht migrieren. Diese müssen aus der alten Domäne zuerst herunter- und anschließend in der neuen Domäne erneut hochgestuft werden. Abgesehen davon sollte ohnehin - wenn möglich - in jeder Domäne zwei DCs existieren.

Doch, den gibt es schon. Das Werkzeug lautet ADMT. Du löst eben die eine oder durch erstellen einer ganz neuen Gesamtstruktur, beide Gesamtstrukturen auf. Was lediglich nicht zu migrieren geht, sind die DCs. Denn das sind komplexe Maschinen, die tief im AD verankert sind. Diese kann man eben nicht so ohne weiteres in eine neue Domäne/Gesamtstruktur migrieren. Anders sieht es da eben bei Benutzer- sowie Computerkonten aus. Diese lassen sich recht einfach migrieren. Du hast z.B. GesamtstrukturA sowie GesamtstrukturB und möchtest in die GesamtstrukturA migrieren. Dann brauchst du um mit ADMT zu arbeiten, eine bestehenden NAmensauflösung sowie eine Vertrauensstellung. Wenn beide Gesamtstrukturen auf Windows Server 2003 basieren, könntest du die NAmensauflösung recht einfach mit einer bedingten Weiterleitung sicherstellen. Danach brauchst du nur noch die Vertrauenststellung einzurichten. Das Routing muss natürlich zuerst stehen. Das migrieren mit ADMT erklärt sich fast von alleine. Im ersten Schritt musst du die Benutzer und im zweiten die Computerkonten migrieren. Somit bleiben die Benutzerprofile erhalten und der Benutzer merkt quasi nichts. Das ADMT legt einen neues Benutzerkonto in der "neuen" Domäne an und fügt die SID des Benutzerkontos aus der alten Domäne, an das neue Benutzerkonto der neuen Domäne als SIDHistory hinzu. Lies dir zum Thema ADMT die Whitepaper durch: Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To

Soweit ich mich erinnern kann, bin ich über solch eine Aussage in meinen damaligen Vorbereitungen auf die MC*-Prüfungen gestolpert. Sie stimmt aber (wie bereits erwähnt) nicht! Deshalb darf man auch nicht immer das glauben, was geschrieben steht ;) . In eigenen Tests sollte das gelesene verifiziert werden. Oftmals ist es auch so, dass die Literatur zu Beta-Zeiten erstellt wurde und dann bis zur RTM evtl. das eine oder andere übersehen wurde, so das es eben nicht korrigiert wird. Sogar auf den Technet-Seten bzw. MSDN-Seiten tauchen immer wieder Fehler auf. Ich möchte es auch nicht unbedingt als Fehler darstellen, sondern, es ist der Kenntnisstand den man zum Zeitpunkt der Veröffentlichung hatte. Diese Erkenntnis kann sich natürlich im laufe der Zeit ändern.

Servus, nein, dass geht nicht. Da hat die MS-Literatur an manchen Stellen einen Fehler... Es müssen sich zuerst alle Domänen in dem Domänenfunktionsmodis "Windows Server 2003" befinden, erst dann kann die Gesamtstruktur hochgestuft werden. Es könnte ja sein, dass in einer weltweit großen Umgebung eine Subdomäne in Australien noch in dem gemischten Modus bleiben muss, wegen Applikation xyz. Dann wäre es fatal wenn der Admin der Root-Domäne quasi mit drei Klicks den Forest hochstufen könnte.

Servus, siehe: Yusuf`s Directory - Blog - Profile (lokal/servergespeichert)

Servus, wenn dieser Fehler ausschließlich nach einem Sever-Neustart erscheint und während des Betriebs dann nicht mehr, dann kannst du diesen Fehler vernachlässigen. Denn der DNS möchte loslegen, kann aber nicht, da das AD noch nicht bereit ist.

Du weißt was eine Suchmaschine ist und kannst diese bedienen ? Resetting computer accounts in Windows 2000 and Windows XP

Wer hat dir denn das erzählt?! Du weißt in welcher Verzeichnispartition ein Computerkonto-Objekt erstellt wird? Zurücksetzen kannst du das Computerkonto z.B. im Snap-In "Active Directory-Benutzer und -Computer" und dort machst du einen Rechtsklick auf das Computerkonto-Objekt.

Servus, dann migriere von einer Gesamtstruktur in die andere. Oder beide Gesamtstrukturen in eine ganz neue Gesamtstruktur. Das Werkzeug mit dem du diese Migration durchführen kannst, lautet ADMT. Damit kannst du die Benutzer- sowie Computerkonten (Client und Memberserver. aber keine DCs) migrieren. Du musst deine Frage präzisieren ;) .

Servus, befolge diesen Artikel: Yusuf`s Directory - Blog - Dateireplikationsfehler mit der ID 13568

Ahoi, das riecht mir verdammt nach DNS-Problemen. Kontrolliere das mal. Der DC selbst sollte mit seiner echten IP-Adresse in seinen TCP/IP-Einstellungen stehen und nicht mit der Localhost Adresse. Ist auf dem Serevr das SP2 installiert? Falls nicht, würde ich das als erstes in Angriff nehmen. Zusätzlich würde ich das SMB-Signing nach diesen Best Practice einstellen: Gruppenrichtlinien - Übersicht, FAQ und Tutorials Wenn das auch nichts geholfen hat, gehe dann den Vorschlägen auf EventID nach: EventID.Net ... und das ist genau ein Domänencontrioller zu wenig! Dann stelle das gezielt mit DCDIAG und den DNS-Tests sicher. Die Hilfe zu DCDIAG ist dir dabei behilflich.

Salut, immer und immer wieder - ist das entscheidende an der Authentifizierung das DNS und dazu kommt noch das Desgin im Snap-In "Active Directory-Standorte und -Dienste". Existieren für die physikalischen Standorte und die Standorte im AD und wurden diesen das entsprechende Subnetz verknüpft? Die Vorgehensweise wäre folgende: Der Client fragt im DNS nach, welche DCs es gibt. Die Liste aus der DNS-Antwort die der Client erhält, geht der Client durch, um einen DC zu finden der funktioniert und online ist. Bevorzugt nimmt der Client dann einen DC aus seinem Standort. Der Domänencontroller reicht die Clientanfrage an seinen NETLOGON-Prozess durch, der dann die Client-IP in seiner Subnet to Site Mapping Table nachsieht und dann das treffende Site-Objekt heraussucht. Der Netlogon-Prozess übergibt an den DC die folgenden Infos: - Den Namen des Standorts, in der sich der befragte Domänencontroller befindet - Den Standortnamen, in dem sich der Client befindet - Ein Flag das anzeigt wird, wenn sich der angefragte DC im gleichen Standort befindet (Bit gesetzt) oder ob der DC ausserhalb des Standortes ist (Bit nicht gesetzt). Dieses Informationen werden dann an den Client gesendet, der sich nun diese Informationen näher anschaut: - Wenn sich der Domänencontroller in der gleichen (oder nächstgelegenen) Standort befindet (gesetztes Bit), dann nimmt der Client bevorzugt dieses DC. - Befindet sich kein Domänencontroller am gleichen Standort (nicht gesetztes Bit), dann weiß der Client, an welchem Standort er sich befindet und stellt erneut eine Anfrage an das DNS nach einem Domänencontroller. Wird die Anfrage erfolgreich beantwortet, nimmt der Client diesen DC. Der Client der Mitglied in der Domäne ist, setzt in seiner Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters - den Wert DynamicSiteName mit dem Standort, an dem sich der Client befindet. Diesen Registry-KEy solltest du mal auf den Clients überprüfen. Steht dieser mit dem richtigen Standort drin? Dann wäre noch interessant, ob die Clients "ihre" korrekten IP-Informationen entweder statisch oder per DHCP eingetragen haben. Was auch noch wichtig ist, welchen DNS-Server benutzen sie? Ein Blick in das DNS sollte auch geworfen werden, ob sich die DCs mit ihren entsprechenden SRV-Records für den jeweiligen Standort eingetragen haben. Z.B.: _tcp.Name-der-Site.DC._MSDCS.Domäne.TLD. Du kannst dem Client auch durch einen Registry-Eintrag zwigen, sich an einem DC, der sich an seinem Standort befindet, zu authentifizieren. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\<SiteName>. Der Nachteil wäre, dass wenn der Client verschoben werden sollte, erstmal keiner an diesen Reg-Key denkt und zum anderen, der Client Schwierigkeiten bekommen kann. Siehe auch: Yusuf`s Directory - Blog - Domänencontroller am Standort

Ja, ich bin auch ein Freund davon, dass man diesen Vorgang manuell durchführt. Damit man sich dessen eben bewußt wird, wohin die Rollen verschoben werden. Die darauf passende Antwort, hat woiza in seinem zweiten Satz bereits erwähnt.