Planning and Deploying VDI and Remote Desktop Services

2. VIR311 Planning and Deploying VDI and Remote Desktop Services Michael Kleef Senior Technical Product Manager Microsoft

3. Agenda • Recap on Windows Server 2008 R2 SP1 • RemoteFX planning • Sessions and VDI planning • Management integration • Close • Assumptions: You already know what VDI is

4. Windows Server 2008 R2 SP1 Richest User Experience for full 3D apps Highest density RemoteFX Dynamic Memory Enables higher density ratios for workloads on Hyper-V Enable 3D graphical and rich media capabilities with Virtual GPU Improves Remote Desktop Protocol (RDP) efficiency Enables 40% higher VDI densities* Rich clients, thin clients and network displays Preserves Windows 7 and Windows Server 2008 R2 platform security Significantly drops the cost per user Supported on Enterprise Server Hardware *Compared to Windows Server 2008 R2 RTM release. Based on internal testing using LoginVSI Medium workload

5. What does a 40% increase in density mean? Microsoft and Citrix VDI delivers savings – with lower CAPEX numbers. Hardware and Hypervisor scale of VDI Licensing Comparison of VDI* $133/ ccu $320/user2 $242/user1 $222/user2 $63/device $42/device annual Citrix $21/device annual MS VMware (Commissioned Report by EMA) 1280 users Hyper-V 2008 R2 RTM 1000 users Hyper-V 2008 R2 SP1 1440 users MS VDI Standard Suite Citrix XenDesktop “VDI Edition” VMware View Premier *Based on a 3 year amortization and publicly available information as of February 2010. 1Based on: http://www.vmware.com/files/pdf/EMA-VMware-View-StatelessVirtualDesktop-WP.pdf?src=ie9tr 2Based on Dell MSRP pricing online as at 3/17/2011 of hardware used in MMS keynote

6. RemoteFX architecture and planning

7. RemoteFX Architecture Inter-VM Communications Windows Server 2008 R2 SP1 Hyper-V Server Protocol Fundamentals (e.g. Authn, Encryption, & Client device Redirection) Hyper-V Integrated Shared Memory Comms Hyper-V Parent Partition W7 Guest OS UMRDP RCC VGPU Driver • VGPU output rendered to physical GPU via DirectX. • First phase of CODEC runs on GPU. • Screen deltas captured from GPU. VMBUS WDDM driver exposes parent GPU to guest OS. RemoteFX Hardware ASIC and Driver GPU Optionally offloads CODEC from CPU/GPU increasing fidelity and scale.

8. RemoteFX Virtual GPU and Rendering Pipeline W7 Child Partition Hyper-V Parent Partition RFx Hyper-V VM Bus Parent Integration D3D9 Application IE Silverlight ActiveX Control RCC Hyper-V VMBUS Shared Memory Comms GDI DX9 APIs DX9 APIs RemoteFX VGPU Driver GPU Vendor Driver RFx Hyper-V VM Bus Child Integration GPU

9. RemoteFX DEMO

10. RemoteFX requirements • RDVH • SLAT-enabled processor • GPU • The GPU driver must support DirectX 9.0c and DirectX 10 • If more than one GPU is installed in the RemoteFX server, the GPUs must be identical • Enough GPUs or VRAM to cope with the number of users • To use Live Migration, the source and destination RemoteFX servers must have the same GPU installed. • RDSH • The processor on the RD Session Host server must support Streaming SIMD Extensions 2 (SSE2) • Microsoft RemoteFX for RDVH Capacity Planning Guide for Windows Server 2008 R2 Service Pack 1 available at http://www.microsoft.com/downloads/en/details.aspx?FamilyID=679193cb-9b74-4590-a2be-00bde429c990

11. Known good hardware and issues • GPUS • nVidia • Quadro FX5800, FX4800 and FX3800 • Quadro 6000, 5000, 4000 • Quadroplex 2200 S4 • Tesla S2050 and S2070 • ATI • FirePro V5800, v7800, v8800 • Servers • IBM iDataPlex • Dell PowerEdge R610, R710, M610x • HP DL/ML 370, WS460c • Don’t do: • Use Crossfire and nVidia SLI extensions or even connect cards together

12. VRAM requirement per VM

13. VDI and Sessions Sizing

