(0) exportieren Drucken
Alle erweitern

Neues beim Installieren und Entfernen der Active Directory-Domänendienste

Veröffentlicht: April 2012

Letzte Aktualisierung: Januar 2013

Betrifft: Windows Server 2012

In diesem Thema werden folgende Inhalte behandelt:

Die Bereitstellung der Active Directory-Domänendienste (Active Directory Domain Services, AD DS) in Windows Server 2012 gestaltet sich einfach und schneller als in vorherigen Versionen von Windows Server. Der AD DS-Installationsprozess basiert von nun an auf Windows PowerShell, und er ist in Server-Manager integriert. Die Anzahl der zum Einfügen von Domänencontrollern in eine vorhandene Active Directory-Umgebung erforderlichen Schritte wurde reduziert. Dadurch wird der Prozess zum Erstellen einer neuen Active Directory-Umgebung einfacher und effizienter. Durch den neuen AD DS-Bereitstellungsprozess werden potenzielle Fehler, die anderenfalls zum Blockieren der Installation geführt hätten, minimiert.

Zudem können Sie die AD DS-Serverrollen-Binärdateien (d. h. die AD DS-Serverrolle) auf mehreren Servern gleichzeitig installieren. Sie können den AD DS-Installations-Assistenten auch per Remoteverbindung auf einem individuellen Server ausführen. Diese Verbesserungen bieten mehr Flexibilität beim Bereitstellen der Domänencontroller, auf denen Windows Server 2012 ausgeführt wird. Dies gilt vor allem für umfangreiche, globale Bereitstellungen, bei denen zahlreiche Domänencontroller in Niederlassungen in unterschiedlichen Regionen bereitgestellt werden müssen.

Die AD DS-Installation umfasst die folgenden Features:

  • Integration von "Adprep.exe" in den AD DS-Installationsprozess. Die mühsamen Schritte, die zum Vorbereiten eines vorhandenen Active Directory erforderlich sind (beispielsweise die Verwendung einer Vielzahl unterschiedlicher Anmeldeinformationen, das Kopieren der Adprep.exe-Dateien oder das Anmelden bei spezifischen Domänencontrollern) wurden alle vereinfacht oder automatisiert. Dadurch wird die zum Installieren von AD DS erforderliche Zeit verkürzt, und potenzielle Fehler, durch die die Heraufstufung von Domänencontrollern anderenfalls blockiert werden würde, werden reduziert.

    In Umgebungen, in denen die Ausführung der adprep.exe-Befehle im Vorfeld der Installation eines neuen Domänencontrollers zu bevorzugen ist, können Sie die adprep.exe-Befehle weiterhin gesondert von der AD DS-Installation ausführen. Die Windows Server 2012-Version von "adprep.exe" wird per Remoteverbindung ausgeführt. Demzufolge können Sie alle benötigten Befehle von einem Server mit einer 64-Bit-Version von Windows Server 2008 oder höher ausführen.

  • Die neue AD DS-Installation basiert auf Windows PowerShell und kann per Remoteverbindung aufgerufen werden. Die neue AD DS-Installation ist in Server-Manager integriert, sodass Sie zum Installieren von AD DS dieselbe Schnittstelle wie zum Installieren anderer Serverrollen verwenden können. Für Windows PowerShell-Benutzer bieten die Cmdlets für die AD DS-Bereitstellung eine umfangreichere Funktionalität und mehr Flexibilität. Zwischen den Installationsoptionen auf Befehlszeilenebene und auf der grafischen Benutzeroberfläche herrscht funktionale Gleichwertigkeit.

  • Die neue AD DS-Installation beinhaltet eine Validierung der Voraussetzungen. Potenzielle Fehler werden identifiziert, bevor die Installation beginnt. Sie können Fehlerzustände noch vor deren Eintreten korrigieren und müssen sich keine Sorgen um Probleme machen, die aus einem teilweise abgeschlossenen Upgrade resultieren. Wenn beispielsweise "adprep/domainprep" ausgeführt werden muss, überprüft der Installations-Assistent, ob der Benutzer über die ausreichenden Rechte zum Ausführen des Vorgangs verfügt.

  • Konfigurationsseiten werden in einer Reihenfolge gruppiert, die die Anforderungen der am häufigsten verwendeten Heraufstufungsoptionen mit verwandten Optionen widerspiegelt, die auf weniger Assistentenseiten gruppiert sind. Dies bietet einen besseren Kontext zum Treffen von Installationsentscheidungen.

  • Sie können ein Windows PowerShell-Skript mit allen Optionen exportieren, die während der grafischen Installation angegeben wurden. Am Ende einer Installation oder Entfernung können Sie die Einstellungen in ein Windows PowerShell-Skript exportieren, das zum Automatisieren desselben Vorgangs verwendet werden kann.

  • Vor dem Neustart erfolgen nur kritische Replikationen. Neuer Switch zum Zulassen der Replikation nicht kritischer Daten vor Neustarts. Weitere Informationen finden Sie unter Argumente für das Cmdlet "ADDSDeployment".

