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 : https://:443/mob ``` 1. Ergebnis des erwarteten Erfolgs: ``` [ec2-user@discoverytool ~]$ curl -v --insecure -u : 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) ... * Connection #0 to host vcsa left intact ``` **Testen Sie das SSL-Zertifikat** 1. Führen Sie diesen Befehl aus: ``` openssl s_client -showcerts -servername -connect :443 ``` 1. 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 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 -Authentication Negotiate -Credential $cred -Port 5985 # Test WinRM connection on port 5986 (HTTPS) Test-WSMan -Computer -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 -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. 1. Ü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. 1. Überprüfen Sie die Konnektivität zu den Windows-Zielservern an WinRM-Ports. Führen Sie die folgenden Befehle aus: ``` nc -zv 5985 nc -zv 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://: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. 1. Stellen Sie sicher, dass das Dienstkonto über die erforderlichen Berechtigungen auf den Zielservern verfügt. 1. Stellen Sie sicher, dass WinRM auf den Zielservern aktiviert ist. 1. 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 Format`username@DOMAIN`, während Remote Desktop das Format verwendet`DOMAIN\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 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/@:1521/` + 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 .1.3.6.1.2.1.6.13.1` 1. 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 -a MD5 -A 192.168.1.100 .1.3.6.1.2.1.6.13.1 #SNMPv3 (with privacy): snmptable -v 3 -u -a MD5 -A -x DES -X 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 : 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/ ``` 1. Füge die Zeile hinzu: ``` ALL=(ALL) NOPASSWD: /usr/sbin/ss, /usr/bin/netstat ``` 1. 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. 1. Wählen Sie **Zugangsdaten verwalten**. Sie haben folgende Möglichkeiten: 1. Wählen Sie alternative Anmeldeinformationen aus der Dropdownliste **Anmeldeinformationen auswählen aus**. 1. Wählen Sie **Neue Anmeldeinformationen verwenden** und geben Sie neue Anmeldeinformationen ein. 1. **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). 1. Testen Sie die SSH-Konnektivität mit Ihrem privaten Schlüssel: ``` ssh -i /path/to/private_key -o StrictHostKeyChecking=no @ ``` 1. 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. 1. 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 |