Daim

So muss das sein :) Bitte tut mir einen Gefallen und benutzt auch die richtigen Begrifflichkeiten. Seit Windows 2000 gibt es nicht mehr PDC sowie BDC wie sie zu NT Zeiten existierten, sondern, es sind alle DCs und einer/manche DCs haben eine besondere Rolle. Dieser ist eben der Träger der fünf FSMO-Rollen. Des Weiteren heißt es nicht ADS sondern AD (das nur nebenbei). Danke für die Beachtung ;)

Das stimmt, wenn die Umbenennung über die grafische Oberfläche erledigt wird. Wenn man den DC mit NETDOM umbenennen möchte, muss sich der Domänenfunktionsmodus im "Windows Server 2003" befinden ;) Wie kann man einen Domänencontroller unter Windows Server 2003 umbenennen? - faq-o-matic.net

Wie sieht es mit diesen beiden Punkten aus ? Erstelle zum Test mal einen neuen Domänen-Admin (neuer Account).

Es heißt immer noch AD ;) Das AD ist nicht "Schrott". Führst Du das DCPROMO auch als DER Domänen-Admin aus ? Dieser hat in der bestehenden Domäne keine Probleme und darf die Domäne mit vollen Rechten administrieren ? Kontrolliere zusätzlich das DCPROMOUI.LOG das sich im Verzeichnis %Systemroot%\Debug befindet. Yusuf`s Directory - Blog - Debug Protokollierung

Servus, kontrolliere dieses: When you run Dcpromo.exe to create a replica domain controller, you receive the "Failed to modify the necessary properties for the machine account. Access is denied." error message

Schaden würde es nicht.

@Doudi 1. Spring nicht in den Threads hin und her, sondern bleibe in Deinem! Das verstößt gegen die Board-Regeln. 2. Empfehle ich dir, besorg dir externe Hilfe. Bei dir fehlen elementare Grundlagen. Ansonsten erleidest du Schiffbruch.

Servus, du weißt das das Mitbestimmungspflichtig ist bzw. vom Betriebsrat zu genehmigen ist ? Yusuf`s Directory - Blog - Dateizugriff überwachen

Du führst es direkt auf dem Schema-Master aus ? Dann kontrolliere mal folgendes: Schema Updates Require Write Access to Schema in Active Directory

Auweiiaa... also auf ein Ratespiel habe ich weiter keine Lust. Und ja, ADMT v. 3 kann nur auf einem Windows Server 2003 installiert werden, steht doch auch da: Downloaddetails: ADMT Version 3 Aber bei einem Standalone Server brauchst Du das auch nicht, wenn schon keine Domäne existiert.

Bitte gebe bei dieser Frage genaue Angaben an. Handelt es sich bei der Migration innerhalb einer Gesamtstruktur oder handelt es sich um eine Migration zwischen zwei Gesamtstrukturen ? Auf alle Fälle ist ADMT Dein Freund. Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To

Hallo, was meinst du mit "ganze Arbeit" ? Möchtest du in eine bestehende Windows 2000 Domänen einen zusätzlichen Windows Server 2003 Domänencontroller hinzufügen oder möchtest du von einer 2000er-Domäne in eine andere 2003er-Domäne migrieren ?

Von was sprichst du genau Wenn du in deine Windows 2000 Domäne einen Windows Server 2003 DC hinzufügen möchtest, dann wendest du zuerst ADPREP an und fügst den 2003er als zusätzlichen DC deiner bereits existierenden Domäne hinzu. Wegen der Ausfallsicherheit sollte auf dem 2003er auch das DNS installiert werden, wobei die Forward Lookup Zone auf dem 2000er DC AD-integriert gespeichert sein sollte. Wenn sich der 2003er DC mit dem 2000er DC repliziert hat, befinden sich die Benutzer/Gruppen auch auf dem 2003er DC. Das passiert automatisch. Mit ADMT migriert man z.B Benutzer- sowie Computerkonten von einer Domäne in eine andere. Das ist aber bei dir nicht der Fall. Also ist das ADMT nicht das Werkzeug das du brauchst.

Sehr viel. Bei einer Migration fast ein unverzichtbares Tool. Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To

Servus, dann existiert bei dir eine Forward Lookup Zone mit einem Punkt ".". Somit meint der DNS-Server das er ein Root-Server sei. Lösche diese Zone mit dem Punkt, anschließend kannst Du einen Forwarder eintragen.

