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:
The guides in this series are intended to complement and augment the product documentation.
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:
Benefits for Infrastructure Stakeholders/Decision Makers:
Benefits for Consultants or Partners:
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.
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:
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.
To limit the scope of material in this guide, the following assumptions have been made:
MED-V product website: www.microsoft.com/windows/enterprise/products/med-v.aspx
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.
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.
The following information is required for designing a MED-V infrastructure:
This guide addresses the following consideration related to planning and designing the necessary components for a successful MED-V infrastructure:
This guide does not address the following:
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.
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:
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.
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.
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:
In Step 1, the project scope was defined, and the following Step 1 outputs were recorded in Table A-1 in Appendix A:
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:
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.
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:
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.
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:
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.
The MED-V server implements policy and stores state and history data about its clients. It performs the following functions:
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.
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.
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.
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:
Multiply these values together to calculate the size of the required data storage in bytes, and then add a safety factor to account for:
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.
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.
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:
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.
In Step 3, the server infrastructure was designed, and the following Step 3 outputs were recorded in Table A-2 in Appendix A:
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.
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:
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.
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:
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.
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.
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.
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.
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.
In Step 4, the image repositories were designed, and the following Step 4 outputs were recorded in Table A-1 in Appendix A:
Microsoft Virtual PC 2007 SP1 with KB958162.
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.
Table A-1. Client Data
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)
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)
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)
Design of repository
Location of repository
Disk space required
Design and placement of IIS servers
Table A-2. Server Data
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)
SQL Server database size
SQL Server log shipping
Number of Management Consoles
Location of Management Consoles
Management Consoles form factor
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:
The client's online/offline status is set by whether it was able to contact the server at the most recent of the above:
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:
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.
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.
Figure C-1. The architecture of Microsoft Operations Framework (MOF) 4.0
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