Problembehandlung bei der Bereitstellung lokaler Anwendungen

Artikel
02/13/2024

Beheben von Testverbindungsproblemen

Nach dem Konfigurieren des Bereitstellungsagenten und des Extensible Connectivity (ECMA) Hosts ist es an der Zeit, die Konnektivität zwischen dem Microsoft Entra-Bereitstellungsdienst und dem Bereitstellungs-Agent, dem ECMA International-Host und der Anwendung zu testen. Dieser End-to-End-Test kann durch Auswählen von Verbindung testen in der Anwendung im Azure-Portal durchgeführt werden. Warten Sie unbedingt 10 bis 20 Minuten, nachdem Sie einen ersten Agent zugewiesen oder den Agent geändert haben, bevor Sie die Verbindung testen. Wenn nach diesem Zeitraum beim Testen der Verbindung ein Fehler auftritt, führen Sie die folgenden Schritte zur Problembehandlung aus:

Überprüfen Sie, ob der Agent und der ECMA-Host ausgeführt werden:
1. Öffnen Sie auf dem Server, auf dem der Agent installiert ist, die Seite Dienste, indem Sie zu Start>Ausführen>Services.msc navigieren.
2. Vergewissern Sie sich, dass unter Dienste die Dienste Microsoft Entra Connect-Bereitstellungs-Agent und Microsoft ECMA2Host angezeigt werden und ihr Status Wird ausgeführt lautet.
Überprüfen Sie, ob der ECMA-Connectorhostdienst auf Anforderungen reagiert.
1. Starten Sie PowerShell auf dem Server, auf dem der Agent installiert ist.
2. Wechseln Sie zu dem Ordner, in dem der ECMA-Host installiert wurde, etwa C:\Program Files\Microsoft ECMA2Host.
3. Wechseln Sie zum Unterverzeichnis Troubleshooting.
4. Führen Sie das Skript TestECMA2HostConnection.ps1 in diesem Verzeichnis aus. Geben Sie bei entsprechender Aufforderung als Argumente den Connectornamen und das geheime Token an.
```
PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> .\TestECMA2HostConnection.ps1
Supply values for the following parameters:
ConnectorName: CORPDB1
SecretToken: ************
```
5. Dieses Skript sendet eine SCIM GET- oder POST-Anforderung, um zu überprüfen, ob der ECMA-Connectorhost ausgeführt wird und auf Anforderungen reagiert. Wenn die Ausgabe nicht zeigt, dass eine HTTP-Verbindung erfolgreich war, überprüfen Sie, ob der Dienst ausgeführt wird und ob das richtige geheime Token angegeben wurde.
Vergewissern Sie sich, dass der Agent aktiv ist, indem Sie zu Ihrer Anwendung im Azure-Portal navigieren, Administratorkonnektivität und die Dropdownliste der Agents auswählen und überprüfen, ob Ihr Agent aktiv ist.
Überprüfen Sie, ob das angegebene geheime Token mit dem lokalen geheimen Token identisch ist. Wechseln Sie zur lokalen Umgebung, geben Sie das geheime Token erneut an, und kopieren Sie es in das Azure-Portal.
Vergewissern Sie sich, dass Sie der Anwendung im Azure-Portal mindestens einen Agent zugewiesen haben.
Nach dem Zuweisen eines Agents müssen Sie 10 bis 20 Minuten warten, bis die Registrierung abgeschlossen ist. Der Konnektivitätstest funktioniert erst, wenn die Registrierung abgeschlossen ist.
Achten Sie darauf, ein gültiges, nicht abgelaufenes Zertifikat zu verwenden. Wechseln Sie zur Registerkarte Einstellungen des ECMA-Hosts, um das Ablaufdatum des Zertifikats anzuzeigen. Wenn das Zertifikat abgelaufen ist, klicken Sie auf Generate certificate, um ein neues Zertifikat zu generieren.
Führen Sie einen Neustart des Bereitstellungs-Agents durch, indem Sie auf Ihrem virtuellen Computer zur Taskleiste navigieren und nach dem Microsoft Entra Connect-Bereitstellungs-Agent suchen. Klicken Sie mit der rechten Maustaste auf Beenden, und wählen Sie dann Starten aus.
Wenn auch nach dem Neustart des ECMA-Connectorhosts und des Bereitstellungs-Agents sowie dem Warten auf den Abschluss des ersten Imports weiterhin The ECMA host is currently importing data from the target application angezeigt wird, müssen Sie möglicherweise die Konfiguration der Bereitstellung für die Anwendung im Azure-Portal abbrechen und erneut starten.
Achten Sie bei Angeben der Mandanten-URL im Azure-Portal darauf, dass sie dem folgenden Muster entspricht. Sie können localhost durch Ihren Hostnamen ersetzen, dies ist aber nicht zwingend erforderlich. Ersetzen Sie connectorName durch den Namen des Connectors, den Sie im ECMA-Host angegeben haben. Die Fehlermeldung „Ungültige Ressource“ weist in der Regel darauf hin, dass die URL nicht dem erwarteten Format entspricht.
```
https://localhost:8585/ecma2host_connectorName/scim
```
Navigieren Sie zum folgenden Ordner, um die Protokolle des Bereitstellungs-Agents zu überprüfen: C:\ProgramData\Microsoft\Azure AD Connect Provisioning Agent\Trace.
1. Wenn der folgende Fehler angezeigt wird, fügen Sie das Dienstkonto „NT SERVICE\AADConnectProvisioningAgent“ der lokalen Gruppe „Leistungsprotokollbenutzer“ hinzu. Dadurch wird der Ausnahmefehler „Metriksammler kann nicht initialisiert werden“ vermieden, da dem Konto der Zugriff auf den gewünschten Registrierungsschlüssel ermöglicht wird: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib.

