A Closer Look at the MED-V Image and Data Repositories
One request I have seen often from my customers lately has been a request for an in-depth discussion on how MED-V handles images and metadata. If you have been working with MED-V, by now you are probably familiar with the basics of how MED-V handles images. MED-V version 1.0 SP1 works with Virtual PC images to facilitate the underlying support for legacy applications on newer operating systems such as Windows Vista and Windows 7. These images are stored in repositories resident on MED-V clients. The default image repository is located in C:\Med-V Images. If you elect to use an Image Distribution Server, the default location for MED-V server images is in the C:\MED-V Server Images directory. Pretty straight forward, however, I would like to go a little deeper into this topic and discuss specifically how each type of image and metadata is used.
Types of Image Files in the Server Image Repository
The Image Repository will contain two files for each virtual machine that has been prepared for deployment with MED-V. These will be uploaded to the server from the MED-V management console by way of BITs to an IIS virtual directory. The server containing these images may or may not also be running the MED-V server. It is always optional as the TrimTransfer process is client-driven and the server-based BITs mechanism is completely handled by the BITs server extensions running with IIS.
· .CKM Files – The .CKM (Compressed Kidaro Machine) files represent the packed images that have been deployed to the server. These are the images that have been linked to specific workspace policies for users. The image is packed first on a MED-V client running the MED-V management console and encrypted.
· .CKM.INDEX Files – The .INDEX files represent indexes of the CKM files that are compared with local indexes to determine which blocks will be delivered over the network when using TrimTransfer for image deployment. The INDEX file will always be the first file downloaded when a server-based image is used with the workspace policy.
NOTE: As a reminder when setting up an Image Repository server via IIS, please make sure the appropriate MIME types are enabled on the Virtual Directory configuration within IIS. This is to facilitate the MED-V client being able to download images from an IIS server via BITs.
• .ckm (application/octet-stream)
• .index (application/octet-stream)
Client Image Repository
The Client Image Repository (also referred to as the Local Image Repository) exists on every MED-V Client. The layout and structure is more complex since this repository will be used for standard client use in addition to the testing, management, and pre-staging of images. This is where all images used by each workspace are deployed. There are several subdirectories beneath this folder:
PackedImages
The PackedImages subdirectory is only used by the management console. This is where packed images are created when a MED-V administrator creates a new local packed image. This is also the source folder for upload, deployment packages creation and pre-staging. The types of files you find here are identical to what would be stored in a server-based image repository.
NOTE: Base Virtual Machine images are not deleted once they have been imported in as a packed image. If you need to make changes to the image, the recommended process is to modify the original
PrestagedImages
The PrestagedImages folder is the target folder for Electronic Software Distribution solutions (such as SCCM) to place the CKM and INDEX files if the administrator wants to bypass TrimTransfer network deployment of the image.
NOTE: These images are not owned and managed by MED-V or the MED-V console. Any image updates will still require delivery from the MED-V server. There is currently no mechanism in MED-V to deploy “difference” images to clients via pre-staging.
Image Folder (identified by the image name i.e XP_Image folder):
When an image has been deployed, a subdirectory beneath the main MED-V Images folder will be created for each named image identified by the image name given in the MED-V Management console. There will be specific subdirectories beneath this folder:
A version folder for each deployed image: This is the client “working directory”, where this is the location where the client is looking for the Workspace image. This folder will contain additional subdirectories corresponding to the version of the image (e.g. v1, v2). Each version folder stores the VMC configuration file, the working EVHD file (an encrypted virtual hard disk,) and the .ENC encryption key. When the workspace starts the client will always start the latest version of the image. If the detection of new image version occurs (when configured to “suggest when new version is available”) a new version of the image will be created and downloaded (with or without TrimTransfer) and placed into a new folder under the new version name.
The settings that control this behavior beneath the image folder is controlled within the “Virtual Machine” tab when configuring the workspace policy.
The first option controls how many versions will be maintained on the MED-V client before the images will be deleted (oldest first.) The second option will determine if the user will be prompted when a new version is made available. The third option will determine if TrimTransfer is going to be used when downloaded updated image versions. Please note that this option also turns on local image indexing which will always run the first time a workspace is started prior to initial image download.
NOTE: From a practical standpoint, using multiple image versions and TrimTransfer is only recommended for use with revertible workspaces.
Other Files and Metadata stored in the Image Folder:
While the PackedImages and PrestagedImages folder contain *.CKM and *.Index files exclusively, the working directories for active workspace images contain additional metadata files designed to facilitate MED-V operation.
· Imagestate.xml: This is the metadata file that contains settings provided by the workspace such as memory allocation, device allowance, network status. It also controls the First-time setup flag as well.
· Image_name.vmc: This is the Virtual PC Virtual Machine settings file created, managed, and controlled by the MED-V client.
· Image_name.vsv: Saved-state file used by the MED-V client. Like the EVHD, this file will be encrypted too.
· Image_name.vsv.enc: This is the encryption key used with saved-state file.
The Test Image Folder
This folder is used specifically by the management console when testing an image. Before packing the image, the administrator will need to test the Workspace image and policy. In the process of doing this, MED-V leverages a special undo process to prevent damaging or altering the original base image during the test phase. The base image is considered the “gold” image and it needs to be kept intact. Therefore when creating a test image the management will create the test sub folder (e.g. C:\MED-V images\XP_Image\Test.) When the client starts a test image it will even mark the VHD as ready only to make sure no changes will be made. In addition, you will also find the following files in the Test Image Folder:
· .VMC file: This is a copy of the base image’s VMC file which points to the original base image image VHD.
· ImageState.XML: This governs dynamic MED-V settings that override existing virtual machine settings.
· A Virtual PC Undo Disk. This is where all of the data will be written to during the testing of the workspace. This disk will be discarded without merging changes once the workspace is stopped.
GLOBALIMAGEDATA.XML
The Image Repository also maintains a GlobalImageData.XML file. This maintains settings that are global to every user on that host using that virtual machine. Common settings such as the generated virtual machine name are stored here. This is a fairly small file in which many fields will not apply in MED-V version 1.0.
For the GLOBALIMAGEDATA.xml file, there are two critical fields:
· <VirtualizationEngine>: This field is important. The engine listed here must match or be a lesser version than the version of the virtualization engine installed on the client host computer. This denotes the minimum virtualization engine version required for the image.
· <WorkspaceVersion>: This field is used by the client to match up version of the MED-V Workspace installed inside the virtual machine. If there is a mismatch where the version of the workspace installed inside the virtual machine is lesser than the the one designated by the client, it will then upgrade the binaries inside the client.
Client Data Repository
The main location for the MED-V Client repository for configuration and data files is located in the %AllUsersProfile%\MED-V folder. The following information is stored in this directory:
· A common subdirectory where files related to the packaging wizard and the created package are stored.
· A Profile subdirectory where the client profile is kept. The client profile is where the information set during the installation is stored. This serves as a template for the actual Windows user running the client. The user working copy is always stored in the %LOCALAPPDATA%\MED-V\Profile directory.
· A Users directory where a subfolder for each user will be kept with encrypted cached credentials.
· A Local Subdirectory where the various management reports, client log queues, status information, last user and workspace information are kept.
The local directory is very important as it contains key subdirectories which will be shared by all users:
· Local\Config : This is where the downloaded policy and configuration from the server and the offline cache repository (Offline.dat) are stored.
· Local\KidaroPublishedIcons: This is where the published applications icons are stored after extracting them from the executables from within the Workspace image and their metadata (PublishedIconData.XML)
· Local\KidaroShortcutData: This is where the information about the published application links in the host Start Menu are stored.
· Local\PublishedMenusIcons: This is where information about the published menus links in the host Start Menu are stored.
· Local\Logs: This stores the devlog.log file and its history. This file is obfuscated by default.
As you can see, while the policy and encryption is ultimately controlled by the MED-V server, the bulk of operations with MED-V is based at the client. This is one of the fundamental differences between MED-V as a desktop virtualization solution and the other Microsoft desktop virtualization solution - Microsoft’s Virtual Desktop Infrastructure (VDI.) VDI is server-hosted (Hyper-V) and MED-V is client-hosted (Virtual PC.)
Steve Thomas | Senior Support Escalation Engineer
Comments
Anonymous
January 01, 2003
I would like to point a mistake: These two fields are actually in the ImageState.XML file: ·<VirtualizationEngine> <WorkspaceVersion>Anonymous
January 01, 2003
I would like to point a mistake: These two fields are actually in the ImageState.XML file: ·<VirtualizationEngine> <WorkspaceVersion>