By far the biggest trap that people fall into when they start leveraging the capabilities of Automate scripting, commands and all other sorts of goodies, is they choose to run those features as Admin. There are a significant amount of functions that allow you to run as Admin. Most people try these functions and they don’t work as they expect them to. These functions include:
- Process Execute As Admin
- File Copy as Admin
- File Delete as Admin
- File Rename as Admin
- Folder Create as Admin
- Folder Delete as Admin
- Powershell Command as Admin
- Shell as Admin
- Any Execute Script with Run As Admin Selected
There’s a number of reasons why this is both unnecessary and doesn’t normally work. Before we get into those reasons, here is the reason they are unnecessary: the Automate Service almost always runs under the context of the System Account. The System Account is the big daddy of all permissions, it basically gives you the ability to do ANYTHING on a local agent. Typically, SYSTEM has permission to everything, including all files, all Windows functions and all services. You cannot get a higher privileged account in Windows. Because the Automate service runs under the context of SYSTEM, it inherits all of the abilities of the SYSTEM account allowing you PHENOMENAL COSMIC POWER itty bitty living space. Essentially, you can do pretty much anything with a standard function without needing to Run as Admin because the Automate service runs under this account.
When you use one of the Automate functions to Run as Admin, there are usually two hurdles:
- The function will extract the Admin credentials set at the Location level and attempt to use them – if they are wrong, all those functions will fail
- Even if you successfully manage to pass the first hurdle, you end up in a completely backwards position when UAC is enabled on an agent, because when Automate launches the task as the user, the NON elevated token is used. This is by Microsoft’s design, because UAC is supposed to prevent unauthorised changes. Even though you are starting as SYSTEM and launching as an Administrator with valid credentials, you will not have Administrator rights. If you think that sounds stupid, you’re right. There is strong and active feedback on this back to ConnectWise in the LabTech Geek community. What this means is ironically you often end up having less ability than if you would have just run the script function without the “As Admin”.
When would you actually need to us the “As Admin” commands? One usage would be when you need to copy something to a UNC Path. The computer account (SYSTEM) doesn’t tend to have permission to access shares, but the user does not need to be elevated for a file copy or similar operation.
Remember this best practice advice from our Lord and Saviour ART:
thank you for explaining this to me, as no one from Labtech support has
This is bad advice, suggesting you leave automate agents in their default configuration and running as system. This breaks other aspects of automate, which is why best practice, and official onboarding training will tell you to get your passwords set up for local admin and get the agent running under that account. In this best practice configuration, not everything assumes system credentials.
Thanks for this! Another issue with this is, if you attempt to execute certain scripts or commands as the admin, and that account has never logged into the machine, you will receive the error “Failed to create temporary file. Username: . Profile folder not found. Validate user has previously logged into the system.”
Any direction on how to find all the scripts in your CWA, which currently use these? As I have found a couple already that are precanned from CWA.
I know this is old, but this is a very good example of bad IT advice from someone who’s job in IT is to make blog posts whilst not really being an SME. You have to Run as Admin for lot’s of things, particularly PS.