MED-V 2.0 at a glance
A lot of changes have been introduced with MED-V 2.0, when you start working with MED-V 2.0 you’d feel that the whole product has been refined, starting from a powershell-based GUI, the look and feel, the architecture, to the functionality that’s been added, and much more.
For those of you that are not familiar with MED-V, it’s the Enterprise-Class product to overcome application compatibility issues with Windows 7. Don’t get me wrong here, it doesn’t fix applications, but it gives you a green light to go on with your Windows 7 upgrade without worrying about applications that don’t work with it which might hold your upgrade.
MED-V Deploys a Windows XP virtual image called a “workspace” to Windows 7 client operating systems and publishes the incompatible applications from that XP workspace into your Windows 7 Start Menu, it also provides full integration with the host’s network printers, file system, and so ever. The integration is completely seamless to the user; they wouldn’t know where the application is coming from until they start it up and see the Windows XP theme on its window. In addition to the application compatibility assistance MED-V provides, it also uses URL Redirection to redirect certain addresses from IE 8 on Windows 7 to IE 6 in the workspace, hence overcoming IE website compatibility issues.
Moreover, MED-V adds a lot of features compared to MED-V 1; that includes support for Configuration Manager 2007 natively, specifically allowing for SCCM to support running in MED-V workspaces configured for NAT networking.
The way MED-V 2 works is fairly simple, you first need to create a VHD for Windows XP, remember this VHD should not be created using Hyper-V or Virtual Server 2005, it should be created using Windows Virtual PC. Next you use one of the MED-V components called the “Workspace Packager” which prepares your VHD to become a MED-V “workspace” once that workspace is ready, you can use Configuration Manager 2007 to deploy that workspace to client computers.
Client computers on the other hand have a MED-V Host Agent running that understands the configuration data included in the workspace, for example what applications should be pulled out of XP to Windows 7? What Internet Explorer URLs that should be opened using IE 6 from the Workspace? Also, guests have their own MED-V Guest Agent that helps MED-V manage the workspace, this agent is automatically installed when you prepare the workspace.
Getting Ready for MED-V 2
So again, MED-V 2 needs Windows Virtual PC to be installed on your client computers, it’s recommended to turn on Hardware-Assisted Virtualization if supported, it is not required anymore as Microsoft has released a patch for Windows Virtual PC to let go of this requirement. Patching Windows Virtual PC should be planned as a part of rolling out MED-V 2; we’ll talk about that in the Deployment section. Check out KB977206 to obtain the patch.
In addition to preparing Windows Virtual PC, I suggest you plan for your MED-V 2 before you actually start the packaging and deployment processes, things you should keep in your mind:
Do I need Shared Workspaces?
MED-V 2 creates a differencing VHD from that Base VHD you deploy, users on a single computer can share one workspace or each user can have their own Workspace, thus creating a differencing disk for each one.
How am I going to manage the workspace?
The Workspace is eventually an OS running in your environment; you should consider having a Configuration Manager or a similar management tool agent installed on it, and/or App-V Client if you have it1.
Do I need URL Redirection?
If you have legacy web applications that run only over IE 6, what are the URLs? Also you should consider limiting the IE6 experience that users have which is done automatically by MED-V.
What are the applications I need to install in the workspace?
We’re talking about Legacy apps here; make sure you test them thoroughly within the workspace before you deploy it.
How are you going to roll out the workspaces?
Using ESDs like Configuration Manager is great, but you need to make sure your network bandwidth can handle it, you should limit the number of applications in the workspace so the VHD doesn’t grow big, compression is good, but still roll it out in a slow steady form.
In addition to the points above, go through the wizard a couple of times and ensure you check your best fit options, for example the level of user interaction with the workspace when it’s being prepared.
Deploying MED-V Workspaces
Alright, MED-V 2.0 doesn’t use dedicated management and deployment servers, so you don’t have to deal with yet another server infrastructure in your environment just to handle application compatibility. You use your existing electronic software distribution (ESD) system to deploy and manage MED-V workspaces. This lets you scale your MED-V deployments to the same extent as your current management system provides. If you don’t use an ESD system, you can always use Group Policy Software Installation (http://support.microsoft.com/kb/816102) to deploy MED-V. But that’s a subject for a different blog post. For the remainder of this post, I’ll discuss one way you might deploy MED-V workspaces with System Center Configuration Manager.
Okay, you have plenty of options to deploy the MED-V setup files, Windows Virtual PC, and the actual workspace to your client computers, each method has its own pros and cons, with SCCM you can:
- Use a Package with multiple Programs
- Use a Task Sequence
Use a batch file
Now, I’m going to explain all three methods but before we actually get to the deployment recipes, let’s have a small recap of what components you need to deploy and what files does the MED-V Packager give you.
Installation Files to be deployed
Depending on your environment the number of files could vary, for instance, if you have Windows Virtual PC already enabled as a part of your standard image, you won’t need to deploy it, so let’s assume you have a clean environment with nothing but Windows 7 deployed, you need the following:
Windows Virtual PC: KB958559
Non-HAV clients patch: KB977206 (already in Windows 7 SP1)
MED-V Client: MED-V_HostAgent_setup.exeSetup.exe: the workspace itself
That’s about it, if you’re deploying Windows 7 you should consider a task sequencer to get them installed, remember Windows Virtual PC requires the clients to reboot, but that’s ok Task Sequencers in Configuration Manager run perfectly fine after a reboot.
Method 1: Using a Package and multiple Programs
The good thing about this method is that each component is installed individually, with its own advertisement, that gives you great flexibility and makes it easy for you to troubleshoot each component; the bad thing about it, well, it’s long!
Let’s examine the files produced by the MED-V Packager:
a .REG Configuration File
a Workspace VHD (compress that, it can save up to 50% of space)
a .EXE Workspace Package Installer
a .MSI File
a PowerShell Script (should you need to repeat your steps!)
that being said, here’s the plan, we’re going to create an SCCM Package that contains the installation source files, then we’ll create a program for each file we need, so let’s begin!
Step 1: Create a new Package
I prefer you create a new folder under Software Distribution, and then create a new Package, the package location should be the path to your custom made folder with all the executable files we need, it doesn’t have to be a UNC since SCCM will copy the contents to an accessible Distribution Point.
Step 2: Create a Program for WPC
As you can see above, the command “Windows6.1-KB958559-X64.msu /quiet” note the (X64) at the end of file name? you guessed it, if you have Windows 7 is 32-bit then you should get the x86 bits, the /quiet switch will take care of the WPC installation quietly, you can specify /noreboot switch if you wish not to reboot your client machine, moreover, you really need to make sure SCCM Deploys WPC whether or not the user is logged on in the next page, here is what you should do in the environment page:
You can do this for every Program we’re going to deploy.
Step 3: Create a Program for the WPC Patch
We’re going to use the same command to get it installed, and again using the /noreboot switch will disable rebooting the client.
Step 4: Create a Program for the MED-V Host Agent
Alright, the command here is similar to what we used above but this time the parameters differ a little bit, “ MED-V_HostAgent_setup.exe /qn IGNOREPREREQUISITES=1” will cause the host agent installation to ignore any prerequisites, for example not having WPC installed.
Step 5: Create a Program for the Workspace
As you can see below the command “setup.exe /qn OVERWRITEVHD=1” will make SCCM install the Workspace even if there any previous Workspaces present at the client.
Step 6: Create an Advertisement for each Program
Now that the Package and all of its Programs have been created, you should create an advertisement for each program, I know, it’s a lengthy process, but with multiple advertisements you can control the deployment level at each client and track every single component being deployed through reporting and Advertisement Status.
Here’s how the advertisement should look like
Now, in the Schedule page, you either run it “As Soon As Possible” causing the clients to pull it right next to its upcoming policy refresh cycle, or schedule to run during off-business hours.
Method 2: Using a Task Sequence
Deploying the components in a Task Sequence allows for fine-grained control, and it also allows you to use one advertisement to send Windows Virtual PC components to clients of differing bitness. Here’s one example of an SCCM Task Sequence to deploy MED-V. Note that it’s okay to install the non-HAV patch to systems that are HAV capable. If a system is capable of HAV and HAV is properly configured, Windows Virtual PC will use HAV features even though the non-HAV patch is installed. Deploying the non-HAV patch universally will allow administrators to ensure that Windows Virtual PC will function properly on all systems. Again, the non-HAV patch is not needed on systems that are running Windows 7 Service Pack 1.
The query at the top of the branch to select x64 systems is from WMI Namespace root/cimv2 and the WQL is “select * from Win32_Computer_System where SystemType = “x64-based PC”
For X86, the WQL is “select * from Win32_Computer_System where SystemType = “x86-based PC”
Method 3: Using a batch file
Here is a sample batch file that installs the MED-V components in reverse order with prerequisite checks turned off. Turning the prerequisite checks off lets you deploy the components with one reboot:
#REM Batch Starts
#REM Installing Host Agent components
start /WAIT MED-V_HostAgent_Setup.exe /qn IGNORE_PREREQUISITES=1
#REM Installing Workspace
start /WAIT .\setup.exe /qn OVERWRITEVHD=1
#REM Installing Windows Virtual PC
start /WAIT Windows6.1-KB958559-x64.msu /norestart /quiet
#REM Installing the non-HAV Patch
start /WAIT Windows6.1-KB977206-x64.msu /norestart /quiet
#REM Optional: Restart the computer after 5 minutes.
Shutdown.exe -c “Please save your work, Windows will restart in 5 minutes” -r -t 300
#REM Batch File Ends
If your Workspace has a Configuration Manager installed, you must reset the client to generate new GUIDs.