Pages

Wednesday, February 29, 2012

I’m sure there’s probably some documentation out there for setting up Citrix XenDesktop 5.5 virtual desktops with Citrix Receiver for pass-through authentication for XenApp 6.5 published applications but I sure couldn’t find a single documentation that had all of the information and since I’m bound to come across this again, I thought I’d document the steps I went through to get it working. Interestingly enough, I received mixed information about whether this would work or not even though I knew it was supposed to since this is Citrix’s best practice—set up your XenDesktop virtual desktops and stream what applications you could to the virtual desktop so you’re just updating the applications from your XenApp servers rather than the virtual desktop image itself. Anyways, I originally placed a call into Citrix when I kept getting prompted for credentials within my virtual desktop:

The support engineer told me this was expected behavior but I was almost certain it wasn’t and that it was a misconfiguration so I reached out to another presales engineer I work with from Citrix and he told me that it should work. So after fiddling around with the configuration, I finally got pass-through authentication to work and the following highlights the steps:

Step 1 – Set up your virtual desktop master image:

Ensure that your XenDesktop virtual desktop has the correct Citrix Receiver. The XenDesktop 5.5’s VDA agent installs bundles the correct one but it doesn’t hurt to double check to ensure you have the correct Enterprise version. More information can be found in one of my previous posts here: http://terenceluk.blogspot.com/2012/01/citrix-xenapp-65-pass-through.html

Once the Citrix Receiver has been installed, make sure the service ssonsvr.exe process is running on the virtual desktop:

Unless you intend on configuring the authentication for Kerberos only, do not select the Use Kerberos only checkbox for your XenApp Services Site for pass-through authentication:

Step 4 – Add your Web Interface server’s virtual name (NLB), NetBIOS name and FQDN into your virtual desktop’s intranet sites via GPO as well as change the User Authentication in the Custom level of the Local Intranet settings to Automatic logon with current user name and password

Whether you want to add the NetBIOS name or FQDN into your virtual desktop’s intranet site via GPO in Active Directory or as a local policy is up to you as both will work:

Note that I haven’t fully tested whether it’s absolutely necessary to have the User Authentication in the Custom level of the Local Intranet settings set to Automatic logon with current user name and password since we’re already putting the web interface’s virtual name (NLB), NetBIOS and FQDN into the Local Intranet site because through other tests with pass-through authentication through the web interface site, I was able to just leave it set to Automatic logon only in Intranet zone.

As a test, although this is optional, I would suggest that you configure a pass-through authentication site on your Web Interface server to check to ensure your virtual desktop can actually authenticate correctly with the site without prompting you for credentials:

Citrix Receiver could not contact the server entered. This may be because the server is down, there is an error in the configuration file from the server, or the details entered are incorrect. Please try again.

Solution

While there can be many reasons why this error could be thrown, one of the common reasons is that the URL entered for the server address is incorrect. Make sure that the URL you enter includes the:

Sunday, February 26, 2012

Those who come from a VMware View 4 or 5 background may immediately notice or find how confusing Citrix’s XenDesktop’s power management scheme can be but in reality, Citrix just chose a different approach to allowing administrators to control when and how many desktops they want powered up.

The way that Citrix allows administrators to management the state of pools containing statically assigned desktops is through the following:

OffPeakBufferSizePercent

OffPeakDisconnectAction

OffPeakDisconnectTimeout

OffPeakExtendedDisconnectAction

OffPeakExtendedDisconnectTimeout

OffPeakLogOffAction

OffPeakLogOffTimeout

PeakBufferSizePercent

PeakDisconnectionAction

PeakDisconnectTimeout

PeakExtendedDisconnectAction

PeakExtendedDisconnectTimeout

PeakLogoffAction

PeakLogOffTimeout

For detailed information about these parameters, refer to the following link which contains the description for them:

Within Desktop Studio, you can find the power management properties by editing the respective desktop group. Here’s a screenshot of the Power Management options for a statically assigned pool:

… and here’s a screenshot of the Power Management options for a randomly assigned pool:

The way that XenDesktop handles how many desktops are powered on for a statically assigned pool is based on values for the PeakBufferSizePercent,PeakHours and DaysOfWeek. Assuming that you have your PeakBufferSizePercent set to 100%, your PeakHours set to all hours and DaysOfWeek set to Weekdays, your desktops will be powered on throughout the day.