14. Windows Server 2008 R2: The core of VDI - Remote Desktop Services and VDI Architecture System Center and App-V RD Session Host with RemoteApp RD Web Access RD Client RD Virtualization Host RD Connection Broker RD Gateway Licensing Server Active Directory®

15. The value of layering Data & User Settings • AppSense • RES • Citrix Profile Manager • App-V 4.6 • SCCM 2007 R2 (Currently personal only) Applications • Sessions • Individual VHDs • Differenced VHD • Citrix Provisioning Services Operating System

16. Windows Server 2008 R2:Why Sessions? • Session Virtualization scales more users per server than VDI • App-V works in both VDI and Sessions • The same RDP connection protocol is used in both • Much of the service infrastructure is shared • Upsides for VDI: • VDI offers better user operating system isolation • VDI has better native application compatibility • VDI allows users to be admins of their own images • Upsides for Session Virtualization: • Session Virtualization requires less hardware than VDI • Sessions are cheaper than VDI desktops • Server management is less than VDI • Way less complicated to deploy…don’t underestimate Remote Desktop Services enables both session virtualization and VDI!

17. Windows 7 Desktop or Virtual Desktop (VDI) Windows Server 2008 R2:Desktop Centralization Choices • Windows Server 2008 R2 Session Virtualization Session Virthas at least 2x scalability over VDI

18. VDI Guest VM ConsiderationsDeployment Choices • Provides virtual machine-based, centralized desktops for individual users that can be fully customized based on user profiles • Allows users to perform specialized tasks that require administrator access to their desktop • Enables users to access their personalized desktop from any computer while retaining the last saved state Personal Virtual Desktop • Provides virtual machine-based, centralized desktop based on a pool of virtual machines that are shared by multiple users • Allows users to perform standardized routine tasks and have access to common applications (such as Microsoft Office) • Rolls back the state upon logoff to provide a “clean” desktop for the next user’s session, but the previous user’s state can be saved offline Pooled Virtual Desktop

19. Guest VM ConsiderationsThe case for Personal Virtual Desktops Pros: • Managed through existing enterprise management tools • Enables single pane of glass management • Allows for local admin access • You don’t have to layer everything Cons: • Images are 1:1 to the user, thus duplication occurs • You have to think about clustering/DR strategies Common Mistakes: • Taking a current SOE and putting into VDI • Failure to virtualize the app layer Result: Easier to manage, more personalized and integrated with current tools

20. Guest VM ConsiderationsThe case for Pooled Virtual Desktops First bear in mind, Windows was never designed to be composable Pros: • Enables a “throw away” image • Great for call centers • Clustering generally doesn’t matter • With Citrix, in some cases, the SAN doesn’t even matter Cons: • You are forced to layer everything • Two management infrastructures are now required • Can’t deliver local admin access Common Mistakes: • Ignoring the fact that the same scenario can also be delivered through Session Virtualization, and waaayyy cheaper Result: Potentially more complicated, less personalized and more difficult to manage

21. Guest VM ConsiderationsWhy can Pooled be difficult? Will a single master image and separation of the user state with linked clones work? • Customer reports are highlighting that updating single master/linked clone desktops aren’t working as expected • Nasty corruption problems • Some customers switching from pooled to PVD • Bad story: switching and leaving the linked clone architecture in place • However: Citrix XenDesktop on Hyper-V does the pooled model very well with its provisioning server

22. Architecture Review & User Experience Comparison DEMO

23. VDI Capacity Planning: Initial Performance DataCaveats and Objectives Performance is very subjective with many variables • Caveats • Data provided is based on benchmark results and is not reflective of many real-life deployment considerations: • Is based on specific usage scenarios • Does not account for necessary “cushion” to deal with temporary peaks in resource usage • Recommend piloting for performance planning • Multiple factors determine actual performance • Variations in hardware • Driver versions • Desktop Workloads • Application quality • What we used: • Two differently configured AMD servers • Fiber Channel SAN • Objectives to be determined: • An indication of VM’s per server that could VDI scale to, before Dynamic Memory came along • Processor, Disk and Memory requirements • Network requirements • Service Placement • Comparison against Session Virtualization scale on same hardware

24. What IO bottlenecks do you hit first? • In order, generally that is: • Disk IO • Memory pressure • Processor • Disk IO is a performance and density related impact • Memory is a density impact • Processor is a performance and density related impact

