Daim

Moin, die Abfrage könntest du auch einfach mit "dsquery user -o samid -limit 0" gestalten. Standardmäßig wird hier die Domäne abgefragt (domainroot). Ich finde eben die Variante mit CSVDE und/oder Ldifde "einfacher" da man damit, alles schön in einer Excel-Datei pflegen kann. CSVDE hat allerdings den Nachteil, es kann nur Konten ohne Kennwörter anlegen. Nach dem Import sind die Benutzerkonten automatisch deaktiviert und es wären weitere Schritte notwendig. LDIFDE setzt zwar Kennwörter, aber das leider nur bei einer SSL-Verbindung. Bestehende Möglichkeiten wären: - DSADD - Net User - VBScript http://www.microsoft.com/technet/technetmag/issues/2007/09/adtools/default.aspx?loc=de Create User Accounts Based on Information in a Spreadsheet Script Repository: Active Directory User Accounts

Oder mit CSVDE bzw. LDIFDE. csvde zum Import und Export von AD-Daten nutzen - faq-o-matic.net Importdateien für CSVDE.exe einfach generieren - faq-o-matic.net Yusuf`s Directory - Blog - LDIFDE - LDAP Data Interchange Format Data Exchange

OK, jetzt habe ich dich verstanden ;) . Du musst natürlich mit einer Maschine deine Ziel-Domäne bereits erstellt haben, sonst funktioniert das migrieren mit ADMT nicht. Ich würde - wenn du keine weitere Maschine zur Verfügung hast - eine bessere Client-Maschine dazu nehmen, auf diesem den Windows Server 2003 installieren und anschließend die neue Domäne "Unternehmen.de" darauf erstellen. Achte aber darauf, weder der NetBIOS-Name, noch der DNS-Name der Domäne sollte mit einer der bestehednen Domänen kolidieren. Denn wenn die Quell- sowie Ziel-Domäne den gleichen Domänennamen haben (sei es nun der NetBIOS oder DNS-Name der Domänen) so kann es ebenfalls zu Problemen kommen. Sogar schon beim erstellen der Vertrauensstellung.

Auhaa... erkannt ;) . ... und die Computerkonten nicht vergessen ;) . Erst danach und wenn alle weiteren Dienste übernommen wurden, gilt es die DCs in der alten Domäne herunter- und in der neuen Domäne erneut, zum DC der neuen Domäne hochstufen. Das ADMT legt ein neues Benutzerkonto in der neuen Domäne an und fügt die SID des alten Benutzerkontos der alten Domäne an das neue Konto der neuen Domäne als SID-History hinzu. Damit kann das neue Benutzerkonto die alte SID als Ausweis vorweisen, wenn seine neue SID keinen Zugriff bekommt. Somit bleibt dem Benutzer auch das lokale Profil auf dem Client erhalten. Denn zum Migrieren der Benutzerprofile musst du im ersten Schritt das Benutzer-, anschließend das Computerkonto migrieren. Das habe ich jetzt zwar nicht verstanden, aber migriere eben die Konten zu der Domäne, die erhalten bleiben soll. Oder erstelle eine neue und migriere in diese Domäne. Ich meine einen Benutzer, der in beiden Domänen den gleichen Benutzernamen und das gleiche Kennwort hat. Aber wenn du es "nach Vorschrift" machst (Namensauflösung+Trust), wärst du auf dem "supporteten" Weg ;) .

Das auf jedenfall. Es gilt eben solch eine Aktion sorgfältig zu planen und alle Eventualitäten mit einzukalkulieren. Mir erscheint auch auf den ersten Blick, du für euch das Ein-Domänen Forest passen würde (sofern ich das von hier beurteilen kann). Benutzer- sowie Computerkonten (Clients+Memberserver) kannst du mit ADMT migrieren. Du kannst aber keine DCs damit migrieren! Dieses müssen aus der alten Domäne herunter und in der neuen Domäne erneut zum DC gestuft werden. Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To Wie bereits erwähnt, die DCs aus den anderen Domänen/Unternehmen musst du wie o.g. übernehmen (zuerst de- und dann promoten). Bezgl. der Dienste werden wie üblich DNS (was ohnehin benötigt wird), DHCP und evtl. WINS laufen. Diese kannst du dann in der neuen Struktur leicht abbilden. Was noch so an Diensten auf jedem einzelnen DC in jeder Filiale läuft, muss natürlich vorher gründlich aufgenommenanalysiert werden. Du musst die "anderen" Domänen auflösen. Dieses beinhaltet, dass die DCs aus diesen Domänen zuerst heruntergestuft werden müssen um dann in der neuen Domäne als DCs der neuen Domäne heraufgestuft zu werden. Das Tool das du für deine Benutzer- sowie Computerkonten benötigst, lautet ADMT. Um aber mit ADMT zu migrieren, wird eine bestehende Namensauflösung sowie Vertrauensstellung benötigt. Jetzt kann man aber "Trick 17" anwenden, wenn der "Administrator" in beiden Domänen das gleiche Kennwort hat, funktioniert ADTM sogar ohne eine Vertrauensstellung. Nur so als Info... Schon klar. Diese musst du leider, wie du bereits nun erfahren hast, in der neuen Domäne zu "zusätzlichen DCs einer bereits bestehenden Domäne" hinzufügen. Dabei sollte auf allen DCs das DNS installiert werden. Die Option lautet "Zusätzlicher Domänencontroller für eine bestehende Domäne". Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen

Das lässt sich aber auch aus meiner Antwort ableiten. Aber gut du es ansprichst. Idealerweise ist die Einstellung Hybrid 0x8 zu wählen.

Alles was mit NetBIOS zu tun hat, bekommt bei bestehenden WINS-Server direkt eine Antwort und muss nicht erst seine Frage (per Broadcast) in der Domäne verteilen.

Nicht gut. Ja, dass würde ich auch vermuten. Denn als die Datenbank entwickelt wurde, gab es keinen Windows Server 2003. Du musst zum einen im Internet weiter recherchieren, evtl. gibt es ja einen anderen Anbieter der dir helfen kann. Und zum anderen musst du "Jugend forscht" betreiben :( .

Servus, prizipiell sollte auch heute noch, ein WINS-Server im Unternehmen eingesetzt werden. Der WINS-Server erfordert kaum Arbeit/Administration und erleichtert dabei dem Administrator das tägliche Leben im wesentlichen. Jede Applikation die eine NetBIOS-Namensauflösung erfordert, profitiert vom WINS. Die Netzwerkumgebung basiert auf NetBIOS - Namensauflösungen und fällt unter den Begriff des "Browsing". Diese baut sich über den Computersuchdienst sowie NetBIOS-Broadcasts auf. Daher muss z.B. für die Netzwerkumgebung das NetBIOS over TCP/IP in den erweiterten LAN - Einstellungen des Servers aktiviert sein. Auch in einer Exchange Umgebung ist ein WINS-Server von großem Vorteil - um nicht zu sagen erforderlich. Diesen Artikel solltest du lesen: Brauche ich noch WINS, wenn ich ein AD betreibe? - faq-o-matic.net

Da würde ich garnicht lange überlegen und mit der neuen Maschine eine neue Domäne erstellen. Entweder richtest du dann die Benutzerkonten neu ein (was ich machen würde, unter Beibehaltung der Profile) und fügst die Clients in die neue Domäne hinzu oder migrierst mit ADMT. Wie gesagt, ein Anruf beim Hersteller regelt oftmals vieles. Oder du versuchst es selbst in einem Testlauf und kontrollierst, ob die DB läuft. Die zwei Zauberwörter lauten: Hersteller anrufen ;) .

Servus, wie wär es, wenn du einen Sniffer dazwischen hängst und die versendeten Pakete, einmal vom Windows 2000 und einmal vom XP-Client analysierst?

Aloha, na das ist doch mal eine schöne Aufgabe. Dann solltest du prüfen, ob diese Datenbanken auf einem neueren System bzw. Domäne noch laufen. Mit einem kurzen Anruf beim Hersteller ist das sicherlich schnell geklärt. Warum "jedoch"? Zumindest ist eine Redundanz vorhanden. Backup von was? Prizipiell hast du folgende Möglichkeiten: Wenn die PDC-NT-Hardware für Windows Server 2003 tauglich ist, kannst du diesen (mit installierten SP6a) auf Windows Server 2003 aktualisieren und installierst anschließend auf diesem das Active Directory. Ist die Hardware nicht tauglich, kannst du auf deiner neuen Hardware das Windows Server 2003 samt Active Directory installieren. Danach könntest du mit ADMT in die neu erstellte Domäne migrieren. Die dritte Variante wäre, wenn die NT-Hardware nicht für 2003 tauglich ist, installierst du auf deiner neuen Hardware ebenfalls NT und fügst diesen als BDC zur NT-Domäne hinzu. Im nächsten Schritt stufst du ihn zum PDC und aktualisierst dann auf 2003 und installierst das AD. Die vierte Variante wäre, du migrierst mit einer VM. Du installierst auf einer Hardware eine VM in der du NT installierst und diesen dann als BDC zur NT-Domäne hinzufügst. Anschließend stufst du die VM zum PDC und aktualisierst auf 2003. Bevor du aber anfängst, erarbeite ein Konzept. Wie soll der NetBIOS-Name bzw. DNS-Name der Domäne lauten etc.

Servus, kurz und schmerzlos: Nein, dass geht nicht. Aber warum kopierst du das Profil nicht auf das bestehende oder beachte diesen Artikel: Wie kann ich Benutzerprofile migrieren? - faq-o-matic.net

Moin, aber erst ab Windows Server 2003 :p . @Guybrush Alle Dienste die auf diesem DC laufen (wie z.B. WINS, DHCP etc.), gilt es auf einem anderen Server/DC zu übernehmen. Das DNS sollte ohnehin auf jedem DC installiert sein und zusätzlich solltest du darauf achten, dass noch weitere GCs existieren. Auch hier kann man die allgemeine Empfehlung geben, auf jedem DC den GC zu aktivieren. Das EFS-Zertifikat wurde bereits erwähnt. Wie es gesichert wird, steht in diesem Artikel: Was muss ich tun, um den ersten DC zu deinstallieren? - faq-o-matic.net Falls das noch ein 2000er DC sein sollte, kannst du nach dem demoten zuerst den Domänenfunktionsmodus gefolgt vom Gesamtstrukturfunktionsmodus auf Windows Server 2003 stellen, damit du von den Vorteilen die dir dieser Modus bietet (bessere Replikation etc.) profitieren kannst.

Ich verstand es aber so, dass du dich aus der Root-Domäne zur Child-Domäne verbunden und dann versucht hast ein Computerkonto zu erstellen. Wenn du direkt in der Child-Domäne, auf dem DC der Child-Domäne die MMC gestartet und es versucht hast, dabei der gleiche Fehler kam - dann kann es nicht an der MMC liegen. Ist bezgl. von Netinstall etwas am Schema geändert worden?

Dann kann das "nur" ein MMC/DLL Problem sein. Versuche auch mal das "ältere" AdminPak zu verwenden, dass ist bestimmt keine große Aktion. In der Child-Domäne tritt dieser Fehler nicht auf?

Off-Topic:Solange es zum Thema passt - wie es hier der Fall ist - ist doch alles in Ordnung ;) .

Servus, wie so oft - ist das entscheidende an der Authentifizierung das DNS und dazu kommt noch das Desgin im Snap-In "Active Directory-Standorte und -Dienste". 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-Object 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 dieses 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. Siehe aus: Yusuf`s Directory - Blog - Domänencontroller am Standort

