Daim

Nein, müsst ihr nicht. Ihr müsst lediglich dem alten Dienstleister gehörig in seine vier-Buchstaben treten und zwar mächtig. Der Kunde ist König, was er sagt wird so gemacht. Also würde ich mit dem Kunden zusammen dem alten Dienstleister - wenn es sogar sein muss - mit rechtlichen Schritten drohen. Denn mit ADMT hast du einfach ein leichtes Werkzeug um somit die Benutzer- und die Computerkonten zu migrieren. Das erspart dir ne Menge Arbeit. Die Antwort kennst du --> ADMT. Also eine ziemlich größere Angelegenheit. Umso mehr würde ich darauf drängen, um mit ADMT zu arbeiten.

Rischtisch ;). Auf allen DCs auch den globalen Katalog zu aktivieren.

Nein, passt schon. Achte darauf, dass in den TCP/IP-Einstellungen des DCs ein bestehender DNS-Server drin steht. Nun ein wenig Geduld, bis die AD-Replikation stattgefunden hat.

Ja, genau aus diesem Grund wurde die TSL auf 180 erweitert. Um eben ein größeres Zeitfenster in der TLS für gelöschte Objekte zu haben. Wenn du es fü diesen Zweck nutzen möchtest, ist es ok. Man kann natürlich den Wert verändern wie einem lustig ist, es sollte aber schon Sinn machen. Man muss auch einkalkulieren, dass durch das verändern der TSL die AD-Datenbank (NTDS.DIT) größer wird. Nein, dann hast du nicht verloren. Sondern würdest deine System State-Sicherung auspacken und das Objekt autoritativ wiederherstellen.

Kooorrrrekt. Aber eben laut diesem Artikel The default tombstone lifetime (TSL) value remains at 60 days instead of increasing to 180 days in Windows Server 2003 R2 soll nach der Installation des SP2 die TSL auf 180 Tage gesetzt sein. Dabei bleibt im Attribut der Wert auf <Not Set> stehen. @IT-Home Vooorrsicht! Man beachte diesen Artikel: Das Geheimnis der Tombstone Lifetime - faq-o-matic.net Wenn R2 installiert sein sollte, dann darf auf diesem lediglich die erste CD installiert worden sein. Danach ist der Server heraufzustufen, um die 180 Tage der TSL zu nutzen. Wenn man den Server mit beiden R2-CDs installiert und dann erst zum DC stuft, dann beträgt die TLS 60 Tage da ein Fehler auf der zweiten R" CD existiert. Dort steht nämlich in der Schema.ini fälschlicherweise ein Wert von 60 Tagen drin. Deshalb hat Microsoft es ja im SP2 gefixt.

Jahaa... auch nach dem installieren von SP2 steht dort <Not Set>.

Servus, das ist auch bisher so. Ich muss selbst zugeben dass ich einen lesbaren Wert im Attribut auch besser finden würde als <Not Set>. Fakt ist, es ist eben für die Tombstone-Lifetime entscheidend, mit welcher Server-Version und welchem Service Pack der erste Domänencontroller in einer Gesamtstruktur erstellt wurde. Ja, dass ist eben ein Irrtum. Ich finde es auch sehr ungeschickt das dort kein Wert angezeigt wird. Fakt ist, laut diesem Artikel, soll nach der Installation des SP2 die Tombstone Lifetime 180 Tage betragen und das, in einer bereits bestehenden Gesamtstruktur. The default tombstone lifetime (TSL) value remains at 60 days instead of increasing to 180 days in Windows Server 2003 R2 Das könnte dir nur Microsoft beantworten ;). Nein, dass kannst du machen. Aber welchen Vorteil versprichst du dir, durch das ändern der Tombstone-Lifetime? Generell lässt sich sagen, man sollte an dem Wert nichts verändern.

Nichts wegen dem DNS. Dann konfiguriere - wie bereits von grizzly erwähnt - im Snap-In "Active Directory-Standorte und Dienste" entsprechende AD-Standorte (gelbe Icons) und verschiebe den jeweiligen DC an seinen entsprechenden Standort. Entscheidend an welchem DC sich ein Client autentifiziert ist das DNS. Dazu muss eben im "Standorte und Dienste" alles korrekt konfiguriert werden. Lies dazu folgenden Artikel: Yusuf`s Directory - Blog - Domänencontroller am Standort

Servus, ohnehin ist es empfehlenswert, auf jedem DC auch das DNS zu installieren. Ich empfehle auch, jeden DC zum GC zu stufen. Wenn es sich um einen Riesen-Forest handelt, dann muss man bezgl. dem Replikationsuafkommen sich das genauer anschauen, aber in den meisten Fällen ist es eher von Vorteil. Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen

Hallo, ich weiß zwar nicht, ob es wirklich harte Begrenzung dafür gibt, das spielt aber erstens bei deinem Problem keine Rolle und zweitens hatte ich davon nie gelesen bzw. gehört. Dann ist generell etwas beim heraufstufen schief gelaufen. Da würde ich das experimentieren sein lassen und den Server herunterstufen und wieder hochstufen. Wie gesagt, hier ist generell etwas faul. Du könntest z.B. zu allererst kontrollieren, ob der DC wirklich ein DC ist. Dazu muss das User-Account-Control Attribut vom DC die Zahl 532480 vorweisen. Wie du das kontrollieren kannst bzw. was du noch alles üebrprüfen solltest, erfährst du das diesem Artikel: Domain controller is not functioning correctly

Also meine Wenigkeit ;). Da bei dir bereits ein Windows Server 2003 DOMÄNENCONTROLLER in der Domäne existiert, ist bereits das Schema für 2003 aktualisiert wurden. Ob nun ein 2000er-DC in der Domäne existiert, spielt dabei keine Rolle. Es ist auch nicht so tragisch wenn du es nicht ausführst und es doch brauchen würdest. Dann würde an entsprechender Stelle eine Fehlermeldung erscheinen. Danach kann man immer noch (um nicht zu sagen jederzeit) die Möglichkeit, dass nachzuholen. Auch könntest du es vorher ausführen. Falls es nicht notwendig sein sollte, wird dir das ebenfalls in der Kommandozeile in Form eine Meldung angezeigt. So oder so, du wirst es schon merken. Da aber wie bereits erwähnt ein 2003er DC existiert, ist ein /DOMAINPREP nicht notwendig, da die Schema-Aktualisierung für R2 lediglich dem Schema hinzugefügt werden muss (in einer 2003er Domäen, also mit bestehendem 2003er DC) und nicht der Domäne.

Exportieren lässt sich die SID, aber nicht importieren. Die SID (oder auch GUID) ist ein System-Attribut "system-only" und diese können nicht importiert werden, sondern wird vom System gesetzt. csvde zum Import und Export von AD-Daten nutzen - faq-o-matic.net

Servus, was du alles beachten solltest, erfährst du aus diesem Artikel: Yusuf`s Directory - Blog - Den ersten/einzigsten Domänencontroller austauschen Das ist korrekt. Du musst das ADPREP von der zweiten R2-CD verwenden, denn das ADPREP befindet sich auf beiden CDs. Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 Nein, der 2000er hat kein Problem damit. Es gibt ja nur ein AD und beim ausführen von ADPREP werden Änderungen bzw. Neuerungen dem Schema hinzugefügt. Mit ausführen von ADPREP von der zweiten R2-CD aktualisiert sich das Schema auf die Version 31. Du solltest nur darauf achten, dass ADPREP auf dem SCHEMA-MASTER auszuführen. 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.

