UAC & Vista Compatibility

Original: 21-Oct-2006;
Last update:
  30-Apr-2007: Added Programmer Talk
  13-Jun-2007: Added Virtualization
Author: Rob Chandler

First up let me say that all Helpware products are now Windows Vista compatible.

Vista UAC is something that everyone will need to deal with sooner or later. While UAC makes Windows more secure, it also has the potential to break our installs and applications. This article is written from a developer/installer's perspective, a result of getting our Helpware products FAR and H2Reg ready for Vista.

I hope this article will help you to fast track your migration to Vista. Feel free to email me comments.
Thanks MVP Dana Worley for being my editor.
Rob

Document Contents:

Vista UAC

Vista UAC (User Account Control) means Security

Under Windows XP most folks normally live in Admin login mode; otherwise, applications don't tend to install and run correctly. However, this is very insecure since "bad software" can too easily get free run of the machine. Windows Vista UAC mode allows you to login as a User but still perform admin tasks. You are prompted every time admin approval is required. Even poorly designed applications that write to protected areas (such as the HKLM registry hive, or to \Program Files directory) can run because Vista intercepts the protected action and prompts you for admin approval before proceeding.

UAC, also called Admin approval mode, is enabled by default in Vista (see UAC checkbox in Control Panel > User Accounts).

The Problem with UAC

The obvious problem with UAC is that some programs, in particular installation applications, really need to run in administration mode. Yet under Vista, Microsoft now recommend you do everything, including install software, under User logon (with UAC enabled).

Our own application H2Reg is used to register MS Help 2 collections (used by MSDN, TechNet, Visual Studio, Office 2007 and Borland documentation). Unfortunately MS H2 API calls, that plug one document collection into another (e.g. into ms.vsipcc.v80), fail under User logon. I'm not sure when this broke under Windows XP. It used to work and we are working with MS to resolve the issue. Our other problem is that the MS Help 2 API cannot be told to register a collection as "All User" or "Current User". IE. If it detects Administrator logon it registers to "All Users", otherwise it registers to "Current User" (which now appears broken). So you see User login is a real problem for us. Or is it? Read on.

By the way I noticed that Office 2007 Beta install does not provide the option to install to "Current User". Possibly because of the problems outlined above.

So then how come Microsoft VS 2005 and Office 2007 installations all install correctly to "All Users"? Well it's because Microsoft "elevate execution level" on their setup programs. Regardless of the login these programs run as if under admin login. Neat eh?

Request Elevated Execution Level

There are a number of ways to elevate the execution level of an executable under Windows Vista.

The last method is what really interests us here. We can mark an executable, ship it to a customer, and have confidence that it will run in administration mode on the customer's PC. The down side -- the user will be prompted for approval when they launch the application. But we're all used to that with setup programs under Windows XP.

Using a Manifest File

Microsoft recommend that all executables, such as Setup programs (which need access to protected areas of Windows), should be marked as requireAdministrator. This is achieved by using a manifest file (embedded or external).

You can try this yourself. Below is a valid manifest file. To mark a file "Fred.exe" as requireAdministrator, save the text below to the file "Fred.exe.manifest" in the same folder as "Fred.exe". When "Fred.exe" is run under Vista User logon you will see the customary Admin approval window appear.

Manifest file 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
    <assemblyIdentity version="1.0.0.0"
	processorArchitecture="X86"
	name="ExeName"
	type="win32"/> 
<description>elevate execution level</description> 
   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
      <security>
         <requestedPrivileges>
            <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
         </requestedPrivileges>
      </security>
   </trustInfo>
</assembly>

 

"Installer Detection" Policy = Automatic Elevation

This is a funny thing the first time you see it. :-)

It turns out that Windows actually examines the names of all executable you run, and if they contain the words "setup", "install", "update", "patch" etc then the executable is automatically elevated; e.g. MySetup001.exe will run elevated. I've heard of cases where a word such as "update" found within an executables resources also trigged elevation. I've also  heard that Windows can recognize and elevate setup files created by InstallShield and Wise. I'm not sure of the exact heuristics used.