Salve, ich hatte das bisher noch nicht. Wird dazu etwas im Vezeichnisdienst-Protokoll verzeichnet? Funktioniert es denn von einem Client - mit installiertem AdminPak - aus? Du könntest das AdminPak ernet auf einem DC installieren, da stellt sich evtl. eine DLL quer. Warum erstellst du händisch ein Computerkonto?

Servus, dann stell doch die Namensauflösung zuerst wieder her. Da es sich um Windows Server 2003 Gesamtstrukturen handelt, warum richtest du im DNS nicht einfach eine "bedingte Weiterleitung" ein? Das ist einfacher als mit sekundären Zonen zu arbeiten. Die Firewall hat alle benötigten Pots offen? How to configure a firewall for domains and trusts Generell müssen folgende Punkte in den Gesamtstrukturen eindeutig sein: - Der NetBIOS Name der Domänen - Der Fully Qualified Domain Name (FQDN) der Domänen - Die Security Identifier (SID) der Domänen

Servus, unter Windows 2000 muss zuerst der DC heruntergestuft-, umbenannt und erneut zum DC gestuft werden. Dieses wurde in Windows Server 2003 geändert. Dort hast du über die GUI jederzeit die Möglichkeit, den DC umzubenennen. Weder der Domänenfunktionsmodus, noch der Gesamtstrukturfunktionsmodus spielen dabei eine Rolle. Wenn du allerdings den DC mit NETDOM aus den Windows Support Tools umbenennen wolltest, muss sich die Domänenfunktionsebene im Modus Windows Server 2003 befinden. Anschließend sollte das DNS kontrolliert bzw. statische Einträge im DNS bzw. WINS und wo der Servername sonst noch eine Rolle spielt (z.B. Netzwerk-Applikationen) korrigiert werden. Wie kann man einen Domänencontroller unter Windows Server 2003 umbenennen? - faq-o-matic.net

