Web Server | Desktops & Apps

XenDesktop 7 Session Launch – Part 2, Enumeration

Posted on October 4, 2013 by Kenny Baldwin

In my last post I talked about how the Citrix Receiver authenticates to a StoreFront server. In this post, I want to talk about resource enumeration with Citrix Receiver <> StoreFront <> XenDesktop deployments.

Before I go into the technical aspects of the way Citrix enumerates published resources, I want to briefly explain the history behind the Citrix XML Broker, as well as how the Citrix client enumerates published resources. In case anyone is interested in a broader history of Citrix, I encourage you to check out the 20 years of Citrix History publication that was published in 2009.

Citrix NFuse and the XML Portal Server

Back in 2000, Citrix signed a licensing deal with Sequoia Software (whom they later acquired in 2001) to integrate the NFuse as the foundation for providing an extensible application portal for MetaFrame. The XML Portal Server (XPS) technology was then built around NFuse to provide the ability to dynamically enumerate and present resources to end users. This integration was critical in giving Citrix the ability to stand apart from the competition (terminal services), and was the reason the next version of MetaFrame had the XP designation:

Since it’s introduction back in 2000, the NFuse protocol has remained at the core of every Citrix desktop/application virtualization product by way of the ‘XML Broker’ service. This service was included in all future releases, including all versions of XenApp & XenDesktop. Until XenDesktop 5 was released, the XML broker service ran as it’s own standalone service. During the XenDesktop ‘Storm’ site architecture rework (now called FMA, aka NOT IMA) the XenDesktop product team decided to relocate the XML broker service to run as a ‘virtual’ service by piggy-backing on the XenDesktop Broker service. Other than this move to virtualize the XML broker service, the service remains as NFuse capable as the XML broker service used in MetaFrame.

Because of the NFuse protocol, resource enumeration has remained compatible as MetaFrame evolved into XenDesktop. In other words, the old MetaFrame Web Interface Server would still enumerate published desktops from a XenDesktop 7 DDC, and a StoreFront 2.0 server would enumerate published applications from a MetaFrame XP XML broker service (theoretically at least!), as long as the requests are NFuse compatible.

One of the main reasons the NFuse protocol is so durable is that it’s able to negotiate capabilities. In this example, a StoreFront site contacts a XenDesktop XML broker to determine what capabilities it has, and what resources are published to the authenticated user:

In this process, the web front-end server sends an XML message to the configured XML broker to request a list of capabilities. The XML broker then responds with an XML formatted list of the types of resources it has access to. StoreFront will then request any compatible resources for the the authenticated user account. The XML broker then works with the XenDesktop broker and controller services to find out what resources are assigned to the user. The enumerated resources are consumed by StoreFront and presented to the end user. This figure from the NFuse Classic 1.7 is still mostly relevant, just different companion components:

StoreFront & Receiver

With Citrix Web Interface, the results of application enumeration were presented all at once to the authenticated user (optionally sorted into tabs and/or folders). In other words, all resources published to a user would be shown to them, though you could hide resources as needed. StoreFront with Receiver added the functionality that was originally introduced with Citrix Merchandising Server and Dazzle, which is to allow a user to pick their ‘favorite’ resources, providing Self-Service ‘App Store’ functionality and allowing a user’s favorite resources to follow them across multiple client devices and device types.

Prior to Dazzle/Receiver, applications were either enumerated in a web browser using a Web Interface ‘Web’ site, or enumerated directly by the Citrix client agent through a ‘Services’ site. In the past three years the Citrix client has evolved from the ‘Online Plug-in’ to the Receiver for Windows.

The concept of client-side agent enumeration began with the ‘Program Neighborhood’ client (pre Online Plug-in), which would access a Services site (hence the default name PNAgent), and looked like this:

Until XenApp replaced Presentation Server, this was the way users would typically connect to applications, as the web portal wasn’t nearly as solid as the old WI server running in IE 5/6. By the time XenApp was released, Citrix decided to rework the ‘PNAgent’ to display resources as a system tray icon jump menu (which remains a fan favorite, quick, easy, intuitive) in what was first called the XenApp Plug-in, and later renamed to the Online Plug-in when XenDesktop was released:

