Reference ArchitectureXenDesktop andXenMobile ReferenceArchitectureThis document is intended for IT architects who want to deliver securebusiness mobility for their organizations. It describes how to useXenDesktop 7.1 together with XenMobile 8.6 to provide users withseamless access to hosted desktops and applications using any

Reference ArchitectureTable of ContentsExecutive summaryIntroductionObjectiveSummaryArchitectural design frameworkUser layerAccess layerResource layerControl layerHardware x XenDesktop overviewCitrix XenMobile overviewSoftware componentsImplementing the designInstallation considerations and concernsConfiguring NetScalerStoreFront considerationsVDI infrastructure VMsProfile managementProvisioning ServicesHosted shared desktopsVDI – random and static pooledXenMobile configurationTest setup and configurationSummaryClient test toolsConclusionAppendix A: NetScaler configuration screensCreating VIP to StoreFront for XenDesktopConfiguring load balancingcitrix.comXenDesktop and 17171718181919202

Reference ArchitectureXenDesktop and XenMobileToday’s technology has created a more mobile user who wants accessto their data from anywhere, with their choice of device. Citrix addresses this need with the concept of a mobile workspace, providingsecure access to desktops, applications and data, anytime, anywhere.XenDesktop with FlexCast technology and Citrix Receiver provide akey component of the mobile workspace, allowing users to connectfrom any device. However smartphones and tablets bring anotherdimension to endpoint devices. Smartphone users want access to mail,web sites, and files, but access from untrusted devices can raise serioussecurity and compliance concerns. XenMobile reduces this risk withenterprise grade mobile device management, mobile applicationmanagement and mobile productivity apps. XenMobile andXenDesktop together provide a truly comprehensive solution forbusiness mobility. To achieve this, XenMobile is deployed to betterempower smartphones and tablets, and is seen as yet anothercomponent in the FlexCast model.When designing a virtual desktop solution, there are many considerations to bear in mind, rangingfrom the type of desktops required, to how users will access the data, and how you build an environment that can grow. For example, does the user require a dedicated persistent desktop, or is ahosted shared desktop the best solution? Successful deployment of virtual desktops relies on usershaving a positive experience: this means getting the correct type of desktop to each user. WithCitrix FlexCast , multiple desktop types and access methods are supported.The objective of this document is to describe how to build a modular environment to deliver desktops and applications to local, remote, and mobile users, supporting both XenDesktop andXenMobile . The design of this environment focused not on maximizing the number of users or onmaximizing performance, but rather on assessing the number of users that could be supported ona pre-defined set of hardware while still maintaining a positive user experience and providingmobile support to XenMobile users.citrix.com3

Reference ArchitectureXenDesktop and XenMobileSummaryThe goal was to: Create an environment to support remote and local XenDesktop and XenMobile users Design a modular solution that allows for growth Follow or highlight Citrix best practices and recommendations where possibleHP ProLiant BL460c Gen8 blades and an EMC VNX 8000 were used to build the first module.Microsoft Windows Server 2012 R2 with the Hyper-V role was used as the base hypervisor. Thenumber of supported users was determined by the mix of HSD (hosted shared desktops) and HVD(hosted virtual desktops – VDI): a mix of 80/20 HSD/HVD was used. A cluster of two servers wascreated in the first module to support the XenDesktop infrastructure VMs (XD Broker, SQL, licenseserver, Provisioning Services, etc.). The infrastructure configuration will support two or threeadditional modules. However, additional SCVMM and Provisioning Services VMs may be requireddepending on the HSD/HVD ratio.XenMobile was configured to support 1000 mobility devices, that is, about 50% of the XenDesktopusers in the first module. A third single server was added to support the XenMobile infrastructure(Mobile Device Manager, AppController).To handle installation and initial configuration two servers were configured to run the root ActiveDirectory, SCVMM, and Windows Deployment Services. These were outside the modules.Our design proved capable of supporting a mix of just over 2000 HSD and HVD users in a singlemodule along with 1000 XenMobile users. The number of XenApp/XenDesktop users is flexibledepending on user workload and the distribution of HSD compared to HVD users.Architectural design frameworkThe architectural goal was to create a modular design that could grow easily while supportingboth local and remote XenDesktop users as well as XenMobile users, using the Citrix 5-layerblueprint1. The blueprint breaks down the architecture into: 1User layerAccess layerResource layerControl layerHardware nt v4.pdfcitrix.com4

