Daim

Hola, ja, dass Quellobjekt wird bei einer InTRA-Migration entfernt. Es ist noch weiterhin so. Nein, dass ist auch heute noch genau so. Alle Objekte können nur in einen Container migriert werden. Man kann z.B. nicht die Benutzer von den Gruppen trennen, leider. Ja, gerade bei einer längeren Migration spielt imho Quest seine Stärken aus. Weitere Vorteile von Quest wären aber: - Volle Undo-Funktionalität, bei AD-Objekten und auch beim Re-ACLing. ADMT kann nur letzten AD-Lauf, nicht das Re-ACLing zurückführen. - Migration der AD-Standorte, Subnets, Sitelinks ist nur mit Quest möglich, nicht aber mit ADMT. - Mit Quest kann die Quell-OU migriert werden, nicht aber mit ADMT. - Mit Quest können während der Migration die Daten verändert werden (z.B. HR-Daten hinzufügen). - Vertrauensstellungen können mit Quest migriert werden, nicht aber mit ADMT. usw. usf. Man darf eben eins dabei nicht vergessen, ADMT ist kostenlos und dafür kann es schon eine ganze Menge. Aber auch (wie gerade bei mir, ich muss nämlich bei einem Kunden seine 20 Subdomänen in die Root-Domäne migrieren ;) ) bei einer InTRA-Forest Migration spielt Quest seine Stärken aus. Der Kunde hat sich eben zu Quest entschieden, da bei dieser Variante der Migration der Benutzer "kaum" etwas davon merkt. Natürlich hätte man das auch mit ADMT realisieren können, jedoch hätte dabei mehr nach Feierabend durchgeführt werden müssen oder am Wochenende. Bis zum Jahresende müssen 20 Domänen migriert werden. So bleiben die Ausfallzeiten der produktiven Einheiten, bei einer Intra-Forest Migration mit dem Quest Tool eben geringer als mit ADMT. P.S. Das war auch der Grund, warum ich überhaupt keine Zeit hatte, mich beim Beta-Test von Josè zu beteiligen. In Kürze pinsele ich ohnehin einen "ADMT vs. Quest" Artikel. Also ich finde es nicht schlecht. Quest hat seine Vorteile. Man kann aber auch jede Größe einer Umgebung auch mit ADMT migrieren. Der Preis von Quest (13 Euro pro zu migrierender Benutzer, wobei je nach Anzahl der Benutzer ca. 10% Rabatt drin ist) ist auch nicht ohne.

Lass mich raten: Du hast dir das Whitepaper zu ADMT - NICHT - durchgelesen? Wenn eine INTRA-Forest Migration durchgeführt wird, also z.B. sollen alle Subdomänen in die Root-Domäne innerhalb einer Gesamtstruktur migriert werden, dann wird standardmäßig das Benutzerobjekt aus der Quell-Domäne entfernt. Bei einer INTER-Forest Migration (zwischen zwei Gesamtstrukturen) bleibt das Objekt in der Quell-Domäne weiterhin bestehen. Teste das doch mit einem Test-Benutzer, dann siehst du es und vorallem, lies das Whitepaper und führe eine Test-Migration in einer Testumgebung durch. Wenn es ein kommerzielles Werkzeug sein darf, dann ist hier der "Migration Manager for Active Directory" von Quest sehr zu empfehlen. Mit diesem Werkzeug, bleibt auch das Bentzerobjekt bei einer INTRA-Forest Migration in der Quell-Domäne bestehen. Hier kann vieles im Hintergrund, ohne das die Benutzer etwas davon merken, durchgeführt werden.

Büddee. Sonne, Strand und... ;)

Eine Domänenaktualisierung ist auch keine Angelegeheit die in 5 Minuten durchgeführt ist. Und idealerweise fügst du einen *zusätzlichen* Windows Server 2008 auf einer separaten Maschine der Domäne hinzu. Natürlich muss vorher das Schema aktualisiert werden. Das unterscheidet sich doch von Fall zu Fall und kommt eben immer auf die Umgebung an. Den GPOs geht es gut und sie bleiben erhalten.

Hallo, kennst du auch diesen schon? Yusufs Directory Blog - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen NUR über einen zusätzlichen Server. Du kannst einen Windows 2000 DC nicht per Inplace-Upgrade auf Windows Server 2008 updaten. Das geht erst mit Windows Server 2003 SP1. Ja, musst du auch. Lies dir einfach den o.g. Artikel durch, dann weißt du bescheid. ;)

OK. Wenn möglich, sollte Exchange NICHT auf einem DC laufen, sondern auf einem Memberserver. Aber da du nur einen DC hast, musst du den Windows Server 2008 als zusätzlichen DC, zur bestehenden Domäne hinzufügen. Doch bevor der 2008er als DC heraufgestuft werden kann, musst du das Schema aktualisieren. Yusufs Directory Blog - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen Yusufs Directory Blog - Einen zusätzlichen DC in die Domäne hinzufügen Yusufs Directory Blog - Die FSMO-Rollen verschieben Yusufs Directory Blog - Globaler Katalog (Global Catalog - GC) Der Rest passt soweit.

