So you know what Virtualization is, and you know what UAC is, but what’s UAC Virtualization?

User Account Control (UAC) is more than just a Prompt

Most Windows users will have seen the User Account Control (UAC) execution prompts, that request the user to confirm if they really want to provide a piece of software with privileged permissions:

Microsoft introduced UAC in Windows Vista (and Server 2008) to limit system-level changes to privileged administrative accounts only. Generally speaking, software shouldn’t need write access to system paths during normal operation, so Windows explicitly restricts them to only run in the user context, significantly improving security over prior operating systems like Windows XP. Without authorisation from an administrator, a software call to write to a system path would fail and the program couldn’t execute. If such access is required (such as installing an update) the UAC prompt requests the user to provide consent before system changes can be made.

This was a great innovation, from both a security and data management point of view. If the software could write to any location with no authorisation required, it could damage files or data, circumvent the operation of other programs, and install or modify anything it liked, all with no oversight and no way for the user to know that their computer was potentially being taken over and controlled by a rogue application. User data was also potentially scattered all over the place in obscure sub-directories within application paths prior to Microsoft forcibly ending such shoddy data management.

UAC breaks Legacy Software, so Microsoft finds a Workaround

The change Microsoft made stopped applications from writing to system files and folders unchecked, which included %ProgramFiles%, %Windir%, %Windir%system32, and the registry path HKEY_LOCAL_MACHINESoftware. Programs could make changes to the application path (for installation and updates) after user acknowledgement of a UAC prompt, but user settings and data should be stored within the user profile. Programs aren’t meant to be calling a UAC prompt every time they run (although there are still some terrible examples of this today). Even global settings should be stored in either a shared editable program space (%programdata%) or the appropriate user hive in Windows registry – nothing user-related should ever be written to the application or Windows folder paths.

However, Microsoft was aware that what they were doing with Vista was new and relatively sudden – rightly or wrongly, application developers had been writing software for years based on some fairly fundamental assumptions, and UAC was going to break some things – things lots of companies depended on to, well, not be broken. As with most major changes, a certain amount of transition was inevitable.

While this new way of limiting how software could alter important system files was an excellent idea, Microsoft now had the problem of supporting legacy applications – software that had been written before the time of enlightenment, in the dark ages when software developers would write user data within the application path (something they should have stopped doing after Windows 2000 introduced the Documents and Settings folder, with user data organised and segmented logically within the one root path). No amount of wishful thinking was going to rewrite the thousands of critical business applications that had been created in the ’90’s, or undo the poor coding practices that persisted right up until Vista’s launch at the end of 2006 (and beyond, in some cases, but let’s not dwell on that).

If legacy software would fail to run in this new, strict, UAC controlled environment, and that software was important, users would either run everything with administrative privileges (losing any improvement UAC was bringing to the table – indeed, running everything with admin rights would actually have been a worse situation than we’d had with XP) or disable UAC altogether (an equally bad outcome).

Please Welcome to the Stage: UAC Virtualization

So Microsoft came up with UAC Virtualization (or UAC Virtualisation, for those of us who speak real English). Because these applications expected to be able to write to a program file path, UAC Virtualization obfuscates the true path to the target folder for the application and presents it with a writable container within the user path (similar to a Symbolic Link or Junction). As far as the application is concerned it has write access to what it needs, but in reality instead of writing to C:Program Files<Application Path>, it’s actually writing to %LOCALAPPDATA%VirtualStore<Application Path> (where Windows makes a copy of all program path files the first time the application tries to write to them).

Interestingly, if the program has the ability to open a file browser it can expose to the user, you’ll find that as far as it’s concerned, it still thinks the files it’s working with are exactly where it expects them to be – in the C:Program Files<Application Path> directory tree. But from outside the application, you can see that it’s actually manipulating files within the Virtual Store – nothing you do from within the virtualized program will allow you to see the true path.

UAC Virtualization Only Works in Specific Circumstances

There are a few caveats to be aware of in order to make sure UAC Virtualization works:

1. Limited to 32-bit applications only. AMD64 compatible applications have all been created after these fundamental design decisions were made and by their very nature can’t be written to address system files in ‘the old way’ that UAC Virtualization was created to address. (IA64 applications have their own special set of problems.)
2. The user must have write access to the files in the original file path. Attempting to write to any files with read-only permissions would bring the whole house of cards crashing down (ie causes the application to crash with an error code).
3. UAC Virtualization can’t be applied to applications running as administrator or otherwise elevated in any way – it must be running within the standard user context.
4. UAC Virtualization is disabled by default – it has to be explicitly enabled.

Registry Virtualization?

Registry Virtualisation is a more specific term for UAC Virtualization applied specifically for registry calls. In that case, registry virtualization fails if an administrator can’t write to the key(s) being called (similar to requirement ‘B’ above).

A correct Application Manifest ensures UAC Virtualization isn’t Applied

UAC also makes use of the Application Manifest XML file. This is a line in the manifest file that tells Windows what access level the application needs to run at when executed. The options are

• ‘asInvoker’ (same access token as the parent process, ie the current user context)
• ‘highestAvailable’ (highest privileges the current user can obtain)
• ‘requireAdministrator’ (can only run as administrator – this is the flag that calls the UAC prompt we all enjoy so much)

If none of these are present, Windows will virtualise the application automatically (assuming that behaviour has been enabled).

UAC Virtualization silently ensured everything kept working

UAC Virtualization was created to allow legacy applications to continue to function in the new UAC world, by having a way to automatically re-route file access requests from the old (incorrect) program path target to the user data path, completely transparent to both the user and the application. Just like all good IT solutions – elegant, completely unseen and almost certainly unknown to the possibly hundreds of thousands of people who would have relied on it every day for some years.

Not a Windows 10 Feature! (and don’t rely on it hanging around)

Some people have mistakenly thought UAC Virtualization was a Windows 10 feature, but it isn’t. It still exists, in the same way that innumerable legacy features continue to be carried forward and supported for the tiny number of edge cases that still need them. But it was a feature built a decade and a half ago for a problem that in most cases has been long since solved. Microsoft has always stated that it is a temporary, ‘interim application compatibility technology’ that will eventually be removed – it exists for the purpose of allowing non-compliant legacy applications to operate, but only as a stop-gap measure, and developers have been encouraged for many years to transition their programs to a compliant state (ie update or replace it with something that no longer attempts to write to sensitive system areas).

So how do You Make it Work?

Activation of UAC Virtualization is done within Group Policy. Browse to Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies and Security Options. Scroll right to the bottom of the Security Options Policy window. The last policy is called “User Account Control: Virtualize file and registry write failures to per-user locations”:

Select the ‘Define this policy setting’ checkbox and change the radio button to ‘Enabled’:

Don’t try this at Home

You’ll never need to do this, of course – if you’ve never heard of this feature before now, that’s because you’ve never come across a legacy application that needed it, and that’s extremely unlikely to change in your future career. But it doesn’t hurt to know what it was, and why it was necessary, if for no other reason than to appreciate that words like ‘virtualization’ can mean rather different things in different contexts. That, and how a single seemingly innocuous change in Group Policy can trigger such an elegant and complicated change to the way Windows treats running applications and can intercept and re-route their file calls on the fly under the hood. Makes you wonder what else you didn’t know about those fifty million lines of code… Like App-V, for example.

Conclusion

UAC Virtualization was essentially a workaround, to allow legacy programs that expected to store and change user data within the program’s application folder path, to continue to work under new, more secure and better-organised data structures introduced in Windows Vista alongside User Account Control security features. This applied to both files and registry targets and was achieved by dynamically redirecting file access calls from application paths to user data paths in a way that was completely transparent to the software. The term ‘virtualization’ here referred to the folders and data only appearing in the expected location ‘virtually’, when it was actually in a completely different location.

Have you had any hands-on experience with UAC Virtualization? Let us know in the comments section below.