EMC BUSINESS CONTINUITY FOR VMWARE VIEW 5.1

White Paper EMC BUSINESS CONTINUITY FOR VMWARE VIEW 5.1 EMC VNX Replicator, VMware vcenter Site Recovery Manager, and VMware View Composer Automating failover of virtual desktop instances Preserving user data and virtual desktop environment EMC Solutions Group Abstract This white paper demonstrates enhancements to business continuity by using custom scripts with VMware SRM recovery procedures. The scripts enable VMware linked-clone virtual desktops created with VMware View Composer, as well as the server infrastructure, to recover as part of the failover to a recovery site. This solution saves recovery time and demonstrates the recovery of user settings, user data, and user data disks using custom scripts. August 2012

Copyright 2012 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. VMware, VMware vcenter, and VMware vsphere are registered trademarks or trademarks of VMware, Inc. in the United States and/or other jurisdictions. Iomega and IomegaWare are registered trademarks or trademarks of Iomega Corporation. All other trademarks used herein are the property of their respective owners. All trademarks used herein are the property of their respective owners. Part Number H10901 2

Contents Executive summary... 5 Business case... 5 Solution overview... 5 Key results... 5 Introduction... 6 Purpose... 6 Scope... 6 Audience... 6 Terminology... 6 Key components... 8 Component overview... 8 EMC VNX... 8 VMware vsphere ESXi 5.0 update 1... 8 VMware High Availability cluster... 9 VMware View Connection Server and Replica Server... 9 VMware View Composer... 9 EMC VNX Replicator... 9 VMware vcenter Site Recovery Manager... 9 EMC VNX Storage Replication Adapter for VMware Site Recovery Manger... 9 Physical architecture... 10 Architecture diagram... 10 Environment profile... 11 Hardware resources... 11 Virtual allocation of hardware resources... 11 Software resources... 11 Design and validation... 13 Design overview... 13 Validation overview... 15 Interoperability... 15 VMware View Connection Server and Replica Server... 16 VMware View Composer Service... 16 VMware View Agent... 16 VMware View Client... 16 Linked-clone desktop pools... 16 Functionality... 17 3

Failback... 18 Performance... 18 Implementation details... 19 VMware Site Recovery Manager... 19 Virtual machine customizations... 20 View 5.1 host caching... 20 DNS changes... 21 VLAN usage... 21 Conclusion... 22 Summary... 22 Key points... 22 Recovery of desktop pools and images... 22 Environment validation... 22 Solution benefits... 22 References... 23 White papers... 23 Product documentation... 23 4

Executive summary Business case Organizations cannot afford to have their key applications unavailable for any length of time for any reason. Business continuity plans must handle service interruptions and recovery from disasters with minimal impact on production. Yet many organizations only consider the server environments in their business continuity plans. Physical desktops make disaster recovery a challenge at the primary or protected site. Re-creating the physical desktop environment at the recovery site takes considerable time, and users may need to adjust to the new desktops. Using VMware View to virtualize the desktops allows organizations to use VMware vcenter Site Recovery Manager (SRM) to handle both the server and the desktop environment business continuity plans. Protecting the virtual desktop along with the infrastructure makes disaster recovery transparent to the end users and has less effect on the business. The ability to recover critical applications and the virtual desktops that access them means restoring user productivity quickly with revenue-generating activities minimally affected. Solution overview Users like to have their desktop preferences and data available from any desktop or handheld device. System administrators want to keep that data secure and be able to effectively manage those critical production desktop pools. VMware View, protected with SRM, satisfies both needs and allows organizations to: Retain the look and feel (desktop personality) of their production virtual desktop at both the protected and recovery sites. Provide a means to retain the same desktop experience, post-disaster and failover, at the recovery site. Improve end-user productivity by speeding the time to recover for critical applications and the virtual desktops that provide access. VMware View Composer uses linked-clone technology to reduce the storage needs for the VMware View deployment. This white paper highlights the challenges involved in recovering linked-clone virtual desktops, and describes how to overcome those issues. Key results This solution demonstrates a method for recovering VMware View Composer linkedclone virtual desktops on the recovery site with custom scripts (included in this white paper) added to the SRM recovery steps. The solution described in this white paper: Demonstrates that the user settings and data are not altered when a recovery is required Demonstrates the recoverability of virtual desktops with User Data Disks (UDD) configured 5