Ab Windows Server 2012 ersetzt der Konfigurations-Assistent für die Active Directory-Domänendienste den alten Installations-Assistenten der Active Directory-Domänendienste als Option auf der Benutzeroberfläche (User Interface, UI) für die Angabe von Einstellungen beim Installieren eines Domänencontrollers. Der Konfigurations-Assistent für die Active Directory-Domänendienste beginnt, wenn der Assistent zum Hinzufügen von Rollen abgeschlossen wurde.

WarningWarnung
Der alte Installation-Assistent für die Active Directory-Domänendienste ("dcpromo.exe") ist mit Windows Server 2012 veraltet.

Unter Installieren von Active Directory-Domänendiensten (Ebene100) wird anhand der UI-Verfahren verdeutlicht, wie der Assistent zum Hinzufügen von Rollen gestartet wird, um die AD DS-Serverrollen-Binärdateien zu installieren und anschließend den Konfigurations-Assistenten für die Active Directory-Domänendienste auszuführen, um die Domänencontrollerinstallation abzuschließen. Die Windows PowerShell-Beispiele zeigen, wie beide Schritte mithilfe eines Cmdlets für die AD DS-Bereitstellung abgeschlossen werden.

Ab Windows Server 2012 gibt es nur noch eine Version von "Adprep.exe" (die 32-Bit-Version "adprep32.exe" gibt es nicht mehr). Adprep-Befehle werden beim Installieren eines Domänencontrollers mit Windows Server 2012 in einer vorhandenen Active Directory-Domäne oder -Gesamtstruktur bei Bedarf automatisch ausgeführt.

Obwohl die adprep-Vorgänge automatisch ausgeführt werden, ist eine separate Ausführung von "Adprep.exe" möglich. Wenn beispielsweise der Benutzer, der AD DS installiert, kein Mitglied der Gruppe "Organisations-Admins" ist (dies ist eine Voraussetzung für die Adprep/forestprep-Ausführung), müssen Sie den Befehl möglicherweise separat ausführen. Sie müssen "adprep.exe" jedoch nur dann ausführen, wenn Sie ein direktes Upgrade Ihres ersten Windows Server 2012-Domänencontrollers planen (d. h., Sie planen ein direktes Upgrade des Betriebssystems eines Domänencontrollers, auf dem Windows Server 2012 ausgeführt wird).

"Adprep.exe" befindet sich im Ordner "\support\adprep" des Windows Server 2012-Installationsdatenträgers. Die Windows Server 2012-Version von Adprep kann per Remoteverbindung ausgeführt werden.

Die Windows Server 2012-Version von "adprep.exe" kann auf einem beliebigen Server mit einer 64-Bit-Version von Windows Server 2008 oder höher ausgeführt werden. Der Server benötigt eine Netzwerkverbindung mit dem Schemamaster für die Gesamtstruktur und mit dem Infrastrukturmaster der Domäne, in der Sie einen Domänencontroller hinzufügen möchten. Wenn eine dieser Rollen auf einem Server mit Windows Server 2003 gehostet wird, muss Adprep separat ausgeführt werden. Der Server, auf dem Sie Adprep ausführen, muss kein Domänencontroller sein. Er kann einer Domäne angehören oder Teil einer Arbeitsgruppe sein.

noteHinweis
Beim Versuch, die Windows Server 2012-Version von "adprep.exe" auf einem Server mit Windows Server 2003 auszuführen, wird der folgende Fehler angezeigt:

"Adprep.exe ist keine gültige Win32-Anwendung."

Adprep-Fehler

Informationen zum Auflösen weitere Fehler, die von "Adprep.exe" zurückgegeben werden, finden Sie unter Bekannte Probleme.

Adprep führt für jeden Befehl ("/forestprep", "/domainprep" oder "/rodcprep") eine Gruppenmitgliedschaftsüberprüfung aus, um zu bestimmen, ob die angegebenen Anmeldeinformationen einem Konto in bestimmten Gruppen entsprechen. Für die Ausführung dieser Überprüfung kontaktiert Adprep den Besitzer der Betriebsmasterrolle. Wenn der Betriebsmaster Windows Server 2003 ausführt und Sie über "Adprep.exe" sicherstellen möchten, dass in allen Fällen eine Gruppenmitgliedschaftsüberprüfung erfolgt, müssen Sie die Befehlszeilenparameter "/user" und "/userdomain" angeben.

"/user" und "/userdomain" sind neue Parameter für "Adprep.exe" in Windows Server 2012. Mithilfe dieser Parameter werden der Benutzerkontenname bzw. die Benutzerdomäne des Benutzers angegeben, der den adprep-Befehl ausführt. Mithilfe des Befehlszeilendienstprogramms "Adprep.exe" wird verhindert, dass einer der Parameter "/userdomain" und "/user" angegeben und der andere Parameter ausgelassen wird.

Die Adprep-Vorgänge können jedoch mit Windows PowerShell oder Server-Manager auch als Teil einer AD DS-Installation ausgeführt werden. Für diese Funktionen wird dieselbe zugrunde liegende Implementierung ("adprep.dll") wie für "adprep.exe" verwendet. Die Windows PowerShell- und Server-Manager-Funktionen verfügen über eine jeweils separate Eingabe der Anmeldeinformationen. Dadurch unterscheiden sich die Anforderungen von "adprep.exe". Mithilfe von Windows PowerShell oder Server-Manager kann ein Wert für "/user", jedoch nicht für "/userdomain", an "adprep.dll" übergeben werden. Wenn "/user" angegeben und "/userdomain" nicht angegeben wird, erfolgt die Ausführung der Überprüfung mithilfe der Domäne des lokalen Computers. Wenn der Computer zu keiner Domäne gehört, kann die Gruppenmitgliedschaft nicht überprüft werden.

Falls die Gruppenmitgliedschaft nicht überprüft werden kann, zeigt Adprep in den Adprep-Protokolldateien eine Warnmeldung an, und der Vorgang wird fortgesetzt:

Adprep was unable to check the specified user's group membership. This could happen if the FSMO role owner <DNS host name of operations master> is running Windows Server 2003 or lower version of Windows.

Wenn Sie "Adprep.exe" ohne Angabe der Parameter "/user" und "/userdomain" ausführen und wenn auf dem Betriebsmaster Windows Server 2003 ausgeführt wird, kontaktiert "Adprep.exe" einen Domänencontroller in der Domäne des momentan angemeldeten Benutzers. Wenn es sich bei dem derzeit angemeldeten Benutzer nicht um ein Domänenkonto handelt, kann "Adprep.exe" die Gruppenmitgliedschaftsüberprüfung nicht ausführen. "Adprep.exe" kann diese Gruppenmitgliedschaftsüberprüfung auch dann nicht ausführen, wenn Smartcard-Anmeldeinformationen verwendet werden. Dies ist selbst dann der Fall, wenn Sie die beiden Parameter "/user" und "/userdomain" angeben.

Wenn Adprep erfolgreich beendet wird, ist keine Aktion erforderlich. Falls Adprep während der Ausführung aufgrund von Zugriffsfehlern erfolglos bleibt, geben Sie ein Konto mit der richtigen Mitgliedschaft an. Weitere Informationen finden Sie unter Anforderungen an die Anmeldeinformationen für die Ausführung von "Adprep.exe" und die Installation der Active Directory-Domänendienste.

Verwenden Sie die folgende Syntax, um Adprep separat von einer AD DS-Installation auszuführen:

Adprep.exe /forestprep /forest <forest name> /userdomain <user domain name> /user <user name> /password *