Unable to initialize metrics collector, exception: 'System.UnauthorizedAccessException: Access to the registry key 'Global' is denied.

Stellen Sie beim Konfigurieren des ECMA-Hosts sicher, dass Sie ein Zertifikat mit einem Antragsteller bereitstellen, der dem Hostnamen Ihres Windows-Servers entspricht. Das vom ECMA-Host generierte Zertifikat führt diesen Schritt automatisch für Sie aus, es sollte jedoch nur zu Testzwecken verwendet werden.

Error code: SystemForCrossDomainIdentityManagementCredentialValidationUnavailable

Details: We received this unexpected response from your application: Received response from Web resource. Resource: https://localhost/Users?filter=PLACEHOLDER+eq+"8646d011-1693-4cd3-9ee6-0d7482ca2219" Operation: GET Response Status Code: InternalServerError Response Headers: Response Content: An error occurred while sending the request. Please check the service and try again.

Der ECMA-Host kann nicht konfiguriert, Protokolle in der Ereignisanzeige können nicht angezeigt oder der ECMA-Hostdienst kann nicht gestartet werden.

Führen Sie den Assistenten für die ECMA-Hostkonfiguration als Administrator aus, um die folgenden Probleme zu beheben:

Beim Öffnen des ECMA-Host-Assistenten wird ein Fehler angezeigt.
Ich kann den ECMA-Host-Assistenten konfigurieren, aber die ECMA-Hostprotokolle werden nicht angezeigt. In diesem Fall müssen Sie den Assistenten für die ECMA-Hostkonfiguration als Administrator öffnen und einen End-to-End-Connector einrichten. Dieser Schritt lässt sich durch Exportieren eines vorhandenen Connectors und dessen erneuten Import vereinfachen.
Ich kann den ECMA-Host-Assistenten konfigurieren, aber den ECMA-Hostdienst nicht starten.

Aktivieren der ausführlichen Protokollierung

Standardmäßig ist switchValue für den ECMA-Connectorhost auf Verbose festgelegt. Mit dieser Einstellung wird eine detaillierte Protokollierung ausgegeben, die Ihnen bei der Problembehandlung hilft. Sie können die Ausführlichkeit in Error ändern, wenn Sie die Anzahl der protokollierten Fälle auf Fehler beschränken möchten. Wenn Sie den SQL-Connector ohne integrierte Windows-Authentifizierung verwenden, empfehlen wir, switchValue auf Error festzulegen, damit die Verbindungszeichenfolge nicht in den Protokollen ausgegeben wird. Um die Ausführlichkeit in „Fehler“ zu ändern, ändern Sie an beiden Stellen wie unten gezeigt switchValue in „Error“.

Dateispeicherort für die ausführliche Dienstprotokollierung: C:\Programme\Microsoft ECMA2Host\Service\Microsoft.ECMA2Host.Service.exe.config

