MED-V deployment planning and requirements

Read this chapter excerpt on Microsoft Enterprise Desktop Virtualization (MED-V) and learn how to plan for a MED-V deployment by assessing customers' environments and requirements.

Solutions provider takeaway: Before a solutions provider deploys Microsoft Enterprise Desktop Virtualization (MED-V) for their customer, they need to determine whether it meets their customer's requirements. This chapter excerpt details the steps that you need to take when planning a MED-V deployment.

About the book
This chapter excerpt on Deploying Microsoft Enterprise Desktop Virtualization (download PDF) is taken from the book Mastering Microsoft Virtualization.

Solutions providers will get detailed information on Microsoft's virtualization products and expert advice on how to deploy a complete virtualization stack with Microsoft's server virtualization offerings. This book also covers topics such as Hyper-V in Windows Server 2008 R2, installing and configuring Remote Desktop Services and the best practices for working with virtualized desktop infrastructures.

Planning Considerations for a MED-V Deployment

At a high level, the process and steps of planning for a MED-V deployment are similar to the approach we took in our last chapter, but the specific details for each step are different. As a review, the planning steps included assessing the current environment, determining needs and requirements, defining the project scope, creating an architectural design, conducting a POC, and continuing on with a pilot and later a full deployment. Let's review these planning steps and their specific MED-V considerations.

Assessing Your Environment

Before an organization deploys a MED-V solution, it's important that they conduct an assessment of their current desktop environment. The assessment would include reviewing desktop hardware, operating systems, applications, user data and settings, network infrastructure, and management tools.

A review of the desktop hardware environment, the processor family and type, memory configuration, and hard disk storage of each desktop should be made and recorded. In addition, the Windows client operating system and versions running on each desktop, either physically or as virtual machines, needs to be identified and recorded. All of this information is required in determining whether the current desktops meet the MED-V client system requirements and if a hardware or software upgrade may be needed.

Another necessary step is to review which corporate applications are running on each desk-top, along with their specific hardware and software dependencies. Each application will need to be evaluated to determine if it can run in a virtual machine and the application vendor supports it.

An assessment of the desktop network environment is also important. Understanding where the desktops are located (main, distributed, or home office) and their associated network band-width and latency will help in determining the location of MED-V server infrastructure and how images will be initially deployed and updated.

Understanding what processes and tools are used to manage the desktop environment along with identifying current management challenges are essential. An organization will need to determine if their existing management process and tools can be used to manage the MED-V client environment or if new processes or tools will need to be evaluated and implemented. In addition, current desktop management challenges should be addressed prior to introducing a new desktop solution into the environment.

As mentioned before, Microsoft has assessment tools that can be used to assist an organization in this effort. The Microsoft Assessment and Planning Toolkit can be found at

Determining Needs and Requirements

The next step for the organization is to determine their requirements for a MED-V implementation. The data collected during the assessment step can help with this process. An organization will need to ask what problem or problems they are trying to solve. For example, is the organization planning to migrate from the Windows XP to Windows 7 operating system and does it need a solution to remediate potential application-to-OS compatibility problems? Are they considering deploying corporate-managed VMs to nonmanaged or employee-owned PCs? Maybe they would like to improve their desktop business-continuity and disaster-recovery capabilities by having the ability to rapidly and easily move a desktop PC image from one PC device to another in the event of a hardware failure, stolen PC, or disaster. This analysis will help an organization determine whether MED-V is the most appropriate solution to meet their requirements and help guide the architecture design and implementation of the solution.

Defining Project Scope

After the organization has conducted an assessment of their environment and identified the problem(s) they are trying to solve and their specific needs, the next step is to define the scope of the MED-V deployment project. Some of the areas to consider when defining the project scope include which scenario(s) to implement first, the type and number of users and groups to target, which locations to include, and whether this effort should be part of a larger project. All of these questions should be answered to help develop the initial, mid-, and long-term scopes of the MED-V deployment project.

An organization may choose to implement the MED-V deployment project in phases, with each phase targeting a specific solution scenario and expanding the scope of users and groups over time. They may decide to initially implement a MED-V solution as a way to improve the disaster-recovery capabilities of the organization. They may also choose to use MED-V to remediate application-to-operating system compatibility issues to support a Windows Vista or Windows 7 deployment project. In this case, the MED-V project would be part of the larger Windows migration project and closely aligned with that project scope. A future plan could also include implementing a MED-V solution as a more agile way to deploy corporate desktop images to employee-owned or unmanaged desktops. Whatever the reason(s) for deploying a MED-V solution, the organization will need to define and closely align the scope of the project with its goals and needs.

Microsoft Consulting Services and Microsoft Partners can assist organizations with defining the MED-V project scope and overall planning efforts. More information regarding Microsoft Consulting Services and Partner offerings can be found at services/microsoftservices and

Creating a Solution Design and Architecture

Once an organization has completed the above steps, from conducting the assessment to defining the project scope, they are ready to design the MED-V solution architecture. A MED-V architecture consists of multiple server components that make up the overall solution. The number of servers needed to support a MED-V solution will depend on the organization's current IT environment and requirements. The architectural design factors include the number of users, location of users, Active Directory domain design, number of Workspace images, existing management infrastructure, security and regulatory requirements, and High Availability needs. Let's explore some of these factors and their effect on designing a MED-V solution architecture.

Today, Microsoft MED-V v1 is positioned and supported only for desktops that are part of an Active Directory Domain Services environment. Microsoft is planning to support nondomain, unmanaged desktops with the next version of MED-V planned for release in 2010. A MED-V solution is called an instance and consists of a Management Server, Image Repository Server, and Reporting Server. A MED-V Management Server can belong to only one MED-V instance at a time, but the MED-V Repository Server and Database Server can be shared across multiple MED-V Management Servers. Microsoft recommends no more than 5,000 concurrent users be supported per MED-V instance. If an organization is planning to support more than 5,000 concurrent users, another MED-V instance will need to be added for each additional 5,000 users. In addition, if the organization has security or regulatory requirements that mandate the separation of specific MED-V Workspace images, they can implement additional MED-V instances to support those requirements.

The MED-V Management Server should be centrally located to provide reliable network access for its clients. A MED-V client regularly connects to the MED-V Management Server to send status and event information once a minute. The MED-V client also checks with the MED-V Management Server for Workspace updates every 15 minutes and image updates every four hours. If a client is unable to connect to a MED-V Management Server, the status and event information is queued on the client until it is able to reconnect. Microsoft does not sup-port using Failover Clustering for MED-V Management Server, so it's important to create a standby MED-V Management Server that can be brought online in the case of server failure. This is especially true if the MED-V Workspace is configured to require the client to be online and authenticated in order to use the MED-V Workspace. It is possible to implement MED-V Management Server on two servers. More information about implementing this type of failover support can be found in the MED-V manual.

The MED-V Management Server stores Workspace configuration metadata, which is 30 KB per Workspace. To determine the disk storage requirements for storing Workspace metadata on the MED-V Management Server, multiply the number of Workspaces by 30 KB. For example, if you have 20 Workspaces, you would multiply 20 by 30 KB, which equals 600 KB. The MED-V Management Server can be backed up and restored to the same server or a backup server using Microsoft System Center Data Protection Manager (SCDPM) or another backup and restore solution. Four XML files make up the server configuration files: ClientSettings.xml, ConfigurationFiles.xml, OrganizationalPolicy.xml, and WorkspaceKeys.xml. The location for the data to back up is drive letter:\microsoft enterprise desktop Virtualization\servers\serverconfiguration.

As mentioned earlier, a Repository Server consists of a Web Server (IIS) and a file server that stores the images on a file share. The number of Web Servers (IIS) and file servers used in a MED-V solution instance will depend on the number of concurrent users, the size and number of the MED-V images, deployment and update frequency, the user location, network bandwidth, and other factors. Multiple Web Servers (IIS) can be used for a MED-V solution instance and load balanced to provide the appropriate level of scalability and performance. The placement of the Repository Servers should be close to the clients, avoiding WAN connections. This is important for the initial deployment of the MED-V image and also image updates. The disk storage requirements for the Image Repository are determined by identifying the number and size of MED-V images that will be supported on a given repository. Backing up the MED-V images is also important and can be accomplished by using SCDPM or another backup and restore solution.

The Med-V Database Server stores client activity and event information. The size of an event sent by a client is around 200 bytes. The MED-V Database Server database storage requirements are determined by the number of MED-V clients, multiplied by the number of events sent by each client per day. Other database size factors include how long the data will be stored and the allocation of additional space for unknown events or circumstances.

Organizations will need to determine how the MED-V client software and images will be deployed and updated on the client. There are different options to choose from, including using the MED-V solution infrastructure, existing client management solutions, and removable media (DVD and USB storage). For example, an organization could deploy the MED-V client software by making it part of their corporate Windows image, deploying it using ESD or with removable media. The initial MED-V image can be deployed to the client by using the MED-V Management Server, prestaging it to the client using ESD or by removable media (DVD and USB storage). The Med-V images will also need to be updated, which can be accomplished by using the MED-V Management Server. Some organizations may also decide to update the client operating system and applications running in the MED-V image by using their corporate ESD solution.

Implementing a MED-V POC

Once the solution design and architecture are completed, the next step is to test the solution in a Proof of Concept (POC) lab environment. POCs are where the rubber meets the road and can vary in goals, scope, time frame, and outcome. It's important to conduct a well-organized POC, focusing only on the goals and scope agreed on, involving the right resources, and documenting the entire process from start to finish, so that this information can be reviewed and utilized to support later project efforts.