Verwenden Sie "/logdsid" in dem Befehl, um eine detailliertere Protokollierung zu generieren. Die Datei "adprep.log" befindet sich im Verzeichnis "%windir%\System32\Debug\Adprep\Logs".

Bei der Windows Server 2012-Version von "adprep.exe" wird eine Smartcard für die Anmeldeinformationen verwendet. Es existiert jedoch keine einfache Methode zum Angeben der Smartcard-Anmeldeinformationen über die Befehlszeile. Eine Methode besteht darin, die Smartcard-Anmeldeinformationen über das PowerShell-Cmdlet "Get-Credential" abzurufen. Verwenden Sie anschließend den Benutzernamen des zurückgegebenen PSCredential-Objekts, das als @@... angezeigt wird. Das Kennwort entspricht der PIN der Smartcard.

Für "Adprep.exe" ist der Parameter "/userdomain" erforderlich, wenn "/user" angegeben wurde. Bei Smartcard-Anmeldeinformationen sollte der Parameter "/userdomain" der Domäne des zugrunde liegenden Benutzerkontos entsprechen, das durch die Smartcard repräsentiert wird.

Der Befehl "adprep /domainprep /gpprep" wird nicht als Teil der AD DS-Installation ausgeführt. Mithilfe dieses Befehls werden Berechtigungen festgelegt, die für die Planungsmodusfunktionalität des Richtlinienergebnissatzes (Resultant Set of Policy, RSOP) erforderlich sind. Weitere Informationen zu diesem Befehl finden Sie im Microsoft Knowledge Base-Artikel 324392. Wenn der Befehl in Ihrer Active Directory-Domäne ausgeführt werden muss, können Sie ihn separat von der AD DS-Installation ausführen. Falls der Befehl bereits in Vorbereitung auf die Bereitstellung von Domänencontrollern mit Windows Server 2003 SP1 oder höher ausgeführt wurde, muss er nicht erneut ausgeführt werden.

Sie können Domänencontroller, auf denen Windows Server 2012 ausgeführt wird, auf sichere Art und Weise einer vorhandenen Domäne hinzufügen, ohne den Befehl "adprep /domainprep /gpprep" zu verwenden. Der RSOP-Planungsmodus funktioniert in diesem Fall jedoch nicht ordnungsgemäß.

Vor Beginn der Installation überprüft der Installations-Assistent für AD DS, ob die folgenden Voraussetzungen erfüllt sind. Dadurch haben Sie die Möglichkeit, Probleme zu beheben, durch die die Installation möglicherweise blockiert werden könnte.

Die Adprep-bezogenen Voraussetzungen beinhalten beispielsweise Folgendes:

  • Überprüfung der Adprep-Anmeldeinformationen: wenn Adprep ausgeführt werden muss, überprüft der Installations-Assistent, ob der Benutzer über die ausreichenden Rechte zum Ausführen der erforderlichen Adprep-Vorgänge verfügt.

  • Schemamaster-Verfügbarkeitsprüfung: wenn der Installations-Assistent feststellt, dass "adprep /forestprep" ausgeführt werden muss, überprüft er, ob der Schemamaster online ist. Andernfalls schlägt der Assistent fehl.

  • Infrastrukturmaster-Verfügbarkeitsprüfung: wenn der Installations-Assistent feststellt, dass "adprep /domainprep" ausgeführt werden muss, überprüft er, ob der Infrastrukturmaster online ist. Andernfalls schlägt der Assistent fehl.

Weitere Voraussetzungsprüfungen, die aus dem alten Installations-Assistenten für Active Directory ("dcpromo.exe") übernommen wurden, beinhalten Folgendes:

  • Überprüfung des Gesamtstrukturnamens: stellt sicher, dass der Gesamtstrukturname gültig und derzeit nicht vorhanden ist.

  • NetBIOS-Namensüberprüfung: überprüft, ob der angegebene NetBIOS-Name gültig ist und nicht mit vorhandenen Namen in Konflikt steht.

  • Überprüfung des Komponentenpfads: überprüft, ob die Pfade für die Active Directory-Datenbanken, -Protokolle und für SYSVOL gültig sind und ob genügend Speicherplatz zur Verfügung steht.

  • Überprüfung des Namens der untergeordneten Domäne: stellt sicher, dass die Namen der übergeordneten und neuen untergeordneten Domäne gültig sind und dass sie nicht mit vorhandenen Domänen in Konflikt stehen.

  • Überprüfung des Strukturdomänennamens: stellt sicher, dass der angegebene Strukturname gültig und derzeit nicht vorhanden ist.

Die Systemanforderungen für Windows Server 2012 sind dieselben wie für Windows Server 2008 R2. Weitere Informationen finden Sie unter Windows Server 2008 R2 mit SP1 – Systemanforderungen (http://www.microsoft.com/windowsserver2008/en/us/system-requirements.aspx).

Für einige Features gelten möglicherweise zusätzliche Anforderungen. Beispielsweise erfordert das Feature zum Klonen virtueller Domänencontroller, dass der PDC-Emulator Windows Server 2012 ausführt und dass ein Computer mit Windows Server 2012 und installierter Hyper-V-Rolle vorhanden ist.

In diesem Abschnitt werden einige bekannte Probleme aufgeführt, die sich auf die AD DS-Installation unter Windows Server 2012 auswirken. Weitere bekannte Probleme finden Sie unter Troubleshooting Domain Controller Deployment.

  • Wenn der WMI-Zugriff auf den Schemamaster beim Ausführen von "adprep /forestprep" per Remoteverbindung durch die Windows-Firewall blockiert wird, wird im Adprep-Protokoll im Verzeichnis "%systemroot%\system32\debug\adprep" der folgende Fehler protokolliert:

    Adprep encountered a Win32 error. 
    Error code: 0x6ba Error message: The RPC server is unavailable.
    
    
    In diesem Fall können Sie den Fehler umgehen, indem Sie "adprep /forestprep" direkt auf dem Schemamaster ausführen, oder Sie können einen der folgenden Befehle zum Durchlassen des WMI-Datenverkehrs durch die Windows-Firewall verwenden.

    Für Windows Server 2008 oder höher:

    netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes
    
    
    Für Windows Server 2003:

    netsh firewall set service RemoteAdmin enable
    
    
    Nach Abschluss von Adprep können Sie einen der folgenden Befehle ausführen, um den WMI-Datenverkehr wieder zu blockieren:

    netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=no
    
    
    netsh firewall set service remoteadmin disable
    
    
  • Zum Abbrechen des Cmdlets "Install-ADDSForest" können Sie die Tastenkombination STRG+C verwenden. Durch den Abbruch wird die Installation gestoppt, und alle am Serverzustand vorgenommenen Änderungen werden rückgängig gemacht. Nach Ausgabe des Abbruchbefehls erhält Windows PowerShell jedoch nicht die Kontrolle zurück, und das Cmdlet kann sich für unbestimmte Zeit aufhängen.

  • Die Installation eines zusätzlichen Domänencontrollers mithilfe von Smartcard-Anmeldeinformationen wird nicht gelingen, wenn der Zielserver vor der Installation nicht der Domäne hinzugefügt wird.

    Die in diesem Fall zurückgegeben Fehlermeldung lautet wie folgt:

    Mit dem Replikationsquellen-Domänencontroller Name des Quelldomänencontrollers kann keine Verbindung hergestellt werden. (Ausnahme: Fehler bei Anmeldung: unbekannter Benutzername oder falsches Kennwort)

    Wenn Sie den Zielserver der Domäne hinzufügen und die Installation anschließend mithilfe einer Smartcard ausführen, wird die Installation erfolgreich abgeschlossen.

  • Das Modul "ADDSDeployment" kann unter 32-Bit-Prozessen nicht ausgeführt werden. Wenn Sie die Bereitstellung und Konfiguration von Windows Server 2012 mithilfe eines Skripts automatisieren, das ein Cmdlet "ADDSDeployment" und andere Cmdlets ohne Unterstützung systemeigener 64-Bit-Prozesse enthält, kann das Skript einen Fehler zurückgeben, laut dem das Cmdlet "ADDSDeployment" nicht gefunden werden kann.

    In diesem Fall müssen Sie das Cmdlet "ADDSDeployment" getrennt von dem Cmdlet ausführen, das keine systemeigenen 64-Bit-Prozesse unterstützt.

  • Windows Server 2012 enthält ein neues, als robustes Dateisystem bezeichnetes Dateisystem. Speichern Sie auf einem mit dem robusten Dateisystem (Resilient File System, ReFS) formatierten Datenvolume keinesfalls die Active Directory-Datenbanken, -Protokolldateien oder SYSVOL. Weitere Informationen zu ReFS finden Sie unter Erstellen der nächsten Dateisystemgeneration für Windows: ReFS.

  • In Server-Manager kann auf Servern, auf denen AD DS oder andere Serverrollen in einer Server Core-Installation ausgeführt werden und die auf Windows Server 2012 aktualisiert wurden, für die Serverrolle ein roter Status angezeigt werden, obwohl Ereignisse und Status erwartungsgemäß erfasst werden. Davon können auch Server betroffen sein, auf denen eine Server Core-Installation einer vorherigen Version von Windows Server 2012 ausgeführt wird.

Wenn die AD DS-Installation während der kritischen Replikationsphase einen Fehler erkennt, kann die Installation für unbestimmte Zeit hängen. Wird beispielsweise der Abschluss der kritischen Replikation durch Netzwerkfehler verhindert, wird die Installation nicht fortgesetzt.

Wenn Sie die Installation mithilfe von Server-Manager vornehmen, bleibt die Seite für den Installationsfortschritt möglicherweise geöffnet. Zudem erscheint auf dem Bildschirm keine Fehlermeldung, und der Fortschritt ändert sich möglicherweise 15 Minuten lang nicht. Wenn Sie Windows PowerShell verwenden, ändert sich der im Windows PowerShell-Fenster angezeigte Fortschritt 15 Minuten lang nicht.

Wenn dieses Problem bei Ihnen auftritt, überprüfen Sie die Datei "dcpromo.log" im Ordner "%systemroot%/debug" des Zielservers. In der Protokolldatei werden normalerweise wiederholte Fehler für die Replikation angegeben. Einige bekannte Ursachen für dieses Problem lauten wie folgt:

  • Die kritische Replikation zwischen dem heraufgestuften Zielserver und dem Replikationsquellen-Domänencontroller wird durch Netzwerkprobleme verhindert.

    Im Protokoll "dcpromo.log" wird beispielsweise Folgendes angezeigt:

    05/02/2012 14:16:46 [INFO] EVENTLOG (Error): NTDS Replication / DS RPC Client : 1963Internal event: The following local directory service received an exception from a remote procedure call (RPC) connection. Extensive RPC information was requested. This is intermediate information and might not contain a possible cause.
    Process ID: 
    500
    Reported error information:
    Error value: 
    Could not find the domain controller for this domain. (1908)
    directory service: 
    <domain>.com
    Extensive error information:
    Error value: 
    A security package specific error occurred. 1825
    directory service: 
    <DC Name>
    
    
    Da der Installationsprozess die kritische Replikation auf unbestimmte Zeit wiederholt, wird die Domänencontrollerinstallation fortgesetzt, wenn die zugrunde liegenden Netzwerkprobleme behoben wurden. Untersuchen Sie bei Bedarf die Netzwerkprobleme mit Tools wie "ipconfig", "nslookup" und "netmon". Stellen Sie sicher, dass zwischen dem Domänencontroller, den Sie heraufstufen, und dem bei der AD DS-Installation ausgewählten Replikationspartner Konnektivität besteht. Überprüfen Sie außerdem, ob die Namensauflösung funktioniert.

    Die AD DS-Installationanforderungen für Netzwerkkonnektivität und Namensauflösung werden vor dem Start der Installation während der Voraussetzungsüberprüfung geprüft. Manche Fehlerzustände können jedoch zwischen der Voraussetzungsüberprüfung und vor dem Abschluss der Installation auftreten, z. B. wenn der Replikationspartner während der Installation nicht verfügbar ist.

  • Während der Installation des replizierten Domänencontrollers wird das lokale Administratorkonto des Zielservers für die Installationsanmeldeinformationen angegeben, und das Kennwort des lokalen Administratorkontos stimmt mit dem Kennwort eines Domänenadministratorkontos überein. In diesem Fall können Sie den Installations-Assistenten abschließen und mit der Installation beginnen, bevor der Fehler "Der Zugriff wird verweigert" auftritt.

    Im Protokoll "dcpromo.log" wird beispielsweise Folgendes angezeigt:

    
    03/30/2012 11:36:51 [INFO] Creating the NTDS Settings object for this Active Directory Domain Controller on the remote AD DC DC2.contoso.com...
    03/30/2012 11:36:51 [INFO] EVENTLOG (Error): NTDS Replication / DS RPC Client : 1963Internal event: The following local directory service received an exception from a remote procedure call (RPC) connection. Extensive RPC information was requested. This is intermediate information and might not contain a possible cause.
    Process ID: 
    508
    Reported error information:
    Error value: 
    Access is denied. (5)
    directory service: 
    DC2.contoso.com
    
    
    
    Wird der Fehler durch Angabe eines lokalen Administratorkontos und Kennworts verursacht, müssen Sie zur Wiederherstellung das Betriebssystem neu installieren, eine Metadatenbereinigung des Kontos für den Domänencontroller ausführen, für den die Installation nicht abgeschlossen werden konnte, und anschließend die AD DS-Installation mit den Anmeldeinformationen für den Domänenadministrator wiederholen. Durch einen Neustart des Servers wird dieser Fehlerzustand nicht behoben, da der Server angibt, dass AD DS installiert ist, auch wenn die Installation nicht erfolgreich abgeschlossen wurde.

Wenn Sie eine neue Domäne oder Gesamtstruktur erstellen und Sie einen DNS-Domänennamen angeben, der internationalisierte Zeichen enthält, die nicht normalisiert wurden, zeigt der Konfigurations-Assistent für die Active Directory-Domänendienste eine Warnung mit dem Hinweis an, dass DNS-Abfragen nach dem Namen fehlschlagen können. Obwohl der DNS-Domänenname auf der Seite "Bereitstellungskonfiguration" angegeben wird, erscheint die Warnung später im Assistenten auf der Seite "Voraussetzungsüberprüfung".

Wenn ein DNS-Domänenname mithilfe eines nicht normalisierten Namens wie "füßball.com" oder "ΒΣΤΑ.com" (die normalisierten Versionen lauten "füssball.com" und "βστα.com") angegeben wird, führen Clientanwendungen, die über WinHTTP darauf zugreifen möchten, eine Normalisierung des Namens aus, bevor sie APIs für die Namensauflösung aufrufen. Wenn der Benutzer in einem Dialog "ΒΣΤΑ.com" verwendet, wird die DNS-Abfrage als "βστα.com" gesendet, und kein DNS-Server ordnet sie einem Ressourceneintrag für "ΒΣΤΑ.com" zu. Der Benutzer kann den Namen nicht auflösen.

Im folgenden Beispiel wird eines der Probleme erläutert, das bei Verwendung eines nicht normalisierten IDN-Namens auftreten kann:

  1. Die Domäne, für die ein nicht normalisierter Name verwendet wird, wird auf dem DNS-Server "füßball.com" erstellt und registriert.

  2. Der Computer "nps" wird der Domäne hinzugefügt, und der zugehörige Name wird registriert: "nps.füßball.com".

  3. Eine Clientanwendung versucht, eine Verbindung mit dem Server "nps.füßball.com" herzustellen.

  4. Die Clientanwendung versucht, den Namen "nps.füßball.com" aufzulösen, indem Sie APIs für die Namensauflösung aufruft.

  5. Aufgrund der Normalisierung wird der Name in "nps.füssball.com" konvertiert und über die Leitung "nps.füßball.com" abgefragt.

  6. Die Clientanwendung kann den Namen nicht auflösen, da der registrierte Name "nps.füßball.com" lautet.

Wenn die Warnung auf der Seite "Voraussetzungsüberprüfung" des Konfigurations-Assistenten für die Active Directory-Domänendienste angezeigt wird, wechseln Sie zur Seite "Bereitstellungskonfiguration" zurück, und geben Sie einen normalisierten DNS-Domänennamen an. Wenn Sie eine neue Domäne mit Windows PowerShell installieren, geben Sie für die Option "-DomainName" einen normalisierten DNS-Namen an.

Weitere Informationen zu IDNs finden Sie unter Umgang mit internationalisierten Domänennamen (Internationalized Domain Names, IDNs).

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft