Windows User State Virtualization – Part 3: Virtualizing Application State

If you would like to read other articles in this series please go to:

• Windows User State Virtualization – Part 1: Introduction and Issues
• Windows User State Virtualization – Part 2: Scenarios
• Windows User State Virtualization – Part 4: Mixed Environments
• Windows User State Virtualization – Part 5: Implementing USV
• Windows User State Virtualization – Part 6: USV Frequently Asked Questions

When a user roams from one computer to another on a corporate network, their basic need remains the same: to be able to perform their job. Redirecting folders like My Documents (where users should and usually do store work-related files) and Desktop (where users sometimes save important files so they can access them quickly) meets some of this need since it allows users to easily access work-related files from any computer on the network. But users sometimes want more than just access to their data—they also want the applications they use to work with such data to look, feel and behave exactly the same regardless of which computer they log on to.

For example, if a user customizes Microsoft Word on one machine then she may want the same customization to be visible when she logs on to a different machine and opens Word on it. Common customizations might include showing the Ribbon minimized, showing formatting marks, ignoring uppercase words during spell checks, and so on. Users who roam between machines are often annoyed if the applications they use aren’t set up exactly the same on each computer.

Per-user application customizations like these together comprise the state of the application. An application’s state can include both settings and data. Per-user application settings are stored in registry, generally within the user’s HKEY_CURRENT_USERS (HKCU) registry hive. Per-user application data consists of files stored on the user’s hard drive, and on Windows Vista and later such data is usually stored within the user’s profile in AppData, a hidden folder found under each user’s root profile folder. Let’s look at roaming per-user application data first.

Roaming Per-User Application Data

Per-user application data is stored in the AppData folder. Beneath the AppData folder are three subfolders described in Table 1 below.

Table 1: Subfolders of USERPROFILE\AppData
As Table 2 shows, the Local and Roaming subfolders in Windows Vista and later had their counterparts in Windows XP.

Table 2: Application state folders in Windows Vista and later compared with Windows XP

What kind of Windows and application data is actually stored in the AppData\Roaming folder? Lots of stuff including network shortcuts, printer shortcuts, Send To shortcut menu items, Start menu recent items, Microsoft Office application templates and custom dictionaries, and so on. Figure 1 shows the AppData\Roaming folder and its subfolders on a Windows 7 machine with Office 2010 installed.

Figure 1: The AppData\Roaming folder and its subfolders on a Windows 7 machine with Office 2010 installed

The contents of this AppData\Roaming folder can be roamed in two ways:

• It can redirected out of the user’s profile to a network share by using Folder Redirection (FR) (see Figure 2 below).
• It can be roamed along with the rest of the user’s profile by using Roaming User Profiles (RUP).

Figure 2: The AppData\Roaming folder can be redirected using Folder Redirection

Roaming Per-User Application Settings

There are many, many more per-user settings stored in the registry however than there are per-user data files stored in the AppData\Roaming folder. These per-user are stored within the user’s HKCU registry hive, which is stored as a file named NTUSER.DAT in the root of each user’s profile, which means these settings can be roamed by using RUP. Examples of per-user Windows settings include such things as the user’s current theme, sound scheme, desktop background, screen saver, display settings, accessibility settings, regional and keyboard settings, problem reporting settings, Windows Explorer customization settings, Internet Explorer options, Windows Media Player settings, and so on.

Examples of per-user application settings for Office 2010 include security settings, Ribbon customizations, most recently used (MRU) entries, user name and initials for reviewing, and more. These application settings are found under HKCU\Software\Microsoft\Office and Figure 3 below shows some of the per-user application settings for Word 2010.

Figure 3: Per-user application settings for Word 2010

How to Roam Application State

Because application state (per-user application data and settings) are stored in two locations (data files in the AppData\Roaming folder and settings in the user’s HKCU registry hive) you have some choices on how to roam application state for your organization if this is needed. Specifically, you can:

• Approach #1: Use RUP to roam both the user’s HKCU registry hive together with the AppData\Roaming folder within the user’s profile.
• Approach #2: Use RUP to roam the user’s HKCU registry hive while using FR to redirect the AppData\Roaming folder out of the user’s profile to a network share.
• Approach #3: Don’t use RUP, just use FR to redirect the AppData\Roaming folder out of the user’s profile to a network share.

Let’s look at the pros and cons of each of the above approaches.

Approach #1: Use RUP alone