<?xml version="1.0" encoding="utf-8"?> 
<configuration> 
    <startup>  
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" /> 
    </startup> 
    <appSettings> 
      <add key="Debug" value="true" /> 
    </appSettings> 
    <system.diagnostics> 
      <sources> 
    <source name="ConnectorsLog" switchValue="Error"> 
          <listeners> 
            <add initializeData="ConnectorsLog" type="System.Diagnostics.EventLogTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ConnectorsLog" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack"> 
              <filter type=""/> 
            </add> 
          </listeners> 
        </source> 
        <!-- Choose one of the following switchTrace:  Off, Error, Warning, Information, Verbose --> 
        <source name="ECMA2Host" switchValue="Error"> 
          <listeners>  
            <add initializeData="ECMA2Host" type="System.Diagnos

Der Dateispeicherort für die Assistentenprotokollierung ist C:\Programme\Microsoft ECMA2Host\Wizard\Microsoft.ECMA2Host.ConfigWizard.exe.config.

      <source name="ConnectorsLog" switchValue="Error"> 
        <listeners> 
          <add initializeData="ConnectorsLog" type="System.Diagnostics.EventLogTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ConnectorsLog" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack"> 
            <filter type=""/> 
          </add> 
        </listeners> 
      </source> 
      <!-- Choose one of the following switchTrace:  Off, Error, Warning, Information, Verbose --> 
      <source name="ECMA2Host" switchValue="Error"> 
        <listeners> 
          <add initializeData="ECMA2Host" type="System.Diagnostics.EventLogTraceListener, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ECMA2HostListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack" />

Abfragen des ECMA-Host-Caches

Der ECMA-Host verfügt über einen Cache von Benutzern in Ihrer Anwendung, die entsprechend dem Zeitplan aktualisiert wird, den Sie auf der Eigenschaften-Seite des ECMA-Host-Assistenten angeben. Führen Sie die folgenden Schritte aus, um den Cache abzufragen:

Legen Sie das Debug-Flag auf true.

Beachten Sie bitte, dass das Festlegen des Debug-Flags die true-Authentifizierung auf dem ECMA-Host deaktiviert. Sie müssen es wieder auf false zurücksetzen und den ECMA-Hostdienst neu starten wollen, sobald Sie den Cache abgefragt haben.

Der Dateispeicherort für die ausführliche Dienstprotokollierung ist beispielsweise C:\Program Files\Microsoft ECMA2Host\Service\Microsoft.ECMA2Host.Service.exe.config.
```
<?xml version="1.0" encoding="utf-8"?>
<configuration>
   <startup>  
       <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" /> 
   </startup> 
   <appSettings> 
     <add key="Debug" value="true" /> 
   </appSettings> 
```
Starten Sie den Microsoft ECMA2Host -Dienst neu.
Warten Sie, bis der ECMA-Host eine Verbindung mit den Zielsystemen hergestellt hat, und lesen Sie seinen Cache in jedem verbundenen System erneut. Wenn in diesen verbundenen Systemen viele Benutzer vorhanden sind, kann dieser Importvorgang einige Minuten dauern.
Fragen Sie diesen Endpunkt vom Server ab, auf dem der ECMA-Host installiert ist, und ersetzen Sie {connector name} durch den Namen Ihres Connectors, der auf der Eigenschaftenseite des ECMA-Hosts angegeben ist: https://localhost:8585/ecma2host_{connectorName}/scim/cache.
1. Starten Sie PowerShell auf dem Server, auf dem der Agent installiert ist.
2. Wechseln Sie zu dem Ordner, in dem der ECMA-Host installiert wurde, etwa C:\Program Files\Microsoft ECMA2Host.
3. Wechseln Sie zum Unterverzeichnis Troubleshooting.
4. Führen Sie das Skript TestECMA2HostConnection.ps1 in diesem Verzeichnis aus, und geben Sie als Argumente den Connectornamen und den ObjectTypePath-Wert cache an. Wenn Sie dazu aufgefordert werden, geben Sie das geheime Token ein, das für diesen Connector konfiguriert ist.
```
PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> .\TestECMA2HostConnection.ps1 -ConnectorName CORPDB1 -ObjectTypePath cache
Supply values for the following parameters:
SecretToken: ************
```
5. Dieses Skript sendet eine SCIM GET-Anforderung, um zu überprüfen, ob der ECMA-Connectorhost ausgeführt wird und auf Anforderungen reagiert. Wenn die Ausgabe nicht zeigt, dass eine HTTP-Verbindung erfolgreich war, überprüfen Sie, ob der Dienst ausgeführt wird und ob das richtige geheime Token angegeben wurde.
Legen Sie das Debug-Flag wieder auf false fest, oder entfernen Sie die Einstellung, sobald Sie mit der Abfrage des Cache fertig sind.
Starten Sie den Microsoft ECMA2Host -Dienst neu.

