Solution provider's takeaway: This chapter excerpt offers the steps necessary to implement application or desktop virtualization in your customer's Windows 7 environment. Check out the requirements and methods to consider.
Many Forms of Virtualization
Windows 7 can support many different methods of virtualization and leverage them in combinations to meet the deployment needs for yourself or your business. We will next look at some of these methods to give you an idea of what can be accomplished.
Using Windows 7 in combination with Windows Server 2008 and Hyper-V and the System Center Suite can provide your enterprise with a very flexible and robust environment to provide your users with the desktop they require. This can start with the very desktop itself to access to applications or a completely hosted desktop. The key to this is a new licensing model that Microsoft has developed. The Virtual Enterprise Centralized Desktop (VECD) license is the Windows 7 license that allows virtualization of Windows desktops.
VECD Licensing Is a Challenge
The VECD license is the Windows 7 license that allows virtualization. Traditionally, a user only accessed one desktop at a time on a single specific device. When a new desktop device was installed, it typically required a new Windows license. If it relocated an existing license, the previous desktop was taken out of service. With virtualization, this is not the typical use case anymore.
The VECD allows a business to run a copy of Windows 7 in a data center that may provision multiple desktops across several servers in production and for disaster recovery.
A VECD license allows the following:
- The ability to run a copy of Windows in a data center – This is required for dynamic provisioning and creating deployment images of Windows 7 for use by your users.
- Rights to move virtual machines between servers for increased reliability – With load balancing and disaster recovery, even a virtual desktop may run on several servers in a data center or even multiple data centers. Each instance of Windows 7 would normally need to be licensed, but with the VECD, only the active instance would need to be licensed.
- Unlimited backup of virtual machines – This is especially important for distributed disaster-recovery sites. Many companies will back up desktops to multiple disaster-recovery sites for rapid recovery if any one location becomes unavailable. This is different from the normal backup to tape or even a removable disk for desktops. It is not uncommon for servers to maintain a continuous data-protection model, but more frequently desktops now fit the category of a critical system.
- Ability to access up to four running VM instances per device – Traditionally, all users needed their own license for a desktop. The VECD will allow the same desktop device to access up to four running virtual machines. We have already loaded Windows XP Mode on our Windows 7 desktop. That is a running virtual machine. You are good for three more. This is possible because we also loaded Virtual PC. You could create a complete data center on just your desktop. You may need to license the other three operating systems but not the connections.
- Rights to access corporate desktops from home for a user that has already been licensed at work – If a user normally accesses a virtual machine running Windows 7 at work, they are allowed to access the same virtual desktop from home without requiring an additional license.
- Availability to volume licensing keys, such as Key Management Service (KMS) and Multiple Activation Keys (MAK) – This feature allows the enterprise to use the KMS system in Windows Server 2008 to activate and authorize Windows 7 desktops locally without the need to connect to the Internet or contact Microsoft individually.
The key to the VECD license is the desktops must be covered under Microsoft's Software Assurance (SA). This is a requirement to even purchase the VECD license. This can save a great deal on the cost of the upgrade and support of the Windows 7 environment. For example,
- Your company has 100 laptops and desktops.
- Your company has 100 thin clients.
- If the laptops do not have SA, you would need 200 VECD licenses (100 thin clients and 100 laptops).
- If the laptops have SA, you would need 100 VECD licenses (100 laptops). You would need to maintain the SA on each of the laptops.
The details and specifics of your exact solution is beyond the scope of this book. You are encouraged to download the latest version of the Virtual Desktop Infrastructure (VDI) licensing brochure at www.microsoft.com/ windows/enterprise/solutions/virtualization/licensing.aspx or contact your Microsoft Licensing Specialist.
As you can see from our simple example, you could save a significant amount on your licensing costs if you decide to leverage virtualization in your business. Although it is a bit tricky at first look, it is worth spending a few minutes discussing the benefits and requirements with your licensing provider.
VDI or Centralized Virtual Desktops
VDI is an alternative desktop deployment model for Windows 7. Instead of running a local copy on each user's desktop, a common image is created and stored on one or more servers in the data center. This image is deployed to a server running a hypervisor.
What is a Hypervisor?
A hypervisor is a layer of software that allows for the running of several operating systems simultaneously on a common computer while maintaining isolation between the different operating systems. Windows Server 2008 has a hypervisor know as Hyper-V. There are also several other hypervisors such as VMware vSphere and Citrix XenServer.
There are several benefits to implementing a VDI infrastructure:
- A common supported desktop environment can be rapidly deployed across your by creating a single Windows 7 desktop image and using that image to deploy virtual machines on your server hypervisor. A single server can support many virtual desktops. Each of these Desktops reacts as a stand-alone Windows 7 desktop. Unlike using Remote Desktop Services (RDS), the users connecting to a virtual desktop can have full access to all features of that virtual machine without impacting the other virtual desktops or the host server. Your users could still use the Remote Desktop Client to connect to their virtual desktop.
- Updates and changes to Windows 7 can be done in a centralized fashion by updating the Windows 7 desktop image and then redeploying the updated image to all your users. When they log on the next time, they will have the updated image and all the rest of their settings will be maintained.
- If a problem with an update requires a rollback to a previous version of the desktop image, it can be quickly done. Saving a copy of the previous image before performing the update allows for a roll back by redeploying the previous image and having users to log off and then log back on to receive the previous image.
Figure 9.37 shows a sample VDI design.
Figure 9.37: Sample VDI Design
There are some barriers to implementing a VDI. The start-up costs can be high, and the return on investment is longer than it is on a server virtualization project. This is a business decision that should not be taken lightly but instead planned and budgeted before embarking on the project. Some specific areas that need to be considered are as follows:
- VDI may not reduce desktop costs because any saving is typically redirected into server, network, and storage infrastructure. Improvements in desktop management and user management are required to support large numbers of virtual desktops. Applying Group Policies through Active Directory to redirect user folders and implementing roaming profiles will increase the flexibility of a VDI design. VDI should be considered when desktop flexibility is more important than immediate cost savings.
- A user connected to a virtual desktop requires a constant connection to the network. Whether this is through a Local Area Network or across a Wide Area Network (WAN) or a remote connection, the user must be connected to the virtual desktop to be productive. If a user must be able to operate in a disconnected environment, VDI is not a suitable solution for them. If your users are not mobile or only work when they are connected to the network, then this could be a viable solution.
- Planning your VDI deployment is critical to the success of the project because it can be a complex and an investment in infrastructure. Defining which users will benefit the most and the needed virtualization components to deploy is crucial for success.
Distributed Virtual Desktops
A distributed desktop model allows for different desktop images to be deployed to a specific group of users based on their location or user group. This model can be useful if you have a number of different types of users in a single location or you have users in a variety of locations like a branch office. Each group has a different desktop requirement or is connected by a slow or intermittent link. The remote users may have a file server that stores their files and information. Figure 9.38 shows a distributed virtual desktop to a branch office.
Another distributed desktop design may include setting up a Pre-eXecution Environment. This method allows an administrator to deploy an image to a server and a desktop to download and boot that image at start up. Several desktop images can be developed and assigned to a desktop. When the desktop is started, the image is streamed to the device as it starts up. Changing a desktop image is as simple as reconfiguring the device's target image
Figure 9.38: Distributed Desktops to a Branch Office
and restarting the desktop. This is a viable design if applications must be run from the local desktop. Some applications require a hardware dongle or a specific Media Access Control address for licensing. Applications that require special graphics or additional cards or adapters not supported in a virtual environment are also good candidates for this type of deployment.
The drawbacks and benefits are as follows:
- The individual images must be loaded with any applications or drivers required for the individual desktop computers. Unless all the desktops are identical, you may need to add the different drivers for each type of hardware the image is being prepared to run on.
- A different image can be configured to load on a desktop as a shift changes or new updates are configured. This is particularly useful because a new image is loaded each time the desktop is rebooted. Viruses and malware are limited in their effectiveness because the entire desktop image is reloaded each time the desktop is reloaded.
- This model is best used with a local server that holds the desktop images. Loading a desktop image over a WAN is a slow process that will discourage the remote users from rebooting their desktops. In this scenario, you should look at using either a local VDI or a distributed VDI solution.
Desktops can also be distributed using Microsoft System Center Configuration Manager (SCCM). This product is part of the System Center Suite and can be used to distribute both applications and desktops to user's desktops, both local and remote. This model will actually install the desktop operating system on the targeted desktop. This is a fairly complex product, and planning and testing of the solution is required for optimum success. You can also use this management solution in conjunction with another System Center Suite component, the Virtual Machine Manager 2008, to create, deploy, and manage desktops in a distributed environment.
Remember, when it comes to deploying a user's desktop, there are several options and one design rarely fits all situations. You can see for the different scenarios that a combination of all options can be leveraged to meet the specific needs of your situation.
Application virtualization can mean many different things when talking about Windows 7 and Windows Server 2008. We have already used one type with Windows XP Mode when we loaded and ran an application that would not normally run on Windows 7. Although this is an easy answer to application virtualization, there are more advanced solutions.
Remote Desktop Services
RDS (formerly Terminal Services) is the most commonly used method of application virtualization. This method presents applications to connected users. The application actually runs in a session on the server in the data center while it appears to be running on the local desktop. This is a cost effective and reliable method of deploying applications to an enterprise. Figure 9.39 shows a simplified diagram of how RDS works.Users, whether local or remote, all connect to the RDS server. The application is displayed to the end user while being executed on the RDS server. This gives equal performance to both local and remote users running the application. When the applications need to be upgraded or patched, they are patched only on the RDS servers. When the users next connect and run the application, they receive the updated version. The RDS server is capable
Figure 9.39: Remote Desktop Services
of supporting multiple users on a single server, and there are many new enhancements in RDS with Windows Server 7 that allow for a variety of connection methods. Web Services, Session Broker, and Network Load Balancing all work together to provide a seamless application virtualization environment for most users.
If your users do not want to connect to a server or a Web page to run their applications, there is a new feature in Windows Server 2008 RDS called RemoteApp. A published application can be converted to a RemoteApp and generate a Windows Installer File (MSI) that can be deployed through Active Directory, file download, e-mail, or your SCCM environment to all the targeted users. When installed on your Windows 7 desktop, double-clicking on it will launch the application just like it is installed on the end-user desktop. The connection to the RDS server is automatically established and the application is started. The RemoteApp can add items to the desktop Start menu or desktop icon just like a locally installed application.
Using the advanced features of the Remote Desktop Client in Windows 7 allows for mapping of resources to the RDS server, so files and printers can be shared when a user connects. The advanced features also can authenticate a user before a user session is created to relieve the extra burden on the RDS server and allow for more connections and better performance. The drawback to this solution is the fact that a user must be able to connect to the RDS server in some fashion to be able to run an application.
App-V (formerly SoftGrid) is a method of application distribution that allows the application to be executed on the local desktop without actually installing the application on the individual desktop. Instead, it is streamed to the desktop as the different features of the application are required. This offers a method of running applications in a disconnected mode and allows applications to run in an isolated environment, so they don't conflict with each other. Figure 9.40 shows this basic design.
When an application is installed on the App-V server, it is sequenced, so the most common program modules are loaded first. The purpose of this sequencing is to allow the application to open faster and to allow the user to begin using the application even before all of it is loaded on the desktop. Because of the sequencing of the applications when the application is
Figure 9.40: App-V Design
requested, the server sends the most common modules first or streams the application to the desktop. As more modules are requested by the desktop, they are streamed to that desktop. The application is actually processed on the desktop and not on the server.
The benefit of this design is that each application runs in a separate memory space. Applications that normally conflict with other applications can be configured to run on the same desktop without problems. These application streams can be directed to individual desktops, virtual desktops, or even RDS server sessions.
If a user needs to run an application in a disconnected mode, the application can be checked out for a specific amount of time. The entire application will be streamed to the desktop and will be available to the user even if the desktop become disconnected from the network. An example of this is laptop users. The user needs to download the application and then disconnect from the network to travel. When the application is started in a disconnected mode, it performs exactly the same as when connected to a network. Files and documents can be updated or created as needed. When the user reconnects to the network, the files are synchronized to the file servers and the application is either checked back in or the ticket can be renewed for the next trip. If the application has been updated since the initial check out, the new version is streamed to the laptop. Because this checkout process is similar to checking a book out of the library, there is a time limit on the application. This time limit is configured by the administrator. If the laptop is lost or stolen, the application will time out and become unusable. This helps protect you and your company from losing expensive software when the laptop is removed from the environment.
User Session Virtualization
User session virtualization is a newer version of desktop virtualization that works at the operating system level. While normal virtualization of the desktop allows an operating system to be run by virtualizing the hardware of the desktop, RDS and App-V allow for the virtualization of the applications. User session virtualization lies between the two.
A desktop has an operating system loaded on the base hardware. This can be either physical or virtual. The user session virtualization keeps track of all changes to the operating system that a user might make by encapsulating the configuration changes and associating them to the user account. This allows the specific changes to be applied to the underlying operating system without actually changing it. This allows several users to have completely different operating system configurations applied to a base operating system installation.
The most common example of user session virtualization is leveraging folder redirection and roaming profiles with Windows Server 2008. Applying these settings in Group Policies allows for a basic operating system to be loaded on several desktops, and a user can have the same experience and find all their files regardless of the specific desktop they choose to use. Although these settings are commonly used in an RDS environment, it can be just as easily implemented for your desktop environment. The big key to performance is to keep the user data close to the desktop the user will access. Because an RDS environment is centrally located in the data center, having the user-redirected folders and profiles in the data center improves overall performance. The same design could be true for a VDI deployment where all the virtual desktops are located in a data center. All the user-redirected folders and profiles should be located close to the virtual host servers.
If you are in a distributed desktop environment and there are local file servers available at each location, you can deploy virtualized user sessions in the form of redirected folders and roaming profiles.
Folder redirection is configured by applying a Group Policy. Windows Server 2008 has several settings that allow you to redirect user folders that would normally be contained in your profile to server-based folders. These settings are contained in the User SettingAdministrator TemplatesSystem Folder Redirection section of the Group Policy. You must be on the domain controller to enable these settings.
Common folders that can be redirected are as follows:
- My Documents
- Start Menu
- Application Data
These are the most common but there may be others you want to redirect. There are normally two settings, Basic and Advanced.
- Basic -- This setting applies the folder redirection to all users to whom the Group Policy applies.
- Advanced -- This setting applies to select users and can apply different settings to different user groups.
These folders are normally contained in your profile. They can become very large and take a long time to load when you log on. By redirecting them, you place a pointer in your profile that points to the folder where this information is located. The pointer is not very large and does not change, so your profile remains smaller.
To enable the roaming profiles, you use the Active Directory Users and Computer tool on your domain controller. By modifying your user account, you can point to the location of your profile on a file server. When you log on to a desktop computer, your profile settings will be downloaded to that desktop. When you log off, any changes will be copied back to the folder and your profile will be removed from the desktop.
There are two main types of roaming profile, Terminal Services and Windows profiles.
- Terminal Services -- This profile is only applied to users running a Remote Desktop Session. It can be different from the Windows profile but is typically only set up for RDS users.
- Windows -- This is the normal profile. It is set up in the Account Properties of each user account.
To set up a roaming profile you must create a shared folder on a centralized server and configure the path to the share in the user account properties. Using the format of ServernameProfileShareName%Username% will create a folder and insert the profile for each user configured to use a roaming profile. If for some reason the file share is not available, a default local profile will be created for the users when they log on. They will not have their settings or files.
Using roaming profiles across a slow link is not recommended because of the amount of time to load the file. You should always locate the file server close to the location the user will need it. That means if the roaming profile will be used in a desktop environment, the profile server should be close to the desktop. If this is a VDI, then the desktop is in the data center. If this is a Remote Desktop Service infrastructure, then the desktop is on the RDS server.
Microsoft Enterprise Desktop Virtualization
Microsoft Enterprise Desktop Virtualization (MED-V) is Microsoft's new core component of the Microsoft Desktop Optimization Pack (MDOP). Med-V enables the deployment and management of Microsoft Virtual PC images of Windows desktops to address enterprise upgrade and migration scenarios. MED-V helps an enterprise upgrade the version of Windows on the desktop even when some applications are not yet functional or supported on the new version of Windows. Windows XP Mode of Windows 7 is part of MED-V and leverages the Virtual PC on the Windows 7 desktop.
MED-V builds on top of Virtual PC to run two operating systems on one device, adding virtual image delivery, policy-based provisioning, and centralized management. MED-V works with other Windows operating systems like Vista to allow them the same benefits of Windows XP Mode on Windows 7.
Using the MDOP tools, an administrator can build and configure a desktop image with the unsupported application and deploy it to the enterprise desktops as a virtual image that will run as if it was installed on the desktop operating system.
MED-V allows deployment of legacy versions of a Windows operating system like Windows XP or Windows 2000 to any version of Windows desktop operating system. The management server allows for the creation and testing of multiple images. When the image is correct, it can be deployed to all users requiring the application.
Once installed, the application is available to users just like it was locally installed. Figure 9.41 shows the processes of MED-V in action.
Figure 9.41: MED-V in Action
The process works as follows:
- The Corporate desktop images are prepared.
- The image is stored in the Image Repository.
- The Image Repository registers the image with the Management Server.
- The Administrator uses the Management Console to assign the image to the appropriate Active Directory user group.
- When the end user signs in, the image is deployed to his or her desktop and stored in the Virtual PC virtual machine folder.
In order to use MED-V, you must use and all managed desktops must be members of the Active Directory domain. Clients can be Windows 7, Vista, or Windows XP SP2. The guest operating system can be Windows XP SP2 or SP3 or Windows 2000 SP4.
The use of MED-V extends the benefits of Windows 7's Windows XP Mode to other desktops. This tool eliminates the barriers to adoption of a current desktop operating system because of application incompatibility.
In this chapter, we learned how to deploy Windows 7's Windows XP Mode feature. To do this, we needed to:
- Verify our Windows 7 operating system was Professional, Enterprise, or Ultimate
- Verify our computer had virtualization hardware assist
- Verify that the computer BIOS was configured to enable the hardware assist features.
- Download and install Windows XP Mode
- Download and install Virtual PC
We configured Windows XP Mode by going through the wizard to assign a password and then performed a reboot of the system. Once we had the Windows XP Mode running, we installed a legacy application. We launched the application from Windows XP Mode and from the Start menu of Windows 7. This demonstrated the integration of the legacy application with the primary operating system.
We discussed several different types of virtualization and how to leverage them with Windows 7 and your enterprise.
- We discussed application virtualization with RDS, RemoteApp, and App-V.
- We discussed the VDI using Hyper-V and how we could leverage a virtual desktop to deploy a large number of corporate desktops quickly to both local and remote users.
About the author
Jorge Orchilles holds a master's degree in science in management information systems from Florida International University and is currently a security analyst at a Fortune 20 financial institution.
Printed with permission from Syngress Publishing. Copyright 2010. Microsoft Windows 7 Administrator's Reference by Jorge Orchilles. For more information about this title and other similar books, please visit http://scitechconnect.elsevier.com/category/computer-security/.