What I find most administrators ask are the following questions:

How can I keep all of my desktops powered on during office hours?

How can I set a specific amount of desktops the XenDesktop DDC should have powered on?

How can I turn power management off completely?

Let’s answer these questions now:

How can I keep all of my desktops powered on during office hours?

The 2 variables that need to be set for you to have all of your desktops powered on during office hours are the following:

PeakBufferSizePercent

PeakHours

PeakBufferSizePercent is set with the PowerShell cmdlet: Set-BrokerDesktopGroup and PeakHours is set with the GUI:

… or the cmdlet: Set-BrokerPowerTimeScheme.

So if you want your desktops to be powered on between 6:00a.m. and 9:00p.m., highlight the appropriate hours in green as shown in the screenshot above and use the Set-BrokerDesktopGroup to set the PeakBufferSizePercent value to 100. Here’s what the cmdlet would like like:

As with a few of my previous posts, I’ve been digging around my old notes to try to compile a list of items I had to do in my previous virtual desktop deployments and to avoid repeating this again, I figured I’ll just blog every item so I can reference these blog posts for future deployments.

Note that these customizations may or may not be applicable to your environment so use them only if your environment calls for the customizations.

Start by loading up the Microsoft Office Customization Tool by executing setup.exe /admin from the installation binaries:

Install location and organization name

Navigate to the Install location and organization name node and enter the

Default installation path

Organization name

Licensing and user interface

If you’re using pooled desktop catalogs in Citrix, it is important that you have a KMS server and license your Office 2010 installations with KMS instead of MAK keys because they will need to get reactivated every time you update the master image. While it’s not absolutely important to configure the installation to use KMS licensing with the OCT tool because you can always use VAMT to do it afterwards, it’s just easier so navigate to the Licensing and user interface node to set it from the start:

The level of display controlled by the Display level does not matter so set it as it pertains to your environment.

Modify user settings

There are quite a few blog posts out there that talks about whether to use cached mode or not but since Citrix XenDesktop’s MCS (Machine Creation Services), unlike VMware View, does not provision a persistent disk and redirect’s the user’s desktop, I would suggest that it’s best to disable cached mode so set the following to disabled under Microsoft Outlook 2010 –> Account Settings –> Exchange –> Cached Exchange Mode

Use Cached Exchange Mode for new and existing Outlook profiles

Cached Exchange Mode (File | Cached Exchange Mode)

Miscellaneous

One of the major annoyances I find that Outlook 2010 does is recommended settings dialog that gets presented to the user if Outlook was never launched. This is usually fine in a regular physical desktop environment but in a virtual desktop environment, this window can get launched every time the master image is refreshed and pushed out so navigate to Microsoft Office 2010 –> Miscellaneous

Suppress recommended settings dialog

Outlook profile

To avoid having the user to configure their Outlook profile every time their desktop is refreshed, we can use the OCT tool to automatically create a profile for them.

Navigate to Outlook –> Outlook profile then sSelect the Modify Profile radio button and in the Define changes to profile named: txt field, type in Outlook:

Select the Add accounts node and select the Customize additional Outlook profile and account information radio button then click on the Add button to create a new Outlook profile:

In the Exchange Settings window, enter the following:

Account Name: %UserName%@yourDomain.com

User Name: %UserName%

Exchange Server: yourExchangeServerCASFQDN

Click on the More Settings… button to launch the additional settings window:

Although we’ve disabled cached mode earlier, I still prefer to set it in the profile as well:

Click the OK button to save the settings:

Save the customization as custom.msp in the Updates folder of your Office installation folder and install Office 2010 via the following command:

setup /adminfile c:\Office_2k10_Pro\Updates\custom.msp

Now regardless of whether an Outlook profile exists on the virtual desktop, Office will automatically create one for the user with the settings set above which to the user will appear seamless.

Yet another challenge that I’ve faced when deploying virtual desktops is retaining signatures across desktop pools or when a desktop pool is refreshed in the case of statically assign pools. Active Directory redirected folders solves half of the problem since a user’s signatures are stored in the %appData% folder and by redirecting this folder to a file server, the user will have access to it across desktops but what most may notice is that the assignment doesn’t. This means that the user will always have to go back into their signature properties and reassign the new and reply signatures. This can quickly become a major annoyance to users as desktop images can be refreshed numerous times. If you’re forced to use scripts to handle the roaming because the business does not want to use Citrix’s User Profile Management, then one of the ways to do it is similar to one of my previous posts where we need to first locate the registry key that stores this information and then use a combination of log on and log off batch files to export and import the setting back in.

Note that there is a caveat to this workaround and it’s that if the only case that it doesn’t catch is as follows:

User has an Outlook profile configured with signature assigned.

Administrator makes modifications to the master image and updates the machine.

User logs into a new virtual desktop for the first time, makes changes to their signature or Outlook settings and then logs off.

In the situation above, the changes the user made to their Outlook profile will not be saved because their virtual desktop has just been refreshed. However, when the user logs back on the second time, the changes will then be preserved. I haven’t had the chance to spend more time on modifying the batch file to correct this problem but will update this post when I figure it out.

I originally didn’t bother to look into what was stored in this registry key but when I finally realized what happens when you simply export and import this key back into the registry, I decided to take a deeper look. Although I still don’t know all the details of what each subkey represents, the top level Outlook key represents the profile that is displayed in the following mail profiles for the Windows desktop operating system:

So if you were to browse HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\ and you see multiple keys, each key represents the profile you have configured. The problem with simply exporting and importing this key upon log on and log off which is a part of the workaround I’m about to demonstrate is that when you launch Outlook for the first time after you’ve refreshed your desktop image, it does not treat the imported profile as a usable profile (most likely because of the encryption keys generated from the previous desktop). Hence, if you’ve configured a custom.msp file to automatically configure an Outlook profile, it will rename the profile to BACKUP OF Outlook and create a new Outlook profile:

What’s interesting is that the signature settings get copied over and everything looks fine until you browse the account’s settings and notice that you have multiple entries as such:

An additional entry will be created every time you refresh your desktop image which causes the Outlook first run to create a new profile. This doesn’t appear to affect the Outlook in any way but imagine performing several hundreds of refreshes later. I’m sure Outlook would eventually get affected at some point if this list gets too long so rather than leaving it as such, I’ve made some changes to the GPO that I will be using.

The process goes as such:

When the user logs on, the batch file will try to import the file hkcuOutlookSignature.reg from %appdata% which is on a fileserver because redirected profiles are set up. Now if this is a new user and has never logged onto the network, this hkcuOutlookSignature.reg will not exist but this is ok because nothing will get imported. The user will proceed with launching Outlook, fill in the information and the registry key will be created.

When the user logs off, 2 batch files will be executed:

The first batch file will check to see if the key BACKUP OF Outlook exists and if it doesn’t, it will exit. If the BACKUP OF Outlook does exist, it will delete the Outlook key and all its subkeys, recreate the Outlook key, copy all of the subkeys in the BACKUP OF Outlook key into the Outlook key then delete the BACKUP OF Outlook key.

One the first batch file has executed, another batch file will export the HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook out to the hkcuOutlookSignature.reg file to the user’s %appdata% folder located on a file server.

The next time the desktops get refreshed and the user logs onto a fresh desktop without this registry key, the log on script will automatically import the Outlook profile into registry, Outlook will create a new profile, rename the old profile but the new profile will have all of the user’s signature settings. Once the user logs off again, step #2 will execute and thus will clean up the profile.

The following is what the export and import batch files will look like:

Import – Log On

cmd /c regedit /C /S “%appdata%\hkcuOutlookSignature.reg”

Export – Log Off

Batch File #1rem This line checks to see if "BACKUP OF Outlook" exists and if it doesn’t, it will exit

Once these batch files are created, proceed with creating a new GPO and assign it to the OU with the user accounts (or elsewhere and filter out who gets the policy by using groups):

**Note that the policy has “Outlook User Infor” in as the name because I bundled in the batch file I used for transporting user info settings cross desktops which is the post I wrote previous to this one.

If you have more than one site in your Active Directory, force replication and ensure that the new GPO is available in the site that you’re going to test in. Use a combination of gpupdate/force and gpresult -r on the desktops to ensure that the policy is applied to the user before trying to restart and refresh your images.

It’s been quite the challenge while setting up roaming profiles for a new Citrix XenDesktop 5.5 farm in an environment that has no redirected folders and scripts to allow users to roam between workstations while maintaining the same look, feel and access to their desktop, my documents, favorites and application folders. Most of the companies I’ve worked in the past have had these policies set up but because one of the recent clients, I had to put on my Microsoft thinking cap to assist in getting these set up in parallel.

The redirected folders were easy enough to set up but as some of us may know, they do not redirect all folders and also doesn’t retain Outlook profile information. This meant that whenever the desktops are recomposed and the user logs onto a fresh desktop, they will receive the following prompt:

Not a big deal if the user has just been migrated to the new Citrix XenDesktop environment and understand this is their new desktop but it will quickly become a big deal if they receive this prompt every time IT updates the image of the pool that their desktop is in. I’ve always told clients that simple annoyances like these are what gives the users a negative impression virtual desktops and as small as this issue may seem, it needs to be dealt with.

So how do we address this? You can search long and hard in the Office Customization Tool menu and Office 2010 GPO adm file but you won’t find any way of retaining or skipping this prompt upon first launch. Before we continue on with the solution, let’s look into the registry where this information is actually stored:

As shown in the screenshot above, this information is actually stored in the registry under:

HKEY_CURRENT_USER\Software\Microsoft\Office\Common\UserInfo

This key is created in the HKCU when Outlook launches and the user enters their information. I’m sure there are multiple ways of transporting this information across desktops but the way that I went with was simply to create a log on and off batch (you can use script as well) file and assign it to the user accounts via Active Directory Group Policy.

The process goes as such:

When the user logs on, the batch file will try to import the file hkcuOutlookUserInfo.reg from %appdata% which is on a fileserver because redirected profiles are set up. Now if this is a new user and has never logged onto the network, this hkcuOutlookUserInfo.reg will not exist but this is ok because nothing will get imported. The user will proceed with launching Outlook, fill in the information and the registry key will be created.

When the user logs off, the batch file will export the HKEY_CURRENT_USER\Software\Microsoft\Office\Common\UserInfo out to the hkcuOutlookUserInfo.reg file to the user’s %appdata% folder located on a file server.

The next time the desktops get refreshed and the user logs onto a fresh desktop without this registry key, the log on script will automatically import the file into registry and thus Outlook will not prompt the user for this information.

I can’t say this is the most elegant solution but unless you have deep pockets to purchase applications such as AppSense then this may be one of the few ways you can get by this annoyance.

The following is what the export and import batch files will look like:

Once these batch files are created, proceed with creating a new GPO and assign it to the OU with the user accounts (or elsewhere and filter out who gets the policy by using groups):

**Note that the policy has “and Signature” in as the name because I bundled in the batch file I used for transporting signatures cross desktops. I’ll be writing another post on how to do this in a similar manner.

If you have more than one site in your Active Directory, force replication and ensure that the new GPO is available in the site that you’re going to test in. Use a combination of gpupdate/force and gpresult -r on the desktops to ensure that the policy is applied to the user before trying to restart and refresh your images.

As fellow administrations who have deployed Citrix XenDesktops in their environment may know, Outlook profiles do not get retained by redirected profiles and when ever they refresh a desktop catalog’s pool with an updated image, users who log onto their virtual desktops will get the following prompt:

Microsoft Outlook 2010 Startup

As with many of the small annoyance challenges that a virtual desktop environment can bring, this is yet another one that can annoy users enough to complain and generate calls to the IT help desk.

The solution to address this is to simply customize your Office 2010 installation with a custom.msp file created in the OCT (Office Customization Tool) so that if an Outlook profile does not exist, Office will automatically create one. Prior to installing your office, execute the command setup.exe /admin to bring up the OCT wizard and create a new customization file:

Navigate to Outlook –> Outlook profile then sSelect the Modify Profile radio button and in the Define changes to profile named: txt field, type in Outlook:

Select the Add accounts node and select the Customize additional Outlook profile and account information radio button then click on the Add button to create a new Outlook profile:

In the Exchange Settings window, enter the following:

Account Name: %UserName%@yourDomain.com

User Name: %UserName%

Exchange Server: yourExchangeServerCASFQDN

Click on the More Settings… button to launch the additional settings window: