View a markdown version of this page

Fehlerbehebung - AWS Transformieren
Überprüfen der Konnektivität des Discovery-Tools mit vCenterWinRM-ProblembehandlungKerberos-FehlerbehebungFehlerbehebung bei der Oracle-DatenbankSNMP-FehlerbehebungFehler bei der NetzwerkerfassungFehler beim Sammeln von Betriebssystem-MetrikenProbleme beim Zugriff auf das Inventar „Ermittelt“Fehlerbehebung bei der SSH-SchlüsselauthentifizierungFehlerbehebung beim Linux-InstallationsprogrammHäufige Fehlermeldungen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Fehlerbehebung

Überprüfen der Konnektivität des Discovery-Tools mit vCenter

Wenn bei der Konfiguration des VMware-Moduls Fehler auftreten, gehen Sie wie folgt vor, um die Konnektivität zu überprüfen:

Greifen Sie auf das Discovery-Tool VM zu

  • Log-in zum Discovery-Tool VM, öffnen Sie Remote Console in vCenter

    • Benutzername: discovery

    • Passwort: Passwort

Testen Sie die vCenter-Konnektivität

  1. Testen Sie den vCenter-API-Zugriff:

    curl -v --insecure -u <username>:<password> https://<vcenter-ip-or-hostname>:443/mob

  2. Ergebnis des erwarteten Erfolgs:

    [ec2-user@discoverytool ~]$ curl -v --insecure -u <user>:<password> https://vcsa/mob > tmp.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 192.168.2.125:443...
