Microsoft Enterprise Desktop Virtualization

The Planning and Design Series Approach

This guide is one in a series of planning and design guides that clarify and streamline the planning and design process for Microsoft® infrastructure technologies.

Each guide in the series addresses a unique infrastructure technology or scenario. These guides include the following topics:

  • Defining the technical decision flow (flow chart) through the planning process.
  • Describing the decisions to be made and the commonly available options to consider in making the decisions.
  • Relating the decisions and options to the business in terms of cost, complexity, and other characteristics.
  • Framing the decision in terms of additional questions to the business to ensure a comprehensive understanding of the appropriate business landscape.

The guides in this series are intended to complement and augment the product documentation.

Benefits of Using This Guide

Using this guide will help an organization to plan the best architecture for the business and to deliver the most cost-effective Microsoft Enterprise Desktop Virtualization infrastructure.

Benefits for Business Stakeholders/Decision Makers:

  • Most cost-effective design solution for an implementation. Infrastructure Planning and Design (IPD) eliminates over-architecting and overspending by precisely matching the technology solution to the business needs.
  • Alignment between the business and IT from the beginning of the design process to the end.

Benefits for Infrastructure Stakeholders/Decision Makers:

  • Authoritative guidance. Microsoft is the best source for guidance about the design of Microsoft products.
  • Business validation questions to ensure the solution meets the requirements of both business and infrastructure stakeholders.
  • High integrity design criteria that includes product limitations.
  • Fault-tolerant infrastructure, where necessary.
  • Proportionate system and network availability to meet business requirements.
  • Infrastructure that is sized appropriately to meet business requirements.

Benefits for Consultants or Partners:

  • Rapid readiness for consulting engagements.
  • Planning and design template to standardize design and peer reviews.
  • A "leave-behind" for pre- and post-sales visits to customer sites.
  • General classroom instruction/preparation.

Benefits for the Entire Organization:

Using this guide should result in a design that will be sized, configured, and appropriately placed to deliver a solution for achieving stated business requirements, while considering the performance, capacity, manageability, and fault tolerance of the system.

Introduction to the Microsoft Enterprise Desktop Virtualization Guide

Microsoft Enterprise Desktop Virtualization (MED-V) enables enterprises to realize the benefits of the latest client operating systems by providing a managed environment for legacy applications. MED-V enables administrative control over the distribution and management of Virtual PC images, thereby ensuring that those images are up to date and compliant with regulations.

This guide leads the reader through the process of planning and designing a MED-V infrastructure. The guide addresses the following fundamental decisions and tasks:

  • Identifying the MED-V server resources that are required.
  • Designing the components, layout, and connectivity of the MED-V server infrastructure.
  • Designing the MED-V image repositories.

Business objectives should be prioritized at the start of the project so that they are clearly understood and agreed on by IT and business managers.

Following this guide will result in a design that is sized, configured, and appropriately placed to deliver the stated business benefits, while considering the user experience, security, manageability, performance, capacity, and fault tolerance of the system.

The guide addresses the scenarios most likely to be encountered by someone designing a MED-V infrastructure. Customers should consider having their architecture reviewed by Microsoft Customer Service and Support or a Microsoft certified partner prior to implementation as these organizations are best able to comment on the supportability of a particular design.

Assumptions

To limit the scope of material in this guide, the following assumptions have been made:

  • The design being created is for MED-V version 1.0.
  • Microsoft Active Directory® Domain Services (AD DS) is already designed. For assistance in designing AD DS, see the Infrastructure Planning and Design Guide for Windows Server 2008 and Windows Server 2008 R2 Active Directory Domain Services at http://go.microsoft.com/fwlink/?LinkId=157704.
  • Software prerequisites for the relevant features have been met.

Additional Reading

MED-V product website: www.microsoft.com/windows/enterprise/products/med-v.aspx

Microsoft Enterprise Desktop Virtualization Design Process

This guide addresses the following decisions and activities that must occur in planning the design for Microsoft Enterprise Desktop Virtualization (MED-V). The four steps that follow represent the most critical design elements in a well-planned MED-V design.

  • Step 1: Define the Project Scope
  • Step 2: Determine the Number of MED-V Instances Required
  • Step 3: Design the Server Infrastructure
  • Step 4: Design the Image Repositories

Some of these items represent decisions that must be made. Where this is the case, a corresponding list of common response options will be presented.