However, around the time the Apple App Store was released, and Windows Vista changed some application UI design consideration, Citrix decided to create a self-service framework by way of Dazzle and Merchandising Server. As a result of this they decided to do away with the notification icon ‘jump-menu’ since it didn’t align with Microsoft’s general UI design recommendations for Windows Vista/7. When Receiver was launched, this legacy ‘PNAgent’ functionality was taken out of the standard ‘Receiver’, and moved to only be included in the ‘Enterprise’ flavor of the Receiver, which is really just a nice way to say that they’re accommodating ‘Enterprise’ customers who still want/need to use this legacy functionality.

As of Receiver Enterprise (the black icon) PNAgent enumerated shortcuts are only available in the start-menu or desktop (according to the site/farm settings):

Citrix’s current preferred method of displaying shortcuts to end-users is using Receiver 3/4 to connect to a StoreFront Store, which uses the ‘Dazzle’ framework to present shortcuts:

The StoreWeb StoreFront site aims to provide the same look and feel for users that aren’t enumerating via the ‘Receiver’ agent:

Connecting from mobile receivers maintains this consistency of favorite resources:

I could go on and on about the technical details of enumeration, but am out of time for today. I encourage readers to check out my previous post on the XML broker for a technical example of NFuse transactions.

In my next post I go into more detail about how enumerated resources are brokered to the receiver.

XenDesktop 7 Session Launch – Part 1, Authentication

Posted on October 3, 2013 by Kenny Baldwin

The process of enumerating, brokering, and connecting to a XenDesktop resource involves quite a few moving parts, and can be a daunting task to troubleshoot for someone who isn’t familiar with the product. There are several key components involved in the session launch process including authentication, enumeration, registration, ticketing, and display/session handling.

In this post I’d like to briefly explain how the Citrix Receiver authenticates to a XenDesktop 7 application or desktop. To keep it simple, I’m only going to talk about StoreFront (no WI) and XenDesktop (no XenApp/IMA). So just Receiver <> StoreFront <> XenDesktop.

The first step to launching a XenDesktop session is to authenticate to the StoreFront Store that the XenDesktop resource is connected to. In this step, a user connects to the StoreFront server and:

Authenticates to a StoreFront virtual directory via Citrix Receiver:
- The Receiver is connecting to a StoreFront Store, StoreWeb, StoreDesktopAppliance, or PNAgent IIS virtual directory. IIS allows anonymous authentication since the StoreFront .NET services (Citrix.Storefront.exe & Citrix.StoreFront.PrivilegedService.exe) handle authentication:

To configure a StoreFront server’s authentication methods, use the Citrix Studio MMC to open the Authentication TreeNode of the Citrix StoreFront deployment. Here you can specify which authentication methods to allow on Stores hosted by that server:

There are four authentication methods available as of StoreFront 2.0:
- User name and password: Similar to windows basic auth in IIS, or explicit authentication in Citrix Web Interface Server.Prompts the user to enter their credentials at logon.
  - In this scenario, the broker passes the user’s credentials to the target ICA server on behalf of the client
- Domain Pass-through: Similar to Integrated Authentication in IIS, and
  - Allows Receiver for Windows endpoints automatically log on using the local session’s logged on user domain account (via NTLM)
  - In this scenario, the client sends credentials (via ssonsvr.exe) directly to the target ICA server
  - For pass-through authentication to work, you must use the /includesson switch when installing Receiver (per CTX133982), which tells the meta-installer to include the ‘SSON’ component (ssonsvr.exe) that is needed to capture the user’s domain credentials at logon. Receiver relies on the SSON component to send the user’s domain credentials to the StoreFront server’s StoreWeb (via browser), Store (via Receiver), or legacy PNAgent (via Online Plugin / Receiver Enterprise) virtual directory.
    - There is currently a bug with XenDesktop 7 published desktops using pass-through authentication to provide ‘FlexCast’ functionality (enumerate and launch published apps from the published desktop) where ssonsvr.exe wouldn’t run (crashed at login) because pnsson.dll wasn’t playing nice with the ICA stack at session logon.
    - Citrix has provided a provisional test-fix to customers with an open case, and will soon be releasing a public hotfix. As of this post, pass-through authentication doesn’t work on XenDesktop 7 published desktops running Receiver 3/4 without this fix in place.