Depending on the goals of the POC, the architecture and server configuration of this environment can be implemented on a much smaller scale than a pilot or production deployment of the solution. For example, a typical MED-V POC involves one physical server and one to two PCs. The server would support the MED-V Management Server and Image Repository, and the PCs would support the MED-V Management Console and MED-V Client. An example MED-V POC server configuration is shown along with the MED-V POC architecture example in Figure 16.1.

Figure 16.1 MED-V POC architecture example

At a high level, you can break the POC into four areas: preparation, installation and configuration, testing and knowledge transfer, and review and analysis. Each area is important and will have an effect on the success of the POC and preparation for a production deployment. The knowledge transfer and testing area should be well defined in terms of what the POC team wants to learn and evaluate regarding the Microsoft POC solution. A simple but effective one-week POC action plan follows.

MED-V POC Action Plan Example

POC Preplanning Activities

  • Conduct an initial meeting.
    • Determine goals, scope, expected outcome, time frame, resources involved, location(s), IT infrastructure needs, and prerequisites (hardware, software, services, networking, storage, and so forth).
  • Conduct a pre-MED-V POC meeting.
    • Include all the required IT and business resources.
    • Review the POC areas described above.
    • Identify potential project showstoppers.
    • Create an agenda for the one-week POC activities along with the responsibilities of IT and business resources participating.

POC Activities

  • Day 1 -- Kickoff meeting, installation of Windows Server 2008 R2, Hyper-V, Web Server (IIS), SQL Server, and MED-V server and client components.
    • Conduct a MED-V POC kickoff meeting the first day of the POC. Verify that the POC prerequisites are completed and the organization is ready to begin.
    • Present an overview of the POC project and planned day 1 activities.
    • Begin MED-V solution server software installation.
        1. Install and configure a Windows Server 2008 R2 Server with Hyper-V called POCServer.
        2. Create a VM on POCServer called MEDVSRV.
        3. Install Windows Server 2008 (32- or 64-bit) and prerequisite software on the VM called MEDVSRV on POCServer.
        4. Install the Web Server (IIS) role on the VM called MEDVSRV on POCServer.
        5. Install BITS Server Extensions feature on the VM called MEDVSRV on POCServer.
        6. Install SQL Server 2008 Express on the VM called MEDVSRV on POCServer.
        7. Install MED-V Management Server V1 on the VM called MEDVSRV on POCServer.
    • Conduct daily status meeting.
  • Day 2 -- Installation of MED-V client components, and creation and testing of MED-V Workspace image.
    • Present an overview of the planned day 2 activities.
    • Install the MED-V client components.
      1. Install MED-V client V1 and Management Console and prerequisite software on PC1 running Windows Vista (32-bit).
      2. Install MED-V client V1 and prerequisite software on PC2 running Windows Vista (32-bit).
    • Create and test MED-V Workspace images.
      1. Prepare Virtual PC images for MED-V.
      2. Add MED-V test images.
      3. Create and configure MED-V Workspaces.
      4. Test MED-V Workspaces.
      5. Pack tested MED-V images.
    • Conduct daily status meeting.
  • Day 3 -- Deployment of MED-V Workspace.
  • About the authors
    Tim Cerling is a senior technology specialist at Microsoft with more than 10 years experience and a focus on Hyper-V.

    Jeff Buller is a virtualization specialist on Microsoft's virtualization solutions team.

    • Present an overview of planned day 3 activities.
    • Continue to create and test MED-V Workspace images.
    • Deploy MED-V Workspace.
      1. Deploy MED-V Workspaces using the MED-V Server.
      2. Update MED-V Workspaces using the MED-V Server.
      3. Deploy MED-V using Deployment package on removable media.
      4. Deploy MED-V using ESD for prestaged deployment.
    • Conduct daily status meeting.
  • Day 4 -- Continuation of MED-V Workspace deployment activities and knowledge transfer.
    • Present an overview of planned day 4 activities.
    • Continue MED-V Workspace deployment activities.
    • Conduct knowledge transfer activities.
    • Conduct daily status meeting.
  • Day 5 -- Knowledge transfer and testing of MED-V environment.
    • Present an overview of planned day 5 activities.
    • Review MED-V troubleshooting tools.
      1. Generate and review MED-V reports.
      2. Run and review MED-V diagnostics.
    • Lead MED-V Q & A discussion.
    • Conduct end-of-POC status meeting.

Post-POC Activities

  • Prepare report on POC activities completed, including highlights and lowlights and key findings.
  • Develop an action plan for moving forward with the project.

Deploying Microsoft Enterprise Desktop Virtualization
  MED-V deployment planning and requirements
  MED-V: Installing server and client components
  MED-V: Creating and deploying images, workspaces
  MED-V Workspace: Testing, deployment and management

Printed with permission from Wiley Publishing Inc. Copyright 2009. Mastering Microsoft Virtualization by Tim Cerling and Jeffrey Buller. For more information about this title and other similar books, please visit Wiley Publishing Inc.

Dig Deeper on Desktop virtualization technology and services

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.