Auflistung einiger häufiger Fehler bei der Ausführung des UST und Tipps zu deren Behebung
FileNotFoundError: [Errno 2]
Beispiel für eine Konsolenfehlerausgabe:
FileNotFoundError: [Errno 2] Keine solche Datei oder kein solches Verzeichnis: 'C:\\\\Users\\\\USER\\\\.pex\\\\install\\\\pycryptodome [...]'
Kann unter Windows aufgrund von Pfaden mit >256 Zeichen erscheinen.
Tipp: Erstellen Sie eine Umgebungsvariable namens PEX_ROOT mit dem Wert C:\pex (wenn das Skript vom Laufwerk C: aus ausgeführt wird oder ändern Sie den Buchstaben entsprechend). Manchmal ist ein Neustart des Systems erforderlich, damit die Änderung wirksam wird.
Datei „user-sync.pex“ kann nicht geöffnet werden: [Errno 2]
Beispiel für eine Fehlerausgabe:
python: Kann Datei 'user-sync.pex' nicht öffnen: [Errno 2] Keine solche Datei oder kein solches Verzeichnis
Tipp: Vergewissern Sie sich, dass Sie die python-Befehlszeile innerhalb des Ordners ausführen, in dem sich user-sync.pex befindet.
Beispiel für eine Protokollfehlerausgabe:
2018-01-01 11:49:42 28102 WARNUNG umapi – UMAPI-Timeout ... Dienst nicht verfügbar (Code 429 bei Versuch 1)
2018-01-01 11:49:42 28102 WARNING umapi – Nächster Versuch in 42 Sekunden ...
Tipp: Wenn der Timeout weniger als 30 Minuten beträgt, werden diese Warnmeldungen empfangen, wenn das Kontingent der API-Aufrufe innerhalb einer Minute erreicht wurde. UST verfügt über einen exponentiellen Back-Off-Mechanismus, um den Aufruf zu wiederholen, wodurch sich die Zeit zwischen den weiteren Zustellversuchen verlängert. Das Skript bricht nach drei fehlgeschlagenen Versuchen ab.
Die Empfehlung hier ist, das Skript bis zum Ende durchlaufen zu lassen.
Wenn die Zeitüberschreitung höher als 1000 Sekunden ist, wäre dies eine Drosselung in Bezug auf die Ausführungshäufigkeit jeder User Sync Tool-Instanz.Wenn beobachtet wird, dass eine Instanz häufiger ausgeführt wird, wird sie zwischen 30 und 75 Minuten gedrosselt.Obwohl die Zeitüberschreitung das UST nur für eine bestimmte Zeit anhält (also kein ausschlaggebender Stopp-Fehler), weiß das UST, dass es sich erholen und die Synchronisierung direkt danach fortsetzen muss.
Da das Skript erkennt, wenn zwei Instanzen gleichzeitig gestartet werden, kann keine neue Instanz ausgelöst werden, bis die erste fertig ist.In diesem Fall kann eine Fehlermeldung im UST-Protokoll erscheinen, die sich auf „ein Prozess ist bereits im Gange" bezieht.
Hier sind einige Empfehlungen für die beste Leistung in Bezug auf die Ausführungshäufigkeit:
- Überprüfe die Häufigkeit der geplanten Aufgabe und stelle sicher, dass sie auf eine Wiederholung von mindestens 2 Stunden eingestellt ist
- Überprüfe die Auslösezeit der geplanten Aufgabe, sodass sie nicht zur vollen oder halben Stunde startet (vermeide Spitzen-Trafficaktivitäten)
- Wenn es erforderlich ist, das Tool häufiger auszuführen, denke über die Möglichkeit nach, UST mit Push-Strategie (Delta der Änderungen) anstelle einer vollständigen Synchronisierung zu verwenden
- Passe den Ausführungszeitplan des UST an den Arbeitstag deiner Organisation an, wenn Anwender bereitgestellt werden müssen (z. B. wenn deine Organisation nachts keine Anwenderbereitstellung ändern muss, führe keine Synchronisierungsaufgaben während dieser Zeit aus)
error.user.belongs_to_another_org
Beispielprotokolleintrag:
2018-01-01 11:49:42 28102 FEHLER umapi.action - Fehler in requestID: action_1 (Benutzer: {'user': 'myuser@domain2.com', 'requestID':'action_1'}, Befehl: {'createFederatedID': {'email': 'myuser@domain2.com', 'country': 'US', 'option': 'ignoreIfAlreadyExists', 'firstname': 'fname', 'lastname': 'lname'}}): code: "error.user.belongs_to_another_org" Nachricht: „Es ist illegal, Benutzer aus einer anderen Organisation einzuladen, die über eine eigene Authentifizierungsquelle verfügt.“
Tip: Die zur Erstellung des Kontos verwendete Domäne ist möglicherweise nicht in Ihrer Organisation beansprucht/vertrauenswürdig.Eine grüne Flagge oder ein grüner Punkt sollte für die aktiven Domänen in Admin Console -> Einstellungen angezeigt werden.Wenn dies nicht der Fall ist, kann der Abschluss des Domänenanforderungsvorgangs helfen.
Beispielprotokolleintrag:
2018-01-01 12:34:23 13383 ERROR umapi.action - Fehler in requestID: action_6 (Benutzer: {'user': ‘user@domain.com’, 'requestID': 'action_6'}, Befehl: {'createEnterpriseID': {'email': 'user@domain.com', 'option': 'updateIfAlreadyExists', 'firstname': 'test', 'lastname': 'user', 'country': ‘US’}}): code: "error.user.type_mismatch" Nachricht: „Der für die Einladung angeforderte Benutzertyp stimmt nicht mit dem angegebenen Domänentyp überein.“
Tipp: Es wird versucht, einen federatedID-Konto-Typ zu erstellen, aber das Verzeichnis wird für Unternehmensbenutzer erstellt oder umgekehrt.Suchen Sie das Attribut user_identity_type in der Datei user-sync-config.yml. Ändern Sie den Wert entsprechend dem in der Admin Consoleonsole angezeigten Verzeichnistyp (Einstellungen > Identität > Domänen > Verzeichnistyp für die gegebene Domäne).
Beispiel für eine Konsolenfehlerausgabe:
Ausführung der PEX-Datei fehlgeschlagen, da kompatible Abhängigkeiten fehlen:
pyyaml
cryptography
cffi
umapi-client
pycryptodome
pyldap
psutil
user-sync
Tipps:
a) Überprüfen Sie, ob es sich bei der auf Ihrem System installierten Python-Version um die 32-Bit-Version handelt. Deinstallieren Sie die 32-Bit- und installieren Sie die 64-Bit-Version, um das Problem zu beheben.
b) Prüfen Sie, ob die Version user-sync.pex, die Sie von GitHub heruntergeladen haben, mit Ihrer Python-Version und Ihrem Betriebssystemtyp übereinstimmt. Beispielsweise sollte user-sync-v2.3-win64-py365.zip für Windows 64-bit und Python 3 heruntergeladen werden.
Die Verwendung der neuesten Version von Python empfiehlt sich nicht immer. Stattdessen sollte die Python-Version der der .pex-Datei entsprechen. Verwenden Sie das Suffix der heruntergeladenen .zip-Datei, um festzustellen, welche Python-Version funktionieren würde. Für das obige Beispiel (user-sync-v2.3-win64-py365.zip) ist dies Python 3.6.5.
Fehler beim Entschlüsseln des privaten Schlüssels
Beispielprotokolleintrag:
2018-01-01 09:52:23 7920 DEBUG umapi – umapi: Lesen von Private Key-Daten aus der Datei C:\pfad\to\private.key
2018-01-01 09:52:23 7920 KRITISCH main – umapi configuration.enterprise: Fehler beim Entschlüsseln des Private Key: Entweder ist das Passwort falsch oder das RSA-Schlüsselformat wird nicht unterstützt.
Tipps:
a) Wenn die Herausforderung nicht schnell identifiziert werden kann, ist es schneller, das Schlüsselpaar neu auszustellen
b) Verwenden Sie das Attribut umapi_private_key_data nicht, wenn Sie das Skript unter Windows ausführen. Verschlüsseln Sie stattdessen den Schlüssel und speichern Sie das Kennwort im Credential Manager.
c) Nutzen Sie einen Private Key der Länge RSA256 /2048 bits, wenn Sie ein anderes Format zur Ausgabe des Schlüsselpaares verwenden
d) Es ist möglich, dass Sie secure_priv_key_pass_key: umapi_private_key_passphrase innerhalb der Datei connector-umapi.yml eingerichtet haben. Stellen Sie in diesem Fall sicher, dass der Eintrag im Credential Store für diesen und die zugehörigen Werte übereinstimmen (siehe unten).
Kein Wert im sicheren Speicher für Benutzer ...
Beispielprotokolleintrag:
2018-01-01 09:52:23 7920 KRITISCH main – umapi KRITISCH main – umapi configuration.enterprise: Kein Wert in sicherem Speicher für Benutzer „someUUIDvalue@AdobeOrg“, Schlüssel „umapi_api_key“
Tipps:
a) Der Eintrag „Credentials Store“ für umapi_api_key fehlt möglicherweise. Erstellen Sie den Eintrag im Credentials Store. Die Hilfedokumentation finden Sie hier.
b) Es kann sein, dass der Wert zum Credentials Store unter einem anderen Benutzerkonto hinzugefügt wurde. Für den aktuell verbundenen Benutzer fehlt dieser Eintrag jedoch. Fügen Sie ihn ggf. hinzu oder wechseln Sie die Benutzerkonten.
error.internal.exceptionflys / error.unauthorized
Beispiel für eine Fehelrausgabe:
umapi_client.error.RequestError: Anfragefehler (401): {"lastPage":false,"result":"error.internal.exceptionflys","Nachricht":"Token konnte nicht ausgetauscht werden"}
ODER
"umapi_client.error.RequestError: Anfragefehler (401): {"lastPage":false,"result":"error.unauthorized","Nachricht":"Authentifizierung des angegebenen Tokens ist fehlgeschlagen"}"
Tipp: Es kann sein, dass unter Admin Console -> Einstellungen -> Authentifizierungseinstellungen eine andere Option als Benutzerfreundlichste Option (Passwort läuft nie ab) ausgewählt wurde.Wenn die Option Sicherer oder Am sichersten aktiviert ist, kann das Kennwort des technischen Kontos, das mit der Integration verknüpft ist, ablaufen.
Um das Problem zu beheben, sollte eine neue Integration geschaffen werden. Stellen Sie sicher, dass die Metadaten auch in der Datei connector-umapi.yml erneuert werden.
Es wurde eine Fehlerbehebung dafür angewendet, aber es kann Integrationen betreffen, die vor Oktober 2018 erstellt wurden.
Neue Verbindung konnte nicht hergestellt werden [Errno 10061]
Beispiel für eine Fehlerausgabe:
ConnectionError: HTTPSConnectionPool(host='usermanagement.adobe.io', port=443): max Wiederholungsversuche mit URL überschritten: /v2/usermanagement/users/someUUID@AdobeOrg/0?directOnly=True (Verursacht durch NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x00000000027B9630>: Fehler beim Herstellen einer neuen Verbindung: [Errno 10061] Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte',))
Tipp:
Es hängt damit zusammen, dass UST keine Verbindung zu den öffentlichen API-Endpunkten herstellen kann. Lokale Einstellungen können den Zugriff aufgrund von Firewall-Regeln, Proxy-Blockierungsverkehr, Kontoeinstellungen für den Internetzugang und mehr verhindern.
In manchen Situationen kann es helfen, die https_proxy Umgebungsvariable mit einem Wert wie folgt hinzuzufügen:
http://<proxyAddress>:<port> ODER https://<proxyAddress>:<port>
In anderen Fällen kann es helfen, den Zugang zu diesen Endpunkten zuzulassen:
ims-na1.adobelogin.com:443
usermanagement.adobe.io:443
Dies kann nur lokal behoben werden, indem der Zugang zu den oben genannten Endpunkten für das laufende Konto freigegeben wird.
Beispielprotokolleintrag:
2017-07-07 09:01:37 4916 CRITICAL main - Verbindung zur Organisation [...] am Endpunkt https://usermanagement.adobe.io/v2/usermanagement fehlgeschlagen: Autorisierung gegen https://ims-na1.adobelogin.com/ims/exchange/jwt: nicht möglich Antwortcode: 400, Antworttext: {"error_description":"Die Metascopes im JWT sind keine Teilmenge der Metascopes in der Bindung.","error":"invalid_scope"}
Tipp: Greifen Sie auf die von Ihnen erstellte Integration unter https://developer.adobe.com/console/projects zu und überprüfen Sie im linken Menü, wo die APIs aufgelistet sind.Stellen Sie sicher, dass die Benutzerverwaltungs-API als Dienst hinzugefügt wird (erscheint in der Liste).
Es wurden keine gültigen Bindungen für die Kombination von Organisation und technischem Konto gefunden
Beispielprotokolleintrag (Debug-Modus):
2017-07-07 09:01:37 4916 CRITICAL main - UMAPI-Verbindung zur Organisations-ID 'someUUIDvalue@AdobeOrg' fehlgeschlagen: Autorisierung gegen https://ims-na1.adobelogin.com/ims/exchange/jwt: nicht möglich
Antwortcode: 400, Antworttext: {"error_description":"Keine gültigen Bindungen für die Kombination aus Organisation und technischem Konto gefunden","error":"invalid_token"}
Tipps:
a) Dies kann dadurch verursacht werden, dass der Wert tech_acct in der Datei connector-umapi.yml einem anderen Wert als der technischen Konto-ID innerhalb der Integration unter https://developer.adobe.com/console/projects entspricht.Überprüfen Sie den technischen Konto-ID-Wert aus der aktuellen Integration und kopieren Sie ihn in diese Datei.
b) Die Ursache kann auch sein, dass das öffentliche Zertifikat aus der Integration abgelaufen ist. Erneuern Sie den privaten und öffentlichen Schlüssel. Laden Sie dann den öffentlichen Schlüssel hoch, und ersetzen Sie den alten privaten Schlüssel durch den neuen Schlüssel. Überprüfen Sie den Pfad innerhalb der Datei connector-umapi.yml, um auf die richtige Datei zu verweisen.
c) Prüfen Sie, ob die Integration für die richtige Organisation durchgeführt wird. Wählen Sie die Organisation in der Dropdown-Liste in der oberen linken Ecke unter https://developer.adobe.com/console/projects aus. Überprüfen Sie dann den technischen Konto-ID-Wert für die aktive Integration zusammen mit den anderen Metadaten (Org-ID, Geheimnis und Kunden-ID).
SSL: CERTIFICATE_VERIFY_FAILED
Beispielprotokolleintrag:
2017-07-07 09:01:37 4916 CRITICAL main - UMAPI-Verbindung zur Organisations-ID 'someUUIDvalue@AdobeOrg' fehlgeschlagen: [SSL: CERTIFICATE_VERIFY_FAILED] Zertifikatüberprüfung fehlgeschlagen (_ssl.c:661)
Tipp: Dies wird durch die aktivierte SSL-Inspektion auf dem lokalen Proxyserver verursacht
Lösung 1: Rufen Sie das CA-Zertifikat der Firewall im PEM-Format ab (unter der Annahme, dass der Name thecert.crt lautet). Wenn das DER-Format verwendet wird, wandeln Sie es mit dem openssl-Befehl in PEM um:
openssl x509 -inform DER -in thecert.crt -out thecert.pem -outform PEM
Hinweis: Wenn du den Inhalt des Zertifikats betrachtest und einen base64-codierten String zwischen den Zeilen
-----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- siehst, bedeutet das, dass du die PEM-formatierte Datei hast.
Erstellen Sie als Nächstes eine Umgebungsvariable mit dem Namen REQUESTS_CA_BUNDLE und legen Sie ihren Wert als Pfad zur Datei thecert.pem fest.
Lösung2: In einigen Fällen wurde unter Windows beobachtet, dass dieser Fehler auftreten kann, wenn das Tool von einem anderen Laufwerk als dem Betriebssystem und Python ausgeführt wird.Das Verschieben des gesamten Skripts auf das Laufwerk, auf dem das Betriebssystem vorhanden ist, kann eine Lösung sein.Wenn dies keine Option ist, sollte die cacert.pem-Datei, die alle vertrauenswürdigen Root-CAs enthält, auf das andere Laufwerk kopiert und ihr Pfad als Eingabewert für die Umgebungsvariable REQUESTS_CA_BUNDLE verwendet werden.Wenn ein Proxy den SSL-Verkehr inspiziert, muss der Inhalt des Root-CA-Zertifikats in die Datei cacert.pem kopiert werden, um die Zertifikate zu überprüfen.
Hinweis: Bei einer standardmäßigen Python-Installation befindet sich das Zertifikatsbündel unter C: \Python36\Lib\site-Pakete\certifi\cacert.pem.
Lösung 3: Deaktivieren Sie die SSL-Prüfung auf der Proxy-Seite für die API-Endpunkte ims-na1.adobelogin.com und usermanagement.adobe.io
Keine Gruppe gefunden [...]
Beispielprotokolleintrag:
2018-01-01 09:01:37 4916 WARNING ldap - Keine Gruppe gefunden für: Name_Of_The_Group
Tipps:
a) Diese Gruppe existiert nicht in LDAP mit diesem genauen Namen. Korrigieren Sie es, indem Sie den korrekten LDAP-Namen der Gruppe hinzufügen
b) Die Gruppe ist unter der deklarierten base_dn nicht auffindbar (siehe Datei connector-ldap.yml). Ändern Sie den Wert base_dn so, dass er die erwähnte Gruppe enthält (dies geschieht hauptsächlich, wenn base_dn auf eine bestimmte OU verweist, anstatt so weit wie möglich gefasst zu sein).
Beispielprotokolleintrag:
2018-01-01 11:25:45 1 ERROR umapi.action - Fehler in requestID: action_1 (Anwender: {'user': 'myuser@domain.com', 'useAdobeID': True, 'requestID': 'action_1'}, Befehl: {'add': {'product': ['group_name']}}): code: "error.group.not_found" message: "Gruppe my_group_name wurde nicht gefunden"
Tipp: Die Benutzergruppe group_name in der obigen Ausgabe existiert auf der Adobe-Seite nicht, erstellen Sie sie also ruhig. Wenn die Absicht war, den Namen einer SPS statt den einer Benutzergruppe festzulegen, dann finden Sie auf dieser Dokumentationsseite eine visuellere Beschreibung.
Beispielprotokolleintrag:
2018-09-05 10:58:08 96329 CRITICAL main - Verbindung zur Organisation some_Org_UUID@AdobeOrg am Endpunkt https://usermanagement.adobe.io/v2/usermanagement fehlgeschlagen: dlopen(/Users/user/.pex/install/cryptography-2.3-cp37-cp37m-macosx_10_12_x86_64.whl.f77d5cc74b0deef9f1df7eacfe5f5ea57ed94a63/cryptography-2.3-cp37-cp37m-macosx_10_12_x86_64.whl/cryptography/hazmat/bindings/_openssl.abi3.so, 2): Bibliothek nicht geladen: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
Referenziert von: /Users/user/.pex/install/cryptography-2.3-cp37-cp37m-macosx_10_12_x86_64.whl.f77d5cc74b0deef9f1df7eacfe5f5ea57ed94a63/cryptography-2.3-cp37-cp37m-macosx_10_12_x86_64.whl/cryptography/hazmat/bindings/_openssl.abi3.so
Grund: Abbild nicht gefunden
2018-09-05 10:58:08 96329 INFO main - ========== Ende des Durchlaufs (User Sync Version: 2.3) (Gesamtzeit: 0:00:00)
Tipp: Dieser Fehler wurde auf einem MacOS High Sierra aufgezeichnet, wenn UST v2.3 mit Python 3.7.0 verwendet wurde.Die Ausführung von brew install openssl im Terminal hat das Problem in diesem speziellen Fall behoben.
Person für Typ 2 oder 3 konnte nicht erstellt werden [...]
Beispielprotokolleintrag:
2019-07-28 07:17:51 2220 ERROR umapi.action - Fehler in requestID: action_1 (Anwender: {'user': 'user@claimed-domain.com', 'requestID': 'action_1'}, Befehl: {'createFederatedID': {'email': 'user@claimed-domain.com', 'option': 'updateIfAlreadyExists', 'firstname': 'First', 'lastname': 'Last', 'country': 'US'}}): code: "error.internal.create_failed" message: "Person für Typ 2 oder 3 konnte nicht erstellt werden. Renga-Ergebnis ist NOT_ALLOWED, Ressource wird extern verwaltet und dem Token fehlt der GROUP_SOURCE_UPDATE-Zweck."
Manchmal ist die Website @claimed-domain.com Eigentum einer anderen Organisation, die einen Azure- oder Google Connector eingerichtet hat, um die Synchronisierung von Konten mit der Admin Console zu verwalten. Dieselbe Domäne wird dann einer anderen Organisation anvertraut, die mit dem User Sync Tool Konten des Formats @claimed-domain.com zu synchronisieren.
Ursache: Die protokollierte Meldung erscheint, wenn das Sync-Tool das Konto
user@claimed-domain.com von einem LDAP-Server extrahiert, um es in der sekundären Organisation zu erstellen. Das Konto wurde jedoch noch nicht über Azure oder den Google-Konnektor in der Hauptorganisation erstellt/synchronisiert.
Tipp: Versuchen Sie, das Konto user@claimed-domain.com in der Organisation mit deme Azure- oder Google-Konnektor zu erstellen/zu synchronisieren, und versuchen Sie dann erneut die Synchronisierung mit dem UST in der Trustee Org.
Unerwarteter LDAP-Fehler beim Lesen von [...]
Beispielprotokolleintrag:
2018-09-05 10:58:08 96329 6348 CRITICAL main - Unerwarteter LDAP-Fehler beim Lesen der Gruppeninformationen: {'desc': 'Referral', 'info': 'Referral:\nldap://domain.local/DC=sub,DC=domain,DC=local'}
Mögliche Ursache: Die relevante(n) Gruppe(n) befinden sich in einer Unterdomäne, aber der Host-Wert ist eine der Root-Domänen.
Tipp: Ändern Sie den Host-Wert auf eine der Unterdomänen, in denen Benutzergruppen gefunden werden können. Wenn sich Benutzer oder Interessengruppen sowohl in der Root-Domäne als auch in deren Unterdomäne(n) befinden, verwenden Sie den globalen Katalog-Port auf der Root-Domäne. Ändern Sie die Gruppen in der/den Unterdomäne(n) in Universal anstatt Global. Beispiel für einen Host-Wert mit globalem Katalog: ldap://domain.local:3268 oder ldaps://domain.local:3269
Wenn in diesem letzten Szenario der globale Katalogport verwendet wird, stellen Sie sicher, dass der Wert base_dn keinen Wert annimmt:
base_dn: ""
error.organization.invalid_id
Beispielprotokolleintrag:
2020-08-20 12:00:00 1892 ERROR main - Unbehandelte Ausnahme
raise RequestError(result)
umapi_client.error.RequestError: Anfragefehler (401): {"lastPage":false,"result":"error.organization.invalid_id",
"message":"UNAUTHORIZED"}
Dieser Fehler wurde bei älteren Integrationen beobachtet.
Die Lösung: Erstelle eine neue Integration (oder ein neues Projekt) unter https://developer.adobe.com/console/projects, neben der bestehenden, die für denselben Zweck verwendet wird.Die neue Integration stellt neue Anmeldedaten bereit. Stelle sicher, dass du sie in der Datei connector-umapi.yml aktualisierst.Es ist sehr wahrscheinlich, dass das keypair (privater/öffentlicher Schlüssel) neu ausgestellt werden muss. Daher muss der neue private Schlüssel den bestehenden ersetzen.
Person vom Typ createFederatedID konnte nicht erstellt werden
Beispielprotokolleintrag:
2021-01-01 18:00:00 14063 ERROR umapi.action - Fehler in requestID: action_19 (Anwender: {'user': 'some_user', 'domain': some.domain', 'requestID': 'action_19'}, Befehl: {'createFederatedID': {'email': 'some_user@some.domain', 'option': 'ignoreIfAlreadyExists', 'firstname': 'FName', 'lastname': 'LName, 'country': 'GB'}}): code: "error.internal.create_failed" message: "Person vom Typ createFederatedID konnte nicht erstellt werden"
Dies ist ein allgemeiner Fehler mit mehreren möglichen Ursachen, aber die übliche Herausforderung besteht darin, dass die bei der Erstellungsaktion verwendete Domain unter dem Einfluss einer Azure- oder Google-Synchronisierungseinrichtung steht.
So überprüfst du das: Melde dich in der Admin Console mit dem Systemadministrator-Konto an, klicke dann auf das Menü Einstellungen, dann klicke in das Verzeichnis, das die Domain enthält, und klicke anschließend auf den Menüreiter Synchronisierung.
Ist eine Synchronisierungsquellen-Karte im Synchronisierungsmenü vorhanden?
Falls Ja, hängt die Lösung davon ab, wie die Synchronisierung weiter fortgesetzt werden soll:
-> Wenn die Azure- oder Google-Verbindung die Synchronisierung durchführen soll, fahre mit der Einrichtung der Synchronisierungsquelle fort und entferne UST vollständig
-> Wenn UST die Synchronisierung durchführen soll, klicke auf den Button „Zu den Einstellungen" und klicke auf den Button „Synchronisierung entfernen" am unteren Rand der Seite; UST sollte danach wie gewohnt laufen
Falls Nein, kann es sein, dass der aktuelle UST gegen eine Konsole läuft, in der die betreffende Domain von einer anderen Konsole (besitzende Org) anvertraut wird.Diese andere Org hat möglicherweise die Azure- oder Google-Synchronisierung aktiviert, was zu dem aktuellen Fehler führen könnte.Die Lösung in diesem Fall besteht darin, das Konto zuerst in der besitzenden Org/Konsole zu synchronisieren und dann UST zu verwenden, um das Konto in der aktuellen Konsole zu erstellen/hinzuzufügen.
Wenn keine der oben genannten Situationen auf das aktuelle Szenario zutrifft, ist es am besten, den Enterprise Support zu kontaktieren.