Das Zielattribut fehlt.

Der Bereitstellungsdienst erkennt Attribute in Ihrer Zielanwendung automatisch. Wenn Sie feststellen, dass ein Zielattribut in der Liste der Zielattribute im Azure-Portal fehlt, führen Sie den folgenden Problembehandlungsschritt aus:

Überprüfen Sie die Seite Attribute auswählen Ihrer ECMA-Hostkonfiguration, um sicherzustellen, dass das Attribut ausgewählt wurde, sodass es für das Azure-Portal verfügbar gemacht wird.
Vergewissern Sie sich, dass der ECMA-Hostdienst ausgeführt wird.
Nach dem Zuweisen der Agent(en) zur Unternehmensanwendung, nach dem Abschließen des Testverbindungsschritts und nach dem Speichern der Administratoranmeldeinformationen aktualisieren Sie den Browser. Dadurch wird erzwungen, dass der Bereitstellungsdienst eine /schemas-Anforderung erstellt und die Zielattribute ermittelt.
Überprüfen Sie die ECMA-Hostprotokolle, um zu bestätigen, dass eine /schemas-Anforderung erfolgt ist, und überprüfen Sie die Attribute in der Antwort. Diese Informationen sind für den Support bei der Problembehandlung nützlich.

Sammeln von Protokollen aus der Ereignisanzeige als ZIP-Datei

Sie können ein enthaltenes Skript verwenden, um die Ereignisprotokolle in einer ZIP-Datei zu erfassen und zu exportieren.

Klicken Sie auf dem Server mit installiertem Agent im Startmenü mit der rechten Maustaste auf PowerShell, und wählen Sie Run as administrator aus.
Wechseln Sie zu dem Ordner, in dem der ECMA-Host installiert wurde, etwa C:\Program Files\Microsoft ECMA2Host.
Wechseln Sie zum Unterverzeichnis Troubleshooting.
Führen Sie das Skript CollectTroubleshootingInfo.ps1 in diesem Verzeichnis aus.
Das Skript erstellt eine ZIP-Datei in diesem Verzeichnis, die die Ereignisprotokolle enthält.

Überprüfen von Ereignissen in der Ereignisanzeige

Nachdem die Hostschemazuordnung des ECMA-Connectors konfiguriert wurde, starten Sie den Dienst, damit er auf eingehende Verbindungen lauscht. Überwachen Sie dann eingehende Anforderungen.

Wählen Sie das Startmenü aus, geben Sie Ereignisanzeige ein, und wählen Sie Ereignisanzeige aus.
Erweitern Sie in der Ereignisanzeige den Eintrag Anwendungs- und Dienstprotokolle, und wählen Sie Microsoft ECMA2Host-Protokolle aus.
Wenn Änderungen vom Connectorhost empfangen werden, werden Ereignisse in das Anwendungsprotokoll geschrieben.

Häufige Fehler

Fehler	Lösung
Die Datei oder Assembly „file:///C:\Program Files\Microsoft ECMA2Host\Service\ECMA\Cache\8b514472-c18a-4641-9a44-732c296534e8\Microsoft.IAM.Connector.GenericSql.dll“ oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Zugriff verweigert.“	Stellen Sie sicher, dass das Netzwerkdienstkonto für den Cacheordner über Berechtigungen für den „Vollzugriff“ verfügt.
Ungültiger LDAP-Stil des DN des Objekts. DN: username@domain.com oder `Target Site: ValidByLdapStyle`	Stellen Sie sicher, dass das Kontrollkästchen „DN is Anchor“ (DN ist Anker) auf der Seite „connectivity“ (Konnektivität) des ECMA-Hosts nicht aktiviert ist. Stellen Sie sicher, dass das Kontrollkästchen „autogenerated“ (automatisch generiert) auf der Seite „object types“ (Objekttypen) des ECMA-Hosts aktiviert ist. Weitere Informationen finden Sie unter Grundlegendes zu Ankerattributen und DNs (Distinguished Names).
ExportErrorCustomContinueRun. objectClass: Wertnummer pro Syntax ungültig	Stellen Sie sicher, dass das zugeordnete Bereitstellungsattribut für das `objectClass`-Attribut nur Namen von Objektklassen enthält, die vom Verzeichnisserver erkannt werden.

Verstehen eingehender SCIM-Anforderungen

