This article describes one method that you can use to deploy the MED-V client using SMS/SCCM. The method that is described in this article is not the only method that is available. Additionally, you may have to modify the information in this article as appropriate for your particular environment.

Electronic Software Distribution (SCCM or SMS) as an alternative to the MED-V Deployment Package Wizard

For many system administrators, there will be a need to deploy the client silently without user interaction. While the MED-V Package Deployment Wizard does create a streamlined installation, it does require user interaction and was not designed to be deployed via SCCM or SMS. It was designed as an alternative.

Installing Pre-requisite Software

Because MED-V v1 requires the Virtual PC 2007 virtualization engine, most MED-V deployments will require at least a partial deployment of Virtual PC. The Virtual PC 2007 SP1 installer (included with MED-V version 1.0) can be fully automated.

Here is an example of a command string to leverage with an installation script for Virtual PC 2007:

%SystemRoot%\System32\MsiExec.exe /i "<PackagePath>\x86\Virtual_PC_2007_Install.msi" /qb! REBOOT=ReallySuppress ALLUSERS=1 /l* C:\Build\Logs\VirtualPc2007.log

Once the Virtual PC engine has been installed, a required QFE update is also needed prior to the deployment of the MED-V client. Since this is an .MSP file (installer patch) we will need to use the MSIEXEC /update option as follows:

%SystemRoot%\System32\MsiExec.exe /update "<PackagePath>\x86\KB974918-x64.msp" /q /l* c:\qfelog.log

For more information on command-line options for installing Virtual PC 2007, please refer to the following link:

Installing the Client

All of the options that can be specified during an interactive installation can also be installed from the command line. For example, the command string below will deploy the MED-V client with an alternate local images folder as well as a pre-configured server configuration:

%SystemRoot%\System32\MsiExec.exe /i <PackagePath>\MED-V_1.0.72.msi /qb! REBOOT=ReallySuppress VMSFOLDER=D:\MEDVImages START_AUTOMATICALLY=1 SERVER_PORT=80 START_MED-V=0 MINIMAL_RAM_REQUIRED=2048 ALLUSERS=1 /log C:\Build\Logs\MEDVClient.log

For more information on command-line options (including all options) for installing the MED-V Client, please refer to the following link:

Image deployments

If you will be using an image distribution server (deployment to client from IIS via BITS) the users will download the image upon the first initialization of the workspace. For many administrators, they would rather push the images to the client in advance to cut down on the time it takes for first-time workspace setup. This is done by pre-staging the image. The pre-staged images folder (defaults to C:\MED-V Images\PrestagedImages) is where the images are put on the client machine. Instead of downloading via TrimTransfer, the client will import the image by extracting the VHD from the CKM file upon first-time workspace launch.

The procedure for placing an image on a location such as a distribution point or share is pretty basic. After you pack an image from the MED-V Management console you can then locate the image and its index file inside the PackedImages folder (default location is C:\MED-V Images\PackedImages) and copy it to the share/distribution point that you want to store the image.

Control of Pre-staged Images Location on the Client

For sizing considerations, the location of the PrestagedImages folder can be controlled by a registry modification. This can be done post-installation by specifying the preferred value in a .REG file. By default, the PrestagedImages path is located in the MED-V Image default directory on the client.


The following is an example .REG script that can be used to adjust this value:

Windows Registry Editor Version 5.00
“PrestagedImagesPath”=”D:\\MED-V Images\\PrestagedImages”

Once the image is located in the PrestagedImages folder, the client will run the KidaroImageImporter utility and extract the image rather than download the image from the image distribution server.


NOTE: While the prestagedimages folder can be placed on a network share, it is recommended not to redirect it to a network share as the net performance may not increase significantly from downloading via BITs from an image distribution server.

Including the image in the Advertised Package

While including the image inside an SCCM advertisement is possible, it is important to consider the fact images may range anywhere from 2 to 20 GB depending on the amount of applications and the degree of image optimization performed. You may run into issues with the CCM cache limitations when the advertisement is set to “download and execute” as opposed to running from the distribution point. When the advertisement is set to download and execute locally it will require additional time for downloading via BITs from the distribution point. This may be the preferred option still – especially when dealing with maintenance windows and network traffic management.

Alternatives to including the image in the Advertised Package

In lieu of including the image inside the advertisement, a script or scheduled task can be deployed to leverage XCOPY or ROBOCOPY for copying down the image to the PrestagedImages folder.

Since Windows Vista, Robocopy has been included with the operating system installation and previous versions of Windows have made Robocopy available in the resource kit. The nice thing about Robocopy is the ability to program restartable copies and control retries and wait times between retries.


In the above example, Robocopy is copying all MED-V image files from a shared directory to the pre-staged images folder with restartable options.

The above options only discuss part of the MED-V SCCM strategy for v1. These will assist you in deployment of the client as well as deployment of the initial images. If you are leveraging MED-V v1 for managed persistent workspaces, SCCM can come in handy for managing these workspaces in a similar fashion as physical machines. I’ll discuss that more in a future blog.

Note: This information was originally contributed by Steve Thomas, Senior Support Escalation Engineer, on the MED-V Team blog: