Windows User State Virtualization – Mixed Environments

Designing a User State Virtualization strategy for a mixed environment poses a number of different challenges. By mixed environment I’m referring to a client computing infrastructure that has:

• Different versions of Microsoft Windows such as Windows 7, Windows Vista and Windows XP on different computers
• Different architecture versions of the same version of Windows such as Windows 7 x86 and Windows 7 x64 on different computers
• Different versions of applications such as Office 2010, Office 2007 and Office 2003 on different computers
• Different architecture versions of the same application such as Office 2010 x86 and Office 2010 x64 on different computers

This article examines the issues that can arise when planning USV solutions for mixed environments and describes some best practices for designing and implementing such solutions.

Planning USV for Mixed Windows Versions

As described in the first article of this series, Windows Vista introduced a new “v.2” user profile that has a flattened folder structure that separates user data and settings better than the Windows XP user profile did. As a result of this change, older Windows XP user profiles are not compatible with the newer v.2 profiles of Windows Vista. This means that you can’t use Roaming User Profiles (RUP) as a solution for roaming between computers running Windows Vista and Windows XP. If you try to implement RUP in a mixed XP/Vista environment, users who roam between the two OS versions will end up with two separate profiles on the RUP server, one profile for XP computers and the other for Vista computers.

No changes were made to user profiles in Windows 7 and the user profile structure in Windows 7 is identical to that in Windows Vista. This means you can use RUP to enable users to roam between computers running Windows 7 and Windows Vista provided there are no other architecture or application-specific issues as described in the sections below. It also means that you can’t use RUP to roam between Windows 7 and Windows XP computers.

If users do need to roam between computers running Windows XP and computers running later versions of Windows, you can use Folder Redirection (FR) with Offline Files (OF) enabled to redirect Documents and other folders where users store work-related data. This allows user data to be accessible from computers running any version of Windows. You cannot roam user settings however, since user settings resides in both the AppDataRoaming folder and in the Ntuser.dat file (the HKCU registry hive) in the root of the user’s profile. Since RUP cannot be used in this scenario, and since AppDataRoaming should never be redirected unless you also use RUP, this means only user data can be roamed in this scenario, not user settings. Table 1 summarizes a USV strategy for mixed environments running different versions of Windows on different computers.

OS versions	RUP	FR with OF
XP and Win7	No	Yes (data folders only)
XP and Vista	No	Yes (data folders only)
Vista and Win7	Yes	Yes

Table 1: USV strategy for mixed environment having different Windows versions on different computers

If you plan on implementing FR in a mixed XP and Win7 (or mixed XP and Vista) environment and you need to redirect the Pictures, Music or Videos folder, you will need to select the Follow The Documents Folder option on the Target tab of the redirection policy for these folders (see Figure 1). Doing this will cause these folders to be redirected as subfolders of the Documents folders (as in XP) instead of as peers of the Documents folder (as in Vista and later) and causes these folders to inherit their redirection settings from the Documents folder instead of having this configured on the folders themselves. Don’t do this however unless you have users who still need to access their redirected data folders from computers running Windows XP since choosing this option alters the structure of the user’s profile. If users only need to access redirected data from computers running Windows Vista or later then don’t select Follow The Documents Folder when redirecting the Pictures, Music or Videos folders. And in any case, you shouldn’t redirect these particular folders at all unless there is a business need for these folders to be redirected (such as centrally backing up internally developed training videos or in-house developed graphics).

Figure 1: Configuring redirection on Pictures to follow Documents

Alternatively, instead of selecting Follow The Documents Folder individually for the Pictures, Music and Videos folders, you can simply select Also Apply Redirection Policy To Windows 2000, Windows 2000 Server, Windows XP and Windows Server 2003 Operating Systems on the Settings tab as shown in Figure 2 as this has the effect of automatically configuring the Pictures, Music and Videos folders to Follow The Documents Folder.

Figure 2: Enabling this setting causes Pictures, Music and Videos to follow Documents.

Planning USV for Mixed Windows Architectures

Beginning with Windows Vista two hardware architectures have been available for Windows platforms: x86 (32-bit) and x64 (64-bit). An x64 version of Windows XP was also released but was never widely deployed, largely due to lack of device driver support, so we won’t be considering Windows XP x64 in this discussion.

