Managing virtualisation for the desktop
Microsoft’s Desktop Optimization Pack includes two virtualisation tools, one for Windows itself and one for individual applications. what is involved with setting these up, and what are the benefits and downsides?
Virtualisation on the desktop deserves wider attention. One of its benefits is to isolate troublesome applications in their own virtual machine, where they can run with elevated permissions or special dependencies without causing problems for the host operating system. Microsoft included XP Mode in Windows 7 for exactly this reason, removing the need to stay on Windows XP just for the sake of one or two incompatible but critical applications. XP Mode lets you run applications in Windows XP on a virtual machine, while integrating them with the host desktop so users hardly notice that they are virtualised. Another benefit is reliability. Applications isolated in a virtual machine will not be broken by other installs that update a shared library, for example.
VMs tend to be large and unwieldy, and another option that brings some of the same benefits is known as Application Virtualisation. It is arguably a misnomer, since these applications are not running in a virtual machine. However, they are designed to be zero-touch installs, by bundling any dependencies into a single executable package. Typically some parts of the application, such as registry access, are truly virtualised so that the host registry is untouched. This simplicity of installation also makes it easy to add and remove applications from a user’s desktop automatically.
Microsoft’s product for this is called Application Virtualization for Desktops (App-V). It is based on an earlier product called SoftGrid, developed by Softricity, a company acquired by Microsoft in 2006.
Although the most obvious App-V benefit is the ability to run non-standard applications, in Microsoft’s studies automated deployment is nearly as important to cost savings. Another App-V scenario is for packaging applications for external business partners. Installing an external application using App-V increases reliability and lowers risk, since in this case the software provider has no control over the configuration of the user’s machine. This type of usage is licensed through a Services Provider Licensing Agreement (SPLA) by Microsoft Partners.
A potentially weak point in any virtual machine is that it vulnerable to malware and attack in the same way as any other operating system. This is mitigated by the fact that VMs are often used only for specialist tasks that are safer than general Web browsing; you can also lock down features in a VM without inconveniencing users. Nevertheless, it makes sense to extend the same care to VMs as to host operating systems, in terms of system updates, anti-virus and security policy. This is hard to enforce with arbitrary virtual machines. Microsoft’s Enterprise Desktop Virtualization (MEDV) is the solution, a managed equivalent to XP Mode that pulls down Virtual PC images from a MEDV server to the desktop.
Microsoft primarily delivers both MEDV and App-V through a suite called the Desktop Optimization Pack (MDOP). MDOP is an additional subscription for customers who have software assurance; in other words, you have to have software assurance, plus the MDOP subscription on top. However, MDOP is also available to MSDN and TechNet subscribers for evaluation, testing and troubleshooting.
The current full version is MDOP 2009 R2; MDOP 2010 has been released but although it includes the final version of App-V 4.6, MED-V 1.0 SP1 is planned for April 2010 and only the release candidate version is included (this is also available on Microsoft Connect at https://connect.microsoft.com/medv).
Getting started with App-V
App-V has several components. A minimal App-V deployment requires just two of them: the App-V Sequencer for packaging an application, and the App-V Desktop Client for running it. The Sequencer lets you create an MSI installer that can be run directly on a desktop that has the client installed.
You can also install the package into an App-V management server, which automates deployment to specified clients. Finally, the App-V streaming server is an optional service for large-scale deployments, dedicated to efficient streaming of App-V binaries.
Version 4.5 of the App-V server is designed to run on Windows Server 2008 connected to Active Directory; the new version 4.6 adds support for Windows Server 2008 R2, Windows 7 and 64-bit Windows clients. Its main dependencies are IIS 7.0 with ASP.NET and the Windows Authentication feature, and SQL Server 2005 or higher, though SQL Server does not need to be on the same machine. Before installing App-V server, set up these dependencies. SQL Server should have both TCP/IP and named pipes enabled. In addition, create groups in Active Directory for both App-V administrators and App-V users before installing App-V server. Note that by default it installs in a secure mode which requires a certificate. If you are just testing App-V, this is not necessary. You need to specify the SQL Server to use, allowing App-V to create a new database, and the App-V groups for administrators and users.
App-V uses a content folder for streaming applications. As part of the install, you define the location of this folder. You then need to share it on the network manually, ensuring that users have read permissions to the share. You also need to create a program exception in Windows Firewall on the server for the two executables, SGHWDSPTR.EXE and SGHWSVR.EXE, to accept incoming traffic.
A common problem is that the App-V server tries to start before SQL Server is available, and fails. You can fix this by starting the App-V Management Server manually after a reboot but small irritations like this spoil the App-V administration experience.
You can test the App-V installation using the supplied Default Application. Run the App-V management console and connect to the App-V server. Under Applications, find Default Application, right-click and choose Properties. You need to configure the path to the .OSD file that defines the package configuration, and the .ICO file which specifies its icon. These are pre-installed in the content folder. However, it is essential to specify the path to these files using the network path, not the local path, by typing it in or clicking Browse. You can also specify details like where the application shortcut appears on the client. If you are not using secure communications, you also need to edit DefaultApp.osd, modifying the CODEBASEHREF to use RTSP rather than RPSPS, and the port number 554 (unless you changed the default).
The desktop install for the App-V client is straightforward. You need to specify the App-V publishing server and port, and whether it uses RTSP or the secure RTSPS. The other key parameter is the refresh interval, when the client queries the server for new or updated installs; the default is on login. If you now login on the client, you should see the default application in the location you specified. Double-click, and after a brief pause it downloads and runs.
Preparing apps for App-V
For larger customers you may be deploying custom apps; for smaller businesses you can use App-V to support apps that don’t run well on newer versions of Windows or offer two versions of the same app side by side; that works because rather than running directly on the client PC, each app is deployed through App-V.
Packaging the application is called sequencing. The idea is that you install the application on a clean machine, while monitoring the install with the App-V sequencer; the sequencer than uses this information to create a package. You can also customise the package, such as by adding files to the install. Despite the tools, sequencing is the most complex aspect of App-V, particularly with applications that have many dependencies, though it is exactly these applications that benefit most from App-V deployment. The sequencer works by analysing what the installer changes, which of course varies according to the configuration of the target machine. In consequence, you should sequence on a clean install of Windows configured in the same way as your standard PCs. This should include Microsoft Office, if that is standard. Furthermore, the sequencer machine should have two or more partitions, one designated as the Q drive. Q is the destination drive used internally by the App-V client by default, and unless it conflicts with an existing use of Q you might as well live with the default.
The easiest way to manage this is to create a virtual machine for sequencing. Then you can use snapshots to restore it to a clean state before each sequencing operation. Microsoft’s Hyper-V is ideal for this. Sequencing is performance-intensive, so can take a long time, but this is just a matter of patience.
The big disappointment of App-V is that Microsoft does not guarantee success if you sequence on a different configuration of Windows than your clients. This is what Microsoft’s sequencing guide says: “Sequence on a machine that matches the Operating System and configuration level for the target clients. Microsoft has clarified its support stance since 4.2. Sequencing on Windows XP and deploying to Windows Vista is not a supported scenario. If you choose to sequence on one Operating System and deploy to another then you do so at your own risk. In addition to the Operating System, you want to make sure your sequencer is at the same service pack and hot fix level of your deployed workstations.”
This is a burdensome requirement, considering how frequently updates are applied to clients. In theory, App-V is meant to reduce client dependencies, so this would seem to be a significant limitation. However, the pragmatic answer is that App-V is less delicate than this implies; it’s not guaranteed but images sequenced on a slightly different setup will usually work.
With those provisos out of the way, you can deploy an application. Run up your VM complete with Q drive, and install the App-V sequencer. Run the sequencer, and choose File > New Package. This runs the packaging wizard. Give the package a name, and click Next. Make sure your application setup files are copied to the VM, and then click Begin Monitoring. You will be prompted to select a target directory, which should be on the Q drive. The sequencer then loads the virtual environment, which takes a while, and then states Monitoring started. You can now install the application.
Once the application is installed, click Next, add any files required which setup did not install, and click Next. You can then add file associations and shortcuts. Click Next, and the Launch Applications page appears. Here, you should select the installed application and click Launch, to run it in the virtual environment. This is a handy test, and optimises the package for streaming. All going well, the application runs. Close it, and click Next, then Finish.
The package is now created, but there are a few details to check on the Deployment tab. First, the protocol defaults to RTSPS and the Hostname of the App-V server to %SFT_SOFTGRIDSERVER%. Client installation does not set this variable, so you need either to set it on the client, or change it to the hostname of the App-V server. You should also change the protocol and port if necessary. You can also select which operating systems to support, noting the caveats above. Finally, if a standalone MSI is also required, check this option. Then click Save, to create a .SPRJ Sequencer Project file.
Find the folder where you saved the sequencer project, and copy the folder with all its files to the content folder on the App-V server. You can now deploy it by right-clicking Applications in the App-V Management Console and choosing Import Application. Verify that network paths are used, as with the default application.
The result of all these efforts on the server is a smooth experience for the user. On the next login, a new shortcut for the application automatically appears on the desktop, ready to click and run; if you sequenced on Windows 7 and pinned the app to the toolbar, it will be pinned on their desktop. The trade-off between effort on the server and great results on the client make most sense on larger networks, or for crucial apps that can’t be supported any other way.
Getting started with MED-V
The setup and configuration of MED-V has some parallels with that for App-V. There is a client component, an optional server, and configuration of packages for distribution, though in this case the packages are Virtual PC virtual machines.
If you will be using the MED-V server, it makes sense to install this first. The installation is straightforward, though it requires Server 2008 and access to a SQL Server 2005 or 2008 database manager, either local or remote. This is for MED-V reporting. You can configure the server for either encrypted communications, with a certificate, or unencrypted. After installation, configure the SQL connection manually in the Server Configuration Manager.
The next step for MED-V is to prepare a VM for distribution. Note that MED-V 1.0, as found in MDOP 2009 R2, does not support Windows 7 and is based on Virtual PC 2007 SP1; MED-V 1.0 SP1 does work with Windows 7, but at the time of writing only the RC is available. Another special requirement is that Windows XP in the VM must be licensed using a Volume License Key, otherwise the MED-V prerequisite tool will not run. MED-V is designed to enable compatibility with older applications. However, unlike Windows XP Mode, hardware-assisted virtualisation is not a requirement.
Run up a VM, install the latest Virtual PC additions, and prepare it for MED-V by running the Workspace Installer from within the VM. This depends on .NET Framework 2.0 SP1 or higher, and that depends on Windows Installer 3.1 or higher, so get these in place before you start.
Next, run the MED-V prerequisite wizard within the VM. This lets you select some preferences for Windows and Internet Explorer configuration, and sets some that are required. You can also set auto-logon. Manually disable hibernation and sleep in the VM, and turn off automatic restart after system failure. You can also use the Sysprep tool to assign a unique ID, though Microsoft recommends you do not use it to join a domain as there is a separate MED-V join script. Then shut down the machine, and tweak the VM settings to disable floppy disk drives and undo disks.
Working with images
One the VM has been created, you can deploy it as a MED-V Image. Images are managed using the MED-V Management Console, which is installed on a client machine (it cannot be installed on a server). The Images section covers three image types; Local Test for trying it out, Local Packed for deployment without a server, and Packed on Server for server-based deployment. Images are created by selecting a base VM. Images are associated with MED-V workspaces. A workspace is an image together with policy data. You can set things like how the VM integrates with the host desktop, clipboard and printer support, and of course applications to publish. A published application turns up as a shortcut in the host Start menu, and can be any command that is valid within the guest VM. For example, you could run IE6 on XP for some otherwise incompatible Web application.
When a workspace is set up on the client, you can configure script actions, including domain join and computer renaming. It may be necessary to update an existing image, in which case the update will be automatically deployed. This will overwrite the existing one, the obvious implication being that you should avoid saving any data on the VM itself, where it is liable to be lost.
MED-V, XP mode, or plain old virtual pc?
MED-V is a powerful solution but overkill for most smaller businesses. It offers the ability to roll out VMs for application compatibility in a controlled manner. Another advantage over XP Mode is that it works across all versions of Windows (with MED-V 1.0 SP1). Vista and Windows 7 aren’t supported as the guest OS, but the point is to virtualise apps that require older versions of Windows anyway rather than to do general VDI (there are other, better tools for VDI); more of a limitation is the requirement for VMs to be based on the Volume License Key version of Windows XP.
XP Mode on Windows 7 is excellent for providing XP compatibility to a few users, provided that the guest operating system is maintained and protected to the same standard as the host; you don’t get the management of MED-V but you don’t have the overheads either. On older versions of Windows, Virtual PC or alternatives such as VMware will meet the need.
Microsoft Desktop Optimization Pack
The official page has ROI guides and brochures rather than technical details:
App-V Team Blog
More regularly updated than the MDOP blog, this has practical tips and solutions:
App-V 4.6: Windows 7, Windows Server 2008 R2, and More
An excellent survey of what’s new and a useful Application Virtualization blog:
Independent App-V Blog
Written by a virtualisation MVP, this blog covers in-depth techniques (including working with Office 2010 and App-V) and third-party tools:
MED-V Team Blog
Announcements about MED-V plus tips like locking down the MED-V file transfer utility by file type:
Download Windows XP Mode
You’ll need to confirm the Windows 7 version and language, but this page is simple enough to point end users to if necessary:
What’s in MDOP?
Microsoft’s Desktop Optimization Pack includes more than App-V and MEDV; it’s a useful set of desktop management products reserved for customers on Software Assurance.
enterprise desktop virtualization
MEDV is a means of deploying and managing virtual PC instances on clients in your network. You can create standardised images, generally used for legacy applications that only run on older versions of Windows, or which have special dependencies or configuration requirements. A technology called Trim Transfer reduces the size of images transferred over the network.
application virtualization for desktops
Application Virtualization, or App-V, is a means of deploying applications without fully installing them. In addition, App-V applications run in a virtual sandbox, though they can still access and interact with local resources. There are several deployment models for App-V applications, ranging from standalone installation via an MSI file to fully managed on-demand streaming from an App-V server.
diagnostics and recovery toolset
DaRT is a troubleshooting tool for recovering Windows desktops that will not boot. It extends the Windows Recovery Environment, booted from installation media, to provide crash dump analysis, event log access, driver disabling, hotfix removal, password reset and more. Even if the system is not reparable, you can use a file explorer to copy files to a safe location elsewhere on the network. This is a great tool, and it is odd that Microsoft does not include it by default in the Windows Recovery Environment.
advanced group policy management
AGPM adds features to group policy management including change control, which provides check-in, check-out and version history for Group Policy Objects (GPOs). There is also role-based delegation, search and filter, copy GPOs between forests, and offline editing.
asset inventory service
The Asset Inventory Service is a cloud-based service operated by Microsoft. Customers must register through the Microsoft Volume Licensing Service. They then install AIS agents on PCs in the network, which report inventory data back to Microsoft’s database. The data is then available for reports on software assets. Microsoft says, “during the registration process, no comparisons are made on customer’s inventory data with in-place volume licensing agreements”, though it is possible to generate a license entitlement report.
system center desktop error monitoring
DEM monitors and reports system crashes and application failures across the network. You can then generate reports identifying the applications with the most failures, the machines which crash most often, and the most common errors overall.