Reference ArchitectureXenDesktop and XenMobileThe design was as follows:User layerThe user layer defines the different user groups and how they access their desktops. In this designthe users were: Remote (20%) or local (80%) users Assigned a hosted shared desktop (80%), a random pooled desktop (10%) or a static pooleddesktop with a personal vDisk (10%).Every user in a company has the potential to be a mobile user at any point in time; however, we specifieda number of 1000 steady-state mobility users. The infrastructure requirements for XenMobile DeviceManager/AppController do not increase significantly between 1000 and 8000 users.Access layerThe access layer defines how a user accesses the resources. In this architecture two NetScaler 10500 systems in an active/passive configuration managed access for all remote users, directingthem either to redundant StoreFront VMs to access a desktop, or to the XenMobile environment ifthey were mobile users. Internal users had direct access to the StoreFront VMs.citrix.com5

Reference ArchitectureXenDesktop and XenMobileResource layerThe resource layer defines the virtual desktops, applications, or XenMobile environment for theusers. Desktops in this design consisted of: Hosted shared desktops (HSD) Random pooled desktops Static pooled desktops with a personal vDiskControl layerThe control layer defines the infrastructure VMs required to support the users in accessing theirresources. For XenDesktop, redundant VMs were created for StoreFront, the XenDesktop Broker,Provisioning Services, and SQL databases. For XenMobile a database server, a Mobile DeviceManager (MDM), and redundant App Controllers were configured.Hardware layerThe hardware layer defines the physical implementation required to support the solution. In thehardware layer in this design, three clusters of servers were created: HSD cluster VDI cluster Infrastructure clusterHardwareIn the diagram above hardware is shown only as servers; however, hardware also includesnetworking and storage.citrix.com6

Reference ArchitectureXenDesktop and XenMobileServersIn the hardware layer, each server blade was configured as follows:Three blades were configured in a cluster to support the control layer VMs. This configurationallows a physical server to fail without affecting the user experience. To support the HSD, ninephysical servers were configured in a cluster, and two two-server clusters were created to supportthe VDI servers.A second enclosure of servers can be added, leveraging the infrastructure VMs in the firstenclosure, as shown below:In this scenario 12 blades are dedicated to HSDs, two blades to random pooled, and two blades tostatic pooled with personal vDisk. The total number of users supported depends on how manyHSD as opposed to VDI servers are configured. It may be necessary to run some additionalProvisioning Services or SCVMM servers on the second enclosure for better performance. Toprevent underutilization of a physical server, the additional infrastructure servers were run on theHSD cluster of physical servers, reducing the number of HSD VMs by one for each infrastructureVM. These additional infrastructure VMs were part of the sites defined in the primary enclosure.In this architecture, all blades were HP BL460c Gen8 blades with: CPU: 2 x Intel(R) Xeon(R) CPU E5-2670 @ 2.60GHz (8 Cores), HyperThreading enabled and thePower/Performance profile set to high Memory: 192 GB Disk: two 300 GB HDD, Raid 1, to hold the Windows Server 2012 R2 operating systemcitrix.com7

Reference ArchitectureXenDesktop and XenMobileNetworkingNetworking was based on using four VLANs at the physical level, and creating a single VM networkwithin Hyper-V to connect the VMs to the correct VLANs.The four VLANs fit into the different layers as follows:At the physical layer four networks were created: DC Management – 3 GBps, for handling infrastructure network trafficDC Storage – 5 GBps, for storage to server networkingDC Guest – 7 GBps, for internal user network trafficExternal – 5 GBps, for connecting to the Internet from NetScalersHP’s Virtual Connect technology was used to set the network speeds. Within the Hyper-V 2012 R2environment a VM network was created using SCVMM. Each of the VLANs was defined as astandard switch within Hyper-V. The network adapters in each VM were then connected to thecorrect standard switch/VLAN using the VM network.citrix.com8

Reference ArchitectureXenDesktop and XenMobileThe following diagrams show the Hyper-V network layout:citrix.com9

Reference ArchitectureXenDesktop and XenMobileStorageFor storage, an existing EMC VNX8000 with 15 shelves of 600 GB 15K drives, two storageprocessors, and eight data movers were used to support the virtual desktop environment. Thisstorage is more than sufficient to support the storage requirements for this design and could beused to expand user capacity going forward. The iSCSI connections for the virtual desktopenvironment were served by the two storage processors.The following tables define the LUNs created:Module 1 LUNSTypeSize GBPurposeiSCSI1800M1 WS2012 HSDiSCSI2Witness LUN M1 HSDiSCSI1350M1 Win81 VDIiSCSI2Witness LUN M1VDIiSCSI2475M1 WIN81 VDI Personal vDiskiSCSI2Witness LUN M1 VDI Personal vDiskiSCSI625SCVMM LibraryiSCSI3045Hyper-V Common InfraiSCSI2Witness LUN M1INFRAiSCSI2200M2 WS2012 HSDiSCSI2Witness LUN M2PVDiSCSI2025M2 Win8 VDIiSCSI2Witness LUN M2PVDiSCSI2475M2 Win8 VDI Personal vDiskiSCSI2Witness LUN M2PVDiSCSI625Provisioning Services 3 vDisk StorageiSCSI663M2 User ProfileSoftwareCitrix XenDesktop overviewXenDesktop 7 is a reimagining of application and desktop virtualization for the mobile and cloudera that transforms apps and desktops delivery. XenDesktop 7 allows customers to select, configure,and scale more mobile use cases more quickly, easily and economically than ever before.With XenDesktop 7.1 and the FlexCast Management Architecture, from a single site and a singleconsole, customers can support three generations of Windows Server, from Windows Server 2008R2 to Windows Server 2012 R2 as well as 16 bit, 32, or 64 bit apps through a combination ofWindows 7, Windows 8, or Windows 8.1.citrix.com10

Reference ArchitectureXenDesktop and XenMobileOne of the major changes at XenDesktop 7 is the concept of a unified architecture andmanagement for XenApp and XenDesktop. Unlike previous deployments requiring separateinfrastructure for XenApp and XenDesktop, the unification of the architecture enablesadministrators to design and deploy a single delivery infrastructure for delivering applications(formerly XenApp) and desktops (formerly XenDesktop).Citrix XenMobile overviewDeployed alongside XenDesktop or XenApp, XenMobile enhances mobile security by ensuring thatall devices—corporate-owned or BYOD—are compliant before they access the enterprise network.With XenMobile, IT administrators gain a centralized tool for managing and controlling BYODdevices used to access corporate resources, including all the desktops and apps delivered throughXenApp and XenDesktop. Simply put, XenApp and XenDesktop centralize management of virtualapps and desktops, and XenMobile centralizes the management of BYO and corporate-issuedmobile devices. The mobile device management (MDM) solution lets you: Enforce password protection for the device’s lock screen Restrict corporate network access from jailbroken devices and blacklisted applications Enable encryption for select applications and data at rest and in motion—an especially importantcapability if your XenApp and XenDesktop policies enable drive mappingSoftware componentsThe following table defines the software versions deployed:ComponentVersionVirtual desktop brokerCitrix XenDesktop 7.1VDI desktop provisioningCitrix Provisioning Services 7.1Endpoint clientCitrix Receiver for Windows 4.1User profile managementCitrix Profile management 5.x (included in XenDesktop)VDI personalizationCitrix Personal vDisk 7.1Web portalCitrix StoreFront 2.1LicensingCitrix License Server 11.11.1Workload generatorLogin VSI 4.0.x (4.09)Office softwareMicrosoft Office 2013Virtual desktop OS (VDI desktops)Microsoft Windows 8.1 x64Virtual desktop OS (hosted shared desktops)Microsoft Windows Server 2012 R2Database server for SCVMM, XenDesktop Controllers,Provisioning ServicesMicrosoft SQL Server 2012 R2Database server for XenMobile Device ManagerMicrosoft SQL Server 2008 R2VDI hypervisor managementMicrosoft SCVMM 2012 R2VDI hypervisorMicrosoft Windows Server 2012 R2 with Hyper-V &Failover Clustering Rolescitrix.com11