While the underlying user profile folder structure of Windows 7 x86 (or Windows Vista x86) and Windows 7 x64 (or Windows Vista x64) are identical, there are differences in how the Windows registry is structured on x86 and x64 versions of Windows. Specifically, the registry on x64 Windows also contains the x86 registry structure, but the reverse isn’t true—the registry on x86 Windows does not contain any x64 registry structure. Another issue is that the location of some programs are stored in the registry using static paths such as C:Program Files or C:Program Files (x86), and this means when you try roaming between 32-bit and 64-bit machines these registry items will typically cause problems. The result of these differences is that you can’t use RUP to roam users between computers running Windows 7 x86 (or Windows Vista x86) and computers running Windows 7 x64 (or Windows Vista x64).

However, if users do need to roam between computers running x86 and x64 versions of Windows, you can use FR with OF to redirect Documents and other data folders to allow work-related data to be accessible to users from computers running both x86 and x64 versions of Windows. You cannot roam user settings however since user settings in HKCU on a computer running an x64 version of Windows are not compatible with user settings in HKCU on a computer running an x86 version of Windows. Table 2 summarizes a USV strategy for mixed environments running x86 versions of Windows one some computers and x64 versions of Windows on others.

OS architectures	RUP	FR with OF
Win7 x86 and Win7 x64	No	Yes (data folders only)
Vista x86 and Vista x64	No	Yes (data folders only)

Table 2: USV strategy for mixed environment having both x86 and x64 versions of Windows on different computers

Planning USV for Mixed Application Versions/Architectures

Issues involving applications in roaming environment are similar to those involving Windows versions. For example, say you have Windows Vista on some computers and Windows 7 on others. You also have version N of an application installed on the Vista machines, but have the newer version N+1 of the same app installed on the Windows 7 machines. If you implement RUP and/or FR/OF in such an environment, can you expect users to experience any problems when they work with this application?

Probably. It’s likely that the new version of the app has more features than the old one, and new features will undoubtedly mean new per-user registry settings and possibly new user settings stored as files under the AppDataRoaming folder. What happens when registry settings or AppDataRoaming files used by the new version of the app are loaded by the old version of the app? Who knows! The only way you can be sure if this scenario will work is to test, test and test before you deploy your USV solution in your production environment. Otherwise, users may find that certain apps they use crash or hang unexpectedly, or behave in strange and unpredictable ways. Such a scenario could even cause users lose data or cause data to be corrupted. It’s best to play it safe and make sure that, regardless of which version of Windows is running on each computer, the same version of each app is installed. Be kind to your helpdesk personnel and don’t let them be inundated with complaints from angry users.

This is even more true with different architecture versions (x86 or x64) of applications. For example, say you have the x64 version of a particular application installed on Windows 7 x64 computers and the x86 version of the same application installed on Windows Vista x64 computers. The OS architectures are both x64 which supports a RUP scenario, but it’s likely that the x86 and x64 versions of the application store their settings in different parts of HKCU and maybe even different folders and files in the AppDataRoaming folder. This means the same kind of frustrating, unpredictable behavior may occur if users try to work on the same data file from one computer running the x86 version of the app and then later on a second computer running the x64 version of the app. Even worse, the data file being worked on might become corrupted. I’m not saying this will happen for sure, and the only way to know for sure is to test, test and test again. But it’s better to play it safe and simply standardize all your computers on either the x86 or x64 version of the app. This may not be a big issue today since 64-bit apps like the 64-bit version of Office 2010 are just now appearing, but in the future it’s likely to be a concern as more and more software vendors start releasing 64-bit versions of apps that had until now only been available in 32-bit form. Table 3 summarizes a USV strategy for mixed environments running different versions/architectures of applications on different computers.

App versions/architectures	RUP	FR with OF
Multiple different versions of the same app	Play it safe—don’t use RUP	Yes (data folders only)
Both x86 and x64 versions of the same app	Play it safe—don’t use RUP	Yes (data folders only)

Table 3: USV strategy for mixed environment having different application versions/architectures on different computers

If there is a clear business need to provide users with multiple versions of applications or even different architecture versions of applications, you should consider implementing one of the following application virtualization solutions from Microsoft (choose the one that meets your need in terms of functionality and manageability):