So this is going to help older setups to work reliably under Vista.

But...

Questions and Answers

Does this mean I don't need to mark my installation programs?

It's best practice to always mark applications that need it. The behaviour above is controlled by the InstallerDetection Policy, which, of course, can be disabled by your administrator (in fact there is talk that this will be disabled by default for Enterprise - see UAC Blog).

What Policies and Security settings control UAC?

There are 2. The policies are only in effect when UAC is enabled (UAC Checkbox in Control Panel > User Accounts).

Shouldn't my Installer application elevate setup.exe for me?

Yes. Later versions of InstallShield, Wise, Inno etc generate setup programs with embedded manifest files that mark for elevated execution;
e.g. We now use INNO 5.1.8 (http://www.jrsoftware.org/isinfo.htm) which does mark its setup executables.

Do I need to mark all my Installer helper executables?

No. Just mark the main setup program. All other executables downstream will run automatically as administrator.

Example: Setup.exe runs MyApplication.msi, which has a custom action to run MyHelper.exe, which inturn runs AnotherHelper.exe. Now if Setup.exe is marked it turns out that all other executables, right down the chain, also run elevated. And the nice thing is that you are only asked once for approval to run.

How do I elevate an .MSI setup file?

If you have an advanced .MSI (MS Installer) editor such as the Orca tool, it is probably possible. However, applications such as Visual Studio 2005, which have a Setup Project that can create .MSI files, cannot do this.

The solution is to simply create a marked executable that runs your .MSI file. So an elevated Setup.exe runs myinstall.msi, and the .msi is automatically elevated.

Why does my .MSI setup fail to run an elevated Helper.exe?

As discussed above VS 2005 does not generate elevated .MSI files. VS 2005 produced .MSI will fail if they attempt to run helper executables that are marked elevated. This is because they are trying to run in impersonation mode and the spawned EXE can't be pulled down to the security level of the MSI (probably not explained well be you get the gist). Orca tool can be used to edit the MSI and disable impersonation. Or write some VB script to tweak the MSI at the end of the build. But we are now getting way to complicated.

Again the simple fix is to write a marked EXE that runs your MSI file (see above).

Does UAC effect the built-in administrator?

No. UAC mode has no effect if you are logged in as the built-in administrator.

What are all these little Shields in Vista?

Everything marked with a shield needs your approval to run. Typically they're executables marked to run with elevated execution level. You will notice that even program icons and shortcuts (such as the H2Reg.exe desktop icon left) are marked with a shield by Vista.

How can I tell if my Setup EXE is explicitly marked for elevated execution?

Use a resource viewer such as Resource Hacker by Angus Johnson. Here's a screen shot of Resource Hacker listing all resources compiled into my exe. The Manifest is stored in resource group "24", item number "1" (as per the C headers distributed by Microsoft).  You can clearly see an embedded XML manifest marked up as "requireAdministrator".

Summing Up

Thanks to the automatic elevation that happens to all applications called setup, install or patch, and the fact that anything they run is also elevated, most installations will thankfully install and run correctly under Windows Vista. But remember to mark your applications that require elevation in case the InstallerDetection Policy is disabled.

We have released an elevated version of H2Reg.exe that should help our customers. Thankfully H2Reg is usually run from an elevated Setup program so things are not as bad as we originally thought.

Thanks to the hard working people at Microsoft who helped us get this far.

 

Programmer Talk

4-Mar-2007

Non-Elevated Application Runs an Elevated Application.

A non-elevated application may need to spawn an elevated application to perform a download, an install, register a COM server etc.

The Shell API calls ShellExecute() and ShellExecuteEx() do this just fine.

Often programmers launch applications using CreateProcess(), which is useful to wait on a process to terminate. Unfortunately CreateProcess() will fail under Vista when running an elevated application from a non-elevated application. You will need to use ShellExecute() or ShellExecuteEx() which BTW can also return a process ID, then use WaitForSingleObject(ExecInfo.hProcess, INFINITE).

 

Forcing an Application to run Elevated

You can launch another executable as level="requireAdministrator" even though it has no manifest (not marked in anyway). To do this you use ShellExecuteEx() using the verb "runas".

 

References:

 

Virtualization

17-Jun-2007

We better talk about Virtualization as well.

Virtualization: The process of diverting writes to sensitive system areas to user-specific locations.
eg. if I write XYZ.INI to c:\Windows\System32\ you will see the file appear in the following location ­ C:\Users\<user>\AppData\Local\VirtualStore\Windows\System32\

Same happens with c:\Program Files\
And writes to registry location HKEY_LOCAL_MACHINE->SOFTWARE are virtualized to HKEY_CLASSES_ROOT->VirtualStore->SOFTWARE

Microsoft intends to remove virtualization from future versions of the Windows operating system as more applications are migrated to Windows Vista. Notice that the VirtualStore areas are "Current User" and not "All User". So... developers should not rely on Virtualization. It is there only to help old applications work.

Note:

Probably when developing SW you should switch off Virtualization. When you do this, a write to a protected area will result in a "Protection Violation". Which will draw your attention to the problem. To switch Virtualization effectively Off, again use a manifest file to set the execution level. Set it to "asInvoker".

<requestedExecutionLevel
   level="asInvoker | highestAvailable | requireAdministrator"
   uiAccess="true|false"/>

asInvoker - The application runs with the same token as the parent process.

That gives you a taste of virtualization. Please see MS documentation for a more accurate view.
 

Further Reading

Screen Shots (Vista RC2 screen shots)

 

Where is UAC enabled?

See Control Panel > User Accounts


 

How to enable the built-in Administrator Logon (disabled by default in Windows)

  1. Go to: Control Panel > Administrative Tools > Computer Management
  2. Go to: System Tools > Local Users and Groups > Users
  3. Right-click user item "Administrator" and in properties uncheck "Account is disabled"

Note: Admin logon mode is not secure. UAC has no effect under Administrator logon.

 

How to Setup FAR to "Run as Administrator"
 

 

Helpware H2Reg

We don't expect much in the ways of trouble for customers migrating to Windows Vista. Most Setup programs by default run in elevated mode (see above) and anything your Setup program runs (including H2Reg.exe) will also run in elevated mode.

Under Microsoft advisement both H2Reg (1.5.0) and H2Reg setup program (1.5.0b) have been marked as "requireAdministrator". This can be downloaded now from the H2Reg Home Page.

H2Reg -N Switch

The H2Reg -N switch which disables Administrator mode check no longer works.

We haven't disabled it but since H2Reg 1.5.0 is now elevated it can never detect non-admin mode and popup the warning.

Registration in Current User mode

Some customers like the -N switch since it allowed H2Reg to skip admin check and register a collection for the Current User only.

Unfortunately we've recently found that plug-in calls made to the MS Help 2 API fail if run under non-admin mode (on both XP and Vista). Not sure when plug-in calls broke under Windows XP. Microsoft are looking into this. So we recommend you stick with administrator mode installs (use the new marked H2Reg.exe and don't use the -N switch).

The other problem is that H2 API doesn't give us the option to install "All Users" or "Current User" (the H2 API simply detects the current mode), so safest to always elevate H2Reg to admin mode (All User registration).

So maybe not as flexible. If MS fix the bug that appears to be on their side, we will let you know. If it's any consolation all Microsoft installation programs such as VS 2005 and Office 2007 all run with elevated execution levels too. And these collections are always registered under "All User".

MSI Installations

If your installation file is a .MSI created by a Visual Studio 2005 Setup Project then it may fail to run H2Reg.exe (or any other elevated exe) under Windows Vista UAC mode.

See Why does my .MSI setup fail to run an elevated helper.exe? above.

 

Helpware FAR

FAR HTML performs a few commands that require Admin access. These include the MS Help 2 Plug-in Registration command, and FAR Preferences dialog, which can create file associations between certain file types and FAR.

So we now warn you if an action requires administration access. If it does then we advise you to restart FAR, and run FAR in "run as administrator" mode. See Requesting Elevated Execution Level above.

We also changed the location where FAR program data is stored under Windows Vista.