Other items in this list represent tasks that must be carried out. These types of items are addressed because their presence is significant in order to complete the infrastructure design.

Figure 1 provides a graphical overview of the steps in designing a MED-V infrastructure.

Figure 1. The MED-V infrastructure decision flow

Figure 2 illustrates the relationship between the components that can work together to deliver a MED-V solution.

Figure 2. Example MED-V architecture

The components can be designed in many different ways. Figure 2 shows the components in one implementation for illustrative purposes only.

Information Collection

The following information is required for designing a MED-V infrastructure:

  • The user population that will be provided with virtual machine images managed by MED-V.
  • A network infrastructure diagram that shows the user locations and the available bandwidth to those locations.
  • The virtual machine images that will be delivered by MED-V.
  • The organization's service level expectations:
    • The acceptable time for a new image to load in the MED-V Client.
    • The time window within which critical updates must be deployed.
    • The expected availability and response time for MED-V reporting.

Applicable Scenarios

This guide addresses the following consideration related to planning and designing the necessary components for a successful MED-V infrastructure:

  • Migration of legacy applications to Windows® 7.

Out of Scope

This guide does not address the following:

  • Virtual PC design.
  • Design of images for Virtual PC 2007.

Step 1: Define the Project Scope

In Step 1, the project scope will be defined in order to align the goals of the project with the business motivation. The user population and the virtual machines that will be managed by Microsoft Enterprise Desktop Virtualization (MED-V) will be identified for inclusion in the project. Then the organization's service level expectations will be documented so that an infrastructure can be designed that best fulfills those expectations.

Task 1: Define the User Population to Be Managed

Identification of the population of end users that will be provided with virtual machine images managed by MED-V will in turn determine the location of the MED-V Client installations, the number of MED-V instances in Step 2, and the number and placement of MED-V repositories in Step 4.

Use Table A-1 in Appendix A: "Job Aids" to record the following user population information:

  • Where are the users located? This information will be used to determine the method of distributing images and placement of repositories in Step 4. Record the name of each location and the number of users in it.
  • How are the user locations connected? Obtain a network infrastructure diagram that shows the user locations and the available bandwidth to those locations. This will be used to determine the location of repositories in Step 4. Record the available bandwidth to each of the locations.
  • Will users travel between locations? If yes, this may require the design of additional capacity in the server infrastructure in Step 3 and repositories in Step 4. It may also increase the required bandwidth to these locations. Add the number of traveling users to each of the locations to which they may travel, and record the maximum number of users that could be in the location in Table A-1 in Appendix A. Note that traveling users may appear in multiple locations.

Task 2: Determine Which Virtual Machines Will Be Managed by MED-V

Now that the user population has been defined, determine which virtual machines will be managed by MED-V for the users in each location. This will be used to design the method of distributing images and placement of repositories in Step 4. Record the names of the virtual machines that will be provided to each user location in Table A-1 in Appendix A.

Next, document whether those users will be permitted to work in the virtual machine images while in offline mode. The implications of offline mode are explained in Appendix B: "Offline Mode and MED-V Clients" in this guide. MED-V does not include a standard capability for fault-tolerant MED-V server configuration. MED-V can be manually configured in cluster mode; this is explained in "Configuring MED-V Server for Cluster Mode" at http://technet.microsoft.com/en-us/library/ff433584.aspx.

Therefore, if users cannot work offline, they will be unable to continue working in the event of a MED-V server failure, even if the MED-V workspace has already been started on the client.

Record the location of users permitted to work in offline mode in Table A-1 in Appendix A. This information will be used in Step 3 to determine whether a backup server should be manually configured.

If any of the virtual machines are already stored in a centralized library, determine the location of that library so that it may be evaluated in Step 4 for use as a MED-V repository. Record this information in Table A-1 in Appendix A.

Task 3: Determine the Organization's Service Level Expectations

For each MED-V workspace, document the acceptable time for a new image to load when a client requires it and the window for critical updates to be deployed. These will be used to determine the performance and fault-tolerance requirements for the MED-V server and database in Step 3 and the image repository in Step 4.

If applicable, record the service level expectations for MED-V reporting in the "Acceptable response time for reports" column in Table A-1 in Appendix A so that this information can be used in Step 3 in the design of the server infrastructure.

Validating with the Business