Anforderungen von Microsoft Entra ID an den Bereitstellungs-Agent und den Connectorhost verwenden das SCIM-Protokoll. Anforderungen, die vom Host an Apps gerichtet werden, verwenden das von der App unterstützte Protokoll. Die Anforderungen vom Host an den Agent und an Microsoft Entra ID basieren auf SCIM. Weitere Informationen zur SCIM-Implementierung finden Sie unter Tutorial: Entwickeln eines SCIM-Endpunkts und Planen seiner Bereitstellung in Microsoft Entra ID.

Der Microsoft Entra-Bereitstellungsdienst führt in der Regel in drei Fällen einen Abruf von Benutzer*innen aus, um nach Dummybenutzer*innen zu suchen: am Anfang jedes Bereitstellungszyklus, vor der bedarfsorientierten Bereitstellung und bei der Auswahl von Verbindung testen. Durch diese Überprüfung wird sichergestellt, dass der Zielendpunkt verfügbar ist und SCIM-konforme Antworten an den Microsoft Entra-Bereitstellungsdienst zurückgibt.

Gewusst wie: Problembehandlung für den Bereitstellungs-Agent

Möglicherweise treten die folgenden Fehlerszenarien auf.

Fehler beim Starten des Agents

Möglicherweise wird eine Fehlermeldung angezeigt, die folgendermaßen lautet:

„Der Dienst ‚Microsoft Entra Connect-Bereitstellungs-Agent‘ wurde nicht gestartet. Überprüfen Sie, ob Sie ausreichende Berechtigungen zum Starten von Systemdiensten besitzen.“

Dieses Problem wird in der Regel von einer Gruppenrichtlinie verursacht, die verhindert, dass Berechtigungen auf das vom Installationsprogramm erstellte Anmeldekonto für den lokalen NT-Dienst (NT SERVICE\AADConnectProvisioningAgent) angewendet werden. Diese Berechtigungen sind zum Starten des Diensts erforderlich.

Dieses Problem lässt sich wie folgt beheben:

Melden Sie sich beim Server mit einem Administratorkonto an.
Öffnen Sie die Seite Dienste, indem Sie zu dieser Seite navigieren oder Start>Ausführen>Services.msc ausführen.
Doppelklicken Sie unter Dienste auf Microsoft Entra Connect-Bereitstellungs-Agent.
Ändern Sie auf der Registerkarte Anmelden den Eintrag für Dieses Konto in das Konto eines Domänenadministrators. Starten Sie den Dienst dann neu.

Mithilfe dieses Tests wird überprüft, ob Ihre Agents über Port 443 mit Azure kommunizieren können. Öffnen Sie einen Browser, und navigieren Sie von dem Server, auf dem der Agent installiert ist, zur obigen URL.

Bei der Ausführung des Agents tritt ein Timeout auf, oder das Zertifikat ist ungültig.

Beim Versuch, den Agent zu registrieren, kann die folgende Fehlermeldung angezeigt werden:

Screenshot that shows that the agent timed out.

Dieses Problem wird in der Regel dadurch verursacht, dass der Agent keine Verbindung mit dem Hybrididentitätsdienst herstellen kann und die Konfiguration eines HTTP-Proxys erforderlich ist. Konfigurieren Sie zur Problembehebung einen Proxy für den ausgehenden Datenverkehr.

Der Bereitstellungs-Agent unterstützt die Verwendung von Proxys für ausgehenden Datenverkehr. Dies können Sie durch das Konfigurieren der Konfigurationsdatei des Agent C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgent.exe.config konfigurieren. Fügen Sie in der Datei gegen Ende unmittelbar vor dem </configuration>-Tag die folgenden Zeilen ein. Ersetzen Sie die Variablen [proxy-server] und [proxy-port] durch den Namen Ihres Proxyservers und die Portwerte.

    <system.net>
        <defaultProxy enabled="true" useDefaultCredentials="true">
            <proxy
                usesystemdefault="true"
                proxyaddress="http://[proxy-server]:[proxy-port]"
                bypassonlocal="true"
            />
        </defaultProxy>
    </system.net>

Fehler bei der Agent-Registrierung mit Sicherheitsfehler

Möglicherweise erhalten Sie während der Installation des Cloudbereitstellungs-Agent eine Fehlermeldung.

Dieses Problem wird in der Regel dadurch verursacht, dass der Agent die PowerShell-Registrierungsskripts aufgrund von lokalen PowerShell-Ausführungsrichtlinien nicht ausführen kann.

