Blog posts tagged with 'xendesktop'

Previously I covered an overview of User Profile Manager as well as how it addresses last write wins.  Now I will cover profile bloat which is one of the more common user profile pain points.  Profile bloat creates unwieldy growth in user profiles and resulting storage and management issues (and the performance impact as profiles continue to grow in size).  So let's take a closer look at how User Profile Manager gives you control over this challenge.

Typically when using Folder Redirection or a roaming profile, the user's profile folders follow them as they move from system to system.  In a perfect world all your applications would behave properly and there would be no profile bloat. We know this is not the case and thus certain folders lend themselves to becoming very bloated fairly quickly.  Application Data is one of those folders, as applications may use it as a temporary folder (instead of the system's temp folder) and do not clean up the folder after the application ends.  This folder can become a graveyard of files no longer wanted or needed.  Or become a repository of files not really needing to be kept from one session to the next - temp files or cached data.  This folder can quickly become 100s of MB in size.

In a roaming profile scenario, this is a lot of data to be dragged around with a user.  With folder redirection, this becomes a lot of data to have to store somewhere - particularly if it's not really needed.  This becomes a painful process since the data may be getting copied back and forth with every logon and logoff event (although some optimizations within the profile contain the copying back to only files that changed).  In the case of XenApp servers where profile caches are almost always deleted upon logoff, all this profile data will have to be copied down again upon next logon.  Situations like this compound the pain we experience with unwieldy profile sizes.