• Microsoft Application Virtualization which is part of MDOP
• Microsoft Enterprise Desktop Virtualization (MED-V) which is also part of MDOP.
• RemoteApp delivered using Remote Desktop Services
• Windows XP Mode using Windows Virtual PC on Windows 7
• For more information on Microsoft virtualization technologies like these, download my free ebook Understanding Understanding Microsoft Virtualization Solutions: From the Desktop to the Datacenter, Second Edition.

Conclusion

The bottom line in mixed environments (different versions/architectures of Windows/applications) is to keep things simple and play it safe. Your USV strategy should be to virtualize only user data folders like Documents (and possibly also Desktop, Pictures, etc.) and you should use FR together with OF to make user data available to users from any computer they log on to. Do not try to virtualize user settings using RUP or by redirecting the AppDataRoaming folder. If possible, try and standardize on a single version/architecture of each of your applications.

How to create Windows 7 Virtual Hard Disk as a backup device

Everyone can create a VHD from the Disk Management Console

As you know, using external hard disks as backup devices has become very popular recently due to the fact that they are now relatively inexpensive to purchase or build. I use several of them for backups on my home and test systems.

The other day I was experimenting with Windows XP Mode on my Microsoft Windows 7 test system and was backing up my Windows XP Mode virtual machine and the accompanying virtual hard disk (VHD), when it occurred to me that I could use a VHD as a backup device.

Once I began experimenting with this technique, I knew that it would be perfect complement to my overall backup strategy. I don’t trust a single backup device and like to have multiple backups just in case. Using VHDs, I can easily back up my data and then just copy the VHD file to another external device.

In this edition of the Windows Desktop Report, I’ll show you how to create and use a VHD as a backup device.

Getting started
Because the technology is built right into the Windows 7 operating system, you don’t have to install Windows Virtual PC to create a VHD – you can do it right from the Disk Management Console or even from the command line with the Diskpart command. Let’s take a look at the procedure using the Disk Management Console. (I’ll go over the Diskpart command procedure at a later time.)

To get started, click the Start button and type Diskmgmt.msc in the Start Search box and then press [Enter]. When the Disk Management Console appears, as shown, you’re ready to create your VHD.

You’ll then need to specify a location, name, and size for your VHD

Creating a VHD
Pull down the Action menu and select the Create a VHD command. When you do, you’ll see the Create and Attach Virtual Hard Disk dialog box. You’ll then need to specify a location and name by clicking the Browse button. You then will specify a size. The Size drop down will allow you to select the size of the VHD in MB, GB, and, TB. As you can see in Figure B, I set up a 40GB VHD called My VH Disk in the Documents folder.

You’ll see a progress gauge at the bottom of the Disk Management Console window

You can specify the format be either Dynamically expanding or Fixed size. The latter is the default and is the option I chose for my VHD. A fixed size VHD will create a file that is the same size as the virtual disk. For example, if you create fixed VHD that is 40GB in size, the system will create a host file approximately 40GB in size.

A dynamically expanding VHD will create a file that at any given time is as large as the actual data written to it plus the size of the header and footer. For example, if you create a virtual hard disk that is 40GB in size, the system will create a host file approximately 80MB in size. As more data is written, the file dynamically increases in size by allocating more disk space from the host hard disk.

For the purposes of creating a virtual Back up device, either format is fine.

When you click OK, the Disk Management Console will begin creating the VHD. Depending on the size that you selected, it may take a little while to create the VHD. You’ll see a progress gauge at the bottom of the Disk Management Console window, as shown.

When you select the command you’ll see the Initialize Disk dialog box

Once the VHD is created, right click on its header panel on the left side and select the Initialize Disk command and you’ll see the Initialize Disk dialog box, as shown. You’ll see that your new disk is already selected and since the GPT partition style is designed for 2TB disks or Itanium-based computers, just go with the default MBR partition style and click OK.

When you select the command and you’ll see the New Simple Volume Wizard

As you may know, MBR is the standard partitioning style that’s been used on hard disks since the PC first came out. (Just FYI: MBR supports a maximum partition size of 2TB. GPT supports a maximum partition size of 256TB.)

Initializing the disk is a very quick operation. Once it is complete right click on right side and select the New Simple Volume command and you’ll see the New Simple Volume Wizard, as shown.

