The document outlines the considerations for implementing Citrix XenDesktop as a desktop virtualization strategy, highlighting its flexibility, cost-effectiveness, and performance. It discusses the architecture, components, and user experience enhancements while posing several critical questions for organizations to define their goals and deployment strategy. Key factors include network and storage management, user categorization, and application delivery methods.

1. Desktop Virtualization with Citrix
Confidential

2. Agenda
• Challenge – Is Citrix XenDesktop the right choice for you desktop
virtualization strategy?
• Goal Definition –What does this need to look like at the end?
• Sketching the Possibilities – Architecture
• Considering the Correct Modules – Component Overview
• Application Delivery – Virtualized & Non-virtualized Applications
• User Experience – Making the End User Experience Shine
• Solidifying the Design – Reviewing Your Module Choices
• Deciding on the Solution
Confidential

3. Challenge
Is Citrix XenDesktop the right choice for your
desktop virtualization strategy?
Confidential

4. Challenge…
Confidential
The “Challenge” is ours; to illustrate why be believe the following to be true:
We think that XenDesktop and the supplementary technologies represents the most
flexible, cost-effective, best performing virtual desktop solution. The solution is as
simple, or as complex, as your strategy needs it to be.
• Flexibility – The modular approach to XenDesktop allows you to customize the
environment to your needs.
•Cost-effective – XenDesktop was designed to integrate with existing
virtualizations solutions, reduce storage requirements, and provide a consistent
user experience.
•Best Performing – Built upon proven technology, XenDesktop brings a high
definition user experience while utilizing minimal bandwidth.

5. Goal Definition
What does this need to look like at the end?
Confidential

6. Goal Definition…
Questions about your environment that require answers.
 What is the scope of your deployment?
 How do you categorize your users’ desktop environment?
 Job function, location, department, etc.
 When desktops are virtualized, who will be responsible for the
various components?
 How will you migrate your users to the new virtual desktop?
 What do you plan to do with the existing desktops?
 What is your network capacity in the datacenter? To the wiring
closets? To the desktops?
 Do you have branch offices? Will they be part of this initiative? If
so, what are the link parameters?
 Will you be providing remote desktop access?
Confidential

7. Goal Definition…
More Questions
 Are you upgrading the OS as well as the delivery platform?
 Are you upgrading applications with the new desktop
image(s)?
 What is/are your target pilot size, scope, timeframe, and
success criteria?
 What is your RPO/RTO for an individual virtual desktop?
 Do you require HA desktops? For everyone?
 Do you have a defined SLA and/or stratified SLAs?
 And so on…
Confidential

8. Goal Definition…
Points to Consider
 Network connectivity is paramount.
 Storage management is vital.
 A desktop virtualization implementation blends the
traditional separation of IT roles.
 Not all applications are good candidates for
virtualization.
Confidential

9. Goal Definition…
Goals will be defined based upon the answers.
Confidential

10. Sketching the Possibilities
Architecture
Confidential

11. Architecture…
Subject matter areas to be considered:
• Procurement and Provisioning
• Desktop Administration
• Server Administration
• Storage
• Network and Security
• Application Ownership
• End User Experience/Client Device Owners
• Operations
Confidential

12. Microsoft/Citrix/AppSenseTechnologiesStack
Confidential
Storage and Data Protection