25. VDI Capacity PlanningDisk IO Rule of thumb: SANs are your new best friends • Disk performance is the most critical factor in achieving density • Internal testing showed Windows 7 having lower Disk IO than Windows XP, after boot up • So did ProjectVRC’s recent testing • SAN is of critical importance. Highly recommended • Plenty of cache • Consider de-duplication support especially if persistent • De-duplication allows the benefits of individual images at the cost of differencing disk • Managing images on a SAN is way faster and easier than over network (provisioning is faster) • We mean real SAN (iSCSI or FC) not NAS across the network… • Remember RDS does not require this huge SAN investment… • If you have low complexity requirements: • Think about cheaper DAS • RAID 0+1 offers better read and write performance than RAID 5 • Make sure to consider RDS

26. VDI Capacity PlanningDisk IO • Peak of read/write @ 3500 IOPs on single un-clustered server (Starting 64 VMs simultaneously) • Multiply that by number of servers • Result is the rough guidance for the maximum SAN disk IOPS you need • Test for the most demanding user logon pattern (for example: 9 am scenario) • This test based on Windows 7 Enterprise • Why use IOPS as a measurement? • Trying to calculate drive perf differences based on seek, latency and transfer rate is hard • IOPS is an easier way of understanding disk/SAN performance • Reference: http://en.wikipedia.org/wiki/IOPS

27. VDI Capacity PlanningMemory Rule of thumb: More is better • Biggest constraint of upper limit VM density (not performance related) • Constrained by: • Available memory slots in servers • Largest Available DIMMs • Creates an artificial scale ceiling • Buy as much RAM as you expect to scale the number of VM’s • Plan for and allocate at least 1GB per Windows 7 VM on Hyper-V RTM • Memory allocation should be determined by upper maximum limit of running apps • Allocate enough RAM to prevent the VM paging to disk • 1GB actually covers a fair amount of app use…. • Also refer to: http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv-R2.mspx • But Dynamic Memory changes all of the above!!

28. VDI Capacity PlanningDynamic Memory Rule of thumb: Less is more!!!  • Still a constraint of upper limit VM density (not performance related) • Buy as much RAM as you expect to scale the number of VM’s • Optimal price/performance curve at 96GB RAM • Plan for and allocate at least 1GB 512MB startup per Windows 7 VM on Hyper-V R2 SP1 • Memory allocation will be determined by Dynamic Memory based on running apps • Actual memory pressure testing in pilot is CRITICAL • Ensure enough spare capacity to prevent the VM paging to disk • YOU DON’T NEED TO WEAKEN WINDOWS 7 SECURITY TO GET MAX DENSITY!  • What difference did this make in testing? A lot!

29. VDI Capacity PlanningProcessor Rule of thumb: If it doesn’t have SLAT don’t buy it • # of VMs per logical processor is highly dependent on user scenarios • Hyper-V R2 supports: • 1000 VMs per cluster in Clustered scenarios (max of 384 VMs per server) • 384 VMs per Server in non-Clustered scenarios • 12VM’s per Logical Proc • 12VM’s/LP is not an architectural limitation but what we have tested and support • SLAT enabled processors provide up to 25% improvement in density • What is Second Level Address Translation (SLAT)? • Intel calls it Extended Page Tables (EPT) • AMD calls it Nested Page Tables (NPT) or Rapid Virtualization Indexing (RVI) • Processor provides two levels of translation • Walks the guest OS page tables directly • No need to maintain Shadow Page Table • No hypervisor code for demand-fill or flush operations • Resource savings • Hypervisor CPU time drops to 2% • Roughly 1MB of memory saved per VM

30. VDI Capacity PlanningProcessor Single (Unclustered) server results: • Win7 VMs using 512 MBs RAM per instance – not supported on Hyper-V RTM • At the time, only supported with 8 VM’s per core • Though lab benchmark testing went as high as 11 VMs per Core at the limit • Note: Requirements for clustering will limit VDI VM supported capacity to 64 VMs per server Server Hardware:

