Verwenden Sie diesen Artikel, um Skriptfehler zu beheben.

Fehlerbehebung bei Skriptausfällen

Schritte zur Fehlerbehebung bei allgemeinen Skriptausfällen.

1. Überprüfen Sie, ob das Gerät reagiert. Dies kann durch Öffnen von Modulen wie Task-Manager, Dienst-Manager usw. erfolgen. Wenn diese nicht funktionieren, könnte es Netzwerkprobleme zwischen dem Agenten und unseren Servern geben. Bitte lesen Sie den Artikel Fehlerbehebung beim Atera-Agenten (Windows), um weitere Informationen zur Lösung von Kommunikationsfehlern zu erhalten.

2. Überprüfen Sie, ob das Skript in Atera den richtigen Dateityp verwendet. Wenn das Skript in Atera den falschen Dateityp verwendet, schlägt es fehl. Erstellen Sie das Skript mit dem richtigen Typ neu.

3. Wenn das Skript *.exe- oder *.msi-Installationsdateien enthält, überprüfen Sie, ob die richtigen Argumente für die stille Installation hinzugefügt wurden. Skripte, die über Atera ausgeführt werden, werden auf Windows-Geräten still ausgeführt. Wenn Installationsdateien enthalten sind, müssen Sie möglicherweise Parameter zum Skript hinzufügen, um die stille Installation des Programms anzugeben. Wenn das Skript nicht so konfiguriert ist, dass es das erforderliche Argument für eine stille Installation enthält, wird es ohne GUI ausgeführt, was den Endbenutzer daran hindert, mit dem Installationsassistenten zu interagieren, und letztendlich dazu führt, dass das Skript fehlschlägt. 

4. Ändern Sie, wie die Skriptrechte von der Atera-Konsole gesendet werden – Aktueller Benutzer oder System – und führen Sie das Skript erneut auf demselben Gerät aus.

5. Überprüfen Sie die Exit-Codes des Skripts. Dies sind die häufigsten Exit-Codes, die Sie beim Ausführen von Batch-Skripten antreffen werden.

Für Powershell-Skripte liefert die Ausgabe die benötigten Informationen zum Problem. Die häufigsten Exit-Codes:

6. Stellen Sie sicher, dass das Skript auf dem lokalen Rechner gut läuft. Wenn dies fehlschlägt, liegt das Problem am Skript selbst.

• Falls das Skript Administratorrechte erfordert, können Sie versuchen, das Skript in Atera mit "System" auszuführen.
  Das Systemkonto hat jedoch bestimmte Einschränkungen, siehe Abschnitt Session 0. Als Workaround führen Sie das Skript als "Aktueller Benutzer" aus und stellen Sie sicher, dass der Benutzer Administratorrechte auf diesem Rechner hat.
• Wenn das Skript lokal gut läuft, mit oder ohne Administratorrechte, gehen Sie zum nächsten Schritt.

7. Kontaktieren Sie das Atera-Support-Team und stellen Sie unserem Team die folgenden Informationen zur Verfügung.

• Stellen Sie unserem Support-Team einen Screenshot der Ausgabe zur Verfügung, wenn das Skript lokal ausgeführt wird, sowohl mit als auch ohne Administratorrechte.
• Das Skript, das Sie ausführen möchten, eine kurze Erklärung, was es erreichen soll, zusammen mit der Ausgabe von Atera und vom lokalen Rechner des Skripts.

Fehler beim Herunterladen des Skripts aus dem Atera-Repository

Um diesen Fehler zu beheben, führen Sie bitte die folgenden Befehle auf Ihrem Gerät aus.

reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\ATERA Networks\AlphaAgent" /v AccountId /f
rmdir "C:\Program Files\ATERA Networks\AteraAgent\Packages\AgentPackageSystemTools" /s /q
rmdir "C:\Program Files (x86)\ATERA Networks\AteraAgent\Packages\AgentPackageSystemTools" /s /q

Falls das Problem weiterhin besteht, wenden Sie sich bitte an unser Support-Team.