13. Architecture…
Confidential
File/Profile Server
CIFS
ICA
SQL
SQL
SC
SC
XML
SC Configuration Manager
`
SC Operations Manager
SC Virtual Machine Manager
SQL Server
Desktop Delivery
Controller
Web Interface
Citrix License Server
App-V
AppSense Server
SC
Provisioning Server
SQL
SQL
SQL
PVS
Hypervisor
SQL
HTTP/S
User Machine
XenApp
AS
ICA
SQL
XML
ICA

14. Six Main Components
 Desktop Receiver – Citrix Online Plugin, Citrix Offline
Plugin
 Storage – Centralized storage for the environment.
 Virtual Desktop – Centralized user desktop
deliverable.
 Desktop Delivery Controller – Management of virtual
desktops.
 Application Delivery Controllers – Getting the apps to
the users’ desktops.
 Provisioning Server – Single image management.
Confidential

15. Considering the Correct Modules
Component Overview
Confidential

16. Storage
 Be sure to check your with your hypervisor vendor and storage
vendor for best practices regarding VMs/LUN, IOPS/disk, etc.
 SAS disk (or better) is preferable for large deployments.
 Large amount of repetitive disk reads.
 Planning for storage is highly dependent on the XenDesktop user
categorization:
 High percentage of “pooled” desktops – Less disk required.
 High percentage of “private” desktop – More disk required.
 Citrix utilizes StorageLink for Hyper-V and XenServer storage
management.
 Simplifies storage provisioning to the hypervisor hosts.
 Support for multiple vendors.
 Turnkey site recovery support.
Confidential

17. Hypervisor
 The hypervisor, at minimum provides the virtualization
platform for:
 Virtual desktops.
 But can, and often does, host other infrastructure modules
as well.
Confidential
• Desktop Delivery Controller
• Citrix Web Interface
• Citrix Licensing Server
• XenApp Servers
• Provisioning Services*
• System Center components
• Database server(s)
• App-V Server
• AppSense

18. Provisioning Services (PVS)
 Hosts one or more images for use in pooled and private
virtual desktops
 Can also be used to host other “template” Windows servers
(e.g. XenApp, WebInterface, etc.)
 All PVS clients have either a relatively small virtual hard
disk attached or no disks attached.
 Small VHD – a “local” write cache for temporary data.
 No VHD – Use a PVS-defined write-cache location.
 PVS clients use a PXE boot to connect to the PVS
Streaming Service. The streaming service delivers the
image via the network.
 PVS client to server ratio is 500:1.
Confidential

19. Provisioning Services (PVS)
 In XenDesktop implementations, PVS images are generally used in either
Standard image mode or Private image Mode.
 Standard – Image is read-only. Writes only take place to the write-cache and are
deleted upon client reboot. This is the mode used in a pooled desktop scenario.
 Private – Image is read-write capable. Writes are written directly to the PVS
image. Only one connection can be made to an image in private image mode:
 An unused copy of the pooled image during updates.
 When a user requires that their local desktop changes be persistent (outside of profile-
managed settings.)
 PVS images are created via the XenConvert utility.
 Images are created while the source machine is online.
 XenConvert will prompt you to automatically optimize the environment for PVS
delivery.
 Connections to the PVS disk are handled via the PVS target device client.
Confidential

20. Provisioning Services (PVS)
Active Directory Integration
 Client names are modified on the fly by the Streaming
Service.
 PVS controls the Active Directory computer account
password for each registered MAC address including
computer account creation, password management, and
deletion.
 PVS handles SID generation/masking for each client
device.
 When creating multiple virtual desktops use the
XenDesktop Wizard; it handles client device name/MAC
registration in PVS.
Confidential

21. XenDesktop
 The Desktop Delivery Controller (DDC) is the component that:
 Handles communication with the hypervisor hosts to manage virtual desktop states.
 Virtual desktop accessibility/security by user/group.
 Publishes information about the available virtual desktops to WI.
 Ensures a XenDesktop license can be acquired.
 Handles all communication with the virtual desktop’s XenDesktop Agent (XDA).
 Assigns, brokers, and then monitors connections from a end user device to the designated
virtual desktop.
 Ensures each pooled desktop group’s idle pool limit* is met. If not, it spins up/down a
random machine(s) selected from the pool until the condition is satisfied.
 DDCs are registered along with the farm name in Active Directory. No schema extensions
required.
 Virtual desktops are assigned to Desktop groups.
 Desktop groups can be:
 Pooled – The user can be attached to any available virtual desktop.
 Assigned – Users are assigned to a specific virtual desktop.
 Assigned on First Use – User is allocated a permanent virtual desktop from an available pool.
 Users are then assigned to desktop groups.
 Very similar to publishing an application in XenApp.
Confidential

22. XenDesktop
 A desktop group is limited to one hypervisor type:
 The DDC utilizes the native management of the
hypervisor to read/execute instructions on the
hypervisor hosts.
 One DDC, however, can manager multiple desktop
groups even if they are assigned different hypervisors.
 The virtual desktop to DDC ratio is 1000:1.
 DDC redundancy is a good idea. For large farms, you
will want to dedicate a DDC “master” that does not
have desktop groups assigned to it but manages read-
write access to the data store.
Confidential

23. Applications
 Applications can be delivered by the following methods.
 Locally – that is local to the PVS image (i.e. written into the
image.)
 Hosted – Application executes on a remote machine and then
delivers the user interface to the virtual desktop (traditional
XenApp.)
 Virtualized
 App-V – Application is installed into a remotely stored, but locally
executed, execution environment called a “package.” App-V does not
modify the local image permanently.
 Citrix Streaming – Application is installed into an OS-dependent
package that hooks all writes to the local registry and file system into
a reserved portion of the file system. Like App-V, it is remotely
stored but locally executed and no permanent changes are made to
the image.
Confidential

24. Virtualized Applications
 Virtualized applications have the advantage of being centrally
stored and are therefore easily upgradable.
 A modified package is delivered the next time it is executed. Only
the changed bits are sent.
 Virtualized applications can be isolated from other applications.
 For example, you can run two versions of Microsoft Office on the
same machine (two packages or one locally installed office and the
second virtualized)
 Virtualized applications can be made to interact.
 For example, if you have an virtual app that requires Adobe
Reader(and Adobe Reader is packaged), you can allow that virtual
app access to the package containing Adobe Reader.
 Initial launch time varies depending on the size of the package.
 To reduce launch time, virtual apps can be pre-staged into the
image.
Confidential

25. Application Virtualization Decisions
 Globally Delivered Applications: Local.
 Office is usually a safe example of an app that everyone gets. If there
is no need to virtualize it, don’t; build it into your image.
 Applications with limited users: Hosted or Virtual.
 If the application supports Terminal Services, hosted is usually the
quickest option (build it into your PVS image for that XenApp silo.)
 If not, virtualize the application so that any updates and/or
maintenance/break-fix are centralized.
 Applications that update on a per-user basis: Local or hosted.
 For smaller groups of users in this situation, an assigned desktop
may be the expedient choice.
 For large-scale deployment, you will really need to understand the
nature of the updates to make a decision. Hosted is usually going to
be the most manageable solution.
Confidential

26. User Experience
Making the End User Experience Shine
Confidential

27. User Experience
 Applications look the same to the end user no matter
how they are delivered.
 There are multiple application access interfaces. Choose
one, two, or all.
 Citrix Online Plug-in: Icons appear on the users’
Desktop/Start menu. Can be administratively or user
controlled.
 Web Interface: Virtual desktops and applications can be
published in a tabbed or unified format. Ratio of 1000:1.
 Enterprise App Store: An iTunes-like interface that allows the
user to choose which apps they see on their desktop.
Confidential

28. User Experience
 User Customization & Personalization
 Traditional Model: Roaming, Mandatory, or Hybrid Profiles
 New Model: Policy-based Profile Management
 Citrix Profile Manager is built into the XenDesktop.
 ADM template integration into GPOs make management familiar.
 No more “last write wins” with roaming profiles.
 Profile streaming.
 AppSense gives hyper-granular management of the user’s
experience.
 Policy-based, administratively enforced settings.
 Point in time recovery on a per application basis.
 Parallel policy execution with inclusion/exclusion criteria.
 Process-driven policy execution.
 Existing profile import, quick migration between platforms.
Confidential

29. User Experience
ICA Enhancements - HDX
 High Definition video/audio. (<30 ms latency, but is
customizable)
 Flash/Multimedia Acceleration.
 Printing – Universal print driver is hitting about 85-95%
 USB Redirection – Users plug in a USB stick to their
device, XenDesktop recognizes it and adds it as a
mapped client drive.
 Multi-monitor support (up to 8.)
 Nominal bandwidth is ~56-64kbps (non-HDX.)
Confidential

30. Deciding on the Best Solution
Confidential

31. Deciding on the Best Solution
 Infrastructure - All modules can be added/removed
except:
 DDC
 Citrix license server
 Hypervisor host
 Provisioning Services - You can deliver one image or
twenty. XenDesktops only or multiple farms of
XenDesktop, XenApp, and Web Interface. You can even
use PVS to stream to hardware directly.
 Applications - Image-local apps only, virtual apps only,
or a mix. From the end user perspective, it stays
consistent.
Confidential

32. End of Presentation
Confidential

33. *For Those Who Want to Go Deeper
 From boot-up to user-level access, the process:
 Hypervisor receives instruction to start a virtual machine.
 Virtual machine boots to PXE.
 PXE/TFTP service delivers boot image with up to four PVS servers.
 Virtual machine installs boot image and contacts the PVS streaming
service, OS begins streaming.
 Once the base system DLLs have loaded and the PVS target device
streaming service starts, it takes over from the initial loader.
 Once the XDA is loaded it tries to contact the last DDC it communicated
with. If it is not available, the XDA queries Active Directory for the
location of a DDC.
 The XDA then registers itself with the DDC.
 The DDC begins to query the virtual machine to see if it is ready to
accept connections.
 The XDA indicates that it is fully booted and can accept connections.
 The next/assigned user is able to connect.
Confidential