Introduction Purpose Scope Audience Terminology This white paper explores the ability to recover VMware View Composer-based linkedclone virtual desktops at a remote site that is replicated with EMC VNX Replicator and managed by VMware vcenter Site Recovery Manager. This white paper discusses the EMC Business Continuity for VMware View Enabled by EMC VNX Replicator and VMware vcenter Site Recovery Manager Solution at a high level. This white paper details how to augment an SRM recovery and includes example scripts used to fail over the VMware View components of the environment, which SRM does not traditionally protect. We assume you are familiar with: VMware vsphere 5 VMware vcenter Server 5 VMware vcenter Site Recovery Manager 5 EMC VNX EMC VNX Replicator This white paper is intended for EMC employees, partners, and customers, including IT planners, virtualization architects and administrators, and any other IT professionals involved in evaluating, acquiring, managing, operating, or designing a private cloud environment that leverages EMC technologies. Table 1 defines some of the key terms used in this paper. Table 1. Term VDM Terminology Definition Virtual data mover, which is an EMC VNX software feature that enables the grouping of file systems and CIFS servers into virtual containers. Each VDM contains all the data necessary to support one or more CIFS servers and their file systems. VMware SRM HA SRA for SRM NAS VMware Site Recovery Manager, which leverages storage-based replication to help you manage your disaster recovery process. High availability, which is a feature that prevents a single point of failure; that is, if a component fails, the overall system maintains its basic functionality. EMC VNX Storage Replication Adapter (SRA) for VMware Site Recovery Manger (SRM). SRA allows VMware SRM to integrate with third-party storage array technologies. Network attached storage, which is file-based storage protocols such as CIFS and NFS. 6

Term SAN CIFS NFS Definition Storage area network, which is block-based storage protocols such as iscsi, Fibre Channel over Ethernet(FCoE), and Fibre Channel(FC). Common Internet File System, which is a network file system protocol commonly used in Microsoft Windows environments. Network file system, which is a networking protocol commonly used to provide access to a shared file system for UNIX-based systems. 7

Key components Component overview EMC VNX The following topics briefly describe the major components of the business continuity solution described in this white paper, including: EMC VNX VMware vsphere 5 update 1 VMware HA Cluster VMware View Connection Server VMware View Connection Replica Server VMware View Composer VMware vcenter Site Recovery Manager EMC VNX Storage Replication Adapter (SRA) for VMware Site Recovery Manger (SRM) EMC VNX Replicator EMC VNX is a unified storage platform that allows connections to multiple storage networks using a set of NAS protocols, including but not limited to CIFS and NFS. The VNX system delivers innovation and native enterprise capabilities for file (NAS) and block (iscsi, FCoE, and FC) and object storage in a scalable, easy-to-use solution. VNX combines powerful and flexible hardware with advanced efficiency, management, and protection software to meet the demanding needs of your business. The VNX series is designed to meet the high-performance, high-scalability requirements of midsize and large businesses. EMC VNX: Provides a high-end, multi-dimensional storage Allows simultaneous connections to multiple storage networks using NAS and SAN protocols Provides storage replication for disaster recovery failover and failback In this white paper, the VMware vsphere servers access storage through the NFSv3 protocol. This high-end storage system provides a standalone solution that can consolidate multiple applications across multiple vsphere servers. VMware vsphere ESXi 5.0 update 1 VMware vsphere ESXi is a data center operating system that virtualizes the entire IT infrastructure. It enables the most scalable and efficient use of server hardware in a robust fault-tolerant environment. VMware vsphere: Abstracts server processor, memory, storage, and networking resources into multiple virtual machines, forming the foundation of the VMware vsphere suite Partitions physical servers into multiple virtual machines. Each virtual machine represents a complete system with processors, memory, networking, storage, and BIOS 8

