Fehler beim Heraufstufen des 2012 R2-Servers zum Domänencontroller in der 2003-Domäne

Beim Versuch, einen 2012 R2-Computer als Domänencontroller in einer Domäne auf Gesamtstruktur- \ Domänenebene 2003 zu fördern, wird beim Durchlaufen der Adprep- und Forestprep-Verfahren die folgende Fehlermeldung angezeigt:

ADPrep-Ausführung fehlgeschlagen -> System.ComponentModel.Win32Exception (0x80004005): Ein an das System angeschlossenes Gerät funktioniert nicht. Überprüfen Sie die Protokolldateien im Verzeichnis C: \ Windows \ debug \ adprep \ logs \ 20160128201714 auf detaillierte Informationen.

Das ADPrep-Protokoll zeigt den folgenden Fehler an:

[2016/01/28: 20: 17: 14.402] Die an ldifde übergebene Befehlszeile lautet ldifde -i -f "C: \ Windows \ system32 \ adprep \ sch32.ldf" -s "ral-ad1.AD.mydomain. com "-h -j" C: \ Windows \ debug \ adprep \ logs \ 20160128201714 "- $" C: \ Windows \ system32 \ adprep \ schupgrade.cat "[28.01.2016: 20: 17: 33.382] FEHLER : Import aus Datei C: \ Windows \ system32 \ adprep \ sch32.ldf fehlgeschlagen. Die Fehlerdatei wird in C: \ Windows \ debug \ adprep \ logs \ 20160128201714 \ ldif.err.32 gespeichert.

Wenn der Fehler "Unzureichende Rechte" (Ldap-Fehlercode 50) lautet, stellen Sie sicher, dass der angegebene Benutzer über Rechte zum Lesen / Schreiben von Objekten in den Schema- und Konfigurationscontainern verfügt, oder melden Sie sich ab und melden Sie sich als Benutzer mit diesen Rechten an, und führen Sie Forestprep erneut aus . In den meisten Fällen reicht es aus, Mitglied von Schema Admins und Enterprise Admins zu sein, um Forestprep auszuführen. [2016/01/28: 20: 17: 33.393] Adprep konnte das Schema auf dem Schemamaster nicht aktualisieren.

[Status / Konsequenz]

Das Schema wird nicht in seinen ursprünglichen Zustand zurückversetzt.

[Benutzeraktion]

Überprüfen Sie die Protokolldatei Ldif.err im Verzeichnis C: \ Windows \ debug \ adprep \ logs \ 20160128201714 auf detaillierte Informationen. [28.01.2016: 20: 17: 33.393] Adprep konnte keine Gesamtstrukturinformationen aktualisieren.

[Status / Konsequenz]

Adprep erfordert den Zugriff auf vorhandene gesamtstrukturweite Informationen vom Schemamaster, um diesen Vorgang abzuschließen.

Das Protokoll ldiff.err.32 wird angezeigt

15: CN = Benutzer, CN = Schema, CN = Konfiguration, DC = AD, DC = Mydomain, DC = com Eintrags-DN: CN = Benutzer, CN = Schema, CN = Konfiguration, DC = AD, DC = Mydomain, DC = com Fehler bei der Eingabe ab Zeile 232 hinzufügen: Nicht zur Ausführung bereit

Der serverseitige Fehler lautet: 0x20c5 Schemaaktualisierung fehlgeschlagen: Klasse in der Aux-Klassenliste existiert nicht oder ist keine Auxiliary-Klasse.

Der erweiterte Serverfehler lautet:

000020C5: SvcErr: DSID-03260249, Problem 5003 (WILL_NOT_PERFORM), Daten 8389

Zeile 232 von sch32.ldf lautet wie folgt

dn: CN = Benutzer, CN = Schema, CN = Konfiguration, DC = X Änderungstyp: ntdsSchemaModify add: systemMayContain systemMayContain: 1.2.840.113556.1.4.1929

Es scheint also, dass versucht wird, das Benutzerschema zu ändern, und dies schlägt fehl. Ich habe überprüft, ob sich mein Benutzerkonto in den Administratorgruppen Schema \ Domain \ Enterprise befindet. Ich habe auch überprüft, ob diese Gruppen mithilfe von adsiedit Schreibzugriff auf den Schema-Container haben. Der nächste Treffer, den ich finden konnte, war dieser . Wo MS MVP Ned Pyle in Kommentaren angegeben hat, könnte dies durch ein Tool eines Drittanbieters verursacht worden sein, das das Attribut zuvor falsch erweitert hat. Wenden Sie sich an den Microsoft-Support. Ich vermute, dass Microsoft Windows 2003 nicht mehr unterstützt, sodass der Pfad möglicherweise nicht weit führt. Hat das schon mal jemand gesehen? Vielen Dank für jede Hilfe.

Sie werden möglicherweise von der Antwort überrascht sein, die Sie vom Microsoft-Support erhalten, da es bei diesem Problem anscheinend weniger um die Unterstützung von Server 2003 als vielmehr um eine Straßensperre geht, die Sie daran hindert, auf 2012 R2 umzusteigen. Zumindest sollten Sie es so drehen.

Ich bin mir auch fast sicher, dass dies auf die Anpassung des Schemas zurückzuführen ist. Es ist normalerweise von Software von Drittanbietern, kann aber manchmal so etwas wie eine verpfuschte Exchange-Installation sein. Sie können Ihr Schema wahrscheinlich wieder in Form bringen, damit Sie es aktualisieren können. Beachten Sie jedoch, dass dadurch möglicherweise die Software beschädigt wird, die die Schemaänderung ursprünglich vorgenommen hat.

Das Folgende wird ohne Garantie und ohne Garantie bereitgestellt. Versuchen Sie dies auf eigenes Risiko. Versuchen Sie es nach Möglichkeit zuerst in einem Labor. Am besten rufen Sie Microsoft an und prüfen Sie, ob sie Ihnen helfen, bevor Sie dies selbst versuchen.

Speichern Sie die Benutzerklassendefinition aus dem Schema:

ldifde -d "CN=User,CN=Schema,CN=Configuration,DC=contoso,DC=com" -f user.txt

Suchen Sie in der Datei nach auxiliaryClassFeldern. Sie werden wahrscheinlich sehen shadowAccount, posixAccountund möglicherweise einige andere.

Speichern Sie für jede dieser Hilfsklassen auch ihre Schemadefinitionen, so wie Sie gerade die Benutzerklassendefinition ausgegeben haben.

Überprüfen Sie in jeder dieser Hilfsklassendefinitionen deren objectClassCategoryEigenschaften. Ist es 1? Wenn ja, sollte es 3 sein. Ändern Sie es in 3.

objectClassCategory ist hier dokumentiert:

https://msdn.microsoft.com/en-us/library/ms679014(v=vs.85).aspx

4 Bytes. Struktur 1, Zusammenfassung 2, Hilfs 3. Klasse 88, 0 sollte nicht verwendet werden.

Eine Hilfsklasse sollte den Wert 3 haben. Wenn eine Hilfsklasse den Wert 1 hat, hat jemand beim Ändern des Schemas einen Fehler gemacht. Ändern Sie es in 3 und erlauben Sie AD, das Schema zu replizieren. Versuchen Sie es dann adpreperneut.

Die von Ihnen gepostete Fehlermeldung:

Der serverseitige Fehler lautet: 0x20c5 Schemaaktualisierung fehlgeschlagen: Klasse in der Aux-Klassenliste existiert nicht oder ist keine Auxiliary-Klasse.

Macht jetzt im Zusammenhang mit dem, was ich oben skizziert habe, viel mehr Sinn.