31. VDI Capacity PlanningProcessor – “Real World” Real world deployments reflect higher RDS scale Our customer engagement feedback indicates differences between tests and real world deployments: • VM’s per core are higher in our tests than in typical production VDI deployments • Production Session Virtualization scale tends to be higher than our lab tests in users per server • Our rough estimate is that some customers see as high as 5:1 in favor of Session Virtualization over VDI • Use cases will determine actual numbers That means at minimum Session Virt scales 2:1 over VDI and as high as 5:1

32. VDI Capacity PlanningNetwork Performance Rule of thumb: Rich User Experience requires rich bandwidth • LAN • Generally place VDI (RDVH) servers as “close” as possible to the users • VDI User experience is heavily dependent on network performance • LAN performance generally not a bottleneck (calculate to be sure) • Network redundancy is very important in switching fabric • When its down, the user is totally down • Ensure Blade servers can sustain on the backplane • WAN • WAN issues now equals worse issues later • Latency kills user experience • Persistent protocols take bandwidth per connection • How to tell: Multiply the number of users by approximately 20kbps • Is that beyond the capacity of your internet/WAN network? • 20kbps is the best case scenario based on HDX • 20kbps represents a cut down user experience • Look at WAN optimization technologies or compression solutions

33. How not to do it…The “sum of the parts” considerations • Everything could be so right… • Powerful Dell blades • Deployed using Citrix Provisioning Services • PVS delivering from EqualLogic SSD SAN • vDisk cache per VM, located on Equallogic SAS SAN • So what caused this mess? Roaming Profiles across “slow” file server and network connection VDI is complicated and requires careful planning and architecture

34. Forefront Endpoint Protection Recommendations • Pooled • Install and do Full Scan • Allows to build the “Mother of all Caches”  • Monitors the USN after that • Means that already scanned files arent rescanned • Scheduled scan • If you insist on it don’t disable scan randomization • Signature Updates • Don’t disable signature update randomization • Consider Risk Profile • Disable scheduled scan • Incoming only if you trust you image • Move to pattern matches only (no behavior monitoring/heuristic)

35. Management – what truly reduces TCO

36. SCVMM Dynamic Placement At capacity already SCVMM Wake VM from Saved State SAN Connect RD Connection Broker VDI Client Hyper-V Cluster (RDVH)

37. System Center Configuration Manager • Tweaks • Apply Local Policy to limit Site Policy application • ConfigMgrv.Next plans will eliminate this requirement • http://msdn.microsoft.com/en-us/library/cc146756.aspx • Hardware Inventory • Eliminate/Minimize • Software Inventory • Eliminate/Minimize • Patch Updates • Be very specific with targeting updates (English Update to English Client) • Timing of deployment • Offline Machine Servicing Tool 3.0 • Wake up, force poll, apply updates, go back to sleep • In VDI, remember, its important to reduce VM IO and Churn

38. System Center Configuration Manager • App-V and Config Manager • App-V 4.6 supports Shared Cache • App-V 4.6 works in Citrix PVS • However… • Config Manager provides single console management • Config Manager allows distributed package management • Be aware: • Config Manager “takes over” App-V client • Cant use both App-V and Config Manager to target the same VM

39. Offline Virtual Machine Servicing Tool 3.0Patching VMs on the Host OVMST UI 1. Provide collection of shutdown VMs and hosts and create servicing job Servicing Job 4. Shutdown VM and move back to the original host 3. Update the VM 2. Mount and start VM on selected maintenance host SCVMM WSUS/SCCM

40. Track Resources • Don’t forget to visit the Cloud Power area within the TLC (Blue Section) to see product demos and speak with experts about the Server & Cloud Platform solutions that help drive your business forward. • You can also find the latest information about our products at the following links: • Cloud Power - http://www.microsoft.com/cloud/ • Private Cloud - http://www.microsoft.com/privatecloud/ • Windows Server - http://www.microsoft.com/windowsserver/ • Windows Azure - http://www.microsoft.com/windowsazure/ • Microsoft System Center - http://www.microsoft.com/systemcenter/ • Microsoft Forefront - http://www.microsoft.com/forefront/

41. Resources • Connect. Share. Discuss. http://northamerica.msteched.com Learning • Sessions On-Demand & Community • Microsoft Certification & Training Resources www.microsoft.com/teched www.microsoft.com/learning • Resources for IT Professionals • Resources for Developers http://microsoft.com/technet http://microsoft.com/msdn

42. Complete an evaluation on CommNet and enter to win!

44. © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.