Troubleshoot: Scripts

Use this article to help you troubleshoot script errors.

• Troubleshoot script failure
• Failed to download script from Atera's repository
• Script creation requests
• Troubleshoot script from Shared Library
• Windows Session 0

Troubleshoot script failure

Troubleshoot steps for general script failing.

1. Verify if the device is responsive. This can be done by opening modules like Task Manager, Service manager, etc. If these are not working, there could be networking issues between the agent and our servers. Please read Troubleshoot the Atera Agent (Windows) article for more details on how to solve communication errors.

2. Verify if the script in Atera uses the correct File Type. If the script in Atera uses the wrong File Type it will fail, so recreate the script using the correct type.

3. If the script includes *.exe or *.msi installation files, verify that the proper arguments have been added for silent installation. Scripts run through Atera are executed silently on Windows devices, so when including installation files, you may need to add parameters to the script to specify the silent installation of the program. If the script isn't configured to include the necessary argument(s) for a silent install, it will run without a GUI, preventing the end user from being able to interact with the installation wizard and ultimately causing the script to fail. 

4. Change how the script rights are sent from the Atera console – Current user or System and run the script again on the same device.

5. Check the exit codes of the script. These are the most common exit codes, that you will encounter when running batch scripts.

For Powershell scripts, the output will provide you with the needed information regarding the issue. The most common exit codes:

6. Make sure that the script runs well on the local machine. If this fails, the problem is the script itself.

• In case the script requires Admin rights, you can try to run the script in Atera using "System".
  However, the system account has certain limitations, see Session 0 section. As a workaround, run the script as the "Current user", and make sure the user has Administrator rights on that machine.
• If the script runs well locally, with or without Admin rights, go to the next step.

7. Contact the Atera support team, and provide our team with the following information.

• Provide our support team with a screenshot of the output when running the script locally, both with Administrator rights and without.
• The script you try to run, a brief explanation of what is supposed to achieve, along with the output from Atera & from the local machine of the script.

Failed to download script from Atera's repository

In order to fix this error, please run the commands below on your device.

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

In case the issue still persists, please reach out to our support team.

Script creation requests

For tickets where a customer requests script creation from the support team, inform them that this is not a service that we offer.

Troubleshoot script from Shared Library

When it comes to scripts that were downloaded from the shared library, we can only suggest the following actions.

• Verify if the File Type is correct.
• Test the script either as System and Current user.

Our support team does not manage/troubleshoot scripts from the Shared Script Library, the scripts are screened only for maliciousness. and not for functionality.

In case you have issues with a script from the Script Shared Library, please contact the script creator for assistance.

Windows Session 0

What is Windows Session 0 and why is this important?

Windows Session 0 is a specialized Windows Session where all aspects of software including interactive GUI Components (pop-ups, dialog boxes) and many other aspects are being initialized in complete isolation from your normal logged-in session.

This separation is intentional, by design, and enforced by OS. This isolation was started with Windows Vista/Server 2008 in order to mitigate various security concerns.

Brief history:

• Windows NT (1993)
  The concept of multiple login sessions takes birth. Session 0 is created at boot, and the first user to log in is placed in Session 0.
• Windows Vista (2007)
  To mitigate various exploits, MS prohibits users from logging in to Session 0. The "Interactive Services Detection service" is created allowing admins to temporarily access Session 0. The first user to log in will take Session 1.
• Windows 8 & Windows Server 2012
  Interactive Detection Service is disabled by default. This prevents anyone from switching to Session 0 (unless a registry key is updated).
• Windows 10 & Windows Server 2016
  I/O devices no longer work in Session 0. This behavior was thought to be a bug, but clearly, it was a deliberate action intended to prevent interaction with Session 0.
• Windows 10, version 1803 (2018)
  The Interactive Services Detection service is officially removed. Switching to Session 0 is forbidden.

Why is this important for Atera?

Since our agent is a service that spawns a process, most of our processes start under Session 0, so they won't be displayed to your end-users. Also, AteraAgent is running as the built-in Windows Account "NT Authority/System" in order to leverage its permissions.

Ok - so what could this actually look like in a real-world scenario? Let's take a common example:
You run a .bat script on your end-user machine from Atera, it's supposed to create a dialog box waiting for the user to click "Ok" or "Cancel". If the script runs as "NT Authority/System", the application is now waiting for input on the pop-up, but the UI is not displayed in the user session.

From the user's perspective, the application appears to be hung/frozen, while it is behaving perfectly normally, and it's waiting for a user response that the user cannot see.

As you have already noticed, this presents a problem. As a workaround, you can either run the script as "Current User", or you can take advantage of "Runas"