Aloha, mit ADMT kann man die Benutzer- sowie Computerkonten von einer Domäne in die andere migrieren. Um mit ADMT zu migrieren, muss eine Namensauflösung (unter Windows Server 2003 z.B. durch eine bedingte Weiterleitung) sowie Vertrauensstellung existieren. Falls sich das einrichten lässt, wäre das eine recht einfache Angelegenheit. Domänencontroller können aber nicht mit ADMT migriert werden. Diese müssen heruntergestuft und in der neuen Domäne erneut heraufgestuft werden. Ansonsten kann man mit CSVDE oder LDIFDE die Benutzer der Domäne exportieren und in der neuen Domäne importieren. Dieser Artikel samt den weiterführenden Links, wäre dabei hilfreich: Yusuf`s Directory - Blog - LDIFDE - LDAP Data Interchange Format Data Exchange

Das würde ich in jedemfall zuerst versuchen, diese zu aktivieren. Nein, es gibt kein Tool. Du kannst dieses Skript aber verwenden. How To Use Visual Basic Script to Clear SidHistory ... und genau diese zwei alten SIDs bereiten die Probleme. Ja, es kann etwas verloren gehen, nämlich der Zugriff auf die "alte" Domäne (falls diese vorhanden bzw. gewünscht ist). In der SID-History stehen die alten Zugriffsberechtigungen für die alten Domänen drin. Da bei die zwei Einträge vorhanden sind, wurde wahrscheinlich das Objekt zweimal migriert. Wenn du dir sicher bist, dass diese Zugriffe nicht mehr benötigt werden, da diese Domänen nicht mehr existieren, dann kannst du die SIDs entfernen. Wenn dein Exchange in der aktuellen Gesamtstruktur existiert, geht dort nichts kaputt.

Servus, yepp, da stimme ich zu. Die Partition zu formatieren ist wirklich keine gute Idee :p . Die Active Directory-Datenbank defragmentiert sich ohnehin automatisch alle 12 Stunden durch den Garbage Collection Prozess. Die Offline Defragmentierung ist i.d.R. nicht notwendig.

Ich denke, die von der zweiten SID. Diese wird genau das Problem sein.

Moin, die genannten Attribute sind alle "normale" Attribute eines Benutzerkontos. Die Attribute HOMEDRIVE und HOMEDIRECTORY stellen die Felder in den Eigenschaften eines Benutzerkontos für das Home-Laufwerk dar. Andere Attribute wiederum sind "System-only" und wird nur vom System vergeben bzw. gesetzt. System-only Attribute wären z.B.: - lastLogoff - lastLogon - badPasswordTime - badPwdCount - pwdLastSet Dein Problem liegt nicht daran. Die Fehlermeldung sagt etwas anderes aus:

Gratuliere Mr. MCSE ;). Ich werde nie den Tag an dem ich meine letzte Prüfung zum MCSE 2000 bestanden hatte vergessen. Es war August 2001. Ich kam morgens um 08:30 Uhr ins Büro und die ersten Kollegen waren schon da und informierten mich das paar User angerufen hätten und meinten sie hätten keinen Zugriff auf die Daten. Wir saßen im EG des GEbäudes und im dritten Stock befand sich mein Prüfungscenter (sehr praktisch). Mir brachen schon die Schweissperlen aus, was soll ich nur machen. Soll ich mir die File-Server anschauen oder gleich die Prüfung machen? Ich hatte mich für die Prüfung um 10:00 Uhr angemeldet. Die Sache war mir dann zu heiß und ich sagte zu mir, wenn du jetzt in den Server-Raum gehst - kommst du vor 22:00 Uhr nicht raus. Das konnte ich bei der letzten Prüfung nicht riskieren, es war mir alles egal. Ich ging direkt zum Prüfungscenter und (da man sich mitlerweile gut kannte) konnte ich gleich die Design-Prüfung machen. Als ich die Prüfung nach zwei bestanden hatte, gehörte die Welt mir ;). Als ich dann wieder runter ins Büro ging, brannte die Luft. Alle standen auf den Fluren. 200 Leute konnten nicht Arbeiten da kein Zugriff auf die Dateien bestand. Die Laune war Großartig und wo war Daim 2 Stunden lang? (ich hatte es natürlich verheimlicht). Lange Rede kurzer Sinn, was war passiert: Der Traum eines jeden Admins! Das SAN war weggeflogen, alles pfutsch, nichts mehr zu retten. Sollte ich heulen oder mich über den MCSE freuen. Es war ein langer und harter Tag (bzw. Wochenende), trotzdem gehörte dieser Tag mir, meine Laune konnte man mir an diesem Tag nicht vermießen, auch mit einer Kündigung nicht ;). Mal eine kleine Anekdote von mir ;). Also Feier schön und bleibe regelmäßig am Ball, dann hast du es im weiteren IT-Leben leichter und musst nicht immer wieder bei Null anfangen. Ein erneutes Congrats on Passing!

Das gilt es eben mit einem Test-User herauszufinden. Ich lese bisher, dass der Benutzer geclonet wird und nicht kopiert. Daher bedeutet dies: Learning by doing ;).

Dann war vielleicht das ADPREP das Problem? Beachte in diesem Artikel den Punkt: Erster Windows Server 2003 R2 64 Bit Domänencontroller in einer Windows Server 2003 32 Bit Domäne Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2

Steht ja auch da ;).

Weitere Vorgehensweisen: Du kannst auch mit dem Tool UMOVE für wenig Geld ein Clone des ADs erstellen. UMove - Move or copy Active Directory for backup or recovery Oder evtl. auf diese Variante: Active-Directory-Double als Testumgebung - faq-o-matic.net

Servus, was hat denn genau nicht funktioniert bzw. waren denn die Fehlermeldungen? War die 64Bit Maschine zufällig der erste Windows Server 2003 --> R2 <-- und soll dieser ebefanns ein DC werden? Erkläre das ganze mal genauer mit mehr Informationen.

Nicht so förmlich... In Communities "duzt" man sich ;). Anderer Ansatz: Suche mal auf der 2000-Server CD nach dem Tool "ClonePrincipal" und versuche damit den Benutzer in die neue Domäne zu migrieren.