This is a good article by Jeremy Hurren explaining how Symantec's Workspace Virtualization handles changes made to the layer format.

With the recent release of Symantec Workspace Virtualization (SWV) 6.1, you may have noticed some small changes in the layer format. But how does SWV handle these changes, particularly when dealing with older layers? After reading this post, you'll never have to wonder again.

When SWV creates a layer, it stores descriptive information about the layer in the registry. In the current releases, this information in stored beneath "HKEY_LOCAL_MACHINE\SYSTEM\Altiris\FSL". Each layer is listed here under a layer-specific number, the same one that you will see in SVSAdmin if you use the Details view. Within this layer key, there are two DWORD values, named "MajorVersion" and "MinorVersion", that represent the format of the layer. If you create a new layer with SWV 6.1, you will see that is it versioned 2.3, while if you import an old layer (but don't activate it), it is versioned 2.2.

SWV uses this information in two ways. First, when you try to activate a layer that is of a newer format than that recognized by the software (e.g., using a layer created with SWV 6.1 on a machine where SWV 2.1 is installed), SWV will refuse to activate the layer. SWV is backward compatible with layers, but cannot be forward compatible. Second, when you activate an older layer (e.g., a layer created with SWV 2.1 on a machine with SWV 6.1), the software will automatically attempt to update the layer to the currently recognized version. If this layer upgrade fails for some reason, the layer will be left at the original version number, which means the upgrade will be attempted again the next time the layer is activated. If the layer cannot be upgraded, and thus cannot be activated, the activation will return an error code FSL2_ERROR_WRONGVERSION (1042). Once the layer upgrade succeeds, the version number is updated, and the layer doesn't need to be upgraded again.

So now let us look at the most recent changes to layer format in SWV 6.1. One of the major features of 6.1 is the ability to support multiple concurrent users. This required changes in the way file system paths are variablized in SWV. Some paths, such as "C:\Documents and Settings\Administrator\Desktop" could previously be variablized simply as [DESKTOP], but now require a user identity along with the variable. This information is largely transparent to the end-user and the layer format, but when paths are stored in the registry it becomes necessary to store user identity along with the path. So in the past you might have noticed a registry value in a layer that looks like "[_B_]DESKTOP[_E_]". Now that same path will look like "[_B_]DESKTOP:S-1-5-12345-123456789-500[_E_]". Notice that the users SID has been added to the variable. This enables SWV to determine which user's Desktop path is stored in the registry value.

The layer upgrade from layer format 2.2 to layer format 2.3 walks through the registry and finds variablized paths that have no user SID, and adds the user SID. It also moves well-known system environment variables that reference SWV user variables to the user-specific section of the registry. (Look under the user SID for an Environment key on a new layer created with SWV 6.1 to see what this is referring to.)

This layer upgrade functionality is not new to SWV. It was introduced with the first version of SWV (which was called Altiris Software Virtualization Solution at the time), and there have been a few layer format changes over the years that this functionality had to deal with. It certainly won't be the last time we have to make changes to the layer format.

Post a comment on the original article at its source.