Can share single server resources across multiple virtual machines, and cluster vsphere servers for further sharing of resources VMware High Availability cluster VMware View Connection Server and Replica Server VMware High Availability (HA) cluster provides cost-effective high availability for any application running on a virtual machine, regardless of its operating system or underlying hardware configuration. VMware View Connection Server manages secure access to virtual desktops and works with vcenter server to provide advanced management capabilities. It is sometimes referred to as a connection broker. The VMware View Connection Replica Server contains a replica of the View Directory database. You use Replica Servers in conjunction with other network load-balancing technology to balance the connection broker traffic. Refer to the VMware View Administration Guide for configuration recommendations for load balancers and SSL off-loaders. VMware View Composer VMware View Composer, which runs as a service on the vcenter server, reduces storage cost for the deployment of virtual desktops by using linked clone technology. A clone is a copy of an existing virtual desktop. Installing the operating system and applications on a virtual desktop can be time-consuming. With clones, you can make copies of a virtual desktop from one master image. A linked clone is a copy of a virtual desktop that shares virtual disks with its parent virtual desktop. This feature saves disk space and allows multiple virtual desktops to use the same software installation. With linked clones, you can: Provision many virtual desktop images Deploy patches and updates Restore virtual desktops to their original state EMC VNX Replicator VMware vcenter Site Recovery Manager EMC VNX Storage Replication Adapter for VMware Site Recovery Manger VNX Replicator is an asynchronous remote replication solution for the EMC VNX family. It provides host-independent data replication across one or more physically separate target VNX systems. VMware vcenter Site Recovery Manager (SRM) automates the recovery process and reduces the complexity of managing and testing recovery plans. VMware vcenter SRM eliminates complex manual recovery steps and removes the risk and worry from disaster recovery. EMC VNX Storage Replication Adapter (SRA) for VMware Site Recovery Manager (SRM) allows VMware SRM to integrate with third-party storage array technologies. EMC VNX SRA is a storage replication adapter that extends the disaster-restart management functionality of VMware SRM to the EMC VNX storage environment. It allows SRM to automate storage-based disaster restart operations on VNX arrays in a Replicator configuration. For additional information, refer to the Release Notes paper entitled VNX Replicator Enabler for EMC VNX SRA. 9

Physical architecture Architecture diagram Figure 1 depicts the overall physical architecture of the solution described in this white paper. Figure 1. Architectural diagram 10

Environment profile Hardware resources Table 2 lists the hardware used to validate this solution. Table 2. Hardware resources Equipment Quantity Configuration Infrastructure blade servers 2 x 2 Two quad-core Intel Xeon E5540 2.53 GHz, 48 GB RAM VDI blade servers 3 x 2 Two six-core Intel Xeon X5680 3.33 GHz, 96 GB RAM Infrastructure switch 1 Multiple VLANs EMC VNX5700 2 DAEs: 3 x DAE6S 3.5 SAS, FAST Cache: 200 GB x 14 Virtual allocation of hardware resources Table 3 lists the virtual allocation of hardware resources described in this solution. These are the virtual machine configurations. Table 3. Virtual machines Equipment Quantity Configuration Domain Controller 2 2 vcpus, 8 GB RAM, 2 vnic, 50 GB VMDK vcenter Server 2 2 vcpus, 16 GB RAM, 1 vnic, 100 GB VMDK vcenter SQL Server 2 2 vcpus, 16 GB RAM, 1 vnic, 130 GB VMDK View vcenter Server 1 2 vcpus, 16 GB RAM, 1 vnic, 100 GB VMDK View SQL Server 1 2 vcpus, 16 GB RAM, 1 vnic, 130 GB VMDK View Connection Server 1 2 vcpus, 16 GB RAM, 2 vnics, 50 GB VMDK View Replica Server 1 2 vcpus, 16 GB RAM, 2 vnics, 50 GB VMDK Virtual desktops 100 1 vcpu, 1 GB RAM, 1 vnic, 20 GB (OS) +10 GB (UDD) VMDK Firewall / Gateway 2 1 vcpu, 128 MB RAM, 2 vnic, 10 MB VMDK Software resources Table 4 lists the software used in this solution. Table 4. Software resources Software Version VMware vsphere 5.0 Update 1 VMware vcenter Server 5.0.0 build 623373 VMware ESXi 5.0.0 build 702118 VMware Site Recovery Manager 5.0.1 build 633117 VMware View Connection Server 5.1.0 build 704644 11