With User Profile Manager you configure to exclude this 'extra baggage' causing that data to be ignored.  The payoff will be better management of the central storage resources (not storing extraneous files back to the user's central store) and this can translate to improved logon times since this extra baggage is not processed with the user's profile (which unless it is already cached on the machine the user is logon into, it will be copied down).

User Profile Manager provides the capability to fine tune the files and folders in a user's profile.  Now an administrator can explicitly include or exclude folders and files within a user's profile (and the ability to combine these such as to include a specific folder and exclude a subfolder within that folder).  For example, you might have an application called MyApp that creates and stores a multitude of supporting files in the \Application Data\MyApp directory (of which the subdirectory called '\MyAppStuff' is not needed).  You could include the root MyApp_ directory but then define an exclusion of the _\Application Data\MyApp\Stuff folder and upon logoff these files are left behind and not transferred to the user's central store.  If you have configured local profiles to not be cached, this extraneous data is just deleted at logoff with the cached profile.

By fine tuning and adjusting over time what is kept and not kept in the profile enables the profile size to be managed more efficiently.  For a start have a look at the INI files installed with User Profile Manager (in the target install directory) provided with UPM as they provide some good initial settings. And of course the profile size being reduced and less data being copied back at logoff can contribute to improved logon and logoff time.

The XenDesktop Setup Wizard allows an administrator to quickly create a pooled desktop group with virtual desktop VMs for their XenDesktop environment.  I wanted to share more information on what the XD Setup Wizard does along with promoting it as we have had several customers unaware of the benefits of this wizard.  If you are going to create a desktop group of pooled desktops then you should seriously consider using the XD Setup Wizard as it will save you a tremendous amount of time.  Trust me on this as I needed to create 300 virtual desktops on VMware ESX two years ago which led to me creating this wizard.  But I will save that talk for another time.

First let's cover the prerequisites and initial configuration...

Before the XenDesktop Setup Wizard is run you need to have a virtual desktop VM template and a base OS image (aka Provisioning Server vDisk).  For detailed setup information on how to accomplish this please refer to the XenDesktop Getting Started Guide.  This guide describes the configuration for the XD Setup Wizard as well as the other components of XenDesktop.  

When you create your virtual desktop VM template you specify the VM hardware parameters for your base virtual desktop VM.   When the XD Setup Wizard is run it reads this VM configuration information and then creates X number of VMs using the same virtual hardware configuration.  For example if you created a VM on XenServer that has 512MB of RAM, 1 virtual CPU, 1 virtual NIC and no virtual hard drive all your new virtual desktop VMs would have that same configuration.  Keep in mind that you do not need to have a nice round number in terms of RAM.  You could try using something like 460MB of RAM per desktop to try and squeeze one or two extra desktop VMs per server.  Of course that would only help if RAM was your bottleneck.  No virtual hard drive for the VM is possible because Provisioning Server (PVS) dynamically streams the base OS image to the VM which does not require a hard drive in the VM.

However, in advanced cases you may want add a virtual hard drive to the VM that will cache information from the streamed base OS image.  This virtual hard drive will be used as the write back cache for the Provisioning Server (PVS) base OS image and will typically be 1 to 2 GB.  Whether or not you want a virtual hard drive depends on your network configuration and storage.  By moving the write back cache off the network storage that also has the PVS base OS image you reduce the load on your network storage and you balance your network load.  However having your PVS base OS image and the write back cache for each desktop on the same storage device makes the configuration easier and can result in better storage utilization.  These are some of the trade offs to consider when you want to have virtual desktops deployments for thousands of users.  If you need to scale your virtual desktop environment to over a thousand users email me at sunil.kumar@citrix.com.

When you create your virtual desktops you will be asked for the base VM template, the base OS image (Provisioning Server virtual disk),  the base host name along with the number of virtual desktops to create, and the name of the desktop group.  In our case let's use

• "CXD_VM_TEMPLATE" as the base VM template
• "CXD_IMAGE" as the base OS image
• "CXD1, CXD2, ... CXD100" as the name of the virtual desktops.
• "CXD_GROUP" as the desktop group name.

You will be asked for all this information when you run the wizard to create a desktop group.  The attached video walks you through this configuration. 

Now let's look at what happens when the wizard starts creating virtual desktops ...

Step 1: Connect to the hosting infrastructure and create new virtual desktops 

The XD Setup Wizard connects to the XenServer resource pool via the master XenServer.  It instructs XenServer to create X number of VMs.  In our case we created 100 VMs.  A new MAC address is created for each VM that corresponds to the virtual NIC for the VM.  The XD Setup Wizard stores this newly created MAC address for each VM along with the host name specified (CXD1, CXD2, ... CXD100).  The XD Setup Wizard uses the first MAC address for the VM if multiple NICs are used.  However I would avoid this configuration because bad things could happen if you try it.  Well actually the worst that could happen is that your virtual desktop would not boot, but because of the complexities of having multiple NICs I would avoid this configuration unless you could not live without having multiple NICs.  We now have 100 VMs created with the XD Setup Wizard storing the host name for each VM along with the MAC address.

Step 2: Configure virtual desktops in Provisioning Server

The XD Setup Wizard adds a target device in Provisioning Server for each of the virtual desktops.  The client name for each of the target devices is the host name.  When the VM boots it replaces the host name of the base OS image with this client name.  Each target device is uniquely identified by the MAC address which is why we stored the MAC address for each VM in the previous step.  Each target device is then set to boot from the specified base OS image (CXD_IMAGE).  In addition Provisioning Server adds each target device to active directory.  You can either let the XD Setup Wizard add computers to the default location or you can specify a custom OU.  We now have 100 provisioning server target (client) devices that correspond to each of the VMs created in the previous step.

Step 3: Add virtual desktops to a new Desktop Group in a Desktop Farm

The wizard now creates the new desktop group we called "CXD_GROUP".  The 100 virtual desktop VMs created above are now added to this desktop group on the Desktop Delivery Controller (aka the Connection Broker or DDC).  The DDC identifies each of the VMs by their AD host name, but when the VMs are added the DDC can only see the VM name and UUID (Universal Identifier).  The wizard knows the host name for each VM so it informs the DDC of this automatically.  Otherwise the administrator would need to manually associate each VM name / UUID with its corresponding AD host name.  We now have a newly created desktop group with 100 virtual desktops.

Readying the desktop group for use

Once the desktop group is created, the Desktop Delivery Controller takes over and starts the initial setup for the desktop group.  This includes starting the idle virtual desktops.  These idle desktops are used to quickly connect a user to a virtual desktop because the virtual desktop is already running and only the profile needs to be applied when the user logs in.  The DDC informs the XenServer resource pool to start a virtual desktop VM.  When this virtual desktop is started it streams down the base OS image using the Provisioning Server component.  The virtual desktop loads the Virtual Desktop Agent as part of the OS boot process which then registers with the DDCs in the XenDesktop farm.  The desktop group is now ready!

In addition to the XenDesktop Setup Wizard automating all of this for you it only takes seconds per desktop.  Are you now convinced to use the XenDesktop Setup Wizard as opposed to doing everything manually?  You can now run the XD Setup Wizard again to either create a new desktop group or add new VMs to an existing desktop group.  To modify advanced options of the desktop group such as idle pool settings you can run the Access Management Console on the DDC.

Since launching XenDesktop, one of the most common questions I have heard from XenApp customers is "Why would I use XenDesktop with my current XenApp implementation?" Well, there are a lot of reasons and this white paper helps answer them. According to the document's description:

The white paper explores these areas:

• Best Practice: Separate Apps and Desktop
• Step 1: Is it an app or desktop problem?
• Step 2: Which workers have this problem?
• Step 3: Identify the solution
• Step 4: Justify with Cost Analysis

Take a read and let us know what you think.

 XenApp and XenDesktop: Using Application and Desktop Virtualization Together

I've used the spare time between two projects to create version 2.0 of the XenDesktop VDA Configurator.
This version has a better Active Directory browsing mechanism (faster & more reliable), checks for GPO configurations of the Virtual Desktop Agent (VDA) and shows you all XenDesktop Farms (Name, GUID, AD location) which can be discovered.

The tool itself:

The show farms dialog:

 

Download here

I hope you find it as helpful as I do...

Cheers,
Thomas

PS: If you feel the need for any other tool related to XenDesktop, just drop a comment here and I'll see what I can do for you.

To satisfy the legal guys:

Disclaimer Notice

This software / sample code is provided to you "AS IS" with no representations, warranties or conditions of any kind. You may use, modify and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the software / sample code may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the software / sample code fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the software / sample code.  In no event should the software / code be used to support of ultra-hazardous activities, including but not limited to life support or blasting activities.  NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE software / SAMPLE CODE, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.  Although the copyright in the software / code belongs to Citrix, any distribution of the code should include only your own standard copyright attribution, and not that of Citrix.  You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.

Now that XenDesktop is out and about, you can certainly tell that users will be experimenting with multiple different settings and scenarios, exposing it to some unknown deltas.

Enabling verbose logging on XenDesktop can help you better understand what goes on behind the scene and troubleshoot issues.

There are three component to be enabled with verbose logging within XenDesktop: Delivery Controller, VM Manager, and Workstation agent.

The procedure is exactly the same for all three components, just follow these simple steps:

Desktop Delivery Controller

1) Create a new directory (ex. "C:\CDS")
2) Change security settings to allow Network Services and Local Service "Full Control" over the new folder.
3) Open the following ".exe.config" files in a text editor:
       C:\Program Files\Citrix\Desktop Delivery Controller\cdscontroller.exe.config
       C:\Program Files\Citrix\VMManagemenet\CdsPoolMgr.exe.config
4) Modify the following section, change the <logFilename> variable, specifying a file within your new directory:
      <appSettings>
      <add key="LogToCDF" value ="1"/>
      <add key="LogFileName" value ="C:\CDS\<logfilename>.log"/>
      </appSettings>
5) Finally, reboot your server to start logging.

Workstation Agents:

1) Create a new directory (ex. "C:\CDS")
2) Change security settings to allow Network Services and Local Service "Full Control" over the new folder.
3) Open the following ".exe.config" file in a text editor:
       C:\Program Files\Citrix\Virtual Workstation Agent\WorkstationAgent.exe.config
4) Modify the following section, changing the <logfilename> variable, specifying a file within your new directory:
      <appSettings>
      <add key="LogToCDF" value ="1"/>
      <add key="LogFileName" value ="C:\CDS\<logfilename>.log"/>
      </appSettings>
5) Finally, reboot your workstation to start logging.
 

There are two primary components to a user's profile - registry information and files.  This article will focus on the registry portion where last write wins becomes an issue.  While session sharing will mitigate this issue since only a single profile will be loaded (e.g. one session being shared by all apps equals one profile), there will be scenarios where multiple sessions occur or may be required and thus the potential for last write wins.  Specifically I will discuss the differences in how User Profile Manager functions over traditional roaming profiles when it comes to managing the NTUSER.DAT file (the user's registry settings also known as the HKEY_CURENT_USER or HKCU registry hive). 