When you complete the wizard, an AutoPlay dialog box will appear and prompt you to open the new drive

There are five steps in this wizard and you can just accept all the default settings and click through to the end. When you do, the disk will be formatted as an NTFS volume and an AutoPlay dialog box will appear and prompt you to open the new drive, as shown.

You can locate and copy your VHD file to multiple locations.

Implementing the VHD backup strategy
To back up your data to the VHD, you can simply copy the files and folders from your hard disk to the VHD or you can use Windows 7’s Backup and Restore to actually create its backup file on the VHD. You can then locate the actual VHD file, as shown, and copy it to an external hard disk or to a network drive.

You can locate and copy your VHD file to multiple locations.

If you want to have multiple copies of your backup, you can copy the VHD file to multiple locations.

Configuring Virtual Networks With Hyper-V

If you’ve ever worked with Microsoft’s Virtual PC or Virtual Server, then you know that those products work in the same way as any other Windows application. They sit on top of the host operating system, and all of the virtual machine’s hardware calls are passed through the host operating system, which manages the server’s hardware usage. Hyper-V takes a completely different approach to virtualization though, and this means that network communications are implemented in a much different way than they were in Microsoft’s other virtualization products. In this article, I will show you how networking works in Hyper-V.

The Virtual Switch

What really sets Hyper-V apart from Microsoft’s other virtualization products is that virtual machines perform much better because they can communicate with the server’s hardware directly rather than having to pass hardware requests through the host operating system (although there are some exceptions to this). Of course you can’t just bombard a network adapter with simultaneous traffic from multiple virtual machines. There has to be a way of managing the traffic. To get around this problem, Microsoft has introduced the concept of the virtual switch.

To understand how this is possible, you have to realize that Hyper-V is not a Windows Server 2008 add-on, but rather is a part of the operating system. When you install the Hyper-V role, the hyper visor is placed “underneath” the Windows 2008 operating system. The existing operating system (known as the host operating system) is placed into something called the parent partition, and each guest operating system is placed into a separate child partition.

To make this type of architecture possible, Microsoft had to unbind the host operating system’s TCP/IP stack from the server’s NIC. In doing so, they have created an additional layer of abstraction known as the virtual switch. The virtual switch is the only networking component that is bound to the physical network adapter. The parent partition and the child partitions use virtual network adapters (known as vNICs), which communicate with the virtual switch using Microsoft’s Virtual Network Switch Protocol.

I realize that this description may be difficult to follow, so I have created the diagram shown in Figure A as a way of helping you to understand the architecture.

Figure A This is what the virtual switch architecture looks like.

Additional Virtual Switches

Hyper-V allows you to create additional virtual switches beyond the one that I just talked about. To do so, open the Hyper-V Manager and then click on the Virtual Network Manager link. Upon doing so, Windows will display the Virtual Network Manager screen, shown in Figure B.

Figure B The Virtual Network Manager allows you to create additional virtual switches.

If you look at the figure above, you can see that the default virtual switch is bound to my physical network adapter. You also have the option of creating a new virtual network, which is the same as creating a new virtual switch. As you can see in the figure, there are three different types of virtual networks that you can create.

Your first option is to create an external virtual network. Doing so creates a virtual switch through which virtual machines can access your entire network, and even the Internet assuming that you have the necessary infrastructure in place.

One thing that you do need to know about external virtual networks is that they must be bound to a physical network adapter. Additionally, each physical network adapter can only be used for a single virtual network. Therefore, if you are creating a secondary external virtual network then you’re going to need a secondary NIC that you can bind the new external virtual network to.

Your next option is to create an internal virtual switch. An internal virtual switch is not capable of accessing the yarn that, or even your private network as a whole. It serves primarily as a mechanism for allowing communications between the virtual machines that are hosted on the server. Additionally, an internal virtual network can facilitate communications between the host operating system and the guest operating systems that are running on it.

Your third option is to create a private virtual network. A private virtual network can only be used to facilitate communications between the virtual machines that are hosted on the current server. Private virtual networks can not access the outside world, nor can they access the host operating system.

Conclusion

In this article, I have explained that under normal circumstances the virtual machines that require access your network typically share a single NIC. I then went on to show you how Windows manages the communications for all of your virtual machines, and how you can create an external virtual network that takes advantage of additional NICs installed in your server.