Mid May I presented a methodology to successfully migrate physical PCs to a virtual desktop environment delivered by Citrix XenDesktop. The key area of focus was thereby around the planning and performing of a migration.

During this TechTalk, not all questions could be answered and therefore, I would like to share the related information below. In case you miss a question not being answered or have further questions, please use the comments field and I will get back to you.

Since many of the attendees asked for the presentation, you can download it from here.

I hope the migration methodology provides guidance during a transition from physical PCs to virtual desktops and don't skip the planning phase since this will ensure a successful migration.

Tarkan

Follow me on Twitter: http://twitter.com/TarkanK

Questions & Answers

Q: What is the best practice for implementing XenApp to deliver applications? A physical or virtual server?

This is a good question. In the past, we followed a best practice "never ever" virtualize a Terminal Server or XenApp server since real-time work was impacted. However, virtualization of workloads made so much progress that this is negligible compared to the benefits you can gain with it. Therefore, if you have a virtualization infrastructure based on XenServer, I would recommend using virtual machines to provide XenApp since you will benefit from the XenApp specific optimizations on XenServer as well as have a more dynamic server management rather than being dependent on a physical machine. Other benefits are definitely around hardware savings, power and cooling costs (even though you will have probably a bigger box for the virtualization infrastructure).

Q: From the application delivery perspective, the slides suggest that streaming is the primary (and recommended) method. Hosted seems to be a secondary method. Why is it *not* recommended to put the "Core" (Office, Adobe Reader, etc.) applications installed on the Virtual Desktop?

The easiest way of delivering apps is probably by installing them into the virtual desktop and you are good to go. There is nothing against this approach. Using this approach for core applications such as Microsoft Office, Adobe Reader is definitely doable; especially considering the fact of Microsoft Office 2007 updates being integrated into the Microsoft Windows Update mechanism simplifies the Office update process.

However, reasons for primarily recommending streaming as the choice for even core apps is mainly driven by the following points:

• Allows virtual desktops being slimmer, especially if hosted apps are used, increasing the number of concurrent virtual machines on a virtualization host.
• Central delivery of applications to virtual desktops, physical desktops, and XenApp servers.
• Simplifies virtual desktop OS maintenance and upgrades

The key for a successful app delivery strategy is that it needs to meet your requirements for app criticality, app type, update frequency, resource usage, and compatibility. Considering these areas may even lead to an app delivery solution leveraging all three methods. My coworker Daniel Feller already created a blog Simplifying Application Delivery into the Virtual Desktop that gives some insights as well.

Q: What is the tested maximum number of Windows XP virtual desktops in a single XenDesktop farm?

We are conducting regular tests based on the latest XenDesktop release version to verify scalability of a XenDesktop farm. However, bear in mind the fact that XenDesktop is a collection of components that interact with each other and each components scalability such as Desktop Delivery Controller, Provisioning services, and virtualization infrastructure may impact the overall architecture. The most recent test results (that were shared during the Citrix Synergy session "iForum221 - Advanced strategies for virtual desktop scalability") simulated a XenDesktop farm with a 9 am logon storm scenario. In this scenario, the XenDesktop farm could easily handle 4,500 logons to virtual desktops within 15 minutes and the peak CPU utilization was at 60% and memory at 2 GB (used hardware specs: dual quad-core, 1.8 GHz, 16 GB RAM). Once the Desktop Delivery Controller brokered a connection, it is not very active. Therefore, the next stop for scalability to look for is Provisioning services and the virtualization infrastructure. In this case factors such as used server hardware or virtual server configuration impacts the scalability and the virtual desktop type (user, OS, workload).

Q: Migrating from physical desktops to virtual desktops, how do you calculate how many users you can get on a server?

This is exactly the point, where the assessment as part of the planning phase is important to have. Therefore, you should assess the following:

• Target virtual desktop OS type - Windows XP, Windows Vista, or Windows 7
• Desktop hardware requirements (CPU, memory, network) to apply the right configuration to virtual machines
• Storage space

Based on this information and the target server hardware running the virtualization infrastructure will allow you a better sizing estimate. Better is to run a scalability test on at least a single server.

Q: Where would you start the migration process for a company with 200 users and 7 different departments?

As part of the migration planning, one action item is definitely to define the migration process. To do so, there are some factors influencing this process, which is not solely depending on the number of users or departments:

• Hardware refresh requirement
• OS upgrade requirement
• User groups
• Maintenance schedules

This should allow the prioritization of where to start and how to sequence the migration process.

Q: Users will want their music files (currently stored on desktop). We have cheap disk but it's only available as NFS (putting this on the SAN is not an option due to expense of storage and low business value of the MP3s). Any idea how we could make this work, maybe by dynamically creating an NFS mount for each user, say an E drive?

One key benefit of XenDesktop is the user experience provided by HDX (High-Definition user eXperience). Leveraging this capability allows mapping of USB drives or local drives of an endpoint into a virtual desktop running in the datacenter. This provides users' access to their files, in this case MP3s and therefore, IT does not need to handle this. However, IT should consider related security measurements and the impact on LAN/WAN usage if users have large files to copy.