Fehlerbehebung für Skripte aus der Shared Library

Bei Skripten, die aus der Shared Library heruntergeladen wurden, können wir nur die folgenden Maßnahmen vorschlagen.

• Überprüfen Sie, ob der Dateityp korrekt ist.
• Testen Sie das Skript entweder als System oder als aktueller Benutzer.

Unser Support-Team verwaltet/analysiert keine Skripte aus der Shared Script Library, die Skripte werden nur auf Bösartigkeit überprüft und nicht auf Funktionalität.

Falls Sie Probleme mit einem Skript aus der Script Shared Library haben, wenden Sie sich bitte an den Skriptersteller, um Unterstützung zu erhalten.

Windows Session 0

Was ist Windows Session 0 und warum ist das wichtig?

Windows Session 0 ist eine spezialisierte Windows-Sitzung, in der alle Aspekte der Software, einschließlich interaktiver GUI-Komponenten (Pop-ups, Dialogfelder) und viele andere Aspekte, vollständig isoliert von Ihrer normalen angemeldeten Sitzung initialisiert werden.

Diese Trennung ist absichtlich, durch Design und wird vom Betriebssystem erzwungen. Diese Isolation wurde mit Windows Vista/Server 2008 eingeführt, um verschiedene Sicherheitsbedenken zu mindern.

Kurzgeschichte:

• Windows NT (1993)
  Das Konzept mehrerer Anmeldesitzungen entsteht. Sitzung 0 wird beim Start erstellt, und der erste Benutzer, der sich anmeldet, wird in Sitzung 0 platziert.
• Windows Vista (2007)
  Um verschiedene Exploits zu mildern, verbietet MS Benutzern die Anmeldung in Sitzung 0. Der "Interactive Services Detection Service" wird erstellt, der Administratoren vorübergehend den Zugriff auf Sitzung 0 ermöglicht. Der erste Benutzer, der sich anmeldet, wird Sitzung 1 übernehmen.
• Windows 8 & Windows Server 2012
  Der Interactive Detection Service ist standardmäßig deaktiviert. Dies verhindert, dass jemand zu Sitzung 0 wechselt (es sei denn, ein Registrierungsschlüssel wird aktualisiert).
• Windows 10 & Windows Server 2016
  I/O-Geräte funktionieren in Sitzung 0 nicht mehr. Dieses Verhalten wurde zunächst als Fehler angesehen, war jedoch eindeutig eine bewusste Maßnahme, um die Interaktion mit Sitzung 0 zu verhindern.
• Windows 10, Version 1803 (2018)
  Der Interactive Services Detection Service wird offiziell entfernt. Der Wechsel zu Sitzung 0 ist verboten.

Warum ist das für Atera wichtig?

Da unser Agent ein Dienst ist, der einen Prozess startet, beginnen die meisten unserer Prozesse unter Sitzung 0, sodass sie Ihren Endbenutzern nicht angezeigt werden. Außerdem läuft AteraAgent als integriertes Windows-Konto "NT Authority/System", um seine Berechtigungen zu nutzen.

Ok - wie könnte das in einem realen Szenario aussehen? Nehmen wir ein häufiges Beispiel:
Sie führen ein .bat-Skript auf dem Endbenutzergerät von Atera aus, das ein Dialogfeld erstellen soll, das darauf wartet, dass der Benutzer auf "Ok" oder "Abbrechen" klickt. Wenn das Skript als "NT Authority/System" ausgeführt wird, wartet die Anwendung nun auf eine Eingabe im Pop-up, aber die Benutzeroberfläche wird in der Benutzersitzung nicht angezeigt.

Aus der Sicht des Benutzers scheint die Anwendung eingefroren zu sein, während sie sich völlig normal verhält und auf eine Benutzerantwort wartet, die der Benutzer nicht sehen kann.

Wie Sie bereits bemerkt haben, stellt dies ein Problem dar. Als Workaround können Sie entweder das Skript als "Aktueller Benutzer" ausführen oder Sie können "Runas" nutzen.