Run Scripts on Windows Vista and Newer

Making Your WinBatch Script Run on Windows Vista and Newer

Keywords: UAC Manifest requestedExecutionLevel UiAccess Windows Vista Win7 Win8

These are a few things to keep in mind while developing and testing .WBT scripts and distributing your compiled WinBatch script on Systems with UAC enabled. This includes: Windows Vista, Windows 7 and Windows 8 ( and newer ).

We recommend getting up to speed on UAC and Manifests if you plan on doing scripting on UAC enabled (Vista and newer) systems. This article is intended as only a starting place. However this topic is much discussed in the Tech Database (UAC and manifest search terms) and on MSFT's web site.

For more about UAC: http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/UAC+UAC~Help.txt

Use of Application Manifests

An application manifest enables Windows to provide the behavior that the application (exe) expects based on the version of Windows that is targeted. This is especially important in regard to systems that have UAC enabled (which is enabled by default on most systems ).

In Windows Vista or newer, the Windows application manifest has been enhanced with attributes that allow developers to manifest their applications with a requested execution level. The available options are:

As Invoker	The application runs with the same access token as the parent process. (Recommended for standard user applications)
Highest Available	The application runs with the highest privileges the current user can obtain. (Recommended for mixed-mode applications)
Require Administrator	The application runs only for administrators and requires that the application be launched with the full access token of an administrator. (Recommended for administrator only applications)
No Execution Level Information	No requested execution level information in Windows application manifest.

WinBatch and WinBatch Studio

WinBatch needed some way for script developers to test and debug their interpreted .WBT scripts using different manifest settings. So since version 2007B, WinBatch includes many differently manifested versions of its WinBatch.exe and WinBatchStudio.exe. Specifically, WinBatch is shipped with 8 versions of WinBatch and WinBatch Studio with 7 different manifest combinations.

WinBatch Special Manifest versions

Tool	Requested Execution Level	uiAccess
WinBatch.exe	highestAvailable	true
WinBatch_AF.EXE	requireAdministrator	false
WinBatch_AT.EXE	requireAdministrator	true
WinBatch_HF.EXE	highestAvailable	false
WinBatch_HT.EXE	highestAvailable	true
WinBatch_IF.EXE	asInvoker	false
WinBatch_IT.EXE	asInvoker	true
WinBatch_NN.EXE	Un-manifested	Un-manifested

You can also give your WinBatch script a special file extension, and WinBatch will run the appropriately manifested version of WinBatch.

32-bit

File Extension	Tool	Requested Execution Level	uiAccess
.WBT	WinBatch.exe	highestAvailable	true
.WBT_AF	WinBatch_AF.EXE	requireAdministrator	false
.WBT_AT	WinBatch_AT.EXE	requireAdministrator	true
.WBT_HF	WinBatch_HF.EXE	highestAvailable	false
.WBT_HT	WinBatch_HT.EXE	highestAvailable	true
.WBT_IF	WinBatch_IF.EXE	asInvoker	false
.WBT_IT	WinBatch_IT.EXE	asInvoker	true
.WBT_NN	WinBatch_NN.EXE	Un-manifested	Un-manifested

64-bit

File Extension	Tool	Requested Execution Level	uiAccess
.WBT64	WinBatch.exe	highestAvailable	true
.WBT64_AF	WinBatch_AF.EXE	requireAdministrator	false
.WBT64_AT	WinBatch_AT.EXE	requireAdministrator	true
.WBT64_HF	WinBatch_HF.EXE	highestAvailable	false
.WBT64_HT	WinBatch_HT.EXE	highestAvailable	true
.WBT64_IF	WinBatch_IF.EXE	asInvoker	false
.WBT64_IT	WinBatch_IT.EXE	asInvoker	true
.WBT64_NN	WinBatch_NN.EXE	Un-manifested	Un-manifested

WinBatch Studio Special Manifest versions

By default the WinBatch Studio.exe file provided with WinBatch has a manifest with the settings: 'Requested Execution Level: highestAvailable' and 'uiAccess Flag: True'. However, if you are trying to develop and debug scripts with UAC on you might be prompted each time your script attempts an operation that requires a higher execution level. Therefore, we have made available various WinBatch Studio EXEs with all the possible manifest setting combinations.

Tool	Requested Execution Level	uiAccess
WinBatch Studio.exe	highestAvailable	true
WBStudio_AF.EXE	requireAdministrator	false
WBStudio_AT.EXE	requireAdministrator	true
WBStudio_HF.EXE	highestAvailable	false
WBStudio_HT.EXE	highestAvailable	true
WBStudio_IF.EXE	asInvoker	false
WBStudio_IT.EXE	asInvoker	true
WBStudio_NN.EXE	NA	NA

