2Table of Contents Snapback, User and Local Disks, and OS Profiles Page 3System Disk LayeringPage 4Read/Write and Read-Only LayersPage 5System, User, and Local DisksPage 6Data Preserved to User and Local DisksPage 7Snapback Cycle for Deployed VMsPage 8Snapback BenefitsPage 9Snapback and Virus ProtectionPage 10Snapback Consequences and Side EffectsPage 11Disabling SnapbackPage 12Snapback OptionsPage 13Registry State FilesPage 14Windows Registry Pseudo-LayeringPage 15Offline Preservation and Restoration of Registry DataPage 16How Registry Data Is Backed Up to SynchronizerPage 17OS ProfilesPage 18OS Profile DefinitionsPage 19Sample OS Profile DefinitionPage 20OS Profile Policies, Snapback, and BackupsPage 21Folder RelocationPage 22User File Access After Profile Folder RelocationPage 23Evidence of Folder Relocation: Windows ExplorerPage 24Evidence of Folder Relocation: Directory ListingPage 25New User Profile Detection WarningPage 26OS Profiles in Synchronizer ConsolePage 27Default and User-Defined OS Profile PoliciesPage 28Importing an OS Profile DefinitionPage 29Adding a Definition to an OS ProfilePge 32When Do OS Profile Policy Changes Take Effect?Page 33Testing OS Profile PoliciesPage 34OS Profile Policy Overrides (for a User)Page 35OS Profile Policy Overrides (for a Computer)Page 36
3Snapback, User and Local Disks, and OS Profiles Snapback is a feature that restores the system disk for a deployed Virtual Machine (VM) to a state that is consistent with the corresponding VM image in Synchronizer. Every time the VM restarts, the Engine deletes (or “snap back”) all changes that were made to the system disk since the VM was installed on the computer.User and Local DisksIn addition to the system disk, a deployed VM also has a user disk and a local disk, most commonly mapped to the U: and L: drive letters respectively. These disks are not subject to snapback and can be used to store data that should persist across the snapback process.OS ProfilesThe OS Profile defines what data from the system disk should be preserved across the snapback process. Data preservation is done by moving or copying files, folders, or registry data from the system disk to the user and local disks.
4System Disk Layering VHD Repository VM Engine The system disk in the VM is backed by a chain of VHD files in the Engine VHD repository. Some VHD files are downloaded from Synchronizer, others are created locally. These VHD files define layers of data, but the VM only sees a single virtual disk and is unaware of the layering.VHD Repositoryruntime.vhdnxprep.vhdsystem.vhdpublish.vhdVMSystemDiskEngineRuntime Layer (Created on Engine)Captures all writes to the system disk while the VM is running.Gets reset when the VM restarts.This is how the VM “snaps back”.NxPrep Layer (Created on Engine)Contains the results of VM image installation on Engine.Sets the system disk baseline state for snapback.Publish Layer (Downloaded from Synchronizer)Contains the results of VM image publish in Synchronizer.Base System Layer (Downloaded from Synchronizer)Usually multiple VHD files.One VHD file per VM image version in Synchronizer.Identical to disk image booted by Hyper-V in Synchronizer.
5Read/Write and Read-Only Layers Runtime Layer: Read/WriteThe runtime layer is the only layer that the VM can write to. This layer stores the results of all write operations, including:Creation of new files.Modification of existing files.Deletion of files.Other Layers: Read-OnlyThe VM is unable to write to any layer other than the runtime layer. Since the layering is implemented in the Engine, not in the VM, the VM does not have direct access to these layers.VHD RepositoryVMEnginereadwriteSystemDiskruntime.vhdnxprep.vhdsystem.vhdpublish.vhd
6System, User, and Local Disks All VMs deployed from Synchronizer to Engine will have three disks.System Disk (C:)Downloaded from Synchronizer.Modified on the Engine when the VM is installed.Snaps back on every VM restart.User Disk (U:)Created locally on the Engine.Does not snap back.Backed up to Synchronizer.Local Disk (L:)Created locally on the engine.Not backed up to Synchronizer.
7Data Preserved to User and Local Disks User DiskData that should be preserved and backed up, including:Most parts of the user profile folders.Documents folders, desktop configuration.User-specific application settings and preferences.User-specific portions of the Registry (NTUSER.DAT, USRCLASS.DAT)Computer name, activation state, and domain membership.Other application and system data that is important to back up.Local DiskData that should be preserved but not backed up, such as:Data that is convenient to preserve but is not worth backing up.User and system temp folders.Browser caches.Downloads folder.Windows prefetch folder.Data that is can be recreated from a server if necessary.Antivirus definitions.Outlook OST files.Data that is backed up using a different mechanism (not to Synchronizer).
8Snapback Cycle for Deployed VMs ReadyVM is shutdown andready to be started.StartingVM start triggered by user action,auto-start settings, or policy.Saving Your ChangesPreserve files and registry settings fromsystem disk to local and user disks.SnapbackRuntime layer discarded, new empty runtime layer created. System diskreverts to post-NxPrep state.StoppingVM shutdown triggered byuser action or policy.Loading Your ChangesRestore preserved files and registry settings back to the system disk.Folder relocation is handled here too.RunningChanges to the system disk and registry accumulate in the runtime layer.
9Snapback BenefitsImage ConsistencySnapback restores the VM system disk to a state that is consistent with the VM image in Synchronizer.Incremental PatchingSnapback is a key feature that enables incremental patching of VMs from Synchronizer.Locked-Down DesktopEven with local Administrator rights, users have very limited ability to install applications in a VM. Most applications will simply be deleted after snapback.Virus and Malware ProtectionMany types of viruses and malware can be uninstalled or at least rendered inoperable by simply restarting the VM.
10Snapback and Virus Protection Before SnapbackUser accidentally downloads virusVirus installed in runtime layerOther layers are unaffectedAfter SnapbackRuntime layer deleted and resetSystem disk restoredVirus is effectively deletedVHD Repositoryruntime.vhdVMSystemDiskEnginesystem.vhdpublish.vhdnxprep.vhdVHD RepositoryVMSystemDiskEnginepublish.vhdnxprep.vhdruntime.vhdsystem.vhd
11Snapback Consequences and Side Effects Users Must Store Data in Standard LocationsUsers must store data in locations that are preserved by the OS Profile.Otherwise the data will be deleted by snapback when the VM is restarted.This can be a training issue for some users.Printers and Other DevicesDevices that require drivers not included in the VM image can be problematic.Driver and device installation generally cannot be preserved by OS profiles.Windows and Office LicensingMust use volume licenses.KMS: Supported and recommended.MAK: Supported, but each deployed VM must be reactivated (once only).OS Profile Policy DefinitionsMost deployments will need one or more custom OS profile policy definitions.Snapback will interfere with many applications (antivirus software in particular).Requires knowledge about where the application stores data.
12Disabling SnapbackSnapback can be disabled in the OS Profile policy. This is only a temporary setting. The VM will always snap back to install an update. This is sometimes referred to as “snap-forward”. To disable snapback in the OS Profile policy:Select the OS Profile policy in the navigation panel.Select the Summary tab and check the Disable Snapback checkbox.
13Snapback Options Shared VM With Snapback Enabled This is the normal model for shared VM images. Snapback should always be enabled unless there is a specific reason to disable snapback. The system disk for the VM image will snap back every time the VM restarts, although snapback might not occur if the VM does not shut down or restart as expected.Shared VM With Snapback DisabledSnapback can be disabled temporarily for shared VM images. With snapback disabled, the system disk will not snap back when the VM restarts. However, if a new VM image version is deployed to the computer, the system disk must snap back in order to install the update. This is sometimes called “snap forward” since snapback is only performed when moving forward to a new version of the VM image. Snapback is usually only disabled for troubleshooting purposes, but it can be useful to support a user with an immediate need to install software in the VM and have it persist across VM restarts. In this case, disabling snapback can provide temporary relief until the VM image can be updated with the desired software and a new version published and deployed.Custom or Personal VMsCustom and personal VMs do not participate in the snapback process. Any changes made to the VM system disk will persist when the VM restarts. Since snapback is a critical part of the VM update process, custom VMs cannot be updated the same way that shared VM images can. If a new version of a custom VM is published in Synchronizer, the new version cannot be deployed to computers already running a previous version of the custom VM image. Once a user gets a custom VM, the user is responsible for updating it, since it cannot be updated through the Synchronizer.
14Do not modify the registry state files! Registry State File on User DiskU:\NxTop\RegistryStateStores registry data that should be preserved and backed up to SynchronizerRegistry State File on Local DiskL:\NxTop\RegistryStateStores registry data that should be preserved but not backed up to SynchronizerOffline Processing of Registry DataEngine copies data from registry to registry state file in the “Saving Changes” phaseEngine copies data from registry state file to registry in the “Loading Changes” phaseRegistry state files are not used while the VM is runningDo not modify the registry state files!
15Windows Registry Pseudo-Layering Windows Registry FilesLocated on the system diskTherefore subject to snapbackBlock-level updates captured in snapback layerPseudo-LayeringNo special handlers for Registry I/OSide effect of system disk layeringReading From RegistryRead from runtime layer firstIf not in runtime layer, read from NxPrep layerIf not in NxPrep layer, read from base layerIf not in base layer, then the data does not existWriting To RegistryAll writes captured in runtime layerNxPrep and Base layers are read-onlyRegistry SnapbackRuntime layer reset when the VM snaps backTherefore the Registry snaps back tooNo special “registry snapback” processwritereadSystem DiskNxPrep LayerBase/Publish LayersRuntime LayerWindows OS or Application
16Offline Preservation and Restoration of Registry Data Local DiskRegistryStateFileUser DiskSystem DiskSaving Changes PhaseAfter VM is shutdown, before snapbackEngine copies registry data:From the registry data files on the system diskInto the registry state files on the user and local disksThis is how registry data is preserved before snapbackLocal DiskRegistryStateFileUser DiskSystem DiskLoading Changes PhaseAfter snapback, before VM is startedEngine copies registry data:From the registry state files on the user and local disksInto the registry data files on the system diskThis is how registry data is restored after snapback
17How Registry Data Is Backed Up to Synchronizer User Disk Registry State FileThere is a registry state file on the user disk, managed by the Engine.The user disk is what gets backed up to Synchronizer.Therefore, backups include registry data preserved in the registry state file.Local Disk Registry State FileThere is a registry state file on the local disk, managed by the Engine.But the local disk is not backed up to Synchronizer.Therefore, this data does not get backed up.No Separate Registry Backup MechanismRegistry data gets backed up as a side effect of having a registry state file on the user disk.Restoring Registry Data from BackupRestoring a user backup from Synchronizer restores the user disk.The user disk backup on Synchronizer includes the registry state file.Therefore, restoring the user disk also restores registry data.
18OS ProfilesC:System Disk: This is the disk that is subject to snapback. Any data not preserved to the User or Local disk will be lost after snapback.L:Local Disk: Not subject to snapback. Stores data that should be preserved across snapback, but not required to get backed up to Synchronizer.U:User Disk: Not subject to snapback. Stores data that should be preserved across snapback, and should also get backed up to Synchronizer.OSProfile
19OS Profile Definitions Each OS Profile policy contains a set of definitions. Each definition contains rules for how data should be preserved for a specific application and whether preserved data should be backed up to Synchronizer.Select the OS Profile policy in the navigation panel.Select the Summary tab.Use the Assign checkboxes to add or remove definitions.
20Sample OS Profile Definition Custom OS Profile definitions are delivered as XML files. These files must be imported into Synchronizer before the new definition can be included in OS Profile policies. A sample XML file for an OS Profile definition is shown below. The file name for this example is “cygwin.xml”.<?xml version="1.0" encoding="UTF-8"?><root><feature><id uuid="5ada388c ac-064e-55b62a28c0c4" version="3"/><name>Cygwin</name><author>Citrix XenClient Enterprise</author><description>Preserve Cygwin home and etc directories.</description><target os="xp,win7"><filesystem folder="\cygwin\home" backup="true" merge=“true” conflict=“client” /><filesystem folder="\cygwin\etc" backup="true" merge="true“ conflict="client" /></target></feature></root>
21OS Profile Policies, Snapback, and Backups OS Profile Policies and SnapbackOS Profile policy defines what data gets saved or relocated to the User and Local disks.System disk snaps back, user and local disks do not.Therefore, the OS Profile policy defines what data is preserved across snapback.OS Profile Policies and BackupsPolicy determines what data gets saved or relocated to the User disk (U: drive).The User disk is what gets backed up to the Synchronizer.Therefore, the OS Profile policy defines what is included in the backups.OS Profile Policy vs. Backup PolicyOS Profile Policy: Defines what gets backed up, but not when or how often.Backup Policy: Enables or disables backups, defines backup frequency and retention.
22Folder RelocationTo preserve folders, the OS Profile relocates the folder to the user or local disk. Some folders, in particular user profile folders, can grow very large. Relocation avoids the need to copy the folder back and forth between the system and user/local disks during every snapback cycle.C:\ProgramDataBefore RelocationThe ProgramData folder is on the system disk. Files are accessed directly from this folder.After RelocationThe ProgramData folder is on the user disk. A junction point links the old folder location to the new location. File access is redirected from the C: drive to the U: drive automatically by the filesystem.C:\ProgramDataU:\ProgramData
23User File Access After Profile Folder Relocation Files stored in the profile are accessed as if they were on the system disk, but they are really on the user disk.C:\Users\efermiSystem DiskefermiU:\Users\efermiUser Disk
24Evidence of Folder Relocation: Windows Explorer Before Folder RelocationAfter Folder RelocationOn first user login, the profile folder resides on the system disk. Note the absence of the shortcut symbol on the user folder icon.After the VM is restarted, the user profile is relocated to the user disk. There is still a profile folder entry on the system disk, but the shortcut symbol indicates it is a junction point.
25Evidence of Folder Relocation: Directory Listing Before folder relocation, the directory listing shows the user profile folder as a regular directory.After folder relocation, the directory listing shows the user profile as a symbolic link to the user disk.
26New User Profile Detection Warning This warning usually occurs when a user logs into a VM for the first time, and the user profile folder is initially created by Windows on the system disk. The VM must be restarted in order to relocate the folder to the user disk. The VM should be restarted to avoid these problems:If the user copies lots of data into the profile before restarting the VM, relocation might take much longer, since all the data must be copied from the system disk to the user disk.Only the user disk gets backed up, so until the profile is relocated to the user disk, data in the user profile will not get backed up to Synchronizer.The warning can be disabled but this should only be done if the VM is not being backed up to Synchronizer, and if the warning causes undue problems for users.
27Where to Find OS Profile Policies in the Synchronizer To manage OS Profile policies in Synchronizer:Open the Policies section.Open the Virtual Machine folder.Select (or open) the OS Profile folder.
28Default and User-Defined OS Profile Policies A default OS Profile policy is created when Synchronizer is installed. The default policy is applied by default to all VM images created in Synchronizer, and all VMs deployed to Engine.The default OS Profile policy can be overridden for a VM image or for a deployed VM.Methods available for creating new OS Profile policies:Creating a new empty policy.Cloning an existing policy.The default OS Profile should not be modified. It is often useful, for troubleshooting or other purposes, to reset the OS Profile policy for a VM back to “factory default”. This becomes much more difficult if the default OS Profile policy has been modified.
29Importing an OS Profile Definition (Part 1) Open the Policies section.Open the Virtual Machine folder.Open the OS Profile folder.Select the Definitions folder.Click the Import action button.
30Importing an OS Profile Definition (Part 2) In the Source input field, select “Your computer”.In the “Select a File…” input field, enter the full path to the definition XML file.Alternately, click the “Browse” button to open a filesystem browser to locate the definition XML file.Then click “Finish” to import the definition.
31Importing an OS Profile Definition (Part 3) When the import is complete, the new definition should appear in the Definitions folder.
32Adding a Definition to an OS Profile In order for the OS profile definition to take effect for a deployed VM, it must first be added to the OS profile assigned to the VM.Select the OS Profile Policy in the Synchronizer console.Check the “Assign” box to add the definition to the policy.Save changes.
33When Do OS Profile Policy Changes Take Effect? In order for an OS Profile policy to take effect for a deployed VM:The profile must be changed in the Synchronizer.The Engine hosting the VM must check for updates with the Synchronizer.The VM must be restarted.The VM must go through a clean shutdown and restart process before changes in the OS profile policy will be applied.
34Testing OS Profile Policies New OS profile definitions should be tested before they are deployed to production users. One possible way to do this:Identify a user to test the new OS Profile policy definition.Locate the OS Profile policy assigned to the user’s VM.Clone the policy into a new policy for testing purposes.Assign the new OS profile definition to the cloned policy.Assign the cloned OS profile policy to the user’s VM (see next page).The user should check for updates, restart the VM, and verify:The new definition is working as expected.There are no adverse side effects from the new definition.Once testing is successful:The new definition can be added to the OS Profile for production users.The test user’s VM can be reassigned the original OS Profile policy.The test OS Profile policy can be deleted.
35OS Profile Policy Overrides (for a User) The OS Profile policy assignment can be overridden for single user. This is useful for testing new OS Profile policies before deploying them to production users.Locate the user in the Synchronizer.Select the user desktop (the VM image assigned to the user).Select the Policies tab.In the “Policies From” dropdown, select “Custom User Policies”.In the “OS Profile” dropdown, select the desired OS Profile policy.Save the changes.
36OS Profile Policy Overrides (for a Computer) For VMs deployed to unowned computers, the OS Profile policy can be overridden for a specific computer if desired.Locate the unowned computer in the Synchronizer console.Select the computer desktop (VM image assigned to the computer).Select the Policies tab.In the “Policies From” dropdown, select “Custom User Policies”.In the “OS Profile” dropdown, select the desired OS Profile policy.Save the changes.