Software Version VMware View Composer 3.0.0 build 691993 VMware View Agent 5.1.0 build 704644 VMware View Client 5.1.0 build 704644 EMC VNX SRA for VMware SRM 5 5.0.1 Microsoft Windows Server 2008 R2 Microsoft Windows 7 Enterprise SP1 For infrastructure For virtual desktops Microsoft PowerShell 2.0 VMware PowerCLI 5.0.1 M0n0wall (used as firewall/gateway for virtual desktops) 1.33 PuTTY 0.62 12

Design and validation Design overview The infrastructure for this solution is deployed in an EMC Compute as a Service (CaaS) environment spanning two data center locations: Protected site: Site A (DC1) Recovery site: Site B (DC2) Three vcenter virtual data centers host the virtual machines (see the sections entitled Physical architecture and Environment profile for details). One virtual data center at each site hosts the SRM and vcenter Server, SQL server, Microsoft Active Directory Domain Controller, and NAT firewall for View VDI instances. We configured the protected site with VMware View vcenter Server, SQL server, and two VMware View Connection Servers. The third virtual datacenter hosts the VDI virtual desktops. 1 Figure 2 displays the virtual data center hierarchy. 1 We set up the ESXi environment at both the protected and recovery sites as well as the VMware View environment in accordance with VMware best practices, (see the References section on page 25 for details). 13

Figure 2. Virtual data center hierarchy We created NFS data stores and exported/hosted them on the VNX arrays. CIFS shares on the VNX host the file systems for roaming profiles and user data for VDI virtual desktops. EMC VNX s Home Directory feature automatically creates and maps home directories to the CIFS data store in a way that is transparent to the end user. A replicated Virtual Data Mover (VDM) hosts the CIFS shares, with a unique IP address (but identical DNS name) at each site for that site's VDM interface. SRM automates the VNX replication failover. We configured the View infrastructure NFS share to replicate to the recovery site using VNX Replicator managed by VMware vcenter Site Recovery Manager (SRM). vsphere hosts mount the linked-clone data store, which is hosted on the local VNX. We accomplished this using a DNS name so that the hostname, path, and data store name at each site are the same, but resolve to the correct local VDM address at each site 14

