XenClient Enterprise 4.5 Snapback and OS Profiles.

XenClient Enterprise 4.5Snapback and OS Profiles


Copyright © 2013 Citrix

Table of Contents

Snapback, User and Local Disks, and OS Profiles Page 3

System Disk Layering Page 4

Read/Write and Read-Only Layers Page 5

System, User, and Local Disks Page 6

Data Preserved to User and Local Disks Page 7

Snapback Cycle for Deployed VMs Page 8

Snapback Benefits Page 9

Snapback and Virus Protection Page 10

Snapback Consequences and Side Effects Page 11

Disabling Snapback Page 12

Snapback Options Page 13

Registry State Files Page 14

Windows Registry Pseudo-Layering Page 15

Offline Preservation and Restoration of Registry Data Page 16

How Registry Data Is Backed Up to Synchronizer Page 17

OS Profiles Page 18

OS Profile Definitions Page 19

Sample OS Profile Definition Page 20

OS Profile Policies, Snapback, and Backups Page 21

Folder Relocation Page 22

User File Access After Profile Folder Relocation Page 23

Evidence of Folder Relocation: Windows Explorer Page 24

Evidence of Folder Relocation: Directory Listing Page 25

New User Profile Detection Warning Page 26

OS Profiles in Synchronizer Console Page 27

Default and User-Defined OS Profile Policies Page 28

Importing an OS Profile Definition Page 29

Adding a Definition to an OS Profile Pge 32

When Do OS Profile Policy Changes Take Effect? Page 33

Testing OS Profile Policies Page 34

OS Profile Policy Overrides (for a User) Page 35

OS Profile Policy Overrides (for a Computer) Page 36



Snapback, User and Local Disks, and OS Profiles

SnapbackSnapback 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.



System Disk Layering

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.

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 Repository

runtime.vhd

nxprep.vhd

system.vhd

publish.vhd

VM

SystemDisk

Engine



Read/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 RepositoryVM

Engine

read

write

read

read

read

SystemDisk

runtime.vhd

nxprep.vhd

system.vhd

publish.vhd



System, User, and Local 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.

All VMs deployed from Synchronizer to Engine will have three disks.



Data 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).



Snapback Cycle for Deployed VMs

Loading Your ChangesRestore preserved files and registry

settings back to the system disk.Folder relocation is handled here too.

SnapbackRuntime layer discarded, new empty runtime layer created. System disk

reverts to post-NxPrep state.

StartingVM start triggered by user action,

auto-start settings, or policy.

Saving Your ChangesPreserve files and registry settings from

system disk to local and user disks.

StoppingVM shutdown triggered by

user action or policy.

ReadyVM is shutdown andready to be started.

RunningChanges to the system disk and registry

accumulate in the runtime layer.



Snapback Benefits

Image 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.



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

VHD Repository

runtime.vhd

VM

SystemDisk

Engine

system.vhd

publish.vhd

nxprep.vhd

VHD RepositoryVM

SystemDisk

Engine

publish.vhd

nxprep.vhd

runtime.vhd

system.vhd



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.



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.



Snapback Options

Shared VM With Snapback EnabledThis 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.



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!



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

write

read

read

read

System Disk

NxPrep Layer

Base/Publish Layers

Runtime Layer

Windows OS or

Application



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

Local Disk

RegistryStateFile

User Disk

RegistryStateFileSystem 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

Local Disk

RegistryStateFile

User Disk

RegistryStateFile

System Disk



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.



OS Profiles

C: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



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.



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>



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.



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.

C:\ProgramData

Before 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:\ProgramData U:\ProgramData



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.

efermi

U:\Users\efermi

C:\Users\efermi

System Disk

User Disk



Evidence of Folder Relocation: Windows Explorer

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.

Before Folder Relocation After Folder Relocation



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.



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.



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.



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:

1.Creating a new empty policy.2.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.



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.




• 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.




When the import is complete, the new definition should appear in the Definitions folder.



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.



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.



Testing OS Profile Policies

New OS profile definitions should be tested before they are deployed to production users. One possible way to do this:

1.Identify a user to test the new OS Profile policy definition.

2.Locate the OS Profile policy assigned to the user’s VM.

3.Clone the policy into a new policy for testing purposes.

4.Assign the new OS profile definition to the cloned policy.

5.Assign the cloned OS profile policy to the user’s VM (see next page).

6.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.

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



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.

1.Locate the user in the Synchronizer.2.Select the user desktop (the VM image assigned to the user).3.Select the Policies tab.4.In the “Policies From” dropdown, select “Custom User Policies”.5.In the “OS Profile” dropdown, select the desired OS Profile policy.6.Save the changes.



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

1.Locate the unowned computer in the Synchronizer console.2.Select the computer desktop (VM image assigned to the computer).3.Select the Policies tab.4.In the “Policies From” dropdown, select “Custom User Policies”.5.In the “OS Profile” dropdown, select the desired OS Profile policy.6.Save the changes.

XenClient Enterprise 4.5 Snapback and OS Profiles.

Documents

Transcript of XenClient Enterprise 4.5 Snapback and OS Profiles.