To ensure that there is a complete understanding of how the planned infrastructure affects the business, ask business stakeholders and application owners the following questions when deciding on which part of the infrastructure to implement MED-V:

  • Are there any images that can be combined? For example, Application A on Windows XP is one Virtual PC image, and Application B on Windows XP is another Virtual PC image. Could a single Virtual PC image be created with both Applications A and B? Combining the Virtual PC images allows users to work in both applications A and B at the same time, thereby reducing the repository space and the bandwidth required for image download.
  • Are the in-scope applications licensable and supportable if delivered in a virtual machine by MED-V? Check with the application supplier to ensure that licensing and support terms will not be violated by delivering the application through MED-V.

Step Summary

In Step 1, the project scope was defined, and the following Step 1 outputs were recorded in Table A-1 in Appendix A:

  • The characteristics of the user population of MED-V.
  • Which virtual machines will be managed by MED-V.
  • The organization's service level expectations.

Step 2: Determine the Number of MED-V Instances Required

In Step 1, the project scope was defined in order to align the goals of the project with the business motivation. The user population and the virtual machines that will be managed by MED-V were identified for inclusion in the project. Finally, the organization's service level expectations were documented to assist in the planning process. In this step, the number of MED-V instances will be determined so that the server infrastructure can be designed for each instance in the next step.

A MED-V instance includes the following:

  • The MED-V server and the workspaces that it stores, including AD DS permissions.
  • A SQL Server® database that stores client events. The database may be shared with other MED-V instances.
  • The image repository for the packed virtual machine images. This repository may be shared with other MED-V instances.
  • The Management Console to create and pack images and to create workspaces. The console cannot be shared with other MED-V instances, but it can be disconnected from one MED-V server and then connected to a different MED-V server.
  • MED-V Clients that receive workspaces, and authorization to use them, from the server.

Separate MED-V instances cannot be integrated or share workspaces. Therefore, each additional instance decentralizes the virtualization management. Task 1 provides scenarios for determining when additional MED-V instances are required and their number.

Task 1: Determine the Number of MED-V Instances Required

In this task, the number of MED-V instances will be determined and the scope of each instance defined so that the design of the server infrastructure for each instance can be completed in the next step.

Begin the planning process with one MED-V instance, and then scale out by adding more instances if any of the following conditions apply:

  • Number of supported users. Each MED-V instance can support up to 5,000 concurrently active clients. Concurrently active means being online to the MED-V server and sending polls to the server for policy and image updates, as well as events. If there will be more than 5,000 active users, add one instance to the design for each 5,000 users.
  • Users in untrusted domains. The MED-V server associates workspace permissions with AD DS users and/or groups. This requires MED-V users to be within the trust boundary of the MED-V server. Add one MED-V instance to the design for each group of MED-V users that is in a separate, untrusted domain.
  • Clients in isolated networks. Determine if any clients reside in networks that are isolated and therefore require a separate MED-V instance. For example, organizations often isolate lab networks from production networks. Add a MED-V instance to the design for each isolated network that will contain MED-V Clients.
  • Organizational requirements. The organization may require that a group of clients be managed by a separate MED-V instance for security reasons, such as when sensitive applications are delivered only to a restricted set of users within a domain. For example, the payroll department may wish to deny users from other departments access to the MED-V instance that stores policy for payroll processing. Additionally, if the organization uses a distributed management model, a separate MED-V instance will be required for each business group having MED-V Clients in order to enable the group to manage its own virtualized environment. Add one MED-V instance to the design for each separate organizational requirement.
  • Legal considerations. National security or privacy issues and fiduciary laws could require the separation of certain data or prevent other data from crossing national borders. Design additional MED-V instances to address this need, if necessary.

Record a name for each MED-V instance, and the reason for designing it, in Table A-2: "Server Data" in Appendix A. This information will be used in Step 3 to determine the scope of each instance and determine the design of the server infrastructure for that instance.

Step Summary

In Step 2, the required number of MED-V instances was determined, and the following Step 2 outputs were recorded in Table A-2 in Appendix A:

  • The name of each MED-V instance.
  • The reason for designing each MED-V instance.

Step 3: Design the Server Infrastructure

In the previous step, the number of MED-V instances required by the organization was determined. In this step, the server infrastructure will be designed for each MED-V instance. This includes determining whether the SQL Server instance will exist on the MED-V server or on a remote server, as well as the size of the SQL Server database. The location of the Management Console will also be determined. Repeat the tasks in this step for each MED-V instance in the design.

Task 1: Design and Place the Server for Each MED-V Instance

The MED-V server implements policy and stores state and history data about its clients. It performs the following functions:

  • Stores workspace policy when created or changed in the MED-V Management Console.
  • Receives an authentication request from each MED-V Client when the MED-V Client starts a workspace.
  • Queries AD DS to authenticate the client for the workspace.
  • Receives policy update polls from clients, and may deliver changed workspaces to those clients.
  • Receives image update polls from clients, by default every 4 hours, and redirects them to the image download location, if appropriate.
  • Receives events from clients and stores them in the database. Events do not flow immediately; they are queued on the client, and then sent each minute.
  • Generates reports on demand for the MED-V Management Console.

Form Factor

The MED-V product group recommends using at least a 2.8-gigahertz (GHz) dual core CPU server with 2 gigabytes (GB) of RAM. The recommendation assumes that the MED-V server will run on a dedicated machine and that SQL Server and the MED-V Management Console will run on separate machines.

Given this workload, the MED-V server should be relatively lightly loaded. So in the absence of specific architectural guidance on the server form factor, design the server using the product group recommendation above, with memory that matches the organization's standard form factor. The MED-V server can be run in a virtual machine on both Windows Server® 2008 and Windows Server 2008 R2 Hyper-V®. If a virtual machine will be used, ensure that it has access to CPU and memory resources equivalent to those specified for a physical machine.

The disk capacity required by the MED-V server must be sufficient to store the workspace configuration files. A workspace can use only one virtual machine, and one policy definition, for one or more users. So the number of workspaces that must be stored will depend on the degree to which different policies are required for different users of the same virtual machine, as well as the number of virtual machines that will be used. The workspace XML files are around 30 kilobytes (KB) in size for a typical workspace. To determine the required disk capacity, multiply 30 KB by the number of workspaces that the MED-V server will store.

The MED-V server's most important network connections are the links to its clients, so place the server in a network location that provides the most available bandwidth and the most robust links to its clients.

Record the form factor and location of the MED-V server, add it to the design, and record it in Table A-2 in Appendix A.

Fault Tolerance

There can be only one active MED-V server in a MED-V instance, and MED-V does not include standard capabilities to place the server in an MSCS cluster to provide fault tolerance. MED-V can be manually configured in cluster mode; this is explained in "Configuring MED-V Server for Cluster Mode" at http://technet.microsoft.com/en-us/library/ff433584.aspx.

Refer to Table A-1 in Appendix A to confirm whether users will be permitted to work in offline mode. The implications of offline mode are explained in Appendix B. If users are not allowed to work offline, they will be unable to continue working in the event of a MED-V server failure, even if the MED-V workspace has already been started on the client. In that case, policy polls and events will be held on the client until the server can be contacted.

If offline work is permitted, for each workspace, determine how long the client is allowed to work offline before it must authenticate. This is the maximum time that the server can be unavailable.

Use this information to determine whether a passive backup server should be manually configured for the MED-V instance. If so, add it to the design, and record it in Table A-2 in Appendix A.

Task 2: Design and Place the SQL Server Database

In this task, the SQL Server database will be designed and placed. The SQL Server database is used by the MED-V server to store client status and events. The SQL Server database can be on the same machine as the MED-V server, or it can be on a separate server running SQL Server, which can be remote. The database can be shared with other MED-V instances, in which case events and alerts from those instances will be stored in the same database, and reports will include events and alerts from all instances. The database can be installed in an existing SQL Server instance, and the databases of other MED-V servers can reside in that same instance.

If the database server is placed in a location that is remote from the MED-V server, across network links that do not have sufficient bandwidth available, reports may be slow to load in the console and may not display the latest data from clients. Refer to the organization's service level expectations that were determined in Step 1, and use that information to decide where to place the SQL Server database. Record the database location decision in Table A-2 in Appendix A.

Form Factor

If SQL Server will be run on the same server as MED-V, and if SQL Server will only be used to store data for that server, start with the product group recommendation for the MED-V server, as stated in Task 1, and add resources for the SQL Server load.

No guidance is available from the MED-V product group for selecting the SQL Server form factor. If SQL Server will store events and alerts from more than one MED-V instance, refer to the Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and SQL Server 2008 R2, available at http://go.microsoft.com/fwlink/?LinkId=163302, for information on how to scale up the server form factor.

The size of the database depends on the number of client events that the database is required to store. Events are created by normal operation of the client, such as when a workspace is started, or by an error in the workspace. The default interval at which events are sent by a client is 1 minute.

To estimate the size of the database, determine:

  • Number of clients in the MED-V instance. The maximum is 5,000.
  • Typical event arrival rate. This will depend on client usage behavior, but it will be approximately 15–20 events per day per client.
  • Event size. Typically, this is around 200 bytes.
  • Storage amount. How many days' events will be stored in the database before those events are cleared by the MED-V administrator?

Multiply these values together to calculate the size of the required data storage in bytes, and then add a safety factor to account for:

  • Errors, which could create a large number of events from a client in a short time.
  • Database table and organizational space.

Record the size of the database in Table A-2 in Appendix A.

No data is available on the performance requirements of the database server. However, to arrive at an approximation of the IOPS (IOs per second) requirement, use the values above, multiplying the typical event arrival rate by the number of clients in the instance. This will yield the number of records that can be written per day. Now divide that number by 86,400 to derive the number of records that will be written per second. If a write operation can be equated to a single IO operation, which is likely the case, this number is the write IOPS required. Add a buffer to that for reporting activity, which will be primarily read IO. This is difficult to determine, but it will depend on the number of consoles in use with the instance and the frequency with which they are used to generate reports.

Fault Tolerance

If the server running SQL Server is unavailable, events will become backed up on the clients, and reports will not be available in the Management Console. Refer to the organization's service level expectations determined in Step 1 to decide whether the design of a fault-tolerant SQL Server infrastructure is necessary.

MED-V does not provide support for running SQL Server in an MSCS cluster. SQL Server can be placed in a log shipping configuration in order to provide warm standby and to avoid data loss in the event of a failure. Refer to the Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and SQL Server 2008 R2, available at http://go.microsoft.com/fwlink/?LinkId=163302, for information on log shipping. Record the decision in Table A-2 in Appendix A.

Task 3: Design the Management Console

In this task, the MED-V Management Console should be designed with a form factor that resembles, as closely as possible, the form factor of a typical MED-V Client machine. This is because the Management Console will be used to test virtual machines before they are packed for distribution to MED-V Clients.

The Management Console is a stand-alone application. It performs three functions:

  • Prepares and tests virtual machines.
  • Creates and configures workspaces.
  • Displays reports.

The Management Console application is installed together with the MED-V Client and uses Microsoft Virtual PC 2007 SP1 with KB958162 to prepare and test the virtual machines, so a client operating system must be used; the MED-V Management Console cannot run on the same system as the MED-V server.

A Management Console cannot be shared between MED-V server instances. The address of the MED-V server is specified during the installation of the Management Console's MED-V Client; this can be changed after installation, but at any time the Management Console can only work with a single MED-V server.

More than one Management Console can be used with a given MED-V server. A mechanism is available that notifies other console users when one console has made changes to a workspace, so conflicts can be avoided.

For each MED-V instance, determine how many Management Consoles will be needed and where they will be placed, and then record this in Table A-2 in Appendix A.

Select a typical MED-V Client form factor to be used for the Management Console, and record that in Table A-2 in Appendix A.

Step Summary

In Step 3, the server infrastructure was designed, and the following Step 3 outputs were recorded in Table A-2 in Appendix A:

  • The form factor of the MED-V server.
  • The location of the MED-V server.
  • Whether a backup server will be manually configured.
  • The SQL Server database placement.
  • The size of the SQL Server database.
  • Whether the SQL Server infrastructure in the design should use log shipping.
  • The number of Management Consoles needed and the placement of those consoles.
  • Selection of a typical client form factor for the Management Console.

Additional Reading

  • Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and SQL Server 2008 R2: http://go.microsoft.com/fwlink/?LinkId=163302
  • Knowledge Base article 958162 "Description of the hotfix rollup package for Virtual PC 2007 Service Pack 1: February 20, 2009": http://support.microsoft.com/?id=958162

Step 4: Design the Image Repositories

In the previous step, the server infrastructure was designed for each MED-V instance. In this step, the repositories for MED-V images will be designed.

MED-V images are created and packed on the MED-V Management Console. They can then be stored on a file server in any location. The files may be served over HTTP/HTTPS by one or more Internet Information Services (IIS) servers. Serving the files directly from a file server is not supported. The image repository can be shared between MED-V instances.

The design of the image repositories includes determining the image distribution techniques that will be used for each location and whether that location will require a local image repository. Each repository is then designed and placed, along with its accompanying IIS servers.

Task 1: Determine How Images Will Be Distributed

In this task, it will be determined how the packed virtual machine images will be distributed to the clients that will use them. This decision must be made for each workspace that the client may run. The decision will then be used to decide how many repositories will be used to store the packed virtual machines, where those repositories will be placed, and then to design those repositories.

Packed virtual machines can be distributed in the following ways:

  • Pre-staged to an image store directory on the client machine, using a corporate software distribution tool such as Microsoft System Center Configuration Manager. This is supported for initial distribution of the image only; it cannot be used to distribute updates.
  • Downloaded over the network from an image distribution server, which comprises a file server and IIS server, when a client first loads a workspace. MED-V uses TrimTransfer technology to reduce the amount of data that must flow over the network from the file server to the client before the virtual machine can be loaded in the workspace. This implementation uses BITS (Background Intelligent Transfer Service) to throttle the distribution in order to minimize competition for bandwidth. As a result, there may be a long delay before the client can work in the virtual machine.
  • On removable media, such as a USB drive or DVD. Note that running the image from the removable media is not supported; instead, it must be copied to the image location on the client machine. The use of removable media requires a process to create and distribute the physical media. The client should be able to immediately begin working when a workspace that uses the virtual machine is loaded.
  • A combination of the above.

Refer to Table A-1 in Appendix A where the locations of MED-V Clients, and the available bandwidth to those locations, are documented. Using the information recorded in Table A-1 and the service level expectations for initial startup of a new image that was determined in Step 1, decide which of the above techniques will be used to distribute virtual machine images to each of the user locations.

For each client location, record in Table A-1 in Appendix A the image distribution techniques that will be used and whether that location will require a local image repository.

Task 2: Determine the Number of Image Repositories

The output of the previous task is the minimum number of repositories that will be required to service the clients' needs for all the MED-V instances. Add more repositories if any of the following criteria apply:

  • Organizational or regulatory reasons to separate the virtual machines. There may be reasons why some virtual machines cannot coexist in the same repository. For example, sensitive personal data may require storage on a server that is only available to a limited set of employees who have a need to access the data.
  • Clients in isolated networks. This only applies if image distribution will be over the network. Determine if any networks are isolated and require a separate repository. For example, organizations often isolate lab networks from production networks.
  • Clients in remote networks. This only applies if image distribution will be over the network. Some client machines may be separated from the repository by network links that do not have sufficient bandwidth available to provide an adequate experience when a client loads a workspace. If necessary, design additional MED-V instances to address this need.

Add these repositories to the design. Record a name for each repository and the reason for designing it in Table A-1 in Appendix A. Also record in Table A-1 which virtual machines the repository will hold and which MED-V Clients will load workspaces with images from the repository. This information will be used in the next task to design each repository.

Task 3: Design and Place the Image Repositories

This task must be repeated for each repository.

The maximum load on a repository occurs when a new version of an image is made available to clients and the clients are notified by a policy change. Multiple clients then start to download the image, possibly at the same time. The image repository must be designed to meet this demand.

Begin by determining how much data the repository will store. Total the sizes of the images that will be stored in the repository. Record this value as the disk space required on the file server in Table A-1 in Appendix A.

Next, total the number of clients that may download virtual machines from the repository. This will be the maximum number of concurrent downloads that can occur when a new virtual machine is loaded into the repository. The file server must be designed with a disk subsystem that can meet the IO demand this will create. Refer to the Infrastructure Planning and Design Guide for Windows Server 2008 and Windows Server 2008 R2 File Services, available at http://go.microsoft.com/fwlink/?LinkId=160976, to design the file server and its disk subsystem.

The image repository can reside on the same system as the MED-V server and the server running SQL Server, or it can be on a remote file share. It can also be run in a Windows Server 2008 Hyper-V virtual machine. Refer to the network location of the clients that the image repository will service, and place the repository in a network location where it will have sufficient bandwidth to meet the service level expectations of those clients that were determined in Step 1.

Fault Tolerance

If the image repository is unavailable, then clients will be unable to download new or updated virtual machine images. The image repository is either a Windows Server 2008 or Windows Server 2008 R2 File Server and, as such, it could be placed in a cluster, but that is not supported by MED-V. Refer to the Infrastructure Planning and Design Guide for Windows Server 2008 and Windows Server 2008 R2 File Services, available at http://go.microsoft.com/fwlink/?LinkId=160976, to design other fault-tolerance options for the file server and fault-tolerant disks. Record the design and location of each repository in Table A-1 in Appendix A.

Task 4: Design and Place the IIS Servers

This task must be performed for each image repository.

If clients will be downloading image files over the network using HTTP/HTTPS, proceed with this task to design the IIS server infrastructure; otherwise, skip to the "Step Summary" section.

The IIS server can coexist on the same system as the MED-V server and the server running SQL Server. It can also be run in a Windows Server 2008 or Windows Server 2008 R2 Hyper-V virtual machine. The IIS server infrastructure must have sufficient throughput to deliver images to clients within the service level expectations of the organization. It must be designed with a disk subsystem that can meet the IO demand this will create.

Total the number of clients that may download virtual machines using the IIS infrastructure. This will be the maximum number of concurrent downloads that can occur when a new virtual machine is loaded into the repository. Use the throughput sum and service level expectations from Step 1 to plan the design of the IIS server infrastructure and to determine the appropriate amount of bandwidth to allocate for the repository.

Refer to the Infrastructure Planning and Design Guide for Internet Information Services 7.0 and Internet Information Services 7.5, available at http://go.microsoft.com/fwlink/?LinkId=157703, to design the IIS server infrastructure.

Fault Tolerance

If the IIS server infrastructure is unavailable, then clients will be unable to download new or updated virtual machine images. The Windows Server 2008–based IIS server can be placed in a failover cluster in order to deliver a fault-tolerant configuration. Refer to the Infrastructure Planning and Design Guide for Internet Information Services 7.0 and Internet Information Services 7.5, available at http://go.microsoft.com/fwlink/?LinkId=157703, to design the fault tolerance for the IIS server infrastructure.

Record the design and placement of the IIS infrastructure for each repository in Table A-1 in Appendix A.

Step Summary

In Step 4, the image repositories were designed, and the following Step 4 outputs were recorded in Table A-1 in Appendix A:

  • For each client location, the image distribution technique that will be used and whether that location requires a local image repository.
  • A name for each repository, the reason for designing it, which virtual machines it will hold, and which MED-V Clients will load workspaces with images from the repository.
  • The number of image repositories required in each location.
  • The amount of data that each repository will store.
  • The design and placement of each repository.
  • The design and placement of the IIS server infrastructure.

Additional Reading

  • Infrastructure Planning and Design Guide for Internet Information Services 7.0 and Internet Information Services 7.5: http://go.microsoft.com/fwlink/?LinkId=157703
  • Infrastructure Planning and Design Guide for Windows Server 2008 and Windows Server 2008 R2 File Services: http://go.microsoft.com/fwlink/?LinkId=160976

Dependencies

Microsoft Virtual PC 2007 SP1 with KB958162.

Conclusion

This guide has outlined the step-by-step process for planning a Microsoft Enterprise Desktop Virtualization infrastructure. In each step, major decisions relative to the MED-V infrastructure were determined and explained.

The guide has explained how to define the project scope, how to determine the number of MED-V instances required, how to design the server infrastructure, and how to design the image repositories. Information was provided relative to scaling and fault tolerance, and job aids were provided to record all of the information that was necessary to plan the MED-V infrastructure.

Using the information recorded from the steps completed in this guide, the organization can help ensure that it meets business and technical requirements for a successful MED-V deployment.

Appendix A: Job Aids

Table A-1. Client Data

Step 1

Task 1

Task 2

Location name

Available bandwidth

Number of users

Maximum number of users

Names of virtual machines to be used in location

         
         
         
         

Table A-1. Client Data (Continued)

Step 1 (continued)

Task 2 (continued)

Task 3

Location of users permitted to work in offline mode

Existing library location

Acceptable initial load time for virtual machine

Acceptable deploy time for updates

Acceptable response time for reports

         
         
         
         

Table A-1. Client Data (Continued)