Q: Can you share a base image disk among multiple desktops?

This is the key benefit of Provisioning services to provide a vDisk to be shared by multiple desktops. These are the available vDisk types:

• Standard Mode - read only OS image and shareable with multiple desktops
• Private Mode - read/write OS image and is assigned to a single desktop (not shareable)

Q: Is there some type of sysprep or utility that needs to be run every time the vDisk is opened up? Does Provisioning Server handle this and dynamically provide a Windows hostname when a Virtual Desktop is booted up?

Provisioning services does not require sysprep to allow sharing of a single vDisk by multiple virtual desktops. Once the "golden" image has been created, Provisioning services takes care about computer accounts and the computer account passwords within the Active Directory. This is also the reason, why Provisioning services should be setup with domain administrator rights. A more comprehensive overview of this process is described in the Provisioning services Administrator's Guide - section "Managing Domains and Active Directory Integration".

Q: If the master image gets updated on Saturday after all users have logout, will there be any delay in OS delivery when the users come in next Monday?

If the master image has been updated on Saturday and you know how many logons you have simultaneously on Monday, you can adjust the setting "Idle Pool" of a Desktop Group. This Desktop Group setting allows you to configure how many idle desktops (booted and waiting at the Windows logon screen) you want in your pool at certain times of the day. You can also configure a peak period to cover the time at which most users will be logging on to their desktops. This period starts at the beginning of your business day.

Q: How do you manage (add/delete) applications on the golden image? Is there a tool to do this?

Due to the fact that the golden image is a read only OS image and this golden image needs to be started in Private Mode (read/write). If the OS or applications need to be updated in the golden image, the best approach is:

1. Take a copy of the file and rename it to reflect a newer version
2. In Provisioning services, change the newer version of the golden image into Private Mode
3. Assign this golden image to a virtual machine and boot from it
4. Apply required changes and updates
5. Shutdown virtual machine
6. In Provisioning services, change the updated golden image into Standard Mode and assign it to the virtual machines

There is also a way to automate the assignment if the Provisioning services option "Automatic Updates" is selected and versioning of golden images is used.

Q: Is there a way to have two (2) different DHCP´s with only one XenDesktop farm?

Sure, however the DHCP scopes should not conflict in order to avoid duplicate IP addresses. As part of a redundant DHCP solution this would be Microsoft best practice called split scope DHCP.

Q: How is a dual monitor connected?

There is no requirement for any specific configuration on the endpoint device to support dual or multiple monitors for a virtual desktop. Multiple monitors are detected on endpoint device and virtual desktop is displayed across all monitors. A single virtual desktop can span up to 8 monitors in a rectangular shape (e.g. 1x8, 2x4), where each monitor must have the same resolution.

Q: How do I solve the road warrior without Internet? Is there a checkout feature available today or being planned?

At the current stage XenDesktop does not have a feature to support offline usage of virtual desktops. However, the showcased XenClient during Citrix Synergy will provide this capability in the near future. This is being developed as Project Independence.

I assume, everyone has faced challenges understanding XenDesktop licensing. It is a bit tricky, especially considering all the components available with XenDesktop Platinum. Some of them are licensed with Citrix License server, some of them have individual licensing. In addition, there are also some regulations through the End User License Agreement (EULA).

More importantly, understanding how a Citrix License server failure or connection loss affects the components is always good to know in order to consider this as part of a XenDesktop implementation.

The recently published whitepaper "Citrix XenDesktop Licensing Explained" provides insights into this and should help to license your XenDesktop implementation appropriately.

Why coffee break?  During logon time?  Our logon time is good, no issues there, and so on.  How many of you faced this situation at customers?  We assume quite a bit.  During all the years working at XenApp projects and recently started with XenDesktop projects at several customers, everyone probably faced that logon times are not usually the best.  Users get used to it and do not complain anymore, so there is no issue, because everyone has a coffee break!
Taking the latest announcement of Citrix about the acquisition of sepago's user profile solution shows again that there are still challenges out there requiring a solution for a stable user profile environment.

Asking administrators about their biggest challenges in a centrally delivered desktop environment, they will usually respond with either "printing" or "user profiles" related to logon and logoff process.  Exactly at this point, many administrators are not familiar with the executed background processes during logon and logoff, which makes troubleshooting difficult for further optimization.

Taking this into consideration, the logon process is usually the first impression an end-user will experience logging on to a centrally delivered desktop, which can be either a XenApp server or a virtualized desktop through XenDesktop.  If this process takes too long, the user acceptance will drastically suffer and leading to the fact that people start questioning a centrally hosted desktop or application infrastructure.

How is the logon process of a user? Roughly the following happens during logon:

1. The user launches a published application (XenApp) or published desktop (XenApp or XenDesktop)
2. Citrix component related processes such as load balancing or assigning a virtual desktop or verification of Microsoft TSCAL (XenApp)
3. Authentication of user at domain
4. Copy of user profile
5. Application of group policies
6. Execution of other processes such as logon scripts
7. Citrix specific processes such as mapping of client devices or printers
8. User access published application or published desktop

You may ask now, why is the logon process not detailed more granular? The answer is pretty simple: The logon details are too complex for XenApp or XenDesktop to be listed in this blog.  A good source to get an overview of what is happening during logon and logoff is at Brian Madden's website, which provides a flow diagram that can easily fill out a A3 format printout.

Now, knowing what is happening roughly, how can I diagnose my logon process?

A good starting point is to leverage Microsoft's built-in tool for logging all Windows processes during logon - the "User Environment Debugging".  This is by default disabled and can be enabled by adding a registry key, which is described Microsoft's Knowledge Base article 221833.

Another good tool is the usage of Citrix EdgeSight, where administrators have the option to isolate performance related issues since EdgeSight provides a user-centric view of delivered applications and desktops.  Furthermore, administrators can also leverage tools such as Windows Performance Monitor, Windows Systinternal Regmon and Filemon or other command line tools.

However, let's have a look at typical suspects for issues and the according screws to be used.

• Domain Controller.  This is the core of any Active Directory and the main component during the user logon process.  We could discuss this component in details filling an entire book; however want to highlight only a few relevant screws.
  • Ensure sufficient system resources
  • Properly running DNS (primary name resolution of Windows Server 2003)
  • Monitor your domain controller - especially during peak logon times

      All of the above components have an impact on the logon process, therefore, know what is happening there.

• User Profiles & GPOs.  User profiles provide a user their "personalized" environment depending on the user profile strategy, which again has a huge impact on logon times.
  • Roaming Profiles provide maximum personalization such as nice wallpapers, saving files on the desktop (especially large files), etc., however can also get quickly out of control if not restricted by certain policies.  Therefore, it is crucial to define a user profile strategy first before starting with any optimization.
  • An ideal profile solution is a Mandatory Profile customized by an administrator that does not allow any personalization by users since it discards any changes applied during runtime.  This is a stable solution however this will probably not meet all users' expectations.
  • A hybrid solution provided by Citrix User Profile Manager, which is based on the recently acquired technology from sepago called sepagoPROFILE.  The biggest advantage of this solution is that users gain a certain degree of personalization (pre-defined by an administrator) while keeping the stability and slimness of a mandatory profile that ensures a fast logon process.  Other similar solutions are provided by partners such as AppSense, RES, and tricerat.
  • Placement of user profiles may also affect the logon process since any additional network hop, procedures to locate the file server (e.g. DNS) as well the file servers' utilization can delay logon times.  A possible improvement with mandatory profiles is storing them locally on a XenApp to avoid network copy jobs.
• Group Policies.  Provide administrators a way to control an Active Directory-based environment.  However, they should be used carefully by reducing it to a minimum set of required group policies, because each policy needs to be processed during logon extending again the logon time.  Thereby, the amount of configured settings is more relevant than the amount of group policy objects.  In order to ensure fast logon times, consider the following:
  • Do not configure unnecessary settings
  • Disable not required settings (e.g. applying solely user specific settings does not require the processing of computer specific settings)
  • Import only required ADM files

Once group policies have been created, you should analyze these with the tool GPResult or RSoP to check for duplicate or conflicting settings.

• Anti-Virus software.  Today, there is almost no XenApp or XenDesktop environment without Anti-Virus software.  Taking this into account, usually the default configuration is applied, which may be not appropriate and can lead to a delayed logon process.  Therefore, the following configuration settings are recommended:
  • Scan on Write only
  • Scan only local drives
  • Exclusion of .DAT files

Another performance enhancement can be achieved if an organization's security guidelines permit to scan only files with executable code.  Further details can be found in article CTX114522.

•  Other possible areas.  Besides the above listed areas and others not covered in this blog, the following are relevant as well:
  • Mapping of client resources such as printers, local drives, audio, COM or LPT-Port - usually the user has access to its desktop once these have been mapped
  • Number of concurrent logons - the amount of executed processes create load on the Write process to the hard disk such as copying user profiles, mapping client resources etc and can be addressed with faster hard disks or a RAID-Controller with a battery backed-up Read/Write Cache.

Even if user profiles provide the impression of a less complex component of the logon process, they should be considered as part of the architectural planning of a XenApp or a XenDesktop environment since every "cool" function may also lead to a delay in logon times.  Doing so, this will ensure acceptable logon times (with no coffee breaks improving efficiency), happy users, less help desk calls because of corrupted user profiles, and cost savings.

We hope that the discussed tools and techniques give you more insights into the logon process.  Luckily, we have now a tool that we can leverage to use in order to ensure happy users.  Therefore, we can only encourage to test out the Citrix User Profile Manager!

Note:  This content was created by Thomas Berger and Tarkan Koçoglu (both from Citrix Consulting) and has been already published in the German Magazine LANline, Edition April 2008 and the Citrix Newsletter "iPunkt Edition 38, April 2008"