Buenas noches, es wäre empfehlenswert in seiner Umgebung Server lediglich mit der gleichen Sprache zu installieren. Es ist jedoch technisch möglich und wird auch seitens Microsoft supportet, Server mit verschiedenen Sprachen nebeneinander zu betreiben. Wenn z.B. mit GPOs gearbeitet wird, sollte in einem "Mischbetrieb" mit den SIDs gearbeitet werden und nicht mit den Namen. Denn z.B. heißt es im deutschen Betriebssystem "Domänen-Benutzer" und im englischen" Domain Users". Wie bereits erwähnt, technisch möglich ist es. Allerdings gilt es die Gefahren zu kennen. Siehe auch: Aktives Verzeichnis Blog : Domänencontroller in unterschiedlichen Sprachen - möglich oder nicht?

Ahoi, ist das wirklich notwendig? Umso weniger Domänen existieren, desto einfacher gestaltet sich die Administration. Du sparst auch Hardware- sowie Lizenzkosten. Denn wenn möglich, sollte wegen der Ausfallsicherheit in jeder Domäne min. zwei DCs existieren. Sind das nicht alle produktiven Forests dieses Planeten? Du hast bisher nicht die Serverversionen die bereits im Einsatz sind und die an "ort3" kommen erwähnt. Im Idealfall, wenn alle Serverversionen gleich sind, musst du lediglich DCPROMO auf einer Maschine ausführen, um die Subdomäne "ort3" zu erstellen. Es ist dann noch nicht einmal eine Schemaaktualisierung notwendig. Daher ist dieser Vorgang recht unkritisch. Es werden dann lediglich die gesamtstrukturweiten Verzeichnispartitionen (sowie das DNS und der GC) auf die "neue" Maschine repliziert. Und falls eine Schemaaktualisierung notwendig wäre, wird das ja mit dem Tool ADPREP durchgeführt. Das Tool ist intelligent genug und richtet keinen Schaden an. Wenn die Basis stimmt und kein Pfusch vorher im Schema getrieben wurde, dann geht mit ADPREP nichts schief. Falls das ADPREP nicht erfolgreich die Schemaaktualisierung durchführen kann, meldet es dir genau, warum es nicht erfolgreich war. Natürlich sollte vorher eine System State Sicherung erstellt werden. Kannst du gerne machen. Jedoch halte ich das bisher, mit den Informationen die bereits vorliegen, für nicht notwendig. Aber abgesehen davon kannst du dir mit dem kostenlosen VMWare Converter, einen DC der Root-Domäne in eine VM konvertieren lassen und an dieser, deine Tests durchführen. Hierbei sollte man aber vorsichtig sein, denn in der VM befinden sich dann auch alle Kennwörter der Benutzer sowie der wichtigen administrativen Konten. Das klingt etwas verquer. Eine bereits erstellte Domäne kann nicht "einfach so" in eine andere Gesamtstruktur integriert werden. Du müsstest dann mit ADMT von einer Domäne, in die andere migrieren. Warum diesen Akt? Deine Umgebung kannst du ja mit DCDIAG sowie NETDIAG aus den Windows Support Tools überprüfen. Damit kontrollierst du den "Gesundheitszustand" der DCs. Falls Probleme bestehen, wird dir das ohnehin im Eventlog der DCs angezeigt. Vergiss es. So wie ich es bereits erwähnt hatte, du müsstest mit ADMT in die andere Gesamtstruktur migrieren. Das lohnt den Aufwand nicht. Eine Domäne kann nicht von einer Gesamtstruktur in eine andere "einfach so" integirert werden. Dazu ist eine Migratione notwendig.

Salut, du suchst die supportete Variante, nämlich SYSPREP. Versiegeln eines Vista Images mit sysprep - Deploymenttechnologien

Salut, Off-Topic:auweia... das habe ich jetzt auch bei mir korrigiert. Danke für den Hinweis. :)

Servus, es ist zwar empfehlenswert das man auf dem DNS-Server eine Weiterleitung z.B. auf den Router einrichtet, jedoch ist das nicht zwingend notwendig. Denn der DNs-Server kann auch über seine "Stammhinweise", den Root-Servern die Namensauflösung durchführen. Die Root-Server findest du in den Eigenschaften des DNS-Servers in der DNS-Konsole, im Reiter "Stammhinweise".

Salut, wenn die Migration abgeschlossen ist, wäre es ohnehin empfehlenswert die SIDHistory zu bereinigen. Nach dem bereinigen der SIDHistory kann der Benutzer lediglich mit dem "neuen" Benutzerkonto auf die Ressourcen zugreifen. Die ACL-Umsetzung sollte zu diesem Zeitpunkt abgeschlossen sein. How To Use Visual Basic Script to Clear SidHistory Wenn sich ein Benutzer nämlich anmeldet, bekommt er ein Access-Token in dem seine richtige SID, die SID der SIDHistory und die SID's aller Gruppen, denen der Benutzer angehört, enthalten ist. Das Access-Token kann aber max. 1024 Einträge enthalten und von daher, sollte nach einer Migration die SIDHistory stets bereinigt werden. Es kommt darauf an, wie das Re-ACLling der Ressourcen durchgeführt wurde. Wenn die Migration z.B. mit ADMT durchgeführt und der Security Translation Wizard ausgeführt wurde, kannst du davon ausgehen, dass die ACLs "eins zu eins" umgesetzt wurden. Vorausgesetzt, es wurde alles richtig und erfolgreich vorher durchgeführt. Ansonsten merkst du es sehr schnell wo etwas "hakt". ;)