During logon the NTUSER.DAT is copied down to the local machine the user is logging on (as well as the profile's files).  The NTUSER.DAT file contains the user's registry settings (HKCU) that are unique for every user (user being defined as a security account GUID).  The exception is when a mandatory profile is applied where all users share the same NTUSER.DAT (but then it's renamed to NTUSER.MAN).

During logoff, a roaming profile will copy the entire NTUSER.DAT file back to the central network share.  In this situation, the last session to end will have its NTUSER.DAT file saved.  Thus any settings in the 'previous' NTUSER.DAT on the network share will be lost if it happens to have changed since being copied down to the current session.  If the user has modified any profile settings in any of their active sessions, then the NTUSER.DAT file will have changed since the original version was copied down.

The difference with User Profile Manager is it will scan the current user hive (HKCU) and only writes back the changed registry settings.  User Profile Manager does this is by loading the 'centrally stored' DAT file called the 'user store' (file name is %USERNAME%.DAT) within the user's active session (in other words with the currently active HKCU hive) and performing a diff against that HKCU.  The results of the diff are then written into the user store.  It does not overwrite the previous NTUSER.DAT file.  So is this good?  It seems good, so let's take a closer look and see.

Let's look at roaming profiles and User Profile Manager using a simple example.  I have two separate XenApp sessions - one session has Microsoft Word and the other has Microsoft Excel (work with me for now on why there would be two sessions).  I make changes to my Microsoft Word application settings in the first session.  In the second session I make changes to Microsoft Excel application settings.  I close out the Microsoft Excel session first.  My roaming profile unloads and the NTUSER.DAT file is written back to the network share replacing the existing copy.  Then I close out the Microsoft Word session.  And again the NTUSER.DAT file is then written back to the network share replacing the one just copied back from the Excel session.  I've just lost my Microsoft Excel settings.  While I've used Microsoft Office applications for simplicity sake, this would be true for any two applications in this scenario.

What User Profile Manager does is as simple as easy: only save the net changes and merge them to the user store.  User Profile Manager's method is to scan the registry for changed settings and then write these settings to the user store DAT file on the network share.  Thus User Profile Manager 'merges' these changed settings into the user store instead of categorically copying back an entire DAT file over any previous DAT file at each logoff.  Thus different sessions being logged off will have their net changes written back to that central DAT file.  Goodbye to last write wins!

One key component in the Citrix VDI solution is the inclusion of communication. This is a clear distinction from other VDI solutions in the market because no one else has even considered adding communication as part of their VDI solution. When Citrix develops XenDesktop, we made a very concerted effort to design a VDI platform that is capable of supporting the next evolution of desktops or operating systems.

There are numerous market drivers that propel Citrix to make EasyCall part of XenDesktop. In enterprises today, the line between the IT and the telecom organizations have been blurred. In many cases, there's no longer a separate organization that handles only telecom. A lot of telecom organizations have been folded into the IT organizations. Applications from Microsoft, Adobe, IBM, Oracle, and more are key culprits in that transition as they increasingly make communication as a core part of their applications. As much as some IT tries to separate communication and application, it's no longer realistic to do so. Enterprise users have already been making voice calls from their PCs, IT can no longer ignore this new reality.

Citrix is fully aware of this communication trend and we are addressing this heads on for our customers so that our customers are well prepared to handle this. With Citrix XenDesktop having communication as part of its core competency, organizations would not have to scramble later to find telephony vendors to add communication.  And telephony vendors are the last place to look for a VDI communication solution as these folks have even yet to understand how applications work in the users' world today.

XenDesktop is not like the VDI solution as some of our competitor like to put it. It is actually at least one generation ahead of where they would like to be.

You have probably seen the latest buzz on the street, an iPhone "running" Windows XP. This topic made big news this week as a story published by ZDNet Australia landed on the home of Digg.com.

The word "running" was loosely mentioned and that sparked a lot of controversy around visitors, but if we take a minute to explain the "phenomena", you will see there's nothing behind the curtains nor up the magician's sleeve. It's purely a high performance remote desktop (HPRD) being delivered via ICA, Citrix remoting technology protocol.

The demo mentioned above was delivered by our fellow Citrites in Australia, very similar to the one Mark Templeton showed us during his keynote early this year at the Citrix Summit.

So for those outraged with the Windows XP "running" on a "slow" processor like iPhone's, I say - you can all relax, the actual processing was done on a back-end virtual desktop and remotely delivered via Citrix XenDesktop.

Also the article mentioned above only posted a still image of the entire demo; so for those who are interested to see the full demo - here it is, the 5 minutes and 20 seconds-long XenDesktop demo "running" on an iPhone.

User Profile Manager provides an easy and reliable way to manage user personalization settings in Windows environments (the user's profile).  A user's profile consists of registry settings (stored in HKEY_CURRENT_USER) along with the files and folders (favorites, My Documents, cookies, Application Data etc).  The purpose of this article is to provide an overview and some details around User Profile Manager.  This will provide you enough to understand its core propose and for preparation to take a deeper dive into the technology.  The Technology Preview is available today for download (go here for links to the download site, Technical FAQ and other related items). 

User Profile Manager is a Windows service that monitors the logon and logoff process.  That means any user that logs onto a Windows environment with this service will have their profile managed by User Profile Manager.  E.g. installing the service on a XenApp server will enable all the users with sessions on that XenApp server to have profiles managed by User Profile Manager.

Let's start with the core files that are installed.  The MSI package (one for 32-bit platforms and one for 64-bit platforms) installs a Windows service (UserProfileManager.exe), two DLLs for Windows XP and Windows Server 2003 (upmHook.dll and upmLogonMonitor.dll) and some supporting files that I will cover a bit later (INI, ADM and ChangeLog.txt).  All of these are installed by default to \Program Files\Citrix\User Profile Manager.  Once installed, a new service will be listed (in the MMC Services plug-in or in Computer Management under Services) called Citrix User Profile Manager.

The service receives its configuration defining which users and what to manage in these users' profiles through a Group Policy Object (GPO) or an INI file.  The service will first read the GPO for its configuration and then check the INI file for any settings not configured in the GPO.  Typically you would use one or the other to manage configurations.  INI files are great for simple pilots and evaluations.  GPOs will offer better manageability and scale as you move into larger production deployments.  If neither the GPO nor INI exists, User Profile Manager will just manage the registry (and thus ignore any files or folders in the profile).  Please note that once you install User Profile Manager it will begin working using a default configuration (based on the INI files that were installed).

The INI files are installed in the target directory with an initial configuration.  There are two types of INI files installed: v1 (Windows Server 2003 and Windows XP profile) and v2 (Windows Server 2008 and Vista profiles).  Also installed in the same directory is the ADM template to be imported into your policies for creating User Profile Manager GPOs.

By virtue of these INI files, User Profile Manager works out of the box with a base configuration (HKEY_CURRENT_USER, My Documents, Favorites, Cookies, Desktop and Application Data etc - just read through the INI files for the full details).  This also means that if you choose to use or move your configuration to GPOs, you should delete or rename these INI files to avoid inadvertently having settings applied.  These INI files can be used as a starting point for your configuration and as a template for your GPO settings.

Once User Profile Manager is installed and a user logs onto that computer, User Profile Manager will manage the user's profile (registry settings, files and folders).  Within GPO settings the administrator has granular control over which users utilize User Profile Manager through AD Groups.  If the user does not belong to the specified AD Group, User Profile Manager will just ignore the user.  By default, all users (including local accounts) are managed and administrators are ignored (also can be configured in GPOs). 

Upon logoff, any net changes within the profile will be copied back to the central share (and only items that have changed).  The user's settings (DAT files, files and folders) are all centrally stored on the network in their defined HOME directory (which can be configured to be any UNC path).  The user now has all their settings and profile data (as defined in the configuration) following them reliably and consistently throughout their sessions.

Stay tuned as I will follow up this article with one that will dig deeper into how the registry settings are handled (NTUSER.DAT) in order to alleviate the 'last write wins' challenge.  As well as a look at how files and folders can by optimized to mitigate the 'extra baggage' challenge creating profile bloat issues (trust me, a bloated profile is not a pretty thing).

I look forward to any and all feedback on your experiences with this Technology Preview.

Citrix has released a new version of the ICA client for Mac OS X users.

As pointed out by our colleague Danny Wannagat, this release includes fixes for XenDesktop connections.

DOWNLOAD CLIENT | ReadMe | Admin Guide
Version 10.00.601 - Universal Binary English 6/5/08 5.0 MB .dmg.zip