* Connected to vcsa (192.168.2.125) port 443 (#0)
...
</xml>
* Connection #0 to host vcsa left intact
Testen Sie das SSL-Zertifikat

  1. Führen Sie diesen Befehl aus: 

    openssl s_client -showcerts -servername <hostname> -connect <hostname>:443

  2. Ausgabe mit erwartetem Erfolg:

    • Sollte vSphere-Zertifikatsdetails anzeigen

    • Überprüft die SSL/TLS Konnektivität auf Port 443

    [ec2-user@discoverytool ~]$ openssl s_client -showcerts -servername vcsa -connect vcsa:443
CONNECTED(00000003)
depth=0 CN = vcsa.onpremsim.env, C = US
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = vcsa.onpremsim.env, C = US
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/CN=vcsa.onpremsim.env/C=US
   i:/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=vcsa.onpremsim.env/C=US
issuer=/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering
---

WinRM-Problembehandlung

Wenn Sie Verbindungsprobleme mit WinRM haben, gehen Sie wie folgt vor, um die Verbindung zu testen. Diese Schritte gelten auch für Hyper-V Verbindungsprobleme, da das Discovery-Tool WinRM für die Kommunikation mit Hyper-V Hosts verwendet.

Testen Sie die grundlegende WinRM-Konnektivität mithilfe der Ports 5985 (HTTP) und 5986 (HTTPS). Wir müssen sicherstellen, dass die Konnektivität auf Port 5986 (HTTPS) funktioniert

# Check WinRM listener configuration
winrm enumerate winrm/config/listener

# Note: Replace <HOST> with the target computer's hostname or IP address. Adjust the username and password as needed. 
# Test WinRM connection on port 5985 (HTTP)
$cred = Get-Credential
Test-WSMan -Computer <HOST> -Authentication Negotiate -Credential $cred -Port 5985

# Test WinRM connection on port 5986 (HTTPS)
Test-WSMan -Computer <HOST> -Authentication Negotiate -Credential $cred -Port 5986

Wenn die obigen Tests fehlschlagen, versuchen Sie, eine PowerShell Sitzung mit deaktivierter Zertifikatsvalidierung einzurichten:

$cred = Get-Credential
$so = New-PsSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
Enter-PSSession -ComputerName <HOST> -Credential $cred -Port 5985 -SessionOption $so

Kerberos-Fehlerbehebung

Wenn bei der Erfassung von Daten von Windows-Servern Fehler bei der Kerberos-Authentifizierung auftreten, können Sie anhand der folgenden Abschnitte häufig auftretende Probleme diagnostizieren und beheben.

Überprüfen Sie die Netzwerkanforderungen

Bevor Sie Probleme mit der Kerberos-Authentifizierung beheben, stellen Sie sicher, dass das Discovery-Tool die erforderlichen Netzwerkendpunkte erreichen kann.

Um die Netzwerkanforderungen für Kerberos zu überprüfen

  1. Überprüfen Sie die DNS-Auflösung für den Domänencontroller. Führen Sie den folgenden Befehl von der Discoverytool-VM aus:

    nslookup dc01.example.com

    Sie können jedoch auch dig verwenden.

    dig dc01.example.com

    Wenn die DNS-Auflösung fehlschlägt, stellen Sie sicher, dass die Discoverytool-VM so konfiguriert ist, dass sie einen DNS-Server verwendet, der Ihre Active Directory-Domäne auflösen kann. Überprüfen /etc/resolv.conf und bestätigen Sie, dass die Nameservereinträge auf Ihre Domänen-DNS-Server verweisen.

  2. Überprüfen Sie die Konnektivität zum Key Distribution Center (KDC) an Port 88. Führen Sie den folgenden Befehl aus:

    nc -zv dc01.example.com 88

    Erwartete Ausgabe:

    Connection to dc01.example.com 88 port [tcp/kerberos] succeeded!

    Wenn die Verbindung fehlschlägt, stellen Sie sicher, dass keine Firewallregeln den Verkehr von der Discoverytool-VM zum Domänencontroller an Port 88 blockieren.

  3. Überprüfen Sie die Konnektivität zu den Windows-Zielservern an WinRM-Ports. Führen Sie die folgenden Befehle aus:

    nc -zv <windows-server> 5985
nc -zv <windows-server> 5986

    Wenn die Verbindung fehlschlägt, stellen Sie sicher, dass WinRM auf dem Zielserver aktiviert ist und dass Firewallregeln eingehenden Verkehr an den Ports 5985 und 5986 zulassen.

Allgemeine Kerberos-Probleme

Im Folgenden werden häufig auftretende Kerberos-Probleme und deren Lösungen beschrieben.

Fehler bei der Berücksichtigung von Groß-

Symptom: Bei der Authentifizierung wird die Fehlermeldung „Server nicht in der Kerberos-Datenbank gefunden“ angezeigt.

Dieser Fehler tritt normalerweise auf, wenn der Kerberos-Bereichsname nicht in Großbuchstaben geschrieben ist. Kerberos-Bereiche müssen in Ihrer Datei in Großbuchstaben angegeben werden. krb5.conf Verwenden Sie z. B. EXAMPLE.COM statt example.com.

Verhinderung der Kontosperrung

Das Discovery-Tool verwendet einen Backoff-Mechanismus, um zu verhindern, dass Konten aufgrund wiederholter fehlgeschlagener Authentifizierungsversuche gesperrt werden. Wenn Ihr Dienstkonto gesperrt wird, können Sie den Erfassungsvorgang zurücksetzen, indem Sie das Erfassungsmodul über die Weboberfläche des Discovery-Tools unter beenden und erneut starten. https://<discovery-tool-vm-ip>:5000

Kinit schlägt über die CLI fehl

In der folgenden Tabelle sind häufig auftretende kinit Fehler und deren Lösungen aufgeführt.

Fehler Ursache Lösung
KDC für Realm kann nicht gefunden werden Der KDC-Hostname oder die IP-Adresse ist nicht erreichbar, oder der Bereich ist nicht konfiguriert. krb5.conf Stellen Sie sicher, dass die krb5.conf Datei den richtigen KDC-Hostnamen und den richtigen Bereich enthält. Bestätigen Sie die DNS-Auflösung und die Netzwerkkonnektivität zum KDC auf Port 88.
Die Vorauthentifizierung ist fehlgeschlagen Das Passwort für das Dienstkonto ist falsch. Überprüfen Sie das Passwort und versuchen Sie es erneut. Wenn das Konto gesperrt ist, entsperren Sie es in Active Directory, bevor Sie es erneut versuchen.
Der Client wurde nicht in der Kerberos-Datenbank gefunden Der Prinzipalname stimmt mit keinem Konto in Active Directory überein. Stellen Sie sicher, dass der Prinzipalname genau mit dem Kontonamen übereinstimmt, einschließlich Groß- und Kleinschreibung. Verwenden Sie das Format username@REALM mit dem Bereich in Großbuchstaben.
Die Netzwerkadresse für KDC kann nicht aufgelöst werden DNS kann den KDC-Hostnamen nicht auflösen. Überprüfen Sie die DNS-Konfiguration in. /etc/resolv.conf Vergewissern Sie sich, dass der DNS-Server den KDC-Hostnamen auflösen kann. Testen Sie mit odernslookup. dig

Die Erfassung schlägt trotz erfolgreicher Initiierung fehl

Wenn die Datenerfassung kinit erfolgreich ist, die Datenerfassung aber immer noch fehlschlägt, überprüfen Sie Folgendes:

  1. Stellen Sie sicher, dass der für die Erfassung verwendete Prinzipalname kinit genau der Groß- und Kleinschreibung entspricht, die während der Erfassung verwendet wurde.

  2. Stellen Sie sicher, dass das Dienstkonto über die erforderlichen Berechtigungen auf den Zielservern verfügt.

  3. Stellen Sie sicher, dass WinRM auf den Zielservern aktiviert ist.

  4. Stellen Sie sicher, dass der für die Erfassung verwendete Hostname mit dem in Active Directory registrierten Hostnamen übereinstimmt.

Kerberos funktioniert auf einigen Servern, auf anderen jedoch nicht

Wenn die Kerberos-Authentifizierung für einige Server erfolgreich ist, für andere jedoch fehlschlägt, untersuchen Sie die folgenden Bereiche:

Wenn sich Ihre Server über mehrere Active Directory-Domänen erstrecken, konfigurieren Sie für jede Domäne separate Kerberos-Anmeldeinformationen. Stellen Sie sicher, dass Ihre /etc/krb5.conf Datei Einträge für alle Bereiche enthält. Für jede Domain sind eigene Anmeldeinformationen mit dem richtigen username@REALM Principal erforderlich.

Vergleichen Sie die WinRM-Konfiguration auf einem funktionierenden Server mit einem ausgefallenen Server. Führen Sie auf jedem Server den folgenden Befehl aus:

winrm get winrm/config

Testen Sie die Konnektivität mit Remote Desktop, um das Problem zu isolieren. Das Discovery-Tool verwendet das Formatusername@DOMAIN, während Remote Desktop das Format verwendetDOMAIN\username.

Stellen Sie sicher, dass das Dienstkonto Mitglied der lokalen Administratorgruppe auf dem ausgefallenen Server ist. Führen Sie den folgenden Befehl auf dem Zielserver aus:

net localgroup Administrators

WMI benötigt lokale Administratorrechte, um auf Betriebssysteminformationen zugreifen zu können. Für die SQL Server-Sammlung ist außerdem erforderlich, dass das Dienstkonto über lokalen Administratorzugriff auf dem Zielserver verfügt.

Checkliste für die Kerberos-Konfiguration

Verwenden Sie die folgende Checkliste, um Ihre Kerberos-Konfiguration zu überprüfen, bevor Sie mit der Datenerfassung beginnen.

  • Die krb5.conf Datei ist auf der Discovery-Tool-VM vorhanden.

  • Der Bereichsname ist in Großbuchstaben geschrieben. krb5.conf

  • Die Ausführung kinit mit dem Dienstkonto ist ohne Fehler erfolgreich.

  • Beim Ausführen wird ein gültiges, nicht abgelaufenes Ticket klist angezeigt.

  • Der Prinzipalname entspricht exakt dem Active Directory-Kontonamen.

  • Die DNS-Auflösung funktioniert für den KDC-Hostnamen.

  • Die Netzwerkkonnektivität zum KDC an Port 88 wurde bestätigt.

  • Die Netzwerkkonnektivität zu Windows-Zielservern an den Ports 5985 und 5986 wurde bestätigt.

  • (Multi-domain) Jede Active Directory-Domäne hat ihre eigenen Anmeldeinformationen, die im Discovery-Tool konfiguriert sind, [realms] und krb5.conf enthält [domain_realm] Einträge für alle Domänen.

Fehlerbehebung bei der Oracle-Datenbank

Um Probleme mit der Erfassung von Oracle-Datenbanken zu diagnostizieren, wie z. B. fehlende Daten oder Fehler, überprüfen Sie Folgendes.

Verbindung verweigert oder Timeout

Symptom: Der Oracle-Sammlungsstatus zeigt einen Verbindungsfehler für einen Server an.

Um dieses Problem zu beheben, überprüfen Sie Folgendes:

  • Stellen Sie sicher, dass der Oracle-Listener auf dem Zielhost läuft: lsnrctl status

  • Überprüfen Sie die Netzwerkkonnektivität vom Discovery-Tool zum Oracle-Host auf Port 1521 (oder Ihrem benutzerdefinierten Port): nc -zv <oracle-host> 1521

  • Stellen Sie sicher, dass die Firewallregeln eingehende Verbindungen auf dem Oracle-Listener-Port zulassen.

  • Überprüfen Sie den Dienstnamen, indem Sie ihn lsnrctl services auf dem Oracle-Host ausführen. Wenn der Dienstname falsch ist, lehnt der Oracle-Listener die Verbindung ab.

Fehler bei der Authentifizierung () ORA-01017

Symptom: Die Erfassung schlägt aufgrund eines ungültigen Benutzernamens oder Passworts fehl.

Überprüfen Sie Folgendes, um dieses Problem zu beheben:

  • Stellen Sie sicher, dass das Oracle-Dienstkonto existiert und nicht gesperrt ist: SELECT account_status FROM dba_users WHERE username = 'DISCOVERY_USER';

  • Stellen Sie sicher, dass das Passwort korrekt ist, indem Sie die Verbindung manuell herstellen: sqlplus discovery_user/<password>@<host>:1521/<service_name>

  • Wenn das Konto gesperrt ist, entsperren Sie es: ALTER USER discovery_user ACCOUNT UNLOCK;

Unzureichende Rechte (ORA-01031)

Symptom: Die Verbindung ist erfolgreich, aber die Erfassung gibt unvollständige Daten zurück.

Überprüfen Sie Folgendes, um dieses Problem zu beheben:

  • Stellen Sie sicher, dass SELECT_CATALOG_ROLE gewährt wurde: SELECT * FROM dba_role_privs WHERE grantee = 'DISCOVERY_USER';

  • Gewähren Sie die erforderliche Rolle, falls sie fehlt: GRANT SELECT_CATALOG_ROLE TO discovery_user;

Die manuellen Anmeldeinformationen zeigen einen Fehler an, aber die automatische Verbindung funktioniert

Wenn Sie Anmeldeinformationen manuell an einen Server anheften, greift das Erkennungstool nicht zurück, falls die Verbindung fehlschlägt. Stellen Sie sicher, dass der Port und der Dienstname, die Sie für die Anmeldeinformationen konfiguriert haben, mit dem Oracle-Listener auf dem jeweiligen Server übereinstimmen. Wenn der Server über einen nicht standardmäßigen Port- oder Dienstnamen verfügt, aktualisieren Sie die Konfiguration der Anmeldeinformationen entsprechend.

OS-level Fallback erkennt Oracle nicht

Wenn keine Datenbankanmeldedaten konfiguriert sind und das OS-level Fallback Oracle nicht erkennt:

  • Stellen Sie sicher, dass die SSH- oder WinRM-Betriebssystemanmeldeinformationen konfiguriert sind und für den Server funktionieren (überprüfen Sie den Status der Erfassung von Betriebssystemmetriken).

  • Stellen Sie bei Linux-Hosts sicher, dass die Prozesse des Oracle Process Monitor (pmon) /etc/oratab vorhanden sind oder dass sie ausgeführt werden.

  • Stellen Sie bei Windows-Hosts sicher, dass Oracle-Registrierungseinträge unter vorhanden sind HKLM\SOFTWARE\Oracle oder dass oracle.exe Prozesse ausgeführt werden.

SNMP-Fehlerbehebung

Greifen Sie auf das Discovery-Tool VM zu

  • Log-in zum Discovery-Tool VM, öffnen Sie Remote Console in vCenter

    • Benutzername: discovery

    • Passwort: Passwort

Installieren Sie die SNMP-Tools (falls erforderlich)

  • sudo yum install net-snmp-utils -y

Testen Sie die SNMP-Verbindung zu Linux-Servern

  1. snmptable -v 2c -c <COMMUNITY_STRING> <REMOTE_SERVER_IP> .1.3.6.1.2.1.6.13.1

  2. Beispiel:

    #SNMPv2c:
snmptable -v 2c -c public 192.168.1.100 .1.3.6.1.2.1.6.13.1

#SNMPv3 (with authentication):
snmptable -v 3 -u <username> -a MD5 -A <auth_password> 192.168.1.100 .1.3.6.1.2.1.6.13.1

#SNMPv3 (with privacy):
snmptable -v 3 -u <username> -a MD5 -A <auth_password> -x DES -X <priv_password> 192.168.1.100 .1.3.6.1.2.1.6.13.1

Fehler bei der Netzwerkerfassung

Zum Lesen des Passworts ist ein Terminal erforderlich

Fehler:

ss command failed on <host>: sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper sudo: a password is required

Der Befehl ss fordert zur Eingabe des Benutzerpassworts auf. Der konfigurierte SSH-Benutzer muss sich in der Gruppe sudoers befinden und mit passwortlosem Sudo für den Befehl konfiguriert sein. ss/netstat Um passwortloses Sudo zu konfigurieren:

  1. Erstellen Sie eine neue Sudoers-Datei:

    sudo vi -f /etc/sudoers.d/<username>

  2. Füge die Zeile hinzu:

    <username> ALL=(ALL) NOPASSWD: /usr/sbin/ss, /usr/bin/netstat

  3. Nach dieser Änderung sudo netstat -tnap sollte es ausgeführt sudo ss -tnap werden, ohne nach einem Passwort zu fragen

Die Netzwerksammlung lief ohne Sudo

Wenn auf der Seite Entdecktes Inventar die folgende Warnung angezeigt wird:

Network collection ran without sudo. Process-level connection data may be missing.

Diese Warnung weist darauf hin, dass das SSH-Benutzerkonto keinen Sudo-Zugriff auf dem Zielserver hat. Ohne Sudo kann das Discovery-Tool immer noch Netzwerkverbindungsdaten sammeln, aber es kann nicht feststellen, welchem Prozess die einzelnen Verbindungen gehören. Um vollständige Verbindungsdaten auf Prozessebene zu sammeln, stellen Sie sicher, dass der SSH-Benutzer über Sudo-Zugriff auf dem Zielserver verfügt.

Fehler beim Sammeln von Betriebssystem-Metriken

Fehlende Server-UUID für Linux-Server

Wenn das Discovery-Tool nicht in der Lage ist, die Server-UUID für Linux-Server zu ermitteln (wird als leer angezeigt oder fehlt), überprüfen Sie, ob die für diese Server konfigurierten SSH-Anmeldeinformationen über Sudo-Rechte verfügen. Das Tool verwendet, um die dmidecode Server-UUID zu lesen. Wenn dmidecode es nicht installiert ist, greift das Tool auf Lesen zurück/sys/class/dmi/id/product_uuid, wofür ebenfalls Sudo-Zugriff erforderlich ist. Ohne sudo kann keine Methode die UUID abrufen.

Lösung: Stellen Sie sicher, dass das SSH-Benutzerkonto, das dem Discovery-Tool zur Verfügung gestellt wurde, Sudo-Zugriff auf den Linux-Zielservern hat.

Probleme beim Zugriff auf das Inventar „Ermittelt“

Wenn Sie im Status „Serversammlung“ eine Meldung wie Fehlende Anmeldeinformationen oder Zugriff verweigert sehen, gehen Sie wie folgt vor:

  1. Wählen Sie den Server in der Tabelle der erkannten Server aus.

  2. Wählen Sie Zugangsdaten verwalten. Sie haben folgende Möglichkeiten:

    1. Wählen Sie alternative Anmeldeinformationen aus der Dropdownliste Anmeldeinformationen auswählen aus.

    2. Wählen Sie Neue Anmeldeinformationen verwenden und geben Sie neue Anmeldeinformationen ein.

  3. Speichern.

Das Discovery-Tool versucht erneut, die Verbindung herzustellen, nachdem Sie Ihre Änderungen gespeichert haben.

Fehlerbehebung bei der SSH-Schlüsselauthentifizierung

Testen der SSH-Schlüsselkonnektivität über das Discovery-Tool

Wenn die SSH-Schlüsselauthentifizierung fehlschlägt, überprüfen Sie die Konnektivität zwischen dem Discovery-Tool und dem Zielserver:

  1. Melden Sie sich beim Discovery-Tool an (über die vSphere-Konsole oder SSH beim Linux-Host).

  2. Testen Sie die SSH-Konnektivität mit Ihrem privaten Schlüssel:

    ssh -i /path/to/private_key -o StrictHostKeyChecking=no <username>@<target_ip>

  3. Wenn die Verbindung erfolgreich ist, liegt das Problem darin, wie der Schlüssel in das Discovery-Tool hochgeladen wurde. Re-upload Geben Sie den Schlüssel ein und überprüfen Sie, ob der Benutzername übereinstimmt.

  4. Wenn die Verbindung fehlschlägt, überprüfen Sie die Fehlermeldung in der folgenden Tabelle.

Fehlermeldung Ursache Auflösung
Permission denied (publickey) Der öffentliche Schlüssel befindet sich nicht in der authorized_keys Datei des Zielservers, oder der Benutzername ist falsch. Fügen Sie den öffentlichen Schlüssel ~/.ssh/authorized_keys auf dem Zielserver für den richtigen Benutzer hinzu. Überprüfen Sie die Dateiberechtigungen:chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys.
Connection timed out after 20s Port 22 ist vom Discovery-Tool aus nicht erreichbar. Stellen Sie sicher, dass Port 22 zwischen dem Discovery-Tool und dem Zielserver geöffnet ist. Überprüfen Sie Firewalls und Sicherheitsgruppen.
Connection refused Der SSH-Dienst läuft nicht auf dem Zielserver. Starten Sie den SSH-Dienst:. sudo systemctl start sshd
Invalid SSH key for credential 'name' Das Schlüsselformat wird nicht unterstützt, die Schlüsseldaten sind beschädigt oder die Passphrase fehlt oder ist falsch. Stellen Sie sicher, dass das Schlüsselformat RSA, ECDSA oder Ed25519 im PEM-, OpenSSH- oder PKCS #8 -Format ist. Wenn der Schlüssel verschlüsselt ist, stellen Sie sicher, dass die Passphrase korrekt ist.

Fehlerbehebung beim Linux-Installationsprogramm

Port 5000 wird bereits verwendet

Symptom: Der Discovery Tool-Dienst kann nach der Installation nicht gestartet werden.

Lösung: Identifizieren und beenden Sie den Prozess über Port 5000:

sudo ss -tlnp | grep :5000

Beenden Sie den Konflikt verursachenden Prozess und starten Sie dann das Discovery-Tool neu:

sudo ./AWS-Transform-discovery-tool.sh start

Häufige Fehlermeldungen

In dieser Tabelle werden häufig auftretende Fehlermeldungen und ihre Erklärungen beschrieben:

Fehlermeldung Speicherort Erklärung
Ein Passwort wurde bereits erstellt Passwortseite erstellen Race Condition, wenn zwei Benutzer gleichzeitig Passwörter erstellen; aktualisiere
Der Export ist fehlgeschlagen Seite „Inventar“ Versuchen Sie es erneut oder senden Sie Protokolle
Eine Erfassung auf Abruf ist bereits im Gange Seite „Inventar“ Rennbedingung, wenn zwei Benutzer gleichzeitig mit der manuellen Erfassung beginnen. Versuchen Sie es erneut, nachdem die aktuelle manuelle Erfassung abgeschlossen ist
Command timed out after 60s Status der Servererfassung Ein Befehl auf dem Zielserver wurde nicht innerhalb von 60 Sekunden abgeschlossen. Dies kann auf stark ausgelasteten Servern auftreten. Versuchen Sie erneut, die Erfassung durchzuführen, oder untersuchen Sie die Auslastung des Zielservers.
Ein oder mehrere Anmeldeinformationen enthalten unbekannte UUIDs Seite für den Zugriff auf das Betriebssystem Race Condition, wenn zwei Benutzer die Anmeldeinformationen für das Betriebssystem gleichzeitig bearbeiten. Versuchen Sie es erneut
Ungültiges Passwort Sign-in Seite Falsches Passwort für die Anmeldung. Wenden Sie sich an den Administrator oder wenden Sie sich an
Ihre Sitzung ist abgelaufen. Bitte melden Sie sich erneut an. Sign-in Seite Die Sitzung ist abgelaufen. Sie müssen sich erneut anmelden
Ein interner Fehler ist aufgetreten Verschiedene Seiten Versuchen Sie es erneut oder senden Sie Protokolle