Reference ArchitectureXenDesktop and XenMobileComponentVersionNetScaler softwareCitrix NetScaler device managementCitrix XenMobile Device Manager 8.6XenMobile App ControllerCitrix App Controller 2.9NetScaler Insight Center Citrix NetScaler VPX for XenServer Implementing the designInstallation considerations and concernsAs stated previously, the aim of the design was to use existing servers and storage and size theenvironment to the hardware available. The number of VDI users per physical server was limited bythe amount of memory in each physical server. The random pooled and static pooled VMs had 2GB per VM and the physical servers had 192 GB. The number of users per physical host was set to90 to ensure that the total assigned memory was less than the total available memory; the aim ofthis was to provide the best user experience and to use the dynamic memory capabilities ofHyper-V for any sudden changes or increased requirements in the environment.Configuring NetScalerThe environment used two NetScaler MPX -10500 appliances with: 8 CPUs 2 1GB ports for management 16 1GB ports for dataThe NetScalers were configured with three Virtual IPs (VIPs): one for the XenDesktop users and twofor the XenMobile users. Appendix A shows some of the screen shots from configuring theNetScalers. Some configuration settings worth noting: Use the X-Forwarded-For client header as specified in In the LB Services group for StoreFront, modify the persistence method: change it fromCOOKIEINSERT to SOURCEIP. Add a hosts file entry on the StoreFront servers to resolve the URL to its own local IP address. For the NetScaler gateway , the callback URL should be the same as the external access URL: forfurther details, see On the NetScalers, go under SSL and make sure that the certificate you are using for the AGEE is linkedcorrectly to the intermediate, and that the intermediate is correctly linked to the root certificate.StoreFront considerationsLoad-balanced StoreFront VMs were configured to provide support for up to two modules and toallow for the potential failure of one of the StoreFront VMs. A basic installation was performedwith the StoreFront software, and then a certificate was created to manage authentication andaccess. The following screens show the configuration:citrix.com12

Reference Architecturecitrix.comXenDesktop and XenMobile13

Reference Architecturecitrix.comXenDesktop and XenMobile14

Reference ArchitectureXenDesktop and XenMobileOnce the store was deployed, authentication was configured with user name and password andthe site domain as the only trusted domain. The StoreFront VMs were joined to a server group, andthe NetScaler Gateway appliance was selected with no VPN tunnel.VDI infrastructure VMsFor the infrastructure VMs a Cluster Shared Volume was created between the physical servers tohold the VMs and create a high availability (HA) environment.Infrastructure VMsVMNo.of VMsOSVHD GBvCPUMemory GBNotesXD Controller VMs22012 R24048XenDesktop brokersStoreFront22012 R24048ProvisioningServices22012 R240416License server22012 R24024App Controllers22012 R24024AD/DNS/DHCP2012 R2Two license servers: onefor Citrix and one forMicrosoftImplemented asphysical server tosupport WDSMobile devicemanagement12012 R24028Configured for labenvironment, need towork with consulting tosize correctlySQL22012 R2120412AlwaysOn configurationwas used for XenAppand XenDesktopHDX Insight 124024VM on XenServer 6.2serverThe VHD for each VM was created as a dynamic VHD. Two physical hosts were configured withWindows Deployment Services, SCVMM, and SQL AlwaysOn as well as the root Active Directory. Thiswas done to allow the use of Windows Deployment Services and SCVMM for bare-metal deploymentof the physical servers. This SCVMM installation was used to manage the entire environment.Two servers were configured to carry out deployment of the other physical servers. The first server wasconfigured as a root AD/DC server with a single forest/domain and ran DHCP, DNS, NTP, andCertification Authority. The second server was configured with Windows Deployment Services andSCVMM to manage the infrastructure Hyper-V cluster and perform the bare-metal server deployment.Profile managementProfile management 5.0 was used to manage user profiles. It was configured with a separate share tostore the profiles, and also configured to leverage Group Policy Management to manage the profiles.citrix.com15

