Connecting Windows 7 to an iSCSI SAN

Configuring iSCSI in Windows 7 

To get started, you need to run the iSCSI Initiator that is installed by default in Windows 7. You can access it in a couple of different ways.

One option is to access it through the Windows 7 Control Panel. Once inside control panel, on the address bar navigation, click on All Control Panel Items, then Administrative Tools, as seen in Figure 1.

From there, you need to run the iSCSI Initiator (also in Figure 1).

Figure 1: Running the iSCSI Initiator from Windows 7 Control Panel / Administrative Tools

The alternative to running the iSCSI Initiator through that path is to execute it by name. All you need to run is iscsicpl.exe. As you see in Figure 2, you can do this by going to Start and in the blank, enter iscsicpl.exe.

Figure 2: Running the iSCSI Control panel from the command line

Either way, you will arrive at the same destination. The iSCSI Warning that you see is in Figure 3 and then our real destination, the iSCSI Initiator Properties that you will see in Figure 4.

Assuming this is the first time you have attempted to run iSCSI-related application, you should see the warning message in Figure 3. This is just saying that that iSCSI service has not been started and it is asking you if you want to start it. Click Yes.

Figure 3: Starting the iSCSI Initiator Service

Finally, we reach the iSCSI Initiator Properties that we want to configure, shown in Figure 4.

Figure 4: Connecting to an iSCSI server using the iSCSI Initator

Now, what you want to do is to connect the iSCSI initiator to the iSCSI target. In our case, that target is the OpenFiler virtual machine, running in our vSphere virtual infrastructure.

Enter the domain name or IP address for your iSCSI target / the iSCSI target. In our case, it is the circled wb-iscsi-san.

Next, in Figure 5, you will be asked which of the discovered targets you want to connect to. In our case, we connected to the WB-iSCSI-WINDOWS  target (which we create just for the Windows Serves).

Figure 5: Connecting to the iSCSI Target

Once you select it and click Connect, your iSCSI SAN volume will be added to Windows so you can click DONE.

You should see the connections that you requested in the iSCSI Initiator (as you see in Figure 6).

Figure 6: Successfully Connected to Window iSCSI SAN

Now, for reliability of the iSCSI volume, you should go into the Volumes and Devices tab and click Auto  Configure. This will make the new iSCSI volume more "resilient".

Figure 7: Connecting the iSCSI Device to the server

Then, OK, to close the iSCSI Initiator Properties.

Now, go into Computer Management and click on Disk Management.

Assuming this is the first time that any iSCSI Initiator (the Windows PC) you should see that a new disk has been found. You will be told that you must initialize the new disk before you can use it, as you see in Figure 8.

Figure 8

Click OK to initialize the newly found disk.

Now, notice the new disk in Storage Manager (shown as Disk 1 but it could be a different number on your system).

In Figure 9, below you can see that the disk is now Online but it is Unallocated.

Figure 9: New Unallocated Disk

Now what you need to do is to click on the unallocated disk and click New Simple Volume, as you can see in Figure 10, below.

Figure 10: Creating a new simple volume

This brings up the New Simple Volume Wizard, as you see in Figure 11.

Figure 11: Simple Volume Wizard

In the Simple Volume Wizard you define how much space will be allocated of that volume and the drive letter that the new volume will have.

In Figure 12, I maxed out the space of the volume with all that the volume offered, 204765 MB or about 200GB.

Figure 12: Specify Size of the new Simple Volume

Now, assign a drive letter, in Figure 13.

Figure 13: Assigning a Drive Letter

And format it with NTFS.

Figure 14: Formatting the new simple volume

At this point, you will see the finalization screen, asking you to confirm what you are about to do. If you have configured everything correctly, click Finish.

You will see that the disk is being formatted and then you should see a new Healthy (Primary Partition) that is formatted with the NTFS filesystem (as you see in Figure 15), below.

Figure 15: New Volume Created

Now that the new volume is created, let us go t o the new volume inside My Computer.

Figure 16: My Computer showing the new volume

With that, we are done!

We successfully connected Windows 7 to an iSCSI SAN. Specifically, we connected it to a free OpenFiler SAN! So, with all the benefits that a SAN provides, Windows 7 (and all the other Windows devices that can now connect to the SAN), you will be able to get a lot more done!

10 New Features of Windows 7 Networking

1. Libraries

One new networking feature of Windows 7 that aggregates data from multiple sources into a single folder view. This could also be called a virtual folder. Actually, it is an indexed view of multiple data sources.

Because of the new library functionality, many of the common user folders in Windows 7 have been renamed. In Windows Vista you had Documents, Downloads, Photos, Videos, and Music. In Windows 7, these folders have been renamed and now you have Personal Documents, Personal Downloads, Personal Photos, Personal Videos, and Personal Music.

Yes, in other words, all the folders in a user's home directory have been renamed with the word Personal in front of them. As I said, there is a reason for this and that reason is to allow us to use libraries and to distinguish between public and personal (private) documents.

Besides these personal document folders, each Windows 7 computer is going to have public folder such as Public Documents.

To reiterate, the purpose of Libraries is to join together these personal and public documents into a single documents directory (as well as any other libraries that you create).

Thus, the default Libraries in Windows 7 are:

• Documents: made up of Personal Documents and Public Documents
• Downloads: made up of Personal Downloads and Public Downloads
• Music: made up of Personal Music and Public Music
• Photos: made up of Personal Photos and Public Photos
• Videos: made up of Personal Videos and Public Videos