Ändern Sie zur Lösung dieses Problems die PowerShell-Ausführungsrichtlinien auf dem Server. Sie müssen die Computer- und Benutzerrichtlinien auf Undefined oder RemoteSigned festlegen. Wenn sie auf Unrestricted festgelegt sind, wird diese Fehlermeldung angezeigt. Weitere Informationen finden Sie unter PowerShell-Ausführungsrichtlinien.

Protokolldateien

Standardmäßig gibt der Agent minimalistische Fehlermeldungen und Überwachungsinformationen aus. Ablaufverfolgungsprotokolle finden Sie im Ordner „C:\ProgramData\Microsoft\Azure AD Connect Provisioning Agent\Trace“.

So sammeln Sie weitere Informationen zur Behandlung von Problemen mit dem Agent:

Installieren Sie das PowerShell-Modul AADCloudSyncTools wie unter PowerShell-Modul AADCloudSyncTools für die Microsoft Entra Connect-Cloudsynchronisierung beschrieben.
Verwenden Sie das PowerShell-Cmdlet Export-AADCloudSyncToolsLogs, um die Informationen zu erfassen. Optimieren Sie Ihre Datensammlung mithilfe der folgenden Switches. Verwendung:
- Verwenden Sie SkipVerboseTrace, um nur aktuelle Protokolle zu exportieren, ohne ausführliche Protokolle zu erfassen (Standard: false).
- Verwenden Sie TracingDurationMins, um eine andere Erfassungsdauer anzugeben (Standard: 3 Minuten).
- Verwenden Sie OutputPath, um einen anderen Ausgabepfad anzugeben (Standard: Ordner „Dokumente“ des Benutzers)

Mithilfe von Microsoft Entra ID können Sie den Bereitstellungsdienst in der Cloud überwachen und Protokolle lokal sammeln. Der Bereitstellungsdienst gibt Protokolle für jeden Benutzer aus, der im Rahmen des Synchronisierungsprozesses ausgewertet wurde. Diese Protokolle können über die Azure-Portal-Benutzeroberfläche, APIs und Log Analytics genutzt werden. Der ECMA-Host generiert Protokolle auch lokal. Er zeigt jede empfangene Bereitstellungsanforderung sowie die an Microsoft Entra ID gesendete Antwort an.

Fehler bei der Agent-Installation

Der Fehler System.ComponentModel.Win32Exception: The specified service already exists gibt an, dass der vorherige ECMA-Host nicht erfolgreich deinstalliert wurde. Deinstallieren Sie die Hostanwendung. Navigieren Sie zu „Programme“, und entfernen Sie den Ordner für den ECMA-Host. Es kann sinnvoll sein, die Konfigurationsdatei zu sichern.

Der folgende Fehler gibt an, dass eine Voraussetzung nicht erfüllt wurde. Vergewissern Sie sich, dass .NET 4.7.1 installiert ist.

  Method Name : <>c__DisplayClass0_1 : 
  RegisterNotLoadedAssemblies Error during load assembly: System.Management.Automation.resources.dll
  --------- Outer Exception Data ---------
  Message: Could not load file or assembly 'file:///C:\Program Files\Microsoft ECMA2Host\Service\ECMA\System.Management.Automation.resources.dll' or one of its dependencies. The system cannot find the file specified.

Beim Versuch, den ECMA-Connectorhost mit SQL zu konfigurieren, tritt ein DN-Fehler „Ungültiger LDAP-Stil“ auf.

Standardmäßig erwartet der genericSQL-Connector, dass der DN mithilfe des LDAP-Stils aufgefüllt wird (wenn das Attribut „DN is anchor“ (DN ist Anker) auf der ersten Konnektivitätsseite deaktiviert bleibt). In der Fehlermeldung Invalid LDAP style DN oder Target Site: ValidByLdapStyle stellen Sie möglicherweise fest, dass das DN-Feld einen Benutzerprinzipalnamen (UPN) enthält, anstatt einen DN im LDAP-Stil, den der Connector erwartet.

Um diese Fehlermeldung zu behandeln, stellen Sie sicher, dass auf der Seite „Objekttypen“ die Option Automatisch generiert ausgewählt ist, wenn Sie den Connector konfigurieren.

Weitere Informationen finden Sie unter Grundlegendes zu Ankerattributen und DNs (Distinguished Names).

Nächste Schritte

Tutorial: Generischer SQL-Connector mit ECMA-Connectorhost