- Smart Card: Allows smart card pass-through
  - Thankfully I don’t work with this method very often, so I’ll refrain from digging in. Just know that it’s required if smart-cards are used in the environment
- Pass-through from NetScaler Gateway: Allows a NetScaler Gateway virtual server to handle user authentication on behalf of the user
  - Requires Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true to be set on the DDC/XML broker)
  - Use the Configure Delegated Authentication option to specify that the NetScaler send logon credentials directly to the remote Windows session

There are also client-side registry values that control whether or not to allow pass-through authentication, and can even lock down the feature to only work with StoreFront sites in specified Internet Explorer Security Zones (aka Client Selective Trust). The easiest way to adjust this is to use the ADM template in %ProgramFiles%\Citrix\ICA Client\Configuration\icaclient.adm

In my next post on XD7 session launch I’ll talk about resource enumeration, including details about the virtual XML broker and XenDesktop broker services.

ShareFile StorageZones Connector 2.0 Install Woes

Posted on July 15, 2013 by Kenny Baldwin

I was recently tasked with implementing ShareFile Enterprise, and am executing on a design that entails the use of the StorageZones feature. In case you’re not familiar, StorageZones allows organizations to provide access to on-premise (private cloud) storage via ShareFile’s web portal, enterprise sync tool, the Citrix Receiver, and mobile access applications. In order to enable this feature, the ‘StorageZones Controller’ service (an ASP.NET web application) needed to be installed on an IIS7 server running .NET 4.5.

This sounds pretty simple, right? Wrong. The installation did not work out of the box, and I spent many more cycles than I should have troubleshooting it. In this post I want to explain how I got from start to finish with a seemingly simple process that became a complex ordeal due to lack of specific steps in the product’s documentation. Hopefully this post helps others running into this issue, which I hope I’m not the only one! 🙂

When I pulled up the installation instructions on Citrix eDocs for the StorageZones Controller 2.0 web service, I found them to be sparse on details. Here’s what’s currently published at http://support.citrix.com/proddocs/topic/sharefile-storagezones-20/sf-install-storagezones.html:

Download and install the StorageZones Controller software:
1. From the ShareFile download page at http://www.citrix.com/downloads/sharefile.html, log on and download the StorageZones Controller 2.0 installer.
  Note: Installing StorageZones Controller changes the Default Web Site on the server to the installation path of the controller.
2. On the server where you want to install StorageZones Controller, run StorageCenter.msi. The ShareFile StorageZones Controller Setup wizard starts.
3. Respond to the prompts and then click Finish. The StorageZones Controller console opens.

After following these ‘3 easy steps’, I quickly ran into several missing pre-requisites which required manual intervention; before being able to move past step 2, I had to:

Install Microsoft .NET Framework 4.5 (download link)
Add the Web Server (IIS7) Role Service

Following a reboot I was able to run the StorageZones Controller (SZC) installer, which required another reboot after it finished. After THAT reboot, the login page came up with a BIG RED error when I opened the SZC login page:

HTTP Error 500.19 – Internal Server Error

The requested page cannot be accessed because the related configuration data for the page is invalid.

Confounded, I turned to Google to hunt any known issues that might have been seen elsewhere, and couldn’t find any. There was a generic ASP.NET post on StackOverflow where someone found a mis-configured side-by-side, but I assumed mine was fine since it was a clean install. I then looked further into the following error details:

This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either set by default (overrideModeDefault=”Deny”), or set explicitly by a location tag with overrideMode=”Deny” or the legacy allowOverride=”false”.

I tried playing with some .configs per other suggestions on MSDN (changing allowOverride=”false” to “true”), nothing of which yielded anything different from the 500.19 error. After getting nowhere fast for about 20-30 minutes I called support to see if they had seen this problem and/or knew what I was doing wrong.

