TrimTransfer, as well as revertible workspaces will not be available in version 2 of MED-V. With a host being Windows 7 and a Workspace being Windows XP, there is not much use for it. As you read more about the new features of MED-V v2, you will also learn that the concept of a MED-V Policy and Image Distribution server is gone as well.
With v1, you could have XP hosts with XP workspaces so de-duplication made much more sense. You could create multiple versions of images and create an image through a combination of the local images and the physical host.
You could control and restrict the image versions but in order to take advantage of TrimTransfer it required an extensive, often time-consuming initial index of the local machine before downloading the initial image. Once the option to select “Clients should use TrimTransfer when downloading images for this Workspace” is selected, the local hard disk indexing will have to commence prior to any image download for that workspace.
If the scenario is one where you have a MED-V client host running Windows XP and a workspace guest operating system that is also Windows XP, this index will optimize the image delta updates for revertible workspaces.
Once the indexing is finished, the image download will occur.
Once the image has downloaded the workspace starts. Now, fast-forward to the future and it is now time for the image to be updated. The MED-V administrator needs to update the master image from the original unencrypted VPC (VHD file.) The MED-V administrator re-runs the VM prep Tool and marks Image for Autologon again. The image is shut down and is re-packed under the same name to create the new version.
NOTE: image Lineage must be manually maintained and synced between the local image repository on the management client and the Image Distribution server(s)
Then the image is uploaded to the server. It is important to understand that when the image is uploaded, TrimTransfer does not occur.
After the user logs on, depending on how the policy is configured, an image suggestion will be made. If the image is selected, the MEDVSERVICE.EXE (service process on client) handles the copying of blocks from the local disk.
This is done by copying the image index down to the image directory.
The image is built using a temporary transfer folder that will then be copied into the permanent version folder in the local client repository.
Changes in MED-V Version 2:
The primary scenario where this works the most optimally is when you are running Windows XP workspaces inside of Windows XP hosts. These workspaces will be revertible and will likely be protected by the VPC NAT router. The changes brought forth in version 2 of MED-V will make the need for TrimTransfer obsolete. Here’s why:
1.) Workspaces will be packaged and pre-staged exclusively: There is a new package that includes the image along with a client-hosted policy. There will be no image distribution server or policy server in V2.
2.) The supported host operating system is Windows 7 and the supported guest operating system is Windows XP: MED-V v2 is an Application-to-OS compatibility solution for migrating from Windows XP to Windows 7. There is no need to du0plicate binaries from the host to the guest operating system.
3.) All MED-V workspaces are managed and persistent: There is no support for revertible workspaces with MED-V v2. TrimTransfer was never recommended for persistent workspaces in v1. In MED-V version 2, the workspaces will be domain-joined and are designed to be managed by an electronic software distribution mechanism such as Configuration Manager (SCCM) or Windows Server Update Services (WSUS.)
Steve Thomas | Senior Support Escalation Engineer
The App-V Team blog: http://blogs.technet.com/appv/ The WSUS Support Team blog: http://blogs.technet.com/sus/ The SCMDM Support Team blog: http://blogs.technet.com/mdm/ The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/ The SCVMM Team blog: http://blogs.technet.com/scvmm/ The MED-V Team blog: http://blogs.technet.com/medv/ The DPM Team blog: http://blogs.technet.com/dpm/ The OOB Support Team blog: http://blogs.technet.com/oob/ The Opalis Team blog: http://blogs.technet.com/opalis The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager The AVIcode Team blog: http: http://blogs.technet.com/b/avicode The System Center Essentials Team blog: http: http://blogs.technet.com/b/systemcenteressentials