Das kann dir nur der Hersteller der Applikation erklären :wink2: Am Ende stellt er es als Sicherheitsfeature hin...

Moin, How to configure a firewall for domains and trusts

Salut, daher sollte man sich auch an das A - G - DL - P Prinzip halten. Du richtest eine domänenlokale Gruppe (DL) in der Domäne ein, in der sich die Ressource (Freigabe) befindet. Dieser DL-Gruppe erteilst du die passende Berechtigung. Dann fügst du die jeweiligen globalen Gruppen aus den Zieldomänen in diese DL-Gruppe ein. Yusuf`s Directory - Blog - Gruppen

Servus, Yusuf`s Directory - Blog - Offline Dateien

Es ist noch kein Meister vom Himmel gefallen, dass ist richtig. Aber dein Vorhaben und das auch noch mit Exchange, ist für das "erste Mal" ein große Nummer. Du solltest über eine Verstärkung nachdenken. Bei Test des Systemlogs prüft das DCDIAG das Eventlog des DCs und kontrolliert dabei ob dort Fehlermeldungen enthalten sind. Ein Blick ins Eventlog hilft dabei und falls die Meldungen keine gravierenden sind, kannst Du dies vernachlässigen. Beim Test von "Trust Relation Ship" werden bestehende Vertrauensstellungen getestet. Falls keine Vertrauensstellung existiert (so wie es bei dir der Fall zu sein scheint), ist das zu vernachlässigen. Das gleiche gilt für den "WAN Configuration Test". Diesen kannst Du ebenfalls vernachlässigen.

Uii... das hatte ich verwechselt und das obwohl mir die beiden Artikel auch noch bekannt waren :(

Warum "und"? Mit dem AdminPak werden doch die Windows Support Tools installiert?

Korrekt, aus "Macht der Gewohntheit" schreibe ich immer von einem DC aus dem System32 Verzeichnis, aber standardmäßig befindet sich das AdminPak auf allen Windows Server 2003 Servern. Das schon, aber der OP meldet sich an einem DC an, da würde ich "bloß" die entsprechende DLL registrieren ;)

Wenn Du das AdminPak installieren möchtest, so macht man das entweder über einen Download, über die 2003 CD oder von einem DC aus dem Verzeichnis %windir%\system32\adminpak.msi. Das Schema Snap-In muss vorher, so wie thorgood es geschrieben hat, registriert und anschließend in einer MMC hinzugefügt werden.

Servus, zuallerst heisst es "AD" und nicht "ADS" ;). Zu Deiner Frage: Die standortübergreifende (Inter-Site) Replikation zwischen zwei Standorten lässt sich als alternative durch das "Simple Mail Transfer Protocol (SMTP)" realisieren. Die Replizierungsinformationen werden dabei vor ihrer Übertragung komprimiert um somit die zur Verfügung stehende Bandbreite effizient zu nutzen. Die Replikation über das SMTP-Protokoll unterstützt ausschließlich die standortübergreifende Replikation zwischen verschiedenen Domänen, sodass die beteiligten DCs verschiedenen Domänen angehören müssen. DCs ein und derselben Domäne müssen auf die standortübergreifende IP-Replikation zurückgreifen. Die Domänenpartition kann nicht über das SMTP-Protokoll repliziert werden (by Design). Dadurch das die Domänenpartition nicht repliziert wird, können z.B. keine Benutzer, Gruppen oder Computerobjekte repliziert werden. Da das SMTP Protokoll kein sicheres Protokoll ist, wäre es notwendig für die Replikation über SMTP eine CA in der Organisation zu installieren. Dadurch werden die Replikationsinformationen digital signiert und verschlüsselt. Denn damit wird sichergestellt, dass die gesendeten Daten unverändert beim Empfänger landen. Ergo; Ein hoher Aufwand. Diese Möglichkeit über das SMTP-Protokoll zu replizieren ist eher eine theoretische. Das wurde von Microsoft als AD designet wurde, mit implementiert, da man noch keine Abschätzung treffen konnte, wie hoch die Replikationslast sei und wo noch WAN-Bandbreite Luxus war. Diese Befürchtung hat sich als heute nicht bestätigt. In der Praxis wird die SMTP-Replikation kaum eingesetzt, da sie ohnehin nur den globalen Katalog, die Schemapartition und die Konfigurationspartition replizieren würde.