To me, the best thing about Windows 7 Libraries is that you can create your own libraries. How do you do it? Easy. In explorer view, just go to your Libraries, right-click, then click on New - Library.

Figure 1: Creating a Windows 7 Library

From here, your new Library will be included in the list of Libraries in the Navigation Pane of all Explorer views (assuming you checked the show in navigation pane).

Figure 2: Results of creating a Windows 7 Library

Once you create it, you need to decide what you want included in the library. To do this, right-click on the folder and click Properties. On the Library Tab, click Add, select a folder, then, click Include in Library. You can include as many folders in your library as you want.

Figure 3: Including Folders in a Windows 7 Library

Of course, the inclusion of folders in your library view is critical to make the library of any use.

2. Network and Sharing Revisions

In Windows Vista the Network and Sharing center was pretty, what I would call "busy". There were lots of options and things that could be done resulting in the use of it being fairly confusing.

In Windows 7 the Network and Sharing center has been simplified. Here is what it looks like:

Figure 4: Windows 7 Network and Sharing Center

The Network and Sharing options have been moved to the Choose homegroup and sharing options window (which we will look at in a minute) and the left navigation options have been moved to other menu windows. I also think that the view your active networks section now looks much nicer and easier to understand.

Personally, I wish that there were more technical networking details shown on the Network and Sharing window. However, I am a technical networking guy and that is likely why I feel that way. I can see where perhaps Microsoft would want to shield less experienced users from technical network details.

3. View Available Networks (VAN)

While the "View Available Networks" or VAN feature sounds like it could be complex and a whole new kind of virtual network, it isn't. However, it is pretty helpful. Essentially, the VAN feature allows you to view all available networks and connect to them, directly from the system tray. Here is what it looks like:

Figure 5: View Available Networks (VAN) - Graphic courtesy of Microsoft.com

With users being more mobile and connecting to various networks, this is a much needed feature.

4. Super Fast Wake up and Boot, Smart Network Power, and Wake on LAN for Wireless

Some of the new features of Windows 7 are there to speed up Windows 7 or save power. Here are 3 examples:

• Fast Wake Up & Fast Boot – enables your Windows 7 machine to wake up faster when it was put in hibernate or standby mode. The fast boot feature allows Windows 7 to boot up faster when it is powered on from a cold boot.
• Smart Network Power – turns off the power to your Ethernet jack when there is no cable connected
• Wake on LAN for Wireless - bring the well-known wired Ethernet feature to wireless networks. Think about it – an Admin can wake up thousands of sleeping computers, not even wired to the network, using wake on LAN for wireless.

5. BranchCache

BranchCache is a big win for branch office users and IT Admins. With BrachCache, when remote Windows 7 users access file or Intranet content on a Windows 2008 R2 server at the headquarters, that data is downloaded to the remote branch. The second time that the same Windows 7 PC, or a different Windows 7 PC, needs that data or Intranet content, access to it is much faster because it has already been cached.

BranchCache can operate in two modes – Hosted Cache or Distributed Mode. With Hosted Cache, a Windows 2008 R2 server at the branch office is the central caching server for that branch. With Distributed Mode, no Windows 2008 R2 server is needed and the cache data is stored on the distributed Windows 7 PCs at the branch.

Before you can raise your security red flag, you should know that BranchCache complies with all Windows security settings and always checks to ensure that it is delivering the latest version of the file to the Windows 7 PC that requested it.

6. Virtualization Enhancements

With the Windows 7 Virtualization Enhancements, when you run Windows 7 in a VDI (virtual desktop interface) mode, the end user will enjoy a higher quality experience. To help you visualize how this works, let us say that you have a Hyper-V server and you are running Windows 7 as a Guest virtual machine on the server. End users running thin client devices connect to the Windows 7 Guest VMs on that server. Previously, with Windows XP or Vista, there would have been limitations to the users' experience, as compared to a traditional desktop. With Windows 7 many of these limitations are removed. Here is what Windows 7 provides when used in a VDI mode:

• The Windows Aero Interface
• Viewing of videos in Windows Media Player 11
• Multiple monitors
• Microphone for VoIP uses
• "Easy Print", which allows you to use a printer on the local printer without installing a printer driver
• Common tools for IT Admins to manipulate virtual desktop images

Something else that is new about Windows 7 and VDI is the new Windows Vista Enterprise Centralized Desktop (VECD) license.

7. Fix a Network Problem

One of my favorite changes to Windows 7 networking is the update to Vista's diagnose and repair. In Windows 7 if you want to get assistance fixing a network issue, you just click Fix a network problem. Sound simple and clear, right? That's what I like about it.

From Windows 7 Network and Sharing, if you click Fix a Network Problem, you get this window, asking you want you want to fix:

Figure 6: Fixing a Network Problem

Windows 7 will go through and attempt to fix any network issues that you select. It will even ask you if you want to fix it as a Windows Administrator. Here is what fixing a homegroup looks like:

Figure 7: Fixing a network problem

8. QoS Enhancements

While Quality of Service (QoS) is not something that end users think about they do see the results if QoS is not working. Windows 7 offers a number of QoS enhancements.

URL based QoS is one of the new Windows 7 QoS Enhancments. Since many mission critical enterprise applications have been moved into hosted web environments, URL based QoS is the answer to giving those IT Admins the ability to prioritize those mission critical web applications over, say, other general web surfing.

Is it slick and exciting? Maybe not but it is a very valuable feature resulting in a better experience for the end users.

9. DirectAccess

I like how Microsoft characterizes the new Windows 7 feature, DirectAccess -

1. Help mobile users get more done
2. Help IT Admins manage remote machines more effectively

The combination of both of these things make DirectAccess worth learning more about (and likely implementing).

So what exactly is DirectAccess? Today, mobile users can connect to the enterprise network with VPN but it is not always easy and can be difficult to configure. DirectAccess wants to be the answer that allows end users to connect to the enterprise quickly and easily, without VPN.

For the IT Admins, DirectAccess will allow them to manage laptops even if the laptops are not connected to the VPN. The IT Admin can schedule software to the updated or configuration changes to be made, the next time that device connects using DirectAccess.

10. HomeGroup

Absolutely, the best new Windows 7 networking feature for home and small office users is the homeGroup feature. Essentially, a homegroup is a simple way to link computers on your home network together so that they can share pictures, music, videos, documents, and printers. There is just a single password that is used to access the homegroup, making creating it and connecting to it easy.

To configure a Windows 7 Homegroup, you can click on Choose Homegroup and Sharing Options from the Network and Sharing Center in Windows 7, then Create now (assuming your network location is set to Home).

Figure 8: Creating your HomeGroup

You will be asked what types of personal content you want to share with the HomeGroup.

Figure 9: Creating a Windows 7 Homegroup

You will be able to select what you want to share in the homegroup.

Figure 10: Viewing the Windows 7 Password to connect to the homegroup

And you will be given a single password, used on other computers, to connect to the homegroup.

When you are done, the Homegroup and Sharing center will look something like this:

Figure 11: Windows 7 Homegroup configured

Windows User State Virtualization - Part 5

Scenario 1: Implementing FR for Windows 7

As discussed in a previous article of this series, if you are going to use Folder Redirection (FR) alone—that is, without also implementing Roaming User Profiles (RUP)—then you should only redirect user data folders such as My Documents and Desktop, not the AppData\Roaming folder which contains user settings. If you are not using FR right now in your environment and your client computers are currently running Windows XP and you plan on migrating them soon to Windows 7, then it is probably best if you don't implement FR until you have Windows 7 deployed since this will ensure a better first logon experience for users as their data folders are initially redirected.

Once all your clients are running Windows 7, the high-level steps for implementing FR are as follows:

1. Decide which user data folders will need redirection based on business need.
2. Estimate the total amount of data that could be redirected using FR and ensure your redirection servers will have sufficient storage space.
3. Implement Failover Clustering for redirection servers to ensure high availability for redirected data.
4. Identify which USV scenario(s) are important for your environment. For example:

• If users have assigned computers and you are implementing FR mainly for centralized backup of user data, then Offline Files should be enabled on client computers so that redirected files are indexed locally on each user's computer. In that case be sure to identify any network issues for your environment as these can impact on the performance of the Offline Files feature. One way to deal with high network latency for example is to configure slow link mode using Group Policy so that the network link is always considered a slow link. That way the user always works from the local Offline Files cache, not the network. If you do this however, be sure to also configure Offline Files Group Policy to frequently synchronize with the server in the background.
• If users do not have assigned computers and instead use whichever computer is available (user roaming scenario) then consider disabling Offline Files on client computers and indexing the shared folders on the redirection server itself. Be sure to install Windows Desktop Search 4.0 on your redirection servers so that Windows 7 clients can perform remote queries against the indexed user data on the redirection servers. The advantage of this approach is that the user's data won't need to be re-indexed locally every time the user works on a computer they never previously logged on to.

5. Identify whether you have any mixed environment issues to consider. For example, if you have some computers running Windows 7 and others Windows Vista, you can basically just implement FR as if all your computers are running Windows 7. But if you also have some Windows XP computers in your environment then you will need to configure the Pictures, Music and Videos folders to follow the Documents folder. In other words, you will more or less be limited to implementing FR the way it was implemented in Windows XP—unless of course your Windows XP computer accounts are in a separate OU in which case you can implement separate FR policies for your Windows 7/Windows Vista computers and your Windows XP computers.
6. Once you've prepared your network and addressed various considerations, use Group Policy to create a new FR policy using the steps outlined in the section titled "Scenario 1: Manage roaming data using Folder Redirection" of the Managing Roaming User Data Deployment Guide.

Scenario 2: Migrating FR to Windows 7

If you are currently running Windows XP and have FR implemented in your environment, and you plan on migrating to Windows 7 and want to continue using FR in your environment, the steps you perform will depend largely on whether you are leaving your existing Windows Server 2003 infrastructure in place or upgrading your back-end to Windows Server 2008 R2. If you are leaving your existing server infrastructure in place, you may want to leave your existing FR policies in place as well.

If you are planning on upgrading your infrastructure to Windows Server 2008 R2 however, then you may want to take advantage of the enhanced FR policies available for this platform. One way of doing this might be to do the following:

1. Migrate your client machines to Windows 7 and your server infrastructure to Windows Server 2008 R2.
2. Migrate the folder structure and redirected user data from your old redirection server running Windows Server 2003 to your new redirection server running Windows Server 2008 R2 (see the File Services Migration Guide on TechNet for details).
3. Upgrade your FR policy so you can redirect Favorites, Downloads and other user profile folders that could previously not be redirected using Windows Server 2003 Group Policy.

The above steps are not meant to be prescriptive guidance however because a lot of things can affect the actual migration steps you will need to perform, so it's best if you enlist the help of your organization's Microsoft Technical Account Manager (TAM) to obtain further guidance on the exact procedure you'll need to follow in this scenario.  Larger organizations may also want to enlist the help of Microsoft Consulting Services (MCS) for designing a migration strategy for this scenario.