By default the WinBatch.exe and WinBatchStudio.exe are manifested using requestedExecutionLevel=Highest Available and UIAccess=TRUE. Most scripts will never need UI Access set to TRUE, however some of the functions in WinBatch do require UIAccess=TRUE ( specifically the Control Manager extender Functions ). So the default tools, are manifested to give WinBatch script developers the highest privileges the current user can obtain, so that they have access to all of WinBatches functionality.

For example, if you happen to be logged in as an administrator, by default you only have standard user access. That is until you attempt to do an administrative operation. At which time Windows will prompt for consent to elevate to full administrative privileges. However if your script is manifested using Highest Available, the script will run with the full administraive privileges. However there is a catch when it comes to mapped drives. if the user ( in this case an administrator ) maps a drive under the standard users token then a script running with highest available will not see those mapped drives. For more info on this subject please see: http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/UAC+Mapped~Drives~Issue~with~UAC.txt

Even though WinBatch is manifested to give the highest privileges it is important to know that when developing your script, you should keep in mind that unless an application is designed to be run exclusively by system administrators, it should be run with the least privileges. For most scripts this means using the manifest settings: requestedExecutionLevel=As Invoker and UIAccess=FALSE.

Compiler

Once you have run and debugged your script and you decide it is time to compile, the WinBatch Compiler offers the ability to define which manifest settings you would like your EXE to use. Keep in mind that all EXE should be run with the least privileges necessary. The SETTINGS button in the WinBatch+Compiler can be used to specify the appropriate options.

Digitally Signing Your Compiled Exes

Digitally signing an executable requires a digital certificate from a trusted certificate authority, such as VeriSign or Thawte. The code signing certificates from these authorities allow you to sign your executable files to guarantee to your end users that the files have not changed since the time you compiled them. Windows also displays the publisher name on the UAC elevation dialogs, so it reassures your end users that the program they're about to run really did come from you.

By Default all tools distributed with WinBatch are code signed. However if you plan on creating your own compiled EXE using the WinBatch+Compiler then you need to consider digitally code signing your compiled EXEs.

For example, if you try to run an unsigned application (in Vista or newer) that requires elevation, but you have the "User Account Control: Only elevate executables that are signed and validated" policy enabled you will get the error 'A Referral was Returned From the Server'. Administrators will enable this policy in domain environments if they really want to control which applications users run with administrative privileges. If the application is a compiled WinBatch script, then you will need to contact your IT department/developer to get it signed. If you've been tweaking the Group Policy settings in your domain, go ahead and disable this policy if you want to run the tool.

For more on this subject please see: http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/64-bit+Code~Signing~an~EXE.txt

Modify Where Scripts Store User Data

Old Windows programs wrote configuration data into files in the application's installation directory, usually under the Program Files folder. Beginning with Windows Vista, most users should be running with "standard user" privileges, and these privileges don't allow them to write to the Program Files folder. That means that any programs they run should be writing configuration data and other settings to an appropriate application data directory. The table below shows some of the common data locations.

Common Data Locations on Windows

This directory paths can be obtainsed using the ShortCutDir function in WinBatch.

Directory Property	Type of Data and Example
AppDataFolder	Per-user, roaming application data C:\Users\username\AppData\Roaming\
CommonAppDataFolder	Per-machine application data C:\ProgramData\
LocalAppDataFolder	Per-user, non-roaming application data C:\Users\username\AppData\Local
PersonalFolder	User-specific documents C:\Users\username\Documents\

You will need to change your script to use these directories to store any application data. If you use the registry, make sure that the script treats HKEY_LOCAL_MACHINE and HKEY_CLASSES_ROOT as read-only registry hives. All user-specific registry data should be stored in HKEY_CURRENT_USER.

In our expereience most users run in a locked-down desktop environment, which means that most users will not be able to run applications with administrator privileges. This means you should design your script to run using standard user privileges. This can be accomplished using proper coding or by repackaging the script with a setup that grants permissions to the appropriate files, folders and registry keys. Is is important that you make your script work well in Windows (Vista and newer) right from the start.

Article ID:   W17507

Filename:   Making Your WinBatch Script Run on Windows Vista and Newer.txt

File Created: 2014:08:13:07:28:58

Last Updated: 2014:08:13:07:28:58

	WinBatch
	WIL Extenders
	WebBatch
	Tutorials
	Best Tech Support Question

Database Search

TechHome