Step 4

Task 1

Task 2

Image distribution techniques

Local repository required (Y/N)

Number of additional repositories and reason added to design

Virtual machine names in repository

MED-V Clients that will load workspaces with images from repository

         
         
         
         

Table A-1. Client Data (Continued)

Step 4 (continued)

Task 3

Task 4

Design of repository

Location of repository

Disk space required

Design and placement of IIS servers

       
       
       
       

Table A-2. Server Data

Step 2

Step 3

Task 1

Task 1

Task 2

MED-V instance name

Reason for designing each MED-V instance

MED-V server form factor and location

Backup server form factor

SQL Server database location

         
         
         
         

Table A-2. Server Data (Continued)

Step 3 (continued)

Task 2 (continued)

Task 3

SQL Server database size

SQL Server log shipping

Number of Management Consoles

Location of Management Consoles

Management Consoles form factor

         
         
         
         

Appendix B: Offline Mode and MED-V Clients

MED-V Clients connect to the Management Server to receive policy and images, but they can optionally be permitted to run in offline mode. This switch is set per user and per MED-V image, and it works in the following way:

The MED-V Client attempts to contact the MED-V server:

  • At client startup, or at workspace startup, when the user supplies authentication credentials.
  • At the policy interval (by default every 15 minutes).

The client's online/offline status is set by whether it was able to contact the server at the most recent of the above:

  • If the client was able to contact the server, the client is online.
  • If the client was not able to contact the server, the client is offline.

Through configuration, the MED-V administrator can prevent offline operation. For example, the administrator can configure a workspace so that user A cannot work offline in image Z. In this case, if the server becomes unavailable:

  • User A will be unable to load image Z.
  • If user A had previously loaded image Z, at a time when the server was available, the MED-V Client will force a shutdown of that image.

By requiring the user to be in online mode in order to load and use a virtual machine, the IT department can implement full control over the use of the virtual machine images. However, this must be balanced with the needs and convenience of users to get their work done.

Appendix C: IPD in Microsoft Operations Framework 4.0

Microsoft Operations Framework (MOF) offers integrated best practices, principles, and activities to assist an organization in achieving reliable solutions and services. MOF provides guidance to help individuals and organizations create, operate, and support technology services, while helping to ensure the investment in technology delivers expected business value at an acceptable level of risk. MOF's question-based guidance helps to determine what is needed for an organization now, as well as providing activities that will keep the organization running efficiently and effectively in the future.

Use MOF with IPD guides to ensure that people and process considerations are addressed when changes to an organization's technology services are being planned.

  • Use the Plan Phase to maintain focus on meeting business needs, consider business requirements and constraints, and align business strategy with the technology strategy. IPD helps to define an architecture that delivers the right solution as determined in the Plan Phase.
  • Use the Deliver Phase to build solutions and deploy updated technology. In this phase, IPD helps IT pros design their technology infrastructures.
  • Use the Operate Phase to plan for operations, service monitoring and control, as well as troubleshooting. The appropriate infrastructure, built with the help of IPD guides, can increase the efficiency and effectiveness of operating activities.
  • Use the Manage Layer to work effectively and efficiently to make decisions that are in compliance with management objectives. The full value of sound architectural practices embodied in IPD will help deliver value to the top levels of a business.

Figure C-1. The architecture of Microsoft Operations Framework (MOF) 4.0

Appendix D: Enterprise Desktop Virtualization in Microsoft Infrastructure Optimization

The Infrastructure Optimization (IO) Model at Microsoft groups IT processes and technologies across a continuum of organizational maturity. (For more information, see www.microsoft.com/optimization/model/coreio.mspx.) The model was developed by industry analysts, the Massachusetts Institute of Technology (MIT) Center for Information Systems Research (CISR), and Microsoft's own experiences with its enterprise customers. A key goal for Microsoft in creating the Infrastructure Optimization Model was to develop a simple way to use a maturity framework that is flexible and can easily be applied as the benchmark for technical capability and business value.

IO is structured around three information technology models: Core Infrastructure Optimization, Application Platform Optimization, and Business Productivity Infrastructure Optimization. According to the Core Infrastructure Optimization Model, implementing administrator-controlled, automated virtual machine image distribution and management will help move an organization to the Rationalized level.

Figure D-1. Mapping of MED-V technology into the Core Infrastructure Optimization Model