One thing you should not do in this scenario is the following:

1. Configure existing FR policy to redirect user data back to client machines.
2. Retire your old redirection server.
3. Migrate client machines to Windows 7 using User State Migration Tool (USMT) to migrate user data and settings.
4. Provision a new redirection server.
5. Configure a new FR policy to redirect user data to the new server.

The reason you should not follow this procedure is simply because the risk of data loss is too great—during the time period that the data resides on the client machines the data is not being backed up.

Scenario 3: Implementing FR with RUP for Windows 7

If are going to use Folder Redirection (FR) together Roaming User Profiles (RUP) then there are two ways you can roam user settings:

• You can decide to use FR to roam the AppData\Roaming folder while using RUP to roam the HKCU registry hive Ntuser.dat.
• You can decide to not use FR to roam the AppData\Roaming folder and instead use RUP to roam both the AppData\Roaming folder and the HKCU registry hive.

For a discussion of the advantages and disadvantages of each of these approaches, see article 3 in this series.

If you are not using FR/RUP right now in your environment and your client computers are currently running Windows XP and you plan on migrating them soon to Windows 7, then it is definitely best if you don't implement FR/RUP until you have Windows 7 deployed because of the incompatibility between older Windows XP user profiles and the newer .v2 user profiles of Windows Vista and later (see article 1 in this series for more info concerning this).

Once all your clients are running Windows 7, the additional high-level steps (on top of those described in Scenario 1 above) for implementing FR/RUP are as follows:

1. Estimate the total amount of roaming user profile data that could be roamed using RUP and ensure your roaming profile servers will have sufficient storage space. Here are some additional considerations for performing such estimation:

• If user profile folders such as Pictures, Music and Video are not business-critical and are not going to be redirected using FR, you should use Group Policy to exclude these folders from being roamed using RUP in order to reduce the size of roaming profiles and thus improve logon/logoff performance. The policy setting for configuring this is User Configuration\Policies\Administrative Templates\System\User Profiles\Exclude Directories In Roaming Profile.
• If you want to restrict the size of roaming profiles, don't try to do this by configuring the User Configuration\Administrative Templates\System\User Profiles\Limit Profile Size policy setting. Instead, add the File Services Resource Manager (FSRM) role service on your roaming profile servers and implement soft quotas with notifications to users via email when they exceed their quotas. 
• You should store roaming user profiles on a different server than redirected data folders. In other words, your RUP server and FR server should be different machines.
• Implement Failover Clustering for roaming profile servers to ensure high availability for roaming user profiles.

2. Identify whether you have any mixed environment issues to consider. For example, RUP cannot be used to roam 64-bit registry settings across both 32- and 64-bit Windows.
3. Create a default user profile and customize it according to the needs of your users, then copy the profile to the NETLOGON share on your domain controllers. Note that this step is different in Windows 7 than it was in Windows XP. Because of this, I'll be covering this subject in detail in an upcoming series of articles here on WindowsNetworking.com.
4. Prepare your roaming profile servers for storing roaming profiles for users. Configure user accounts in Active Directory to use roaming profiles. Now when a user logs on for the first time to her computer, the customized network default profile will be downloaded from NETLOGON to her computer. Then when she logs off from her computer, her profile will be uploaded to the roaming profile server where it will be downloaded from the next time she logs on to her computer. You can find detailed information concerning these steps in the section titled "Scenario 2: Manage roaming data using Roaming and Mandatory Profiles" of the Managing Roaming User Data Deployment Guide but make sure you do NOT follow the steps in the section titled "Create a Default Network User Profile" as this no longer works in Windows 7. Instead you can follow the steps outlined in my upcoming series of articles on this subject.

Scenario 4: Migrating FR with RUP to Windows 7

If you are currently running Windows XP and have both FR and RUP implemented in your environment, and you plan on migrating to Windows 7 and want to continue using both FR and RUP in your environment, your best bet is probably to start again from scratch. That's because Windows XP user profiles are not compatible with Windows 7, so once you've migrated your users won't be able to load their existing Windows XP roaming profiles on their Windows 7 machines. In other words, you could do the following:

1. Redirect all user data folders back to users' computers.
2. Create and customize a network default .v2 profile and copy it to NETLOGON.
3. Migrate from Windows XP to Windows 7.
4. Implement FR to redirect user data back to the network by following the steps outlined in Scenario 1 above.
5. Implement RUP by following the steps outlined in Scenario 3 above.

Again however, due to the complexity of this scenario it's really best if you enlist the help of your TAM or even involve MCS to help you perform the migration.

Windows User State Virtualization - Part 4

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 AppData\Roaming 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 AppData\Roaming 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 AppData\Roaming folder. What happens when registry settings or AppData\Roaming 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 AppData\Roaming 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.

Windows User State Virtualization - Part 3

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.

Subfolder	Purpose
Local	Windows and application settings that either (a) are per-user settings but should not be roamed or (b) are per-machine settings and therefore cannot be roamed.
LocalLow	Settings used by certain low-integrity processes such as Internet Explorer Protected Mode. These settings cannot be roamed.
Roaming	Windows and application per-user settings that are capable of being roamed.

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.

Windows Vista and later	Windows XP
%USERPROFILE%\AppData\Local	%USERPROFILE%\Local Settings\Application Data
%USERPROFILE%\AppData\LocalLow	(no counterpart in XP)
%USERPROFILE%\AppData\Roaming	%USERPROFILE%\Application Data

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.

Windows User State Virtualization - Part 2

Centralized Backup of User Data

Is the data that your users create and work with important to your business? If your answer is Yes, then USV can bring benefits to your organization. Business users typically work with many different kinds of data including Word documents, Excel spreadsheets, PowerPoint presentations, PDF files, image files, video files, and so on. These data files are usually saved in user profile folders such as My Documents, My Pictures, and so on. Sometimes users even save these files directly on their desktops so they can open them quickly when required. If a user is saving all his work files on his local machine and the machine's hard drive fails, all their work will be lost unless it's been backed up. The problem is that most businesses don't back up files stored on client computers. There are several reasons for this:

• Licensing costs for software that can back up hundreds or thousands of client computers can be prohibitively expensive.
• Backing up hundreds or thousands of client computers over the network can only be done once a day during off-hours because of the huge amount of data involved. It can even saturate the network and create a bottleneck that prevents other network services from functioning properly.
• If management tells users to save files to the network but they fail to do so, the users may get reprimanded. Your business on the other hand may fail and go bankrupt if critical business data is lost.

If you use Folder Redirection (FR) however to redirect each user's My Documents and Desktop folders to a file server on your network, you'll only need to back up that server and not each and every client machine. And because your servers are located in your datacenter (or server room) and are connected to your high-speed network backbone, you can back them up several times a day if needed without interruption to users working with the data. This is a much more reliable approach to safeguarding your business data than trying to educate users to always save files to mapped drives or network shares.

If image, music and video files can also be work-related types of files in your environment, you can also redirect the My Pictures, My Music and My Videos folders using FR. On the other hand, if your users tend to store their own personal music files on their machines (possibly in clear violation of company policy) then you may want to avoid redirecting My Music in order to save disk storage space on your file servers—and to be able to say "Told-ya!" when someone's computer crashes and all their music is lost.

Of course, regardless of what you tell them some users may decide to save important files outside their user profile, for example in the root of their C: drive, and this means such files won't be backed up. But the vast majority of files should be able to be backed up when FR is implemented together with centralized backup of file servers, and the stubborn users that present the few edge cases can be dealt with administratively by Human Resources.

In summary, here are some recommendations if centralizing backup of user data is important for your business:

• Always implement FR of the My Documents and My Desktop folders even if your users never roam between computers. In other words, even if each user is assigned their own computer and it's the only computer they ever use at work, you should still implement FR as it lets centralize user data on network file servers instead of on each user's computer. Then regularly back up the file server where these redirected folders reside.
  
  
• Be sure to also enable Offline Files (OF) so that users can still work on their documents if the file server or network goes down. OF will maintain a local cache of files in redirected folders on each user's computer so they can still do their job even if they can't get to the data stored on the servers. Note that OF is enabled by default in Windows Vista and later, so you don't have to do anything more to gain the benefits of OF once you've implemented FR.
  
  
• Don't redirect My Pictures, My Music or My Videos unless users have a specific business need for working with image, music or video files as part of their job.

As a side benefit, this kind of scenario also works well with mobile users who use laptops as it lets them work with business data while disconnected from the company network. Then when they connect in using a VPN connection, the changes they've made to files in redirected folders are synced up to the company file server using OF. So if you're organization has users who regularly travel and take their laptops off-site, the above recommendations for implementing FR and OF apply too. Finally, this scenario also helps users who regularly work from more than one computer, for example a user who has both a desktop PC and an employee-issued laptop, as it enables them to access their data files from either computer when they need them (and to use Sync Center to resolve any conflicts that might occur should they edit the same document from both computers).

Replaceable PCs

If the hard drive on a user's PC fails, all user data and settings stored on the PC is lost. Unless of course there is a recent system image backup of the user's PC, in which case they can replace the failed drive and restore their PC to the way it was before it crashed. Most businesses don't do system image backups of desktop PCs because of the huge amount of disk space that would be required for storing hundreds or thousands of multi-gigabyte backups. Instead, most businesses concentrate on making sure data stored on business-critical servers is backed up regularly. And if you're already implementing FR to centralize backup of user data as described above, user data shouldn't be lost when a user's PC fails.

But user settings can be important too, especially if the user has customized her applications to make herself more productive. So if her PC fails and you provide her with a new one with all the pre-installed applications the user needs to perform her work, she may still have to spend several hours or more customizing the applications on her computer, downloading templates, and performing various operating system personalizations such as redefining libraries, configuring taskbar properties, and so on. And some items such as custom dictionaries that were created over time may need to be built up again from scratch. Time spent doing these sorts of things is not only frustrating to the user but is also lost productivity for your business.

Fortunately, by implementing Roaming User Profiles (RUP) together with FR and OF you can store the entire user state—both user data and user settings—on your file servers. The net effect of doing this is to be able to provide your users with "replaceable PCs" which works like this:

1. Hard drive on user's PC fails.
2. User calls Helpdesk.
3. Technician arrives with a PC that has Windows and necessary line of business (LOB) applications pre-installed.
4. Technician removes failed PC and connects replacement PC.
5. User boots new PC, logs on, downloads their roaming profile and immediately has access to all of user data and user settings including personalizations, customizations, templates, toolbars, custom dictionaries, and so on.
6. Happy user immediately gets back to work; boss happy too—end of story

Of course, happy endings aren't all that common in the real world, and there are a couple of things that can go wrong with this scenario:

• Users who choose to store files outside their user profile will lose those files forever if their hard drive crashes. As indicated earlier, user education is the answer here.
• Applications that store per-user customization settings in the wrong place (outside either the HKCU registry hive or the AppData\Roaming profile folder) will lose such user settings forever if the hard drive fails in the user's PC. We'll talk more about this problem in the next article of this series.

