XenClient Enterprise 4.5

1. XenClient Enterprise 4.5 Snapback and OS Profiles

2. Table of Contents

3. Snapback, User and Local Disks, and OS Profiles Snapback 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 Disks In 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 Profiles The 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.

4. System Disk Layering 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. runtime.vhd nxprep.vhd • Runtime 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. system.vhd Engine publish.vhd VM VHD Repository System Disk

5. Read/Write and Read-Only Layers runtime.vhd nxprep.vhd • Runtime Layer: Read/Write • The 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-Only • The 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. system.vhd Engine publish.vhd VM VHD Repository write read read read read System Disk

6. System, 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. • Does not snap back. • Not backed up to Synchronizer.

7. Data Preserved to User and Local Disks • User Disk • Data 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 Disk • Data 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).

8. Snapback Cycle for Deployed VMs Ready VM is shutdown and ready to be started. Starting VM start triggered by user action, auto-start settings, or policy. Saving Your Changes Preserve files and registry settings from system disk to local and user disks. Snapback Runtime layer discarded, new empty runtime layer created. System disk reverts to post-NxPrep state. Stopping VM shutdown triggered by user action or policy. Loading Your Changes Restore preserved files and registry settings back to the system disk. Folder relocation is handled here too. Running Changes to the system disk and registry accumulate in the runtime layer.

9. Snapback Benefits Image Consistency Snapback restores the VM system disk to a state that is consistent with the VM image in Synchronizer. Incremental Patching Snapback is a key feature that enables incremental patching of VMs from Synchronizer. Locked-Down Desktop Even 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 Protection Many types of viruses and malware can be uninstalled or at least rendered inoperable by simply restarting the VM.

10. Snapback and Virus Protection • Before Snapback • User accidentally downloads virus • Virus installed in runtime layer • Other layers are unaffected • After Snapback • Runtime layer deleted and reset • System disk restored • Virus is effectively deleted runtime.vhd nxprep.vhd nxprep.vhd Engine Engine system.vhd system.vhd publish.vhd publish.vhd VM VHD Repository VM VHD Repository runtime.vhd System Disk System Disk

11. Snapback Consequences and Side Effects • Users Must Store Data in Standard Locations • Users 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 Devices • Devices 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 Licensing • Must use volume licenses. • KMS: Supported and recommended. • MAK: Supported, but each deployed VM must be reactivated (once only). • OS Profile Policy Definitions • Most 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.

12. Disabling Snapback • Snapback 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.

13. Snapback 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 Disabled Snapback 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 VMs Custom 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.

14. Registry State Files • Registry State File on User Disk • U:\NxTop\RegistryState • Stores registry data that should be preserved and backed up to Synchronizer • Registry State File on Local Disk • L:\NxTop\RegistryState • Stores registry data that should be preserved but not backed up to Synchronizer • Offline Processing of Registry Data • Engine copies data from registry to registry state file in the “Saving Changes” phase • Engine copies data from registry state file to registry in the “Loading Changes” phase • Registry state files are not used while the VM is running • Do not modify the registry state files!

15. Windows Registry Pseudo-Layering • Windows Registry Files • Located on the system disk • Therefore subject to snapback • Block-level updates captured in snapback layer • Pseudo-Layering • No special handlers for Registry I/O • Side effect of system disk layering • Reading From Registry • Read from runtime layer first • If not in runtime layer, read from NxPrep layer • If not in NxPrep layer, read from base layer • If not in base layer, then the data does not exist • Writing To Registry • All writes captured in runtime layer • NxPrep and Base layers are read-only • Registry Snapback • Runtime layer reset when the VM snaps back • Therefore the Registry snaps back too • No special “registry snapback” process System Disk Base/Publish Layers NxPrep Layer Runtime Layer write read read read Windows OS or Application

16. Offline Preservation and Restoration of Registry Data • Saving Changes Phase • After VM is shutdown, before snapback • Engine copies registry data: • From the registry data files on the system disk • Into the registry state files on the user and local disks • This is how registry data is preserved before snapback System Disk • Loading Changes Phase • After snapback, before VM is started • Engine copies registry data: • From the registry state files on the user and local disks • Into the registry data files on the system disk • This is how registry data is restored after snapback System Disk Local Disk User Disk Local Disk User Disk Registry State File Registry State File Registry State File Registry State File

17. How Registry Data Is Backed Up to Synchronizer • User Disk Registry State File • There 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 File • There 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 Mechanism • Registry data gets backed up as a side effect of having a registry state file on the user disk. • Restoring Registry Data from Backup • Restoring 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.

18. OS Profiles 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. C: L: U: User Disk: Not subject to snapback. Stores data that should be preserved across snapback, and should also get backed up to Synchronizer. OS Profile Local Disk: Not subject to snapback. Stores data that should be preserved across snapback, but not required to get backed up to Synchronizer.

19. OS 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.

20. Sample 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-0994-46ac-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>

21. OS Profile Policies, Snapback, and Backups • OS Profile Policies and Snapback • OS 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 Backups • Policy 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 Policy • OS Profile Policy: Defines what gets backed up, but not when or how often. • Backup Policy: Enables or disables backups, defines backup frequency and retention.

22. Folder Relocation To 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. Before Relocation The ProgramData folder is on the system disk. Files are accessed directly from this folder. C:\ProgramData After Relocation The 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. U:\ProgramData C:\ProgramData

23. User 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. System Disk C:\Users\efermi U:\Users\efermi User Disk efermi

24. Evidence of Folder Relocation: Windows Explorer Before Folder Relocation After Folder Relocation On 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.

25. Evidence 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.

26. New 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.

27. Where 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.

28. Default 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.

29. Importing 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.

30. Importing 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.

31. Importing an OS Profile Definition (Part 3) When the import is complete, the new definition should appear in the Definitions folder.

32. Adding 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.

33. When 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.

34. Testing 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.

35. OS 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.

36. OS Profile Policy Overrides (for a Computer) • For VMs deployed to unownedcomputers, 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.