Daim

Aloha, na klar. Im ersten Schritt wird der Benutzer und im zweiten wird das Computerkonto migriert. Beim zweiten Schritt "übersetzt" man die lokalen Ressourcen. ADMT ändert z.B. nicht die ACLs der Freigaben oder Files, sondern legt einen neues Benutzerkonto in der neuen Domäne an und fügt die SID des alten Benutzerkontos aus der alten Domäne, an das neue Benutzerkonto der neuen Domäne als SID-History zu. Nein, dass sollte automatisch funktionieren. Daher ist es auch wichtig, dass die Ziel-Domäne sich im einheitlichen Domänenfunktionsmodus befindet, denn nur dann, kann die SID-History genutzt werden.

Hallo, wenn der erste Windows Server 2003 R2 in eine Domäne als Domänencontroller hinzugefügt wird, MUSS das ADPREP von der zweiten CD mit dem Schalter /FORESTPREP auf dem Schema-Master ausgeführt werden, anschließend danach mit dem Schalter /DOMAINPREP auf dem Infrastruktur-Master. Du musst das ADPREP ausführen, bevor du den Server zum DC in der Domäne hoch stufst. Du brauchst aber nicht das ADPREP ausführen, wenn du den Server nur als Mitgliedsserver hinzufügst und du nicht die neuen R2 Features nutzen möchtest. Lies die unten stehenden Links, dann wird es klarer ;). Auf der ersten R2 CD ist nichts weiter als ein Windows Server 2003 mit integriertem SP1 drauf. Erst mit der zweiten R2 CD werden die R2 Erweiterungen installiert bzw. das System auf R2 erweitert. Die zweite CD macht daraus ein "R2" indem Zusatzkomponenten unter Systemsteuerung - Software eingetragen werden, die man dann für bestimmte Szenarien nachinstallieren kann. Wenn Du ein R2 hast, schau mal auf die zweite CD im Ordner DOCS. Die dortige Datei R2SETUP.CHM enthält alle Informationen über R2. Als Anleitung siehe: Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 Yusuf`s Directory - Blog - Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update) Yusuf`s Directory - Blog - Den ersten/einzigsten Domänencontroller austauschen Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen

Servus, hier findest du auch eine gute Anleitung ;) Yusuf`s Directory - Blog - Den ersten/einzigsten Domänencontroller austauschen

Servus, also der Domino-Server ist ganz klar, die eierlegende Wollmilchs... Die Replikation bzw. ein Update/Migration kann leichter nicht gehen. Das "negative" am Lotus Notes ist der Client. Er ist nicht transparent genug für den Otto-Normal Benutzer der in der Regel mit Microsoft Produkten arbeitet. Bis der User mit dem Notes-Client warm wird, vergehen Tage bzw. Wochen. Deswegen treibt IBM auch so Websphere so voran. Ich denke der Notes Client wie es bisher existiert, wird sterben. Dein Vergleich den du haben möchtest, hängt aber viel von eurer Umgebung bzw. Workflow ab. Wie wird mit was gearbeitet? Was soll wohin repliziert werden usw. Geht es nur ums reine mailen und etwas kalendering, dann sollte man Exchange ins Auge fassen.

Dann schau dich mal bei UTIMACO um, die sind im professionellen Bereich einer der Besten. Utimaco Safeware AG Ansonsten wie unsern Doc bereits erwähnte, einfach auf Longhorn warten ;).

Du machst deine Hausaufgaben nicht :( .

Bei solchen Vorgängen würde ich es sowieso immer händisch erledigen. So kann man sich dessen immer bewusst sein, was man ausführt ;).

Servus, war es nicht so, dass die Rollen erst mit dem SP1 automatisch verschoben werden?

Servus, um den Server zu klauen, muss man physikalisch an den Server ran. Wie? Der Server steht "mitten im Raum"? Dann brauchst du dir um die Daten keine Gedanken zu machen. An dem Server hängt evtl. noch das Backup und die Bänder stehen neben dran?

Ich hatte geschrieben: Was das Thema Imaging von DCs betrifft, lies: Yusuf`s Directory - Blog - Images als Sicherung ? Warum Images nicht als Datensicherung taugen - faq-o-matic.net ... und vorallem der Papst :cool:

Salut, es heißt AD ;). Zerlegen kannst du nicht das AD, höchstens die Maschine :(. Eine Garantie das nichts schief geht, kann dir keiner geben. Daher solltest du vorher immer an das Backup denken und vorallem an eine Sicherung des SYSTEM STATES.

Servus, nein. Das "Computerkonto zurücksetzen" setzt das Computer-Kennwort zurück. Das wäre das gleiche, wie wenn du NETDOM RESET .. ausführen würdest. Wenn man z.B. das Computer-Kennwort eines DCs zurücksetzen möchte, dann geht das nicht über die GUI (ADBuC) sondern kann nur mit NETDOM zurückgesetzt werden. Falls man es über die GUI versuchen würde, bekäme man auch eine entsprechende Meldung. Dieser Befehl setzt das Kennwort für den sicheren Kanal zurück.

Du hast einen Denkfehler ;). Du fügst lediglich eben die zweite R2-CD hinzu, mit eben den neuen R2 Features. Wenn ein Windows Server 2003 das SP2 installiert hat, dann fehlen ihm trotzdem die neuen R2-Features die er eben nur durch die zweite R2-CD erhält und nicht durch das SP2. Das SP2 ist für beide Version: Für Windows Server 2003 sowie für Windows Server 2003 R2. Wie bereits erwähnt, der Kern von R2 ist ein Windows Server 2003 mit SP1.