If you absolutely must centralize all user settings and data to enable replaceable PCs, you might want to look at using Remote Desktop Services (formerly Terminal Services) to do this. You can either provide users with session-based desktops using RD Session Host servers (formerly terminal servers) or with personal virtual desktops running on RD Virtualization Host servers (Microsoft's Virtual Desktop Infrastructure solution). Either way, users will have fully replaceable "desktops" they can access from any PC on the network. But these approaches might be overkill for smaller organizations. On the other hand, implementing RUP brings its own headaches which you'll see in later articles of this series, so many businesses may want to be satisfied with "semi-replaceable PCs" where FR is used to centralize user data but user settings are not centralized. Then when the user's PC fails and you bring them a new one and they complain they've lost their custom dictionary and toolbar preferences, tell them not to complain and be happy they have a brand new PC instead of the old clunker they were using before.

Desktop Migration

Every once in a while a new version of Windows comes along and it's time to begin the migration dance. If your desktop computers are still running Windows XP then it's time to consider migrating to Windows 7 since Windows XP is nearing the end of its support lifetime. The thing to understand is that implementing a USV solution can simplify the desktop migration process. This is because in most cases migrating users from Windows XP to Windows 7 involves using the User State Migration Tool (USMT) which migrates user accounts, operating system and application settings from the old system to the new one. Small Office / Home Office (SOHO) businesses can use Windows Easy Transfer instead, but most mid- and large-sized businesses will want to use USMT because it's more powerful, customizable and scriptable.

By implementing FR to redirect My Documents and similar profile folders where users store their data, you can speed up the desktop migration process because user data won't need to be migrated, only user settings will. It will also reduce the risk of data loss occurring should something go wrong during the migration process because all business data is stored on central file servers, not on end-user computers. This desktop migration scenario is another compelling reason why you should implement FR in your environment if you haven't already done so.

Occasional Roaming

Some organizations set up shared "kiosk" PCs in semi-public places like the reception area or cafeteria so that employees can use these computers when they have need of doing so. You can think of this as an "occasional roaming" scenario because users generally work from their assigned PCs and only occasionally roam to these shared computers.

In this case, the best approach is to do the following:

• Use FR to redirect My Documents, Desktop and other folders where users store business data. This way users will be able to access their data from both their assigned PCs and from the shared kiosk computers located in public places.
• Disable OF on the shared kiosk computers so that the hard drives of these computers won't get filled up with locally cached copies of user data (and because it's not a good idea to cache sensitive business data on computers located in semi-public places). This is one of the few cases in which you will want to disable OF in your environment, and you can do so on a per-machine basis by using Group Policy.

If you also happen to be using RUP in your environment, you can also use Group Policy to delete cached copies of roaming profiles on the shared kiosk computers when users log off from these machines. That way the hard drives of these machines won't get filled up with user profiles (plus the added security benefit of not leaving user profiles on the machines). But most organizations don't use RUP and it's really not needed to support the kind of occasional roaming described in the above scenario.

Hot Desking

Call centers, helpdesks and similar environments often implement hot desking where employees don't have their own assigned computers. Instead, employees share a common pool of computers and use whichever one is available at the time to do their work. Remote Desktop Services (either session-based desktops or pooled virtual desktops) is really the best solution for such environments, but smaller organizations can use a custom USV strategy tailored to the needs of such environments as follows:

• Use FR to redirect My Documents, Desktop and other folders where users store business data.
• Disable OF so that the hard drives of the computers won't get filled up with locally cached copies of user data.
• Enable indexing on the file servers so that users will be able to search for files and file content within redirected folders. By default, when OF is enabled it lets you search for files and file content within the redirected folders by performing the query locally against the OF cache on the user's computer. But in hot desktop environments you don't want to have OF enabled for the same reasons as the Occasional Roaming scenario described previously. So you want to disable OF on computers used for hot desking, but you want users to be able to take advantage of the powerful search capabilities of Windows 7. The solution is to make sure your file servers are running Windows Server 2008 and enable the Windows Search (WSearch) service on these servers by adding the File Services role together with the Windows Search role service. Then make sure the shared folder used for FR is included in the indexed scope on the remote computer. Doing this will enable remote search whereby queries issued by users' computers will be performed against the indexes on the file servers. For more information on remote search, see Chapter 19 of the Windows 7 Resource Kit (Microsoft Press, 2010).

What about RUP? Well, you can use RUP if users need access to their personalized Windows desktop when they log onto a computer in the shared pool, but in this kind of scenario RUP just complicates things. That's because call center / helpdesk workers typically use only a small set of standard applications and it's probably better if you use Group Policy to lock down the desktop environment for these workers instead of providing them with roaming desktops they can personalize.

Windows User State Virtualization - Part 1

User state virtualization or USV refers to the process of virtualizing (decoupling) user state information from the user's computer and storing this information elsewhere, usually on a server in the datacenter. User state information is anything stored on the computer that pertains to the user, such as:

• User data such as documents, pictures, music files, video files, spreadsheets, PowerPoint presentations, and other types of files that belong to the user.
  
  
• User settings such as operating system settings (e.g. wallpapers, screensavers, keyboard layouts etc.) and application settings (e.g. toolbar selections, custom dictionaries, autosave settings, default page layout etc.) that can be customized on a per-user basis.

Figure 1: Windows user state information comprises user data and user settings