Reference ArchitectureXenDesktop and XenMobileWhen using personal vDisk, by default the user profile is stored in the personal vDisk file. Whenusing Profile management, in order to save space you should prevent the user profile from beingdirected into the personal vDisk file by editing the registry as follows: KEY: “HKLM\Software\Citrix\personal vDisk\Configuration” VALUE: “EnableUserProfileRedirection” 0 profile is not directed to the personal vDisk 1 profile is redirected to the personal vDisk (this is the default)Caution! Using Registry Editor incorrectly can cause serious problems that might require you toreinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrectuse of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up theregistry before you edit it.For more details see ioning ServicesProvisioning Services 7.1 was used to deploy the VMs. DHCP was configured to run on anotherdomain controller, and PXE was configured to run on the Provisioning Services servers. Please notethe following when using Provisioning Services 7.1: Best practice is to apply the latest hot fixes from Citrix. You must attach a network adapter to a logical network in the template, otherwise VM creation will fail.Hosted shared desktopsThe HSD VMs were configured as follows: 4 vCPU12 GB RAM80 GB VHD25 GB Write Cache File with 24 GB fixed Page File, stored on SAN clusterEach physical server supported 4 HSD VMs, giving a total of 36 HSD VMs across the nine physicalservers in module 1. In our environment each HSD supported 50 users, so 200 users per server weresupported with a total of 1800 users for module 1 in our design2. The loss of a physical server wouldmean the loss of four VMs and 200 users. This means that each remaining VM would need to supportapproximately 6-7 additional users and still remain within the acceptable performance levels.Each HSD VM was installed with Windows Server 2012 R2. The HSD VMs were configured in acluster to allow server migration if a physical server needed to be brought down for maintenance.For HA, the overall site was configured so that each HSD VM worked at about 80-90% capacity andif a physical server failed it was not necessary to restart the HSD VMs on different serversimmediately because the users would be absorbed by the other VMs in the site. We determinedthe HSD VM performance using the Mobilizing Windows Apps FlexCast Services Design Guide3 .For more information about XenApp scalabilty see citrix/en ide.pdf?accessmode direct23citrix.com16

Reference ArchitectureXenDesktop and XenMobileVDI – random and static pooledBoth random and static pooled VMs were configured as follows: 2 vCPU2 GB RAM40 GB VHD4 GB Write Cache file with fixed 3GB Page file, stored on SAN clusterFor static pooled VMs using personal vDisk, the vDisk was 10 GB in sizeTwo clusters were created: one for random pooled and one for static pooled with personal vDisk.The physical servers had 192 GB of RAM and each VDI VM had a maximum of 2 GB of RAM. Eachphysical server supports a maximum of 90 VDI VMs, leaving 12 GB of RAM for the operating system.XenMobile configurationA third physical server was added to the management cluster to support the XenMobileinstallation. The installation process followed the Citrix Reference Architecture for mobile devicesand app management4. The installation focused on the MDM for managing devices and the SQLconfiguration to support MDM. The installation was not configured with HA, although Citrixrecommends an HA configuration. Contact your Citrix Consultant for the best approach to buildingan HA XenMobile installation. The VMs were configured as follows:VMNo.of VMsVHD GBvCPUMemory GBXenMobile Device Manager14024XenMobile SQL Server14026App Controllers14024Test setup and configurationSummaryThe goal of this test was not to determine the maximum number of users that could besupported, but to follow Citrix best practices and ensure that the environment worked for thosenumbers and recommendations.For the infrastructure VMs, the second VM was added strictly for HA purposes; a single VM wouldhave been more than sufficient to support the number of users, and this is also true for the twoNetScaler appliances.As stated previously, the HSD/HVD was an 80/20 mix, with the HVD configured 50/50 betweenrandom pooled and static pooled with personal vDisk. For the local/remote mix, 80% wereconfigured as local, 20% as remote, and 1000 XenMobile users were configured.In the testing there was no intention of stressing or investigating the performance of either XenDesktopor XenMobile, but to show that the two could function successfully in the same data en m17