Servus, über Sinn und Unsinn lässt sich lange diskutieren. Fakt ist, ich mache mir das Leben gerne leicht und würde sogar einen DHCP-Server für 5 Benutzer installieren. Das kommt viel mehr auf die Firmenpolitik drauf an. Yepp. Ich kenne viele Unternehmen die wie oben erwähnt, auch für 5 Benutzer einen DHCP installieren. Das kann man natürlich machen. Das ist ja der Witz an der Sache. Das AD hat mit dem DHCP kaum bis garnichts zu tun. Im AD autorisiert man lediglich nur die WINDOWS-Server die in einem AD-Forest DHCP-Server spielen dürfen. Verhindert das AD wenn man einen Router auf dem der DHCP-Dienst aktiviert ist, ins Netz bringt das dieser keine Adressen verteilt? Nein, tut es nicht. Der Router würde in aller Ruhe Adressen verteilen. Der Knackpunkt ist eben an dieser Stelle der Windows-Client. Dieser düfte halt keine Adressen von einem nicht autorisierten DHCP-Server annehmen. Lange Rede kurzer Sinn: Das AD hat keine Belastung wenn du 20 oder mehr DHCP-Server integrierst.

Hallo, warum soll das nicht funktionieren? Windows Server 2003 R2 wird auf zwei CDs geliefert. R2 ist keinerlei Update der Betriebssystemkomponenten. R2 müßte man eher "Feature-Pack" nennen. Die erste CD von R2 ist ein Windows Server 2003 mit Service Pack 1. Die zweite CD macht daraus ein "R2" indem Zusatzkomponenten unter Systemsteuerung - Software eingetragen werden, die man dann für bestimmte Szenarien nachinstallieren kann. Der Unterschied ist lediglich die zweite R2 CD, wo sich die neuen Features befinden, die dem Schema hinzugefügt werden. Ein Windows Server 2003 SP2 (kein R2) hat eben diese neuen R2 features nicht und kann diese natürlich noch erhalten (ADPREP). Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2

Moin, yepp, dass hatten wir damals auch so gemacht. Du musst nur darauf achten, dass die benötigten Treiber installiert sind. Wenn der Soundkarten-Treiber fehlt, ist das nicht schlimm ;). Ja, du kannst ihn als NetBIOS-Namen und/oder als DNS-Namen (mit den Vor- und Nachteilen) verwenden. Die externe Domain example.com sollte euch gehören. Dann wirst du aber Probleme bekommen, wenn beide Domänen den gleichen Domänennamen haben und du von einer Domäne auf die andere zugreifen möchtest.

Nope. Das funktioniert auch bevor das AD bereinigt wurde ;).

Servus, du musst natürlich den gecrashten DC mit NTDSUTIL - METADATA CLEANUP bzw. ADSI Edit aus dem AD entfernen. Sonst meint der andere DC immer noch, sich mit diesem replizieren zu wollen: Entfernen von Daten aus Active Directory nach fehlgeschlagener Domänencontroller-Herabstufung

Wenn der OP das mit einem Benutzer versucht, der bereits zwischengespeichert ist (es besteht ein lokales Profil), dann ist das kein Wunder ;). Er müsste es mit einem Benutzer testen, der nach dem einrichten der Policy, sich noch nicht an dem Client angemeldet hatte.

Heißt das Problem dann nicht LAYER 8 ;) Die Meldung war auch eindeutig ;). Rufe REGEDIT auf und navigiere zu: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters. Dort kontrollierst Du den Eintrag "Schema Version". Die Zahl in Klammer (Version), z.B. (30) bedeutet Windows Server 2003 mit oder ohne SP1. Die Zahl (31) bedeutet Windows Server 2003 R2. Oder du kontrollierst mit ADSIEdit im Pfad: CN=Schema,CN=Configuration,DC=<DeineDomäne>,DC=<TLD>, dass Attribut objectVersion.

Servus, das geht nicht per ADSI bzw. einer Abfrage. Man kann die Anzahl bei sAMAccountName nicht definieren. Das beudeutet, du machst eine Abfrage mit allen Benutzern und verarbeitest diese Abfrage weiter und suchst die User mit länger als 15 Zeichen. Dsquery ist nicht das richtige Werkzeug dazu. Carmen kenn ich nicht genau. Da musst du dir einen anderen Weg suchen.

