Jared Payne provides the step-by-step details on how to implement user-specific variables to protect data on multi-user machines.

In pre-release versions of SVS, only one set of user variables existed for an SVS-enabled computer. Now, each user gets their own set of user variables. User variables are associated with the currently logged on user and include things like DESKTOP, STARTMENU and USERPROFILE. Allowing each user to have their own set of user variables lets multiple non-concurrent users log onto a machine without being able to see the other user's virtualized user-specific data.

Adding user-specific variables changed the way SVSAdmin looks; there are some new areas when modifying layers. In the file system area in the layer editor, each sub layer now has 2 sections: System and User-specific.

Figure 1: SVSAdmin

Click to view.

Let me explain how the User-specific area works. First, expand the User-specific folder in the read-only sub layer, then expand the USER_TEMPLATE folder.

Figure 2: User Specific, expanded USER_TEMPLATE

Click to view.

The only time SVS puts data under these variables is when the layer is in capture mode. Now, expand the User-specific area of the writeable sub layer.

Figure 3: User-specific area of the writeable sub layer, expanded.

Click to view.

Notice that there are several sections under the User-specific area of the writeable sub layer. SVS stores the user variables for each user under that user's SID. When a new user logs onto the machine, SVS copies USER_TEMPLATE into the writeable sub layers' user-specific area for the new user.

SVS copies the USER_TEMPLATE when these events occur:

1. At the end of capture mode
2. When a new user logs on for the first time and there is no profile for the user
3. When a layer is activated and there is no profile for the currently logged on user
4. When a layer is reset, the currently logged on user's profile is recreated in the writeable sub layer from USER_TEMPLATE

Giving each user their own user variables keeps a clean separation between users. If we look at the registry section using the layer editor we have a similar setup there.

Figure 4: Registry Section using the Layer Editor

Click to view.

The rules for copying the registry to the user-specific area of the writeable sub layer work just like the file system.

This approach makes it so that each user gets their user area populated with the correct data. After you modify anything in HKEY_USERS or USER_TEMPLATE, reset the layer before testing the layer. The user-specific data will not get copied if the user profile already exists.