The first number I dialed (800-4CITRIX) took triage almost 10 minutes to tell me that I needed to call another number (8004413453). I called the other number and was quickly connected to a customer service rep. However, the rep had no technical knowledge about the product I was installing, took down some details on the error message, and told me that an escalation resource would reach out soon.

With it already being late in the day, I decided to just move on to something else while I waited to hear back. The next day I was contacted by the escalation resource, and hopped on a GoToAssist for them to help me get to the console. They ensured me that we’d get it resolved, and proceeded to validate my installation, and do some basic break/fix tasks (re-install, reboot, etc.).

I started to become frustrated after what should have taken minutes quickly turned into many minutes, and eventually close to two hours of re-installing, rebooting (two times, every time), and various other poking and prodding. For example, after adding the ASP.NET role service, we started getting a totally different error message (404.17 Not Found), and started modifying .configs and adding/removing role services.

Near the end of the call (and the subsequent reason for the end of the call) the support representative insisted that the problem was being caused by installing the service with a user account other than localhost\administrator. This was after I already humored him and created, and installed with, a local administrator account (localhost\sharefile) because he stated that a Domain Admin account wouldn’t work even though it was part of the Local Administrators group, and wasn’t supported for this installation (which I eventually determined is not at all true). He also stated that ‘a lot of the steps aren’t documented’, which was beyond frustrating.

It was at that point I decided that I was getting nowhere even faster with support, and told him that I needed to end the call. After arguing that it would be fixed by simply installing with the localhost\administrator user account, I finally convinced him that I would figure it out offline since I wasn’t close to buying his unfounded assertion. After the call was over, I went back to eDocs to review the ‘System Requirements‘ section of the documentation and make sure I wasn’t missing something. Here’s what was listed for the web server pre-requisites:

Windows Server 2008 Standard/Datacenter R2, SP1
Install on a dedicated server or virtual machine. A high availability production environment requires a minimum of two servers with StorageZones installed.
Use a publicly-resolvable Internet hostname (not an IP address).
Enable the Web Server (IIS) role.
Install ASP.NET 4.5.
In the IIS Manager ISAPI and CGI Restrictions, verify that the ASP.NET 4.5 Restrictions value is Allow.
Enable SSL for communications with ShareFile.
If you are not using DMZ proxy servers, install a public SSL certificate on the IIS service.
Recommended as a best practice: Remove or disable the HTTP binding to the StorageZone controller.
Allow inbound TCP requests on port 443 through the Windows firewall.
Open port 80 on localhost (for the server health check).

The steps that I was stuck on were surely related to the items in this list that aren’t very specific. Take Install ASP.NET 4.5 for example; To someone that has never installed ASP.NET 4.5, this step is unspecific, and lacks any semblance of detail. While searching for clues on what was causing the 500.19 issue, I recalled seeing the following command to ‘Register’ ASP.NET 4.5 (4.0.30319) on this Stack Overflow thread:

%WINDIR%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i

I decided to run this command and refresh the login page, at which point I got a new BIG RED error on what should have been the login page. This time it was a 404.2 Not Found error. Based on the error message, I started investigating the other pre-requisite that wasn’t very clear in terms of steps, and isn’t even relevant if the ASP.NET v4 extensions weren’t properly registered:

In the IIS Manager ISAPI and CGI Restrictions, verify that the ASP.NET 4.5 Restrictions value is Allow.

I found and opened the ISAPI and CGI Restrictions feature in the IIS management console, which can be found in the IIS section of the server-level node. I then found that while the ASP.NET v2 extensions were set to ‘Allow’, the v4 extensions were set to ‘Deny’. I set both 32-bit and 64-bit extensions to ‘Allow’, and was then able to get to the login page (great success!); whew..

And so, something that should have taken a couple of minutes ended up taking a couple of hours. Hopefully I saved somebody somewhere a headache (or a couple of hours) by doing the ShareFile product and support team a solid, and sharing clear steps that should have either been handled by the installer, or at least the technical writer who published this lackluster, detail lacking, setup guide.