Hello, deaktiviere das SIDFiltering. Netdom TRUST <TrustingDomain> /domain:<TrustedDomain> /quarantine:No /userD:<DomänenAdminkonto> /passwordD:<Kennwort> Erklärung: MS02-001: Forged SID could result in elevated privileges in Windows 2000

Hola, eine Namensauflösung (z.B. eine "bedingte Weiterleitung") hattest du aber eingerichtet? Ansonsten, hast du auch auf dem Windows Server 2008 DC folgenden Registry-Eintrag erstellt? HKLM\System\CurrentControlSet\Services\Netlogon\Parameters Registry value: AllowNT4Crypto Type: REG_DWORD Data: 1 Überprüfe auf jedenfall die Vorrausetzungen anhand des Whitepapers. Download details: ADMT v3.1 Guide: Migrating and Restructuring Active Directory Domains

Salut, dann kannst du diesen Fehler ignorieren. Siehe: Event IDs 40960 and 40961 in the System Event Log When You Restart Windows Server 2003 After You Run Dcpromo.exe

Servus, du kannst mit NTDSUTIL ooder ADSIEdit die Leiche aus dem AD entfernen. Yusufs Directory Blog - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen Des Weiteren solltest du überprüfen, ob der noch vorhandene DC die FSMO-Rollen trägt und falls nicht, diese auf ihn "seizen". Yusufs Directory Blog - Die FSMO-Rollen verschieben Ansonsten kontrolliere das Eventlog ob nicht evtl. noch weitere Fehler existieren und führe auch mal ein DCDIAG (aus den Windows Support Tools) auf dem DC aus.

Moin Meenzer,

Ja, aber nicht nur der Core-Server. Im nächsten Server-Betriebssystem wird die Powershell 2.0 generell mehr Einzug nehmen. Auch im AD-Bereich mit mehr als 85 Cmdlets. Also eins kann ich dir versichern, NTBACKUP wird nicht mehr zurück kommen. ;) Weitere offizielle Infos gibts hier: http://download.microsoft.com/download/F/2/1/F2146213-4AC0-4C50-B69A-12428FF0B077/Windows_Server_2008_R2_Reviewers_Guide_(BETA).doc

Nicht weiter darüber nachdenken. Glücklich sein das es zum Wochenende wieder rund läuft. ;) Zu mal es ohnehin empfehlenswert ist, die FSMO-Rollen auf dem aktuellesten DC zu betreiben. http://blog.dikmenoglu.de/PermaLink,guid,5aee4b82-3dd9-4480-a35c-c3d0b0e35fdd.aspx

Bleibt nur noch zu sagen, dass diese Art des "Backups" seitens Microsoft nicht supportet wird. Zumal der OP nach: sucht. ;)

Servus, als Backup für die Domäneninformationen reicht eine System State- bzw. ASR-Sicherung aus.

Salut, nein, denn es kann nur einen SBS in einer SBS-Domäne geben, keine weiteren. Wenn du einen Printserver haben möchtest, solltest du einen "normalen" Windows Server 2003 zur SBS-Domäne hinzufügen. Siehe auch: Yusufs Directory Blog - Die Besonderheiten eines Small Business Server`s (SBS)

Du weißt selbst, meist darf es nichts kosten. Da sollte man eben die Möglichkeiten der Bordmittel vollstens ausnutzen. Ist zumindest besser, als nichts zu nutzen. ;)

Buenos dias, du könntest das AD abfragen, wann sich das Benutzerkonto das letztemal angenmeldet hat. Dazu musst du das Attribut "Last Logon" abfragen. Der Nachteil daran ist, dass dieses Attribut nicht zwischen den DCs repliziert wird. Du musst also jeden DC in der Domäne abfragen, um das aktuellste Datum zu erhalten. Es gibt zwar noch das Attribut "LastLogonTimeStamp" was zwischen den DCs repliziert wird, jedoch ist der Wert nicht tagesaktuell. Siehe dazu: Yusufs Directory Blog - Die letzte Benutzeranmeldung herausfinden

Hola, wie mein Vorredner bereits geschrieben hat, definiere die Kennwortrichtlinie entsprechend (Kennwortlänge, Komplexität etc.) auf Domänenebene und gut ist. Wenn in den Eigenschaften der Benutzerkonten dann noch die Option "Benutzer muss Kennwort bei der nächsten Anmeldung ändern" gesetzt wird, werden die Benutzer bei ihrer nächsten Anmeldung aufgefordert, ihr Kennwort zu ändern. Siehe auch: Yusufs Directory Blog - Das Kennwortalter zurücksetzen