Reference ArchitectureXenDesktop and XenMobileClient test toolsTo drive the XenDesktop workload, LoginVSI 4.0 was used. 20% of the client launchers wereconfigured to be remote and to connect through the NetScaler; 80% were configured as localusers connecting directly to StoreFront. Each client launcher session was configured to support 15sessions, and each HP BL460c G7 host was configured to support 12 client-launching VMs.A Citrix-created tool was used to drive the XenMobile workload. This tool simulates a connectionbetween a client device and the App Controller within the data center, creating micro VPNconnections through the NetScaler. The tool creates three micro VPNs per connection, so 1000users create 3000 connections through the NetScaler. With this version of the tool no actualXenMobile applications were started. The test tool simulates IOS, Android, and Windows mobileconnections. For our testing a 50/50 mix of IOS and Android connections was used.ConclusionThe physical servers had 192 GB of memory, which limited the number of hosted virtual desktop(HVD) users that could be supported per physical server. Each HVD was created with 2 GB ofmemory, so the number of users per server was restricted to 90 to prevent memory over-commit.Sizing under the memory maximum allowed for taking advantage of memory over-commit ifconditions or user counts changed on the physical server.For our configuration of the hosted shared desktop (HSD) VMs, support was set to 50 users perVM. For a different VM configuration the number could successfully be varied.For XenMobile use, the user count was set to 1000 (approximately 50% of the XenDesktop users ina module). As stated previously the goal was not to maximize the number of XenDesktop andXenMobile users but to establish a range that provides an optimal user experience for the amountof hardware used.The Citrix-developed test tool that was used to simulate mobile users supports both IOS andAndroid connections and creates micro VPN connections to the XenMobile App Controllers. A mixof 50/50 IOS and Android connections was used. The tool creates three micro VPN connectionsper test tool user connection, so 1000 users generate 3000 micro VPN connections. We excludednew user connections, which create five or more micro VPN connections during device registrationwith the XenMobile Device Manager (XDM). The NetScalers were configured to do SSL offloading.With the servers assigned and configured in conjunction with the EMC enterprise storage used tosupport our environment, we were able to support 1800 HSD users and 360 HVD users in our firstmodule, which also supported the infrastructure VMs required to run the environment. This alignedwith our aim of 80% HSD users and 20% HVD users. The first module consisted of 16 HP BL460cGen8 blades: three dedicated to supporting XenDesktop infrastructure (Brokers, SQL databases,license servers, and Provisioning Services servers) running as VMs as well as the XenMobile XDMand App Controller VMs, nine servers to support HSD, and four servers to support HVD.Adding a second module of 16 servers required adding two more Provisioning Services VMs and anadditional SCVMM VM. To avoid having to use two servers to support only three infrastructure VMs,the VMs were run on the HSD cluster in the second module. The number of HSD VMs was reducedcitrix.com18

Reference ArchitectureXenDesktop and XenMobileby three. For the second module 12 physical servers were in the HSD cluster, supporting 2250 usersin 45 HSD VMs and the three infrastructure VMs. Four servers were used to support the HVD,totaling 360 users.Appendix A: NetScaler configuration screensThe following screenshots show how the NetScaler was configured.Creating VIP to StoreFront for XenDesktopcitrix.com19

Reference ArchitectureXenDesktop and XenMobileConfiguring load balancingcitrix.com20

Reference Architecturecitrix.comXenDesktop and XenMobile21

Reference ArchitectureXenDesktop and XenMobileCorporate HeadquartersFort Lauderdale, FL, USAIndia Development CenterBangalore, IndiaLatin America HeadquartersCoral Gables, FL, USASilicon Valley HeadquartersSanta Clara, CA, USAOnline Division HeadquartersSanta Barbara, CA, USAUK Development CenterChalfont, United KingdomEMEA HeadquartersSchaffhausen, SwitzerlandPacific HeadquartersHong Kong, ChinaAbout CitrixCitrix (NASDAQ:CTXS) is a leader in mobile workspaces, providing virtualization, mobility management, networking and cloud services toenable new ways to work better. Citrix solutions power business mobility through secure, personal workspaces that provide people withinstant access to apps, desktops, data and communications on any device, over any network and cloud. This year Citrix is celebrating 25years of innovation, making IT simpler and people more productive. With annual revenue in 2013 of 2.9 billion, Citrix solutions are in use atmore than 330,000 organizations and by over 100 million users globally. Learn more at 2014 Citrix Systems, Inc. All rights reserved. Citrix, XenDesktop, Citrix Receiver, HDX Insight, XenMobile, XenApp, FlexCast, CitrixProvisioning Services, NetScaler, NetScaler Insight Center, NetScaler VPX, XenServer, NetScaler MPX and NetScaler Gateway are trademarksof Citrix Systems, Inc. and/or one of its subsidiaries, and may be registered in the U.S. and other countries. Other product and companynames mentioned herein may be trademarks of their respective companies.0614/PDFcitrix.com22

Reference Architecture XenDesktop and XenMobile Reference Architecture This document is intended for IT architects who want to deliver secure business mobility for their organizations. It describes how to use XenDesktop 7.1 together with XenMobile 8.6 to provide users with seamless