Servus, das EFS-Zertifikat ist auf dem allerersten installierten DC zu sichern. Wenn dieser aber bereits in der Vergangenheit aus der Domäne genommen wurde, steht das Zertifikat ebenfalls nicht mehr zur Verfügung. Um sicher zu gehen das deine Vorgehensweise auch korrekt war, kannst du das noch einmal an diesem Artikel vergleichen: Was muss ich tun, um den ersten DC zu deinstallieren? - faq-o-matic.net Falls das Zertifikat nicht mehr existiert, kannst du entweder mit CIPHER /R ein neues generieren und diesen an die Clients per GPO verteilen lassen oder stellst das ganze auf vernünftige Beine - wenn du schon an den Einsatz von EFS im Unternehmen denkst - und installierst gleich eine PKI.

Eine Firewall ist auf dem Server nicht aktiv? Du kannst den bestehenden DC mit seiner IP anpingen? Der neue Server ist auch ein Windows 2000 Server? Das ist der NetBIOS-Name der Domäne. Ich weiß zwar immer noch nicht wo du was eingibst, aber der DNS-Name deiner Domäne lautet "gs062.local". In dem du z.B. in die DNS-Verwaltung auf dem bestehenden DC schaust.

Servus, im Bereich der FSMO-Rollen hat sich diesbezüglich von Windows Server 2003 zu Windows Server 2008 nichts geändert. Die Rollen haben ihre gleichen Funktionen wie bisher und sind weiterhin fünf an der Anzahl. In gewissen Situationen, muss lediglich die eine oder andere Rolle auf einem Windows Server 2008 DC liegen. Als Beispiel, möchte man einen RODC in einer Windows Server 2003 Gesamtstruktur hinzufügen, muss die Rolle des PDC-Emulators auf einem Windows Server 2008 liegen. Yusuf`s Directory - Blog - Read-Only Domain Controller (RODC) Daher das sich nichts bezgl. der FSMO-Rollen geändert hat, findest du darüber auch nichts. Im allgemeinen findest du die Neuerungen zu Windows Server 2008 auf diesen Seiten: Microsoft Corporation

Du hast also in den TCP/IP-Einstellungen (Netzwerkkarte) des neuen Servers, den bestehenden DC/DNS als "Bevorzugten DNS-Server" eingetragen. Der neue Server braucht den bestehenden DNS-Server. Bekommst du eine Fehlermeldung und falls ja, wie lautet diese? Na du trägst idealerweise den DNS-Namen der Domäne ein (obwohl ich immer noch nicht weiß, "wo" du dich gerade befindest).