Buenos dias, richtig. Wenn der neue DC der erste Windows Server 2003 R2 DC ist, dann ist das ADPREP von der zweiten CD auszuführen. Der Schalter /Forestprep ist auszuführen. Damit wird das Schema auf die Version 31 aktualisiert. Da aber die Domäne bereits auf 2003 läuft, ist der Schalter /Domainprep nicht anzuwenden. Die Domäne läuft bereits auf 2003. Mit dem Schalter /Forestprep werden lediglich die R2 Features dem Schema (und nicht der Domäne) hinzugefügt. Hat mit der Fehlermeldung die der OP erhält, nullstens zu tun ;). Kann sein, kann aber auch nicht sein. :p Bei einer Migration von NT auf 2003 hat man während DCPROMO die Möglichkeit zwischen "Windows 2000 gemischt" und "Windows 2003 Interim" zu wählen. Aber wie gesagt, der Modus hat nichts mit der Fehlermeldung zu tun. @ dvbuddy Deine Fehlermeldung ist eindeutig. ADPREP von der zweiten CD gilt es auf dem Schema-Master mit dem Schalter /FORESTPREP auszuführen, wenn der neue Server der erste R2-DC in deiner Domäne/Gesamtstruktur ist. Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 Du kannst auch mal kontrollieren, ob du das Schema aktualisieren darfst: Schema Updates Require Write Access to Schema in Active Directory

Null Problemo (würde Alf sagen). Yepp, tue das. Schlafe auch mal eine Nacht darüber und lass es dir in den Träumen noch einmal durch den Kopf gehen ;). Yepp, kannst du gerne machen. Aber bevor du weitere Fragen stellst, lies dir bitte die folgenden drei Links durch, vorallem das erste. Er ist zwar in englisch, lässt aber kaum Fragen offen. Microsoft Corporation Replikation: Standorte & Standortverknüpfungsbrücken - faq-o-matic.net Active Directory-Replikation - faq-o-matic.net

In den Eigenschaften der Standortverknüpfung kann man einen Zeitplan definieren (Zeitplan ändern...). Dort kann man festlegen, zu welchen Zeiten eine Replikation stattfinden kann. Wenn z.B. eine geringen WAN-Leitung besteht, kann man festlegen, dass die AD-Replikation nur AUßERHALB der Bürozeiten repliziert werden darf. Standardmäßig repliziert das AD den ganzen Tag alle 180 Minuten zwischen allen Standorten die durch Standortverknüpfungen verbunden sind. In dem Verbindungs-Objekt (wenn man auf NTDS-Settings klickt) legt man fest, in welchen Intervallen repliziert werden soll. Dort kann die Zeit zwischen 15 Minuten bis 10.080 Minuten betragen. Standortintern (Intra-Site) gibt es keinen Zeitplan. Dort wird über Änderungsbenachrichtigungen repliziert. Genaues entnimmst du bitte auf diesem Artikel: Yusuf`s Directory - Blog - Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren Siehe obige Erläuterung.

Hallo, ich schreibe mal eins-zwei Sätze... in dem Container IP befinden sich die Standortverknüpfungen, welcher Standort mit welchem Standort repliziert. Diese gilt natürlich auch für die SMTP Replikation auch was die Zeiteinstellung betrifft. Aber in der Praxis wird immer über das IP Protokoll repliziert. Das bedeutet, es wird über RPC over IP repliziert. Das SMTP-Protokoll wurde quasi als Sicherheit mit in die AD-Replikation aufgenommen, als man noch keine Erfahrung mit der AD-Replikation hatte. 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. Standardmäßig sind die einzelnen Standortverknüpfungen alle überbrückt. In den Eigenschaften des IP-Containers kann die Überbrückung deaktiviert werden. Dadurch kann man gezielt Standortverknüpfungen erstellen und somit kann nicht mehr jeder Standort mit einem x-beliebigen Standort replizieren. Was aber standardmäßig so ist. Entscheidend bei der AD-Replikation ist natürlich das Routing. Besteht ein voll durchgeroutetes WAN oder eine Hub-and-Spoke Topologie. Standortintern (Intra-Site) wird öfters repliziert wie standortübergreifend (Inter-Site). Der KCC (Knowledge Consistency Checker) ist ein Prozess des Active Directory`s und dieser ist dafür zuständig, dass in einer Gesamtstruktur eine effiziente Replikationstopologie entsteht. Innerhalb eines Standort`s wird nach einem Ringentwurf repliziert. Standortübergreifend baut der KCC ein spanning-tree auf. Für die standortübergreifende Replikation ist der ISTG "Inter-Site Topology-Generator" zuständig. Dieser ist eine Komponente des KCC. Wichtig für die Replikation sind die Informationen, die in "Standorte- und Dienste" eingetragen werden. Daher sollte man stets darauf achten, dort alles zu konfigurieren damit eine effiziente Replikationstopologie entstehen kann. To be continued... ;)