The goals of USV are essentially the same as those of any other type of virtualization: lower TCO, increased availability, improved business agility, and easier manageability.

Windows USV refers to a collection of features and technologies that can be used to implement a USV solution for client computers running some version of Microsoft Windows. The key features and technologies of Windows USV are these:

• User profiles which are file system structures (folders and files) that contain the user state information for each user on a Windows-based computer. Some folders and files in a user profile are normally hidden from view to keep users from messing with their contents.
  
  
• Folder Redirection which is a Windows technology that lets administrators redirect certain folders within user profiles to shared folders on the network so that when users save files they are working on these files are saved onto the network instead of on their own machines.
  
• Offline Files which is a Windows technology that lets users work with local copies of files stored in shared folders on the network even when the network itself is unavailable.
  
  
• Roaming User Profiles which is a technology that lets you store user profiles in shared folders on the network. When the user logs on to his computer, his profile is downloaded from the network and loaded to display his desktop. When the user logs off, his profile is uploaded back to the network.

Figure 2: Windows USV technologies

As a WindowsNetworking.com reader, you are probably already familiar to some degree with these different technologies, but let's review them really fast anyways. And while the focus of this series of articles will be on virtualizing user state information on Windows 7 computers, we'll also examine how USV technologies have changed from Windows XP to Windows Vista to Windows 7 since understanding these changes is important when implementing USV strategies in mixed environments.

User Profiles

There are a bunch of different types of user profiles you need to know about:

• Local profiles which are user profiles stored on the user's computer. Even when RUP is used to virtualize (decouple) a user's data and settings from the user's computer, there is still a locally stored copy of the user's profile on the user's computer.
  
  
• Roaming profiles which are user profiles stored on the network. Note that Roaming User Profiles (capitalized) or RUP refers to the procedures and technologies involved while roaming profiles (Iowercase) refers to the actual profiles themselves.
  
  
• Mandatory profiles which are roaming profiles that are ACL'd as read-only. Mandatory profiles are frequently used in Remote Desktop Services (a.k.a. Terminal Services) environments when you don't want your users to be able to make any changes to the configuration of their session-based desktops or RemoteApp programs.
  
  
• Temporary profiles which are used when the user's local profile can't be loaded and there is no roaming profile to download. A typical scenario where you might find yourself logged on with a temporary profile would be when your antivirus software locks files during the logon process thus preventing your local profile from loading. The result is that all your personal files suddenly seem to have vanished—My Documents is empty!! Fortunately, logging off and then on again usually causes your profile to load and your documents to be restored—whew!
  
  
• Default profile refers to a special user profile that is used as a template for creating a user's local profile the first time he logs on to his computer. By customizing the default profile prior to deploying Windows, you can ensure a customized, uniform experience for your users. For example, you could prepopulate desktops with shortcuts to network shares, ensure that a corporate wallpaper is being used, and so on. Group Policy can be used to do some of these things as well.

User profiles changed significantly from Windows XP to Windows Vista (or Windows 7) as you can see by comparing Figures 1 and 2 below. Some of the important changes include the following:

• Windows XP stores local profiles in the C:\Documents and Settings folder; Windows Vista and Windows 7 store them in the C:\Users folder.
  
  
• In Windows XP the root folder of your user profile can be accessed using Windows Explorer. In Windows Vista and Windows 7 however, you can access your root profile folder directly from the Start menu and this is not necessarily a good thing since it means you can create additional folders in your user profile and these folders can't be redirected (though they can be roamed).
  
  
• Windows Vista and Windows 7 profiles have more subfolders (and some different subfolders) than Windows XP profiles have.
  
  
• In Windows XP the folders My Pictures, My Music and My Videos were subfolders of My Documents; in Windows Vista and Windows 7 the user profile structure was flattened so that all of these folders are now peers.

The bottom line here is that the changes in the user profile structure starting with Windows Vista are so significant that these new profiles are called "v.2" profiles to distinguish them from the earlier Windows XP profile structure. This has significance, particular when trying to implement Roaming User Profiles in an environment (more about that in another article of this series).

We'll dig deeper into certain portions of user profiles later in this series, but meanwhile if you're interested in more detailed information concerning user profile changes in Windows Vista and Windows 7 you should read Chapter 15 of the Windows 7 Resource Kit (Microsoft Press, 2010). You can also find good information in the Managing Roaming User Data Deployment Guide (for Vista) here and What's New in Folder Redirection and User Profiles (for Windows 7) here.

Figure 3: User profile structure in Windows XP. Other profile folders may be present depending on Windows features enabled and applications installed

Figure 4: The new "v.2" user profile structure in Windows 7 (and Windows Vista). Other profile folders may be present depending on Windows features enabled and applications installed

Roaming User Profiles

Roaming User Profiles (RUP) was actually developed way back in the Windows NT 4.0 timeframe and was intended to allow users to change seats and access their personalized desktop from any Windows computer on the network. In other words, RUP provides the ability for users to roam between computers. RUP as it was initially implemented had some problems however:

