Daim

jetzt ist das problem, dass der jetzige dienstleister die ad struktur für den kunden abbildet und höchst wahrscheinlich nicht so stark mit uns kooperieren wird das er uns eine direkte migration ermöglicht ... jetzt müssen wir hingehen und sagen "lieber dienstleister gib uns doch bitte die entsprechenden daten" damit wir eine neue ad struktur aufbauen können.

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.

jetzt bin ich halt am überlegen wie es für uns am einfachsten wird ohne jeden client anzufassen.

Die Antwort kennst du --> ADMT.

ein echt schwieriges projekt an dem ein ziemlicher rattenschwanz (exchange, file & print und citrix müssen auch noch migriert werden) dranhängt.

Also eine ziemlich größere Angelegenheit.

Umso mehr würde ich darauf drängen, um mit ADMT zu arbeiten.

@Daim

Du empfiehlst also, neben DNS auf allen DCs auch GC auf allen DCs ??

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.

@Daim warum sollte man den Wert nicht auf 180 ändern, MS gibt ja nun als Standard auch die 180 raus...

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.

wenn ich mal ein Objekt wiederherstellen möchte und es älter als 2 Monate ist habe ich verloren. Da ist mir 180 (halbes Jahr) lieber...

Nein, dann hast du nicht verloren. Sondern würdest deine System State-Sicherung auspacken und das Objekt autoritativ wiederherstellen.

Das hängt eben davon ab, mit welcher Windows Version der 1. DC erstellt wurde (s.o. in einem Post von Daim., #5).

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

Naja, der R2 hat ja mindestens das SP1 integriert ...

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.

Hi, ja in dem MS Artikel steht der Wert soll nach der SP2 Installation auf 180 sein. Bei mir aber immer noch auf <not set> ...

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

Servus,

Habe 2 Win 2003 R2 Server. Service Pack 2 ist installiert worden. Die Tombstone Lifetime ist immer noch auf nicht konfiguriert gesetzt (sichtbar mit Adsi edit).

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.

Ich dachte nach der Installation von SP2 müsste der Wert auf 180 sein?

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

Kann mir jemand sagen warum dem nicht so ist

Das könnte dir nur Microsoft beantworten ;).

und ob ich dort einfach 180 eintragen kann oder obs Probleme gibt?

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.

also, der dc1 hat DNS AD-integriert. Muss ich unter AD-Standorte und Dienste noch etwas verändern?

Nichts wegen dem DNS.

Mit, wo sich der Ex anmeldet, meine ich, dass ich mit dem set-Befehl gesehen habe, dass er sich auf einem der beiden DC am anderen Standort angemeldet hat (Logonserver). Dabei wäre es doch wohl besser, wenn er sich an dem DC an seinem Standort anmeldet? Oder?

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,

Gehe ich richtig in der Annahme das die Erstellung von NTDS Einstellungen für die Replikation je DC begrenzt sind?

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.

Wenn nicht, wie kann ich NTDS Einstellungen am root DC erstellen, wenn sie vom gejointen DC (child domain) nicht angelegt werden.

Dann ist generell etwas beim heraufstufen schief gelaufen.

Da würde ich das experimentieren sein lassen und den Server herunterstufen und wieder hochstufen.

Ich kann nämlich nur den Server manuell der Site hinzufügen, aber keine NTDS Einstellungen erstellen.

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

Zitat von Yusuf,

Also meine Wenigkeit ;).

ich habe ja noch einen 2000er DC, das heisst meine Domäne läuft noch auf 2000 resp. im Mix-Mode. Ich muss also den Schalter /Domainprep bei adprep auch noch anwenden, ist doch richtig so, oder?

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,

ich habe bis anhin eine Domäne mit DC 2000er und 2003er Server. Nun möchte ich einen dritten DC hinzufügen mit 2003 R2. Den 2000er möchte ich dann irgendwann herab stufen.

was du alles beachten solltest, erfährst du aus diesem Artikel:

Yusuf`s Directory - Blog - Den ersten/einzigsten Domänencontroller austauschen

Nun habe ich gelesen, dass ich das AD mit adprep auf 2003 R2 bringen muss, damit den neuen Server mit R2 in die Domäne aufnehmen kann mittels dcpromo.

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

Hat der 2000er kein Problem mit dieser Erweiterung oder könnte es hier evtl. Probleme geben? Oder kann ich beruhigt das adprep auf dem 2003er Server ausführen und dann den R2 in die Domäne aufnehmen?

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

Soo, ich habe festgestellt, das in der SID-History eine SID existiert die keiner aktiven Domäne bei mir zuzuordnen ist. Das sehe ich natürlich am Domänenteil der SID.

Wie kann ich diese löschen oder muß ich einfach nur die SID-Filterung in Win2000 aktivieren. So weit ich weiß ist diese in Win2000 deaktiviert per default und erst in Winn2003 per default aktiviert.

Das würde ich in jedemfall zuerst versuchen, diese zu aktivieren.

Gibt es ein Tool um die alte SID zu entfernen ? (es sind übrigens 2 in der SID History)

Nein, es gibt kein Tool. Du kannst dieses Skript aber verwenden.

How To Use Visual Basic Script to Clear SidHistory

Der User hat also eine aktuelle und 2 alte SIDs.

... und genau diese zwei alten SIDs bereiten die Probleme.

Kann ich beim entfernen von den alten SIDs etwas kaputt machen, z.B. im Bezug auf Exchange?

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,

Es wird nicht empfohlen, die Partition zu formatieren

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.

Welche Kontogruppen sind damit gemeint ?

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:

ERROR: 0x212d Bereits zuvor verschobene Objekte mit domänenübergreifender Zugehörigkeit können nicht verschoben werden. Dies wäre ein Verstoß gegen die Zugehörigkeitsbedingungen der Kontogruppe. Entfernen Sie das Objekt aus allen Kontogruppen, und wiederholen Sie den Vorgang.

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!

Wenn ich es richtig verstanden habe macht "ClonePrincipal" eine Kopie des Users in der Subdomain.

Führt das in meinem Fall nicht zu Problemen ?

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 ;).

Die 64-Bit Maschine ist die erste 2003 R2 und soll den "alten" 2003 DC ablösen.

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 ;).

Adprep hat ermittelt, dass der angemeldete Benutzer kein Mitglied der folgenden

Gruppen ist: Gruppe "Organisations-Admins" und Gruppe "Schema-Admins".

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.

Vielleicht haben Sie ja noch einen Tipp

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.