Note: It is important not to configure ESXi vsphere hosts at the recovery site in the same cluster as the hosts at the protected site. In addition, the recovery hosts cannot have the linked-clone data stores mounted. Either case may cause provisioning errors when provisioning or refreshing desktops with VMware View. We configured SRM to fail over the View vcenter Server, View Connection servers, and SQL database server. We included a script in the recovery plan to make an SSH connection to the recovery VNX and fail over the CIFS VDM, roaming profiles, user data, and linked-clone data stores. We ran a second script (see Figure 8 on page 20) when the View vcenter Server came online at the recovery site. This script connects the linked-clone data stores to ESXi hosts at the recovery site. It also moves the ESXi hosts into the View Cluster, and takes the hosts out of maintenance mode. Note: In this solution design, if the VMware View vcenter Server must change IP addresses during the recovery process, SRM cannot be used to change them. The migrated vcenter virtual machine will hang during the boot process while attempting to connect to the old SQL server s IP address before SRM can use VMtools to change the IP address. In this case, we suggest that you do one of the following: Use a DHCP reservation for the View vcenter Server. Run an SRM script on the View vcenter Server virtual machine to change the IP address. Manually change the IP address or use the same IP address at both data centers. For this white paper, we used a DHCP reservation. Validation overview Interoperability To validate the business continuity of VMware View using SRM, perform the following steps: 1. Set up the protected site virtual infrastructure environment. 2. Deploy the View environment at the protected site. 3. Verify virtual desktop operations. 4. Set up the recovery site virtual infrastructure environment. 5. Configure replication between sites using VNX Replicator, ensuring that the whole VDM is replicated. 6. Configure the protection group at the protected site. 7. Configure the recovery plan with any custom scripts at the recovery site. 8. Upon failover, execute the recovery plan. 9. Verify the functionality at the recovery site. The VMware View Composer environment consists of: VMware View Connection Server and Replica Server VMware View Composer Service VMware View Agent 15

VMware View client Desktop pools Base image For a successful VMware View recovery, we must recover all of these components properly. VMware View Connection Server and Replica Server VMware View Composer Service VMware View Agent VMware View Client Linked-clone desktop pools VMware View clients connect to entitled virtual desktops through the VMware View Connection Server. To make the Connection Server available on the recovery site, we must perform the following steps on the virtual machine: 1. Configure the virtual machine for protection in the SRM protection group. 2. Change the IP addresses, if necessary. 3. Update the DNS registration. 4. Update the network load balancing or SSL offload configuration (if used) in the recovery step. VMware View Composer Service on the View vcenter server: Uses an ODBC connection to a SQL database. Has SQL Server 2008 installed on a virtual machine that is configured to fail over with SRM. We installed View Agent on the base image that interacts with VMware View Connection Server. No special steps are needed for recovery. The VMware View Client is an application that launches the virtual desktops hosted on VMware View. We installed this application on the end-user devices, and installed and connected it to the recovery site. Users should point to a DNS name configured to point to the correct data center or a load balancer. Users can access virtual desktops using either PCoIP or RDP. Desktop pools are collections of virtual desktop that have the desktop operating system installed on them. Creating a linked-clone desktop pool from the base image: Copies the operating system disk and its snapshot to the replica folder on every data store being deployed. Creates a new snapshot and presents it as an operating system disk to the source virtual desktop. Clones the source virtual desktop to create additional virtual desktops. Tracks changes to the disk image only, thereby reducing disk space requirements for each additional virtual desktop. 16

Functionality We performed the following steps when configuring this solution: 1. Created a protected site environment with: An automated desktop pool with virtual desktops. Linked clones and user data file systems hosted on a separate data store. 2. Configured users to connect to their virtual desktops to create files and folders on their own desktops and My Documents folder 3. Executed the SRM recovery plan with custom scripts to: Fail over the VNX NFS shares, including linked clones and replica data stores. Fail over the VNX CIFS shares, including CIFS VDM, roaming profiles, and user data file systems. Connect linked-clone data stores to the ESXi hosts at the recovery site. Move the ESXi hosts at the recovery site into the VMware View cluster. Bring the ESXi hosts at the recovery site out of maintenance mode and into connected mode. 4. Enabled users to: Connect to their virtual desktops without any modification to their normal procedure. Access and update the files and folders created on the protected site. 5. Enabled View administrators to recompose, refresh, and deploy new pools and desktops. Figure 3 displays these steps in SRM. 17