• RUP roams the entire user profile including settings for applications that aren't specifically intended to be roamed (in other words, RUP has no granularity in what you can roam—it just roams everything in the profile). This isn't a problem however for applications that are "well-designed" that is for apps that store their settings in the proper places—we'll talk more about this later in this series.
  
  
• RUP syncs the local copy of the profile on the user's computer with the copy stored on the server only at logoff. This is still the default behavior in Windows 7 though you can now choose to sync periodically in the background if you desire—more on this as well in a later article.
  
  
• RUP doesn't work well in scenarios where users need to log on to multiple computers at the same time. The least that can happen might be data loss or settings that don't apply the way you expect them to; the worst can be profile corruption, which necessitates rebuilding the user's profile from scratch and losing all the data and settings that were previously present. And generally speaking in Active Directory environments there's no easy way to prevent users from logging on to multiple computers concurrently except by educating them not to do this.
  
  
• RUP doesn't work well if you have a mixed environment of Windows XP and Windows 7 (or Windows Vista) computers. RUP also doesn't work well if your environment has a mix of computers running x86 and x64 versions of Windows. We'll talk more about mixed environments later in this series.
  
  
• Because the profiles RUP creates (roaming user profiles) contain all of the user's data and settings, they can grow very large, especially if the user has lots of pictures, music and videos on their computer. The result is that RUP as it was originally designed could result in terribly long logon/logoff times for users as their profile was downloaded to or uploaded from their computer.

That last issue led Microsoft to introduce a second USV technology to complement RUP and that's what we'll look at next. But meanwhile if you're interested in learning more about RUP you can check out the chapter of the Windows 7 Resource Kit mentioned earlier in this article.

Folder Redirection

Folder Redirection (FR) was introduced in Windows 2000 as a way of mitigating the slow logon/logoff issue associated with large roaming profiles in NT. The idea is that FR lets you redirect certain profile folders such as My Documents out of the user's profile and store the contents of these folders on a separate network share than the one where the user's profile is stored. Then when the user's computer downloads (or uploads) the user's roaming profile from the network, the contents of My Documents and other redirected folders won't need to be downloaded, making logon (and logoff) times faster.

FR was also introduced for several other reasons:

• So that users could roam between computers and access their data from the network even when RUP has not been implemented in the organization's environment. FR in this case can be seen as a kind of "poor man's RUP" that roams only user data but not user settings, but we'll see below that you can also use FR to roam user settings (sort of).
  
  
• So that administrators could more easily back up user data by having such data stored on the network (in the redirected My Documents folders located on a file server) instead of on client computers (in each user's local My Documents folder).
  
  
• So that any application settings (specifically, files associated with applications and certain Windows features) stored in the Application Data subfolder could also be redirected and hence roamed. More on this in a moment.
  
  
• So that RUP could work more effectively in a Terminal Services environment. More on this too in a moment.

FR was updated a bit in Windows XP and Windows Server 2003 and let you redirect the following profile folders:

• My Documents - This is usually the biggest profile folder by far, so redirecting this folder is always a best practice whenever you implement RUP. And since My Pictures, My Music and My Videos are subfolders of My Documents, the contents of these folders also get redirected to the network. Finally, as mentioned above redirecting My Documents lets administrators back up your data more easily so you don't lose your work if your machine crashes.
  
  
• Desktop - Some (if not most) users tend to store important documents on their desktop so they can access them easily, and if you store a lot of files on your desktop then you may experience logon/logoff delays if RUP has been implemented in your environment. Redirecting the Desktop folder also ensures that anything you save to your desktop also gets backed up.
  
  
• Application Data - This profile folder stores configuration settings for Windows features and installed applications. In other words, by redirecting the Application Data folder you can roam user settings (in addition to roaming user data by redirecting My Documents and Desktop). The trouble is, redirecting the Application Data folder redirects all settings stored in this folder, even for applications that weren't designed to be roamed. In fact, it turns out that roaming per-user settings applications is a thorny problem, so we'll devote an entire article in this series to discussing it later.
  
  
• Start Menu - Redirection of this folder was intended mainly for Terminal Services environments where everyone is supposed to get the same Start Menu and be able to run a common set of applications. Because of this, redirection of Start Menu is a specialized topic that we'll look at later in this series.

Anyways, in Windows XP and Windows Server 2003 you can use Group Policy to implement FR as shown in Figure 5 below. Beginning with Windows Vista however, you now have the option of redirecting additional profile folders (up to 13 folders in total) and Figure 6 illustrates this new situation. There are a few other improvements to FR in Windows Vista and Windows 7 that we'll talk about later in this series.

Figure 5: Folder Redirection policy in Windows XP and Windows Server 2003

Figure 6: Folder Redirection policy in Windows Vista, Windows 7 and Windows Server 2008

Offline Files

When FR was introduced in Windows 2000 there was another feature introduced alongside it called Offline Files (OF) that was intended to complement FR. The reason is because if FR redirects user data (and possibly user settings) to a network server but the network (or the server) suddenly becomes unavailable, the user won't be able to access their data files (and some application customization files) resulting in confusion, frustration and lost productivity. Offline Files is designed to mitigate this problem by synchronizing folders and files on the user's machine with their copies on the network. OF thus goes hand-in-hand with FR and OF is almost always implemented when FR is implemented. We'll dig deeper into OF later on in this series, but for now you can think of OF as a given whenever FR is being used.

Issues to Consider

What then are the major issues you need to consider when designing and planning a USV strategy for your organization? Here is a list of some key issues we'll be looking at in this series of articles:

• What business scenarios can benefit from USV?
• What issues can arise when trying to virtualize application state?
• What considerations are there for mixed environments, for example when some of your users have Windows 7 running on their computers while others still have Windows XP?
• What do you need to be aware of when planning migration of a Windows XP environment that has FR/OF/RUP to Windows 7?
• Are there any security considerations for implementing FR/OF/RUP?
• Are there any other limitations you should be aware of concerning what one can do with FR/OF/RUP?
• And finally, how should you actually go about implementing a USV solution? What steps do you need to take in what order?