Exploring Symantec Workspace Profiles

The introduction of Roaming Profiles on Windows opened up a whole new world of usability for the mobile user. No longer are user settings and documents bound to a single end-point (i.e. workstation machine). A user can roam from workstation to workstation and as long as they authenticate as a Windows Domain user, their application settings and documents will roam with them. As great as this new feature is, it comes with some deficiencies that make it less than optimal for use in enterprise environments. Profile corruption, very long logon and logout times have plagued roaming profile users from the beginning. The good news is that Symantec now provides a solution to these roaming profile deficiencies called Symantec Workspace Profiles (SWP). With SWP, gone are the long logon times, long logout times and profile corruption issues. This article will describe how SWP overcomes the deficiencies of roaming profiles and conclude with a description of how easy it is to install and configure.

What's the Problem?

The problem with the roaming profiles feature as it stands "out of the box" from Microsoft stems from the way it is implemented. Before we jump into the root of the problem, let's take a small tangent to describe how roaming profiles work.

The concept is really simple. There is a "Common Profile Store" (I'll call it "CPS" for short) that resides on a server. When users login to an client workstation there is a "profile synchronization" process that runs as part of the logon process that copies the user profile to the local profile area on the user's machine. All changes made to the user profile throughout the duration of the logged in session are made to the local profile. When the user logs out, the local profile is copied back to the CPS as part of the logout process. With all this talk about "local profile" business you might be wondering where it is stored. The file system portion of the local profile is stored in "C:\Documents and Settings\<user name>". The registry changes are stored under the "HKEY_CURRENT_USER" area of the registry. Technically, this is just a file named "ntuser.dat" which is stored in the file system area of the local profile and just "mounted" as the "HKEY_CURRENT_USER" area of the registry. Okay, enough on how roaming profiles work, time to talk about some of the problems introduced by the windows implementation of roaming profiles.

The most prevalent problems with the Windows implementation of roaming profiles are: Long logon times, long logoff times and profile corruption. Let's talk about each these.

Long logon time: Over time, the user profile stored in the CPS for a user grows quite large as s/he copies files to the desktop and other locations in the profile area. As we've learned, when logging on to an end-point machine, the contents of this CPS are copied to the local profile. The user must wait until the entire repository is copied to the local profile area before the logon process completes. So, all those MP3 and movie files that coworker Bob copies to his desktop must be copied down to his local profile before he can get to work and be productive. Another factor that slows down logon time is that many users may be logging in at the same time (e.g. when arriving in the morning) and all the profile data for all users must be copied to each of their respective local profiles. The server that hosts the CPS can become sluggish as it is bombarded with many simultaneous requests to copy centrally stored profiles from the server to connecting client machines.

Long logoff time: The cause of long logoff times is now much more obvious. All of Bob's music, movie and data files that have accumulated over several days must be copied to the CPS once he finally logs off to go home for the weekend. Yes, some people logoff every night before they go home, but others may stay logged in for several days. The important thing to understand is that the local profile is not copied to the CPS until the user logs off! The duration of the logoff time is directly proportional to the size of the local profile that must be copied to the CPS before the client machine will shutdown. If the client machine is shared and a user must wait for the previous logoff to complete this can be a frustrating wait. So frustrating in fact that this can contribute to the next big problem: corrupted profiles.

Corrupted Profile: No one likes to wait while their machine shuts down. If you are like me, you want to wait and confirm that the machine shuts down properly. If that wait time extends much beyond a couple minutes I start to get antsy. If it takes too long some may choose to speed up the process by simply powering off the machine manually. While this does get you on your way quicker, it may also corrupt your profile on the CPS if the copy was interrupted part way through the profile synchronization process. This can be particularly frustrating when a user logs on later and discovers that precious data has been lost. While this might serve as an opportunity to test whether corporate backups can restore properly, it can also be a frustrating loss of time and productivity.

Symantec Workspace Virtual Profiles to the Rescue!

One of the primary goals of the Symantec End-Point Virtualization team is to make the user experience at the end-point seamless and tailored to the needs of the user. In the case of user profiles, this means a user should be able to have their profile roam with them from machine to machine without the hassle associated with the traditional roaming profile experience. A user should be able to login to any suitable end point in the enterprise and have their profile appear nearly instantaneously. The logoff experience should be very quick and it goes without saying that they should never need to worry about losing their data due to profile corruption. Sound too good to be true? Not now! Let's dive into how SWP makes this seamless end-point experience a reality.

How Does it Work?

The question you may be asking is "So how does SWP solve the traditional problems associated with roaming profiles?" Let's revisit each problem described above with a description of how SWP provides a solution.

Long Logon Time: SWP performs its magic by delaying the copying of desired profile data from the CPS to the connecting client's local profile until the moment it is needed. All the files and icons appear on the desktop and elsewhere in the local profile but the contents of the files still reside at the CPS until a user clicks or double-clicks the shortcut. At that moment SWP copies the data to the client machine's local profile. This "just in time" copying of data allows the client desktop's logon process to execute very quickly and the long delay of copying all profile data is replaced with brief, usually unnoticeable, delay associated with copying only the desired data at the moment it is required.

Long Logoff Time: SWP provides an elegant solution to this problem as well. Instead of waiting until the logoff process to copy the entire local profile to the CPS, SWP monitors changes to the local profile and only copies the incremental changes, in real time, to the CPS. This ensures that when the logoff process takes place, all the profile data is already safely tucked into the CPS so no additional time is required to logoff. All profile-copying duties have already been completed!

Corrupted Profile: The answer to the "corrupted profile" issue relates to the solution described for handling long logoff times. Because the profile data is copied real time to the CPS, the possibility of corrupting or losing profile data is eliminated. This also ensures that if a user remains logged in for days at a time, all the local profile changes will be reflected in the CPS as they happen.

Installation and Configuration

Now that we know how SWP solves the problems of Window's roaming profiles, it's time to take a peek at how quick and easy it is to install and configure. The really good news is that if you already know how to configure Windows roaming profiles you already know most of what is required to get SWP up and running. If you have configured your environment to establish the roaming profile automatically via the use of Group Policy Objects (GPOs) then all that remains is to simply invoke the SWP install on the client workstations. It is not the intent of this article to describe how to install and configure Window's roaming profiles. A Google search on the terms "configure roaming profiles" will yield almost 2 million hits so I'll defer to the many references on the web. I'll walk you through the installation of SWP and point out the important details of configuration.

Step one is to invoke the installation program for SWP on the client machines where roaming profiles will be utilized. You'll need to install this with Administrative privileges. The installation's file name is something like "Symantec_Workspace_Profiles_v6.1.1.x86.msi". The install is very straightforward (aren't these the best kind?). Once the installation dialog appears simply click "Next", then "Next", then "Finish". That's it! There is no configuration data to supply during the install.

Step two is to configure SWP to point to the file share where the CPS is stored. Remember, if you're using the Group Policy to set the profile path on the machine then there is nothing more you need to do. The profile path is read from the registry automatically, eliminating the need for additional configuration. Once SWP is installed, and the machine has rebooted, you'll see the SWP icon added to the Windows system tray.

Right click this icon and select "Settings". This will invoke the "Symantec Workspace Profiles" dialog box:

The only required configuration is under the "Profiles" section. Click the "Add" button, then browse to the profile storage area on the server (we've been calling this the CPS). That's it! Now that the profile location (CPS) has been configured, each time a user logs on to the Windows domain, SWP will handle the duties of synchronizing the user's profile.

Summary

Symantec Workspace Profiles resolves the deficiencies of Windows roaming profiles such as long logon times, long logoff times and corrupted profiles by making necessary profile data available immediately upon logon. Long logoff times and profile corruption issues are resolved by providing real-time synchronization of local profile changes to the CPS on the server. SWP brings productivity, stability and data integrity benefits to Windows roaming profiles that make true mobile computing at the end-point a reality.

Are you interested in giving Symantec Workspace Profiles a test drive? Use the following steps to sign-up for the beta program:

1. Register at http://beta.altiris.com
2. Apply for access to the closed beta by sending an email to: erik [UNDERSCORE] hughes [AT] symantec [DOT] com

Erik Hughes, product manager for SWP, will respond with information on how to participate in the beta program.

Please give SWP a try and let us know what you think!