As you may already know, hosted shared desktops are part of the Citrix FlexCast™ delivery technology and are ideally suited for subscribers who need a set bundle of applications. Both Citrix and Microsoft have defined SPLA programs that enable a Citrix Service Provider (CSP) to deliver hosted shared desktops from a cloud. Here are the first steps to make it happen in YOUR datacenter.

In this 2-part blog series, I am going to list the 5 steps needed to deliver a hosted shared desktop from a cloud.

The steps below assume that you, as a CSP administrator have the following environment:

  • Access to Active Directory with permissions to join a server to a domain, create OUs, create user & group accounts.
  • A XenApp 6 deployment created by configuring the necessary server roles like License Server, Data-collector, XML-broker and Web Interface.
  • You have one or more XenApp 6 servers that you plan to use to host the desktop sessions. I will refer to these machines as worker machines. Alternatively, you can have an image of a XenApp 6 server that you can use to create virtual worker machines.

To find documentation on how to setup such an environment, check out the Citrix eDocs. In a future blog, I will go over the best practices for setting up such an environment.

Step 1: Register a new tenant with Active Directory
For every tenant, Citrix recommends creating the following objects in Active Directory (in addition to the user objects that represent the tenant’s users):

  • An organizational unit (OU) that will contain the user accounts representing the tenant’s users.
  • A global group account whose members will be the tenant’s users.
  • An organizational unit (OU) that will contain the worker machines reserved for the tenant.
    The purpose of these objects will become clear in the next few steps.

Step2: Enable the Windows 7 desktop experience on worker machines
The default desktop delivered by a XenApp 6 server (or Windows 2008 R2 server) is a desktop intended primarily for an administrator to manage a server. As such, it looks a bit bland, has no support for themes and a number of accessory applications like the Windows Media Player, Snipping tool, Sound recorder etc are not available. See the picture below:

To enable a Windows 7-like experience, Microsoft documentation states that you need to add the Desktop Experience feature to the worker machine (or image). This can be done easily using Server Manager or you can add the lines below to your worker machine preparation script.

<span class="code-keyword">import</span>-module ServerManager
Add-WindowsFeature Desktop-Experience

The Windows Desktop experience feature adds support for themes and it also installs the accessory apps that I mentioned above. Once this feature is installed and you reboot the server, you need to start the Themes service (and ensure that its startup type is configured as Automatic). To do this, you can copy the lines below to a script/workflow step that gets invoked after the machine is rebooted during the worker machine (or image) preparation process.

Set-Service -Name Themes -StartupType Automatic
Start-Service Themes

If you were working on an image, you can now create virtual worker machines from this image. Citrix recommends placing all the worker machines that are reserved for a specific tenant in an Active Directory OU created for that tenant (in step 1).

You should also create a GPO that will set a specific theme and wallpaper for all users (assuming for now that all of the tenant’s users get the same theme and wallpaper and are not allowed to change this). The PowerShell code for this is shown below. This code creates a domain GPO that sets the theme to the Win7 Basic theme and allows you to specify a path to a wallpaper file that is present on the local server.

<span class="code-keyword">import</span>-module grouppolicy
#Create a <span class="code-keyword">new</span> domain GPO
$gpo = <span class="code-keyword">new</span>-gpo -name &lt;Name of the GPO&gt;
#Set the policy <span class="code-keyword">for</span> Themes
$gpo | Set-GPRegistryValue -Key <span class="code-quote">"HKCU\Software\Policies\Microsoft\Windows\Personalization"</span>
-Type <span class="code-object">String</span> -ValueName ThemeFile -Value <span class="code-quote">"%windir%\resources\Ease of Access Themes\basic.theme"</span>
#Set the policy <span class="code-keyword">for</span> wallpaper
$gpo | Set-GPRegistryValue -Key <span class="code-quote">"HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\<span class="code-object">System</span>"</span>
-Type <span class="code-object">String</span> -ValueName WallPaper -Value &lt;path to a local wallpaper file&gt;

Once the GPO is created you can link it with the OU (created in step 1) that contains the tenant’s users.

Now, when a user logs in to a hosted desktop, the desktop looks like the picture below. See the difference?

Note: In my testing, I noticed that the wallpaper policy wasn’t taking effect. Luckily, Microsoft has already released a hotfix for this issue – KB 977944, which you need to install on the worker machine.

That’s it for now. In the 2nd part of this blog, I will go over the XenApp objects that need to be created to deliver a desktop. Stay tuned..

Sep 20th 2010 update:
Part 2 of this blog series has now been posted – link.