User Account Control (UAC) and FastTrack Scripting Host One of the first obstacles when moving from Windows XP to Windows 7 is the User Account Control (UAC). A decision has to be made as to whether to enable it or not. As UAC is effectively a lock-down mechanism, it will obviously impose some limitations in relation to what can be automated - or how it can be automated. Throughout this article, we will try to map what exactly UAC means in relation to scripting and possible workarounds. Please have a look at this article to understand what UAC is, before continuing reading: Microsoft Technet: Understanding and Configuring User Account Control Related pages Setting up logon scripts How to set up logon scripts with FastTrack Logon. Configuring FastTrack Logon How to customize settings for FastTrack Logon. Documentation overview Browse online documentation.

UAC and policies

From hereon we will assume that you have read the article above and we will adopt the term "elevate" as prompting the user for permission to change token. The article above also explains policy settings and one interesting thing about the UAC policy settings is that they are per-machine and effectively all-or-nothing settings. It would make sense to create one domain admin user that is not under User Account Control, which could be used for automation tasks. But this is not possible by design by Microsoft.

Understanding permissions and privileges

To fully understand what it means that administrators have multiple tokens, let's look at this from a more practical angel. If you are new to Windows 7 scripting and User Account Control, here is a little surprise that will put things in perspective. We will assume that you, as the executing user, are a local administrator and that you are under User Account Control. Let us try to run a very simple script:

WriteRegistry HKLM\Software\Acme Corporation\Test,Test

Pretty straight-forward, but this happens when we execute the script:


The reason this happens is that the executing user has the permission to write to the registry, but not the privilege to do so. So even if you have permission to change any system-wide settings like the machine part of the registry, system files or any other setting that is not per-user, UAC will block. That is in essence the point of UAC. By default you cannot change system-wide settings, even if you are administrator. So let's go back to the Microsoft article again and look at the "UAC Architecture" section, which says:

"When an administrator logs on, the user is granted two access tokens: a full administrator access token and a "filtered" standard user access token. By default, when a member of the local Administrators group logs on, the administrative Windows privileges are disabled and elevated user rights are removed, resulting in the standard user access token."



The reason we are not allowed to set the registry key is that we are now running a sub-process of the top explorer.exe on the drawing. This means that we need to make sure that we are executing the script with the full administrator access token. For this reason there is a command called "ElevateUser" from version 7.2. If we use this command before setting the registry key, the script will look like this:

ElevateUser WriteRegistry HKLM\Software\Acme Corporation\Test,Test

If the executing user is not under User Account Control, the command does nothing. But if the executing is under User Account Control, the script will stop and ask for permission to continue:


So does this mean that it is not possible to do any kind of automation that requires administrative permission and privilege? Well, it certainly means that some options are out. For example, if you wanted to set a registry key in the machine part of the registry or install an application from a logon script, it would normally be possible to include a script that runs as a domain admin user and then set the key or install the application. This cannot be done, if UAC is enabled for administrators, because it wouldn't be possible to ask this user for UAC permission - that is, if you could live with the UAC halting at all.

Version 7.2 has 4 additional commands that will prompt for permission to elevate, if UAC is enabled: LaunchElevated, LaunchScriptElevated, RunElevated and RunScriptElevated. Obviously these commands are not usable for fully automated processes, but there are scenarios, where one could live with the UAC blocking before continuing script execution. For example, if you create a script with a menu that executes jobs on the local machine and this menu is started manually by for example help desk operators. In such a case, one could live with an initial prompt to continue.

Alternatives when UAC is enabled for administrators

So we can safely conclude that if UAC is enabled for administrators, some automation options are out. It would not be possible for example to install software from a logon script, as shown here.

There are alternatives, but they require a little more work to implement. If users and administrators are under User Account Control, what are the options then? Well, the local system account is not under User Account Control. When we deploy MSI packages through group policies, the local system account is used and that works because this account is not restricted by UAC. So one option to get automation done on clients would be to simply package a script inside an MSI package and deploy that through group policies. You can build MSI packages from within the script editor; see here for details. MSI packages built with FastTrack Scripting Host supports the "Major Upgrade" feature of Windows Installer, which allows automatic re-deployment, when new packages are built.

An MSI package is a good alternative to deploying general software. It may however seem overkill for maintenance tasks for example. A better option in such a scenario is to use startup scripts, as described here. Startup scripts also runs as the local system account and as mapping network drives and reading files off network shares are not limited by UAC, the system account can freely use the LogonUser command to establish network credentials and then read required files from the network.