The main advantage of this approach is that it keeps application data and application settings in sync with each other. This is because both the user’s HKCU registry hive and the contents of the AppData\Roaming folder are normally synced only at user logon and logoff. This can be important because some applications may not work properly and can even crash if the application’s settings stored in HKCU become out of sync with the application’s data stored in AppData\Roaming.

Another advantage of this approach has to do with poorly behaved applications that just don’t work right when certain subfolders of AppData\Roaming are roamed. In such cases you can use the “Exclude directories in roaming profile” policy setting to exclude these subfolders from being roamed with RUP (see Figure 4) which is found under Computer Configuration\Policies\Administrative Templates\System\User Profiles.

Figure 4: Policy setting for excluding user profile subfolders from being roamed with RUP

The main downside of this approach however is that it can increase logon/logoff times for users. This is because the contents of the AppData\Roaming folder can frequently change and can often grow quite large over time. The resulting increase in the size of user profiles means that when RUP is used the logon/logoff experience for users can become poor. Note that beginning with Windows 7 there is a new policy setting called “Background upload of roaming user profile’s registry file while user is logged on” found under User Configuration\Policies\Administrative Templates\System\User Profiles. By enabling and configuring this policy setting you can upload changes to roaming profiles in the background while users are logged on, and this can help reduce logon/logoff times for users (see Figure 5). But while frequently uploading roaming profiles in the background might lessen the chance of application data and settings getting out of sync, it doesn’t solve the problem completely and can also add a lot of additional traffic to your network.

Figure 5: Policy setting for enabling background upload of roaming profiles

Approach #2: Use RUP but use FR to redirect AppData\Roaming

The advantage of this approach is that redirecting the contents of the AppData\Roaming folder out of the user profile reduces the size of user profiles and thus can provide a much better logon/logoff experience for users than the previous approach above. In this scenario, RUP syncs the HKCU registry hive to a network share while Offline Files syncs the contents of the redirected AppData\Roaming folder to a different network share. Once again however, the problem becomes keeping application settings and data in sync with each other for applications that behave poorly when these become out of sync. In this case, another policy setting can come to the rescue, namely “Network directories to sync at logon/logoff time only” which is found under User Configuration\Policies\Administrative Templates\System\User Profiles. By enabling and configuring this policy setting, you can specify certain subfolders under AppData\Roaming as needed so that they sync using Offline Files only at logon/logoff (see Figure 6). Doing this for certain subfolders can help ensure that the data and settings for certain applications are always in sync with one another.

Figure 6: Policy setting for syncing specified redirected folders only at logon/logoff using Offline Files.

Approach #3: Use FR to redirect AppData\Roaming but don’t use RUP

Finally, what if users only need access to Word custom dictionaries and templates when they roam between computers, and not to other customization settings for Word? Since Word custom dictionaries and templates are stored in AppData\Roaming, could you simply use FR to redirect this folder to the network and not use RUP?

Nope. Don’t redirect AppData\Roaming using FR unless you are also using RUP. Otherwise you’re going to end up at the least with applications behaving strangely and possibly even crashing, and at worst lost data and lost productivity.

Conclusion: The Importance of Testing

The bottom line about virtualizing application state is that you must test your solution before deploying it in your production environment. In addition to the reasons mentioned above, this is also important for two additional reasons. First, most vendors who develop applications probably never bother to test their applications in different roaming environments to see if they actually roam properly. Even Microsoft has fallen down in this area at times. For example, when Office 2007 was released it was soon discovered that the configuration of the Quick Access Toolbar didn’t roam. Microsoft soon issued a hotfix for this issue, but this illustrates how easy it is for application vendors (even Microsoft) to fail to verify that all of an application’s per-user data and settings can roam properly.

And second, vendors may decide for reasons unknown to deliberately store certain user-configurable application settings outside of HKCU or to store certain user-configurable application files outside of the AppData\Roaming folder. For example, they might decide to store all application settings in HKLM instead of storing the user-configurable ones in HKCU. As a result, such applications may not behave properly in roaming user environments.

So test, test, test before you try and implement a USV solution that includes roaming application state!

If you would like to read other articles in this series please go to:

• Windows User State Virtualization – Part 1: Introduction and Issues
• Windows User State Virtualization – Part 2: Scenarios
• Windows User State Virtualization – Part 4: Mixed Environments
• Windows User State Virtualization – Part 5: Implementing USV
• Windows User State Virtualization – Part 6: USV Frequently Asked Questions