Figure 3. SRM recovery steps Failback Performance Once all file systems are protected again (manually for CIFS shares and linked-clone data stores, and automatically for the SRM-protected file systems), the administrator can manually initiate the failback process. It is the same as for the failover process, except we perform the operations on the opposite site. We performed the same steps on Site B for the failback that we performed on Site A during failover. We put the ESXi hosts at the recovery site into maintenance mode, removed them from the View Cluster, and unmounted the linked-clone data store. For this specific configuration, the entire recovery took approximately 30 minutes for 100 virtual desktops. The infrastructure virtual machines were online within 22 minutes after initiating the recovery steps in SRM, and within 30 minutes, all 100 virtual desktops had completed the boot process. Actual operation times will vary depending on your specific environment. The number of desktop pools and virtual desktop all affect the operation time. 18

Implementation details VMware Site Recovery Manager VMware SRM provides the cornerstone of a solid business continuity solution. We configured SRM on the two infrastructure vcenter sites to provide failover for the View vcenter, View SQL Server, View Connection Server, and View Replica Server virtual machines. It also controls the VNX Replicator processes to replicate the NFS data store containing these virtual machines. The script call.cmd runs during recovery Step 8 of the SRM Recovery Plan (see Figure 3Error! Reference source not found. on page 18). The script call2.cmd runs during recovery Step 12.1.4, which is after the VMware View vcenter Server virtual machine has finished booting at the recovery site. Figure 4 shows the call.cmd command, which runs the failover recovery Powershell script. @echo off C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -File C:\scripts\vnx_failover_recovery.ps1 Figure 4. call.cmd Figure 5 shows the vnx_failover_recovery.ps1 command, which causes the VDM, CIFS shares, and linked-clone data stores to fail over to the recovery site. # Fail over VDM, CIFS Shares, and linked-clones datastore C:\windows\system32\cmd.exe /c "echo y `"C:\Program Files (x86)/putty/plink.exe`" -ssh [vnx ssh user]@[recovery vnx ip address] -pw [password] -m C:\scripts\vnx_failover_recovery.sh" exit Figure 5. vnx_failover_recovery.ps1 Figure 6 shows the commands that run on the Recovery VNX Control Station SSH prompt when called by the vnx_failover_recovery.ps1 script. #!/bin/sh /nas/bin/nas_replicate -failover Linked_Clones_and_Replicas /nas/bin/nas_replicate -failover CIFS_VDM /nas/bin/nas_replicate -failover User_Data_FS /nas/bin/nas_replicate -failover Roaming_Profiles_FS Figure 6. vnx_failover_recovery.sh Figure 7 shows the call2.cmd, which calls the VMware vcenter connect Powershell script. @echo off C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -File C:\scripts\vcenter_connect.ps1 Figure 7. call2.cmd 19

Figure 8 shows the vcenter_connect.ps1 command, which: Connects the linked-clone data store to the recovery ESXi hosts Connects the ESXi hosts to the View vcenter Server Brings recovery ESXi hosts out of maintenance mode # Add VMWare cmdlets Add-PSSnapin vmware* # Connect to View vcenter Server Connect-VIServer Server [View vcenter Server hostname] -Protocol https -User [user] -Password [password] # Connect linked-clone datastore to ESXi Hosts $recoveryhosts = Get-VMHost Where{$_.Name -like "*dc2*"} $recoveryhosts New-Datastore -Nfs -Name Linked_Clones -Path "/Linked_Clones" - NfsHost linked_clones #Connect ESXi hosts at Recovery Site $cluster = Get-Cluster -Name "View Cluster" $recoveryhosts Move-VMHost -Destination $cluster # Connect ESXi Hosts at Recovery Site $recoveryhosts Set-VMHost -State "Connected" exit Figure 8. vcenter_connect.ps1 Virtual machine customizations During the recovery process, virtual desktops may prompt you to confirm if the virtual machine was moved or copied before allowing vsphere/view to turn the power on. You can automate this by following the process documented in VMware KB 1027096. Make this change before taking the snapshot used to create the desktop pool. Figure 9 shows how you might automate this process. answer.msg.uuid.altered = "I moved it" Figure 9. Addition to Gold image.vmx file View 5.1 host caching View 5.1 adds the ability to dedicate host memory for file caching to reduce data store I/O when using vsphere 5.0 (and higher) ESXi hosts. The View 5.1 Administrator GUI (View Configuration -> Servers -> [vcenter] -> Edit -> Caching) enables you to accomplish this task. You can also enable file caching for a specific desktop pool through the GUI Administrator at: Inventory -> Pools -> [POOL] -> Edit -> Advanced Settings. 20

DNS changes VLAN usage We used Windows Active Directory (AD) for serving DNS queries. When used in AD integrated mode, it is not possible to have site unique DNS entries. For this reason, we did not enable AD integration for the forward-lookup DNS zones. This allowed us to provide unique IP entries for the protected and recovery sites at the expense of having to manage DNS entries at both sites. The VLAN used for the virtual desktops must be the same at both the protected and recovery sites. This allows the VDI virtual machines to start at either site without requiring changes to the NIC port group after a failover event. This task may require special network changes if the protected and recovery sites share a common infrastructure. Most site pairs do not link in this manner, but you should consider this during planning. 21

Conclusion Summary This white paper demonstrates a method for recovering VMware linked-clone virtual desktops on the recovery site with custom scripts added to the SRM recovery steps. This method of virtual desktop recovery provides a rapid, reliable, and cost-effective solution that replaces tedious error-prone manual steps. These automated processes reduce recovery time from hours or days, to minutes. Key points This section outlines the key points that this solution addresses. Recovery of desktop pools and images The VDI Pool is available at the recovery site via SRM automation with no change in look or feel for end users. We are able to deploy new desktop pools, new desktops in the existing pool, and recompose and refresh the existing desktop pool. Environment validation In this solution, we validated the recovery of 100 virtual desktops within a 30-minute timeframe. Note: The recovery time depends on the size of the deployment. Solution benefits This solution demonstrates: How the user environment settings as well as the data are not altered during recovery when using the described scripts. The recoverability of virtual desktops with a floating desktop pool and roaming profiles configured. The ability to fail back using SRM and VNX Replication. 22

References White papers Product documentation For additional information, see the white papers listed below. Site Recovery Manager Evaluator Guide: http://www.vmware.com/pdf/srm_10_eval_guide.pdf VMware vcenter Site Recovery Manager Performance and Best Practices: http://www.vmware.com/resources/techresources/10057 Automating Network Setting Changes and DNS Updates on Recovery Site Using VMware vcenter Site Recovery Manager: http://viops.vmware.com/home/docs/doc-1491 VMware View Composer Advanced Image Management and Storage Optimization for your VMware View Environment: http://www.vmware.com/files/pdf/vmware-view-4-composer-ds-en.pdf For additional information, see the following product document. VMware vcenter Site Recovery Manager Documentation: https://www.vmware.com/support/pubs/srm_pubs.html VMware View documentation: http://www.vmware.com/support/pubs/view_pubs.html EMC VNX Replicator Enabler for EMC VNX SRA Version 5.0.12 Release Notes: https://support.emc.com/docu41258_vnx-replicator-enabler-for-emc-vnx- SRA-5.0.12-Release-Notes.pdf Configuring Virtual Data Movers on VNX https://support.emc.com/docu41477_configuring-virtual-data-movers-on- VNX.pdf Using VNX Replicator: https://support.emc.com/docu41540_using-vnx-replicator.pdf Installing VMware ESXi 5.0 Best Practices: http://kb.vmware.com/kb/2005099 Installing vcenter Server 5.0 Best Practices: http://kb.vmware.com/kb/2003790 Running vcenter Server in a Virtual Machine: http://kb.vmware.com/kb/10087 VMware View Best Practices: http://kb.vmware.com/kb/1020305 23