Unitek Citrix Training Blog

The Access Gateway 4.5 with Advanced Access control is the Platinum product’s preferred access portal, called the “Access Navigator Portal”, or the “Nav” portal for short. Configuring the Access gateway with AAC (Advanced Access Control) and with the Presentation Server Farm in 4.5 is a little more involved than it had been in 4.2, and the order of the steps can be critical. Below is a fully worked out and replicable implementation, with the CAG 4.5, AAC 4.5, and Citrix Presentation Server 4.5 with a Web Interface.

The roadmap is:

1. WI 45 install & configure (unsecure)
2. configure Web Interface for use with Advanced Access control in AMC for WI site.
3. configure web resource for Web Interface (set as “integrated windows auth”, “WI42 or later resource”)
4. integrate CPS farm into AAC farm, with farm, server, XML, and pick which Web Interface (from the web resource), at the logon point in the AMC.
5. create a policy to grant access to Web Interface resource (now it should integrate WI 45, but insecure)
6. add security to the WI45 site (enter FQDN of Access Gateway appliance, and URL of Secure Ticket Authority (STA); set DMZ settings to “secure gateway direct”)
7. power on the Access Gateway appliance and import it into AAC farm
8. add at least one secure ticket authority (STA) to Access Gateway tab in AMC for AAC server
9. configure ‘accessible networks’ in AG tab; add “entire network” resource to default policy, (or some subset of the network that contains the resources to be provided).

In order to integrate Presentation server applications into AAC, the Web Interface 4.5 must be installed and configured properly, as explained in the chapter on Web Interface advanced configuration in CPS 4.5.

There is an item in the task pane of the 4.5 Web Interface site called “manage access method”, and under that pane the Web Interface can be configured either for “direct” access, where the users enter the URL of the Web Interface, or else “using the advanced access control”, where the users enter the URL of the AAC web server, (or the Access Gateway enters it on their behalf). The task in the roadmap is the simple modification of this property page, to point to the Advanced Access Control server.

The Web Interface site will no longer work when contacted through the Web Interface URL, because it is now supposed to be accessed through the portal. We will have users authenticating to the portal, so we probably want to let the authentication PASS THROUGH to the Web Interface. This is done later in the AMC of the Advanced Access Control server, but in the Web Interface site configuration we need to leave “prompt users for password” unchecked.

In the AMC of the Advanced Access Control server we need to create a new web resource, since nothing can be accessed through the portal without being first created as a resource, then also associated with a security policy.

The Web Interface 4.5 gets integrated into the AAC portal as a special type of web resource, by using the drop down menu in the resource creation window, and choosing “Citrix Web Interface 4.2 or later”.

To get the third pane in the Access Gateway portal, on the left, we need to “publish” the web interface as a web resource, and we need to add the exact URL of the Web Interface server, even though that site no longer works when we contact it directly with a browser - it is now set only to listen to this AAC server, over port 80.

Any resource created in the farm becomes an available resource in the farm security policies, unselected by default, so we can either create a new policy for the new web resource, or more practically modify an existing policy to allow access to one more web resource.

To add the resource to a policy we go to the policy in the AMC and click “edit”. On the resources tab, there is a new web resource available, and to grant the same access this policy is granting for other web resources on the web interface, we only need to click the box next to the resource, in the heart of the AG/AAC.

Any number of logon points can be created in the AAC farm, and any number of them can be associated with Presentation Server farms, but by default no logon point allows access to Presentation Server, and so the special web resource we just configured can’t work yet. In the AMC of the AAC server, at the farm level, the Presentation Server Farm has to be added, with a designated XML server and an XML port. This has to be done AFTER the addition of the web resource, because we pick which “Web Interface” from a list of web interface-type web resources in the farm.

The Presentation Server farm that is added to the AAC farm needs to be added to the logon point, after being configured at the farm level, in the AMC.

Then we go to the logon point with any configured browser, and automatically get the three pane default configuration of the Access Gateway 4.5 portal, with the Web Interface applications enumerated in the left-most pane. Pass-through authentication from the AAC web server to the Web Interface was accomplished by creating the “Citrix Web Interface 4.2 or later” resource-type, and by choosing “Integrated Windows Authentication”.

Securing Advanced Access Control with the Access Gateway appliance

The portal we have configured has two different pieces that need to be secured, even if we are using the same Access Gateway device to secure both of them.

The left pane with Web Interface published apps are secured in a manner very similar to the Secure Gateway software - the Web Interface AMC is used, under DMZ settings, to give out “secure Gateway Direct” IP addresses, (or “Secure Gateway Translated”, if the appliance itself is behind a NAT router). Then we put in the FQDN of the CAG and the URL of an STA. The only difference from the CSG implementation is that instead of configuring an STA on the CSG, we configure the STA on the CAG appliance settings, in the AMC of the AAC server.

The right side of the Access Gateway portal - the file shares - we secure separately, not in the AMC of the Web Interface site, as above, but in the AMC of the AAC server, in the farm properties, Presentation Server farm integration properties, in a unique interface, where we also configure DMZ settings, for “Access Gateway Direct”, then enter the FQDN of the CAG, and an authentication service, NOT an STA as in the Web Interface screen.

The settings in the AAC AMC affect how the Citrix apps will run if they are “launched” by hitting the “Launch” button under the drop-down menu, which appears when File Type Association (FTA) is configured.

To configure the Web Interface - left pane - for SSL/TLS, we go to the DMZ settings of the Web Interface site we are integrating, and change from the default of “Direct”, (referring to direct, or “internal, non-routable”, IP addresses of Citrix servers), to “Secure Gateway Direct”, meaning we will get the IP address of whatever secure gateway device we configure in the next screen. The next screen is one click down from DMZ settings; the “edit gateway settings” tab.

There are two critical components being configured here, that need to be configured precisely, over precise ports. The first is the Fully Qualified Domain Name of the Access Gateway appliance. This will be configured on the appliance itself in the CAG admin tool, and the name of the certificate on the appliance will have to match.

The second component we need to integrate here is the Secure Ticket Authority (STA), which runs on any Presentation Server 4 or 4.5 over the designated XML port. If the XML port is anything other than “80″, which it usually is, the URL will not work without having the port added into the URL after the server name.

These two configurations, both under “manage secure client access” in the AMC of the Web Interface site, constitute “adding security to the WI45 site”. Now that we have told the Web Interface to send out ICA files that point to the AG appliance, we will have to power up the appliance and begin to configure it.

The appliance ships with a CD which is a backup of the firmware, and should be backed up and saved. This CD can be placed in the appliance at any time to reset the system back to the factory defaults. Configuration information stored on the Access Gateway can be backed up to a file through the graphical access gateway administration tool, and restored later. When the machine is set to factory defaults, its IP address is 10.20.30.40, the root user’s password is ‘rootadmin’, and there is no license on the device and so it is incapable of accepting regular traffic.

On the back of the server there are the typical connections for keyboard, mouse, and video, but these connections are not to be used on the Citrix Access Gateway appliance. The serial port is a special case, and can be used for direct basic administration, just to change the IP address to something on the network so that it can be managed with a more comprehensive utility.

To get where we need to go with the Access Gateway, we have a roadmap of several steps, across several utilities.

1. power on the appliance and connect with a crossover serial cable from a Windows machine running “HyperTerminal”, hit “enter” and login as root, rootadmin, to set an IP address and default gateway on the subnet. This is the “serial Console”.
2. plug the CAG into the network using a network cable, use a browser to go to the Access Gateway over TCP/IP to the address just given to it, and port 9001. This is the “CAG Admin portal”. From here we download the CAG Admin tool. (From here we can also run a Linux desktop on the appliance that monitors all traffic through the appliance in a Citrix management console.)
3. With the admin tool downloaded to the desktop of a Windows workstation, we install the admin tool and log in to the IP address of the appliance as root, rootadmin.
4. In the admin tool, we set the DNS server for the appliance, set an FQDN, and go to the “Advanced Settings” tab to configure all other settings to come from “Advanced Access control”, and then name the AAC server that can “discover” the appliance.
5. create a DNS record in the domain for the appliance, that the Web Interface and the AAC web server are able to resolve.
6. Discover the appliance in the AMC of the AAC server, in order to configure “accessible network” and “secure ticket authority”.

The Access Gateway comes with one serial null-modem cable, which can be connected to the back of the Access Gateway, and to a PC on the other end. The PC needs to be a Windows machine running HyperTerminal, and the baud rate of the new connection needs to be set to 9600. Hitting enter a couple of times should produce a login prompt. The only valid account is root, and the password is rootadmin.

From the “Express Setup”, only IP address, subnet mask, and default gateway can be set. The IP address is being set for “eth0” only, which is the first of the two LAN connections on the back. Any DNS information has to be configured in another utility; this tool is only to make it easier to get to the next utility. From here the administration port on the Access Gateway can be closed, further securing the appliance.

The next step is to connect to the new IP address of the Access Gateway from a browser on the intranet, at port 9001, using https; (there is a pre-configured private certificate on the Access Gateway when it ships).

https://<ag ‘s new IP address>:9001

The Administration Portal is only the next step along the way to the main administration utility. The admin portal is be used to download the next tool, which is called the Access Gateway Admin tool.

There is also an Access gateway desktop that can be downloaded from here, for administrative use. The desktop is a Linux X—Windows desktop that runs several GNU utilities including Ethereal, and a Citrix tool called the Citrix Real time monitor.

The Access Gateway Administration Tool is the main administration tool if the Access Gateway is used as a stand-alone device, without the Advanced Access Control feature. Even with the Advanced Access Control feature, with policies managed in an Access Management Console snap-in, there is still critical work to be done in the Access Gateway Administration Tool.

The tool downloads and installs onto a Windows 2000 or higher machine, and manages either a single appliance or a cluster.

The critical tasks on an Access Gateway in an Advanced Access Control implementation are all on the “This Gateway” tab under the “Access Gateway Cluster” tab at the top of the admin tool. On the first screen, “general networking”, an FQDN for the gateway needs to be set, and the network card can be fixed to full duplex at the same time.

Clicking “submit” causes the Access Gateway to go to a reboot. The Admin tool can remain open, and in about two to three minutes the gateway will be able to be contacted again. On the “Name Service Providers” tab the DNS server can be set.

On the “Routes” tab, the choice is between “Static” or “dynamic” (RIP II) routing. Static is the default and there is a table for the input of static routes.

The Administration tab is the place to shutdown and restart the Access Gateway, not with the button on the front or the power cable on the back. This is also the tab for managing certificates from a CA. Certificate requests can be generated at the “Generate CSR” tab.

Most critically for the Advanced Access Control implementation, there is an “Advanced” tab, on the Access Gateway 4.2 (and up)firmware only, that allows the Gateway appliance to receive its configuration information either from this utility, or from the Advanced Access Control configuration on a SQL or SQL Express database.

When the Advanced Access Control option is chosen, all the tabs other than “Access Gateway Cluster” become grayed out

The entire Citrix web implementation is extremely dependent upon DNS, and we will need an internal DNS record for whatever we want to call the AG appliance.

Finally, as the Access Gateway reboots knowing about its Advanced Access Control server, the AMC on the AAC server can run a discovery and automatically discover the appliance. Once discovered, we can configure the critical “accessible networks” and “secure ticket authority” settings.

By going into the “Edit gateway appliance properties” page, we can configure the critical appliance settings that are otherwise configured on the gateway appliance itself, when the appliance runs in “Standard” mode. Specifically, we need to enter the IP Addresses that are allowed to be accessed through the gateway appliance. Also, by setting the STA, we are saying what server authenticates tickets that were given out by the Web Interface, so we MUST choose here the same STA server(s) that we chose in the Web Interface security pages.

The Secure Ticket Authority interface is completely different from all the other places it is entered. In the Web Interface, it was entered as a URL, pointing to “:8080”, the XML port. Here, we point to the same server, over the same port, but we do not use a URL to configure it.

At this point we should be able to run any Presentation Server app, through the Web Interface pane of the Access Gateway portal, with SSL/TLS protection over all ICA traffic.

CM, Citrix Training Instructor
Unitek Citrix Training

GPO’s

Windows 2003 Group Policies can do a lot of things; it’s such a big list of things that you can do in a Group policy, with the default templates, that it can be difficult to find a setting among the hundreds of fields and sub-fields in the Group Policy tool in Active Directory. There is an Excel spreadsheet called PolicySettings.xls that is searchable, and contains detailed explanations of each setting in the default Windows 2003 SP1 templates.

But there are a few key settings among all the registry keys that are critical to the success of a Citrix implementation.

• Delete Cached Roaming Profile – removes the roaming profile from the Terminal Server after the user logs off, and the changes have been successfully copied back to the central roaming profile directory. (used in conjunction with two others – “- do not detect slow connection” and “-wait for remote profile to load”)
• Folder Redirection (to keep the size of the roaming profile down and keep the user’s data centralized and secure)
• Lockdown of Internet Explorer / the Desktop (may require significant testing to make sure things aren’t too locked down to get the work done).
• Loopback –replace /merge
• Hide Drives on My Computer – determines exactly which drive letters a Citrix client can see, and has to take into account the home drive, the other network drives, and the remapped client drives.

“Loopback-merge / Loopback-replace”

The “loopback merge” or “loopback replace” setting in group policy can be a critical component to getting the control over user access that a Citrix implementation requires:

First of all, the users don’t go in the users container, and the Citrix servers don’t go in the computers container, because they can’t be controlled with group policies; instead, separate containers, “OU’s”, are created by the AD administrator.

At the minimum, we require a single OU for the Citrix server we are implementing. As the Citrix integrator, we need to be able to control the type of access the users are getting when logged on to the Presentation Servers, and we use GPO’s, on an OU, to accomplish this.

As far as the users, they also don’t belong in a folder, but in an Organizational Unit. But there are a few different scenarios to look at with the users. If we are building the AD from scratch along with the Citrix implementation, we might as well create the “Citrix Users” OU; but we might more likely be bringing Citrix into an AD implementation that already exists, for completely different designs than “terminal services”, and the users already may have GPO’s controlling things like folder redirection and hiding server drives, in ways that conflict with what we need them to do.

In this case the Citrix integrator needs to be able to “lock-down” the Citrix SERVER Organizational Unit, so that already-existing users with conflicting user settings can come in without threatening the stability of the Citrix implementation.

In the case of the “folder redirection” GPO, we have to configure the GPO in the “user” section, since there is no corresponding setting in the “computer” section. But if we set a “user” GPO and put it on our one SERVER organizational unit, by default, we don’t get the guarantee that our GPO will work.

User settings will be read in AD first at the computer OU, but then at the user OU, and the user OU will win out if there are any conflicts, by default.

The key to controlling what happens is the “User Group Policy loopback processing mode” GPO setting. After setting it to “Enabled”, on the GPO of the OU of the Citrix server, the integrator has the option of setting it to either “merge” or “replace” mode.

In the scenario where the integrator has no control over the GPO’s on the user’s OU’s, and the GPO’s could very well be conflicting, (in terms of which drive letters are hidden or revealed, for example, or how locked down a machine is), the integrator can use “loopback-replace”, to cancel out any user-settings that may have been assigned at the user OU, and then use another GPO to set all the user-settings that the users will have, when logging in to servers in that OU.

In this scenario, any setting under the “user” portion of the GPO will have to monolithic, meaning every user will have the same setting.

In another scenario, an organization can require differing types of access for different types of users. For instance, a regular branch employee may be restricted to only one mapped client drive that is going to correspond to their USB audio device files, and the other client drives are to be hidden, so that they cannot use the WAN for transferring data from their hard drives to the central “home” drive they are mapped to in the Citrix implementation; the manager at the branch, however, will be allowed to access his own client drives in the Citrix environment, and the transfer of files across the WAN will be at his discretion.

In order to implement this type of access, Citrix says the integrator needs to be able to control the GPO’s at the user’s OU’s, and designs different user GPO’s on those user containers.

With a different OU for each of the three types of users, the integrator can set up different user GPO’s, then, at the server container, the integrator places a “loopback-merge” GPO, in order to allow the various user rights to be “merged” into the Citrix Presentation Server’s environment, providing the user GPO’s of any user’s capable of logging in to these servers have been analyzed for any security or incompatibility issues.

A user is logging in to Terminal Services and getting this Terminal Services environment, often only after having logged in to a server or domain and run a different set of GPO’s for that environment. If the user is logging in from a Windows workstation, access that workstation itself is managed by AD as well; in the case of a thin client, there is less of a GPO management issue.

The Citrix integrator needs to provide access to mission critical applications. Some of these may be web apps, and may be provided by publishing IE on the Citrix Presentation Servers. This doesn’t necessitate the granting of access for users to browse the web through the Presentation Server, however. GPO’s can be set to restrict the users of the IE on servers in an OU to only a fixed set of websites. (These websites can be further enhanced with SSO by adding a Password Manager agent to the Citrix Servers.) As long as functionality of these websites is not impeded, the IE on the Citrix servers should be locked down as tightly as possible, and virus scan software installed, and internet traffic monitored, and filtered for only a fixed set of websites.

On the other hand, users may want or need access to external websites from time to time. This access can be assumed less mission critical, or it would be transferred to the Presentation Server environment. Therefore, the client machines should be less restricted, allowing web browsing, and less restricted access to the machine as well, compared to the Citrix environment of the same user account.

To accomplish this, the workstations reside in a different OU, separate from the Citrix servers. A loopback policy is placed on the workstation container as well, and in this scenario, the option would be “loopback-replace”. This way, the user settings that restrict drives, and IE and desktop access, and reside in GPO’s on the user containers, will be discarded, or “replaced”, when the users log in to the workstations, and there will be only minimal restrictions to replace them.

Then, within those varying user GPO’s, login scripts are pointed at to map home and shared drives, the settings to lockdown the server are set, folder redirection of My Documents and Desktop to the user’s home drive is configured, and “Hide Drives on My Computer” has to be configured, to control exactly what the user can see when connected to the Citrix servers.

The disadvantage of this design, though it is the Citrix and Microsoft “Best Practice”, is that it necessitates re-building the entire AD for the Terminal Services implementation, or building two different user accounts for each actual person - one for the terminal services and another for whatever the old AD account was used for.

As an alternative, there is a way to lock-down the Citrix server OU with “loopback-REPLACE”, while still configuring different types of user access. By adding the multiple, conflicting GPOs for different user types at the one server OU, with “loopback - replace” in place, we can go into “properties” on each user GPO, go into “advanced”, and highlight each group on the menu, de-select “apply group policy to”, then add a group from AD, like “managers”, and “apply group policy” only to that AD group.

The “apply group policy to” button is in the properties of the GPO, under “properties”, “Security”:

Hiding Server Drives

The TSC tool or a PSC policy can be used to enable or disable “client drive mapping”, and assuming the “remapping of server drives” has not been done, the client drives are going to be V, U, and T, possible continuing up the alphabet backward from there for any other existing client drives at the moment of connection.

The login scripts can get the user an “H” drive for home and an “S” drive for share. By default, the user gets access to the Presentation server’s drives, as they are in its own registry, most likely C, D, and E.

All this can be then filtered by a GPO that reveals, or not, each letter in the alphabet, if there is something there to reveal.

The problem is that in the standard Windows template file – the “system.adm” file on a standard domain controller, didn’t predict the complexity of this environment.

Among the string of V,U, an T, H & S, and C, D, and E, we want to reveal or hide various combinations. The interface in AD offers 6 different, pre-configured, variations in a drop down menu, on which drives to hide. The choices are “Restrict A&B”, “Restrict C only”, “Restrict D only”, “Restrict A B & C only”, “Restrict A B C & D only”, and “Restrict all Drives”.

The two more options we might be hoping for are “Restrict All but S & H”, and “Restrict S, H & T.

And there is a way to modify the ADM file on the domain controller(s) so that the extra options can be available. It involves typing the alphabet backwards into a calculator in binary, clicking 1’s for every letter to hide and 0’s for every letter to reveal, then converting the number to decimal, and appending the system.adm file on the domain controller. The MS KB article # 231289 details the steps;

One thing to watch out for is that the number of drive letters on each Presentation Server have to be standard and consistent, and this GPO is customized around that particular drive letter situation, as well as the client drive situation. Without standards in practice, the implementation will become a problem.

Since many people find themselves in the same situation with the need to hide specific drive letters other than the ones in the default windows policy template, there is a third party tool available from http://www.petri.co.il called gpdrivesoptions:

CM, Citrix Training Instructor
Unitek Citrix Training

There are two main areas of Active Directory design that are critical to most Citrix implementations: Profiles, and Group Policies.

Profiles

With the most simplistic, default situation on a Windows Terminal Server, a user exists in Active Directory without any “profile”, or “terminal services profile” information included. When the user first logs in to the Terminal Server, a “local profile” is created, under “Documents and Settings” on that application server that they happen to hit, and this directory structure includes windows settings, as well as “My Documents”, the “Desktop”, and Internet Explorer’s “cookies” and “bitmaps”; If a user then saves data in these locations, logs out, and logs in to a different Presentation Server the next day, a completely different local profile would be created, and the user would be mystified as to why their data from the day before is “sometimes there, sometimes not”, as they log in to different load balanced desktops or applications.

There are advantages to “local” profiles on a Presentation Servers: no data has to travel across a wire before the profile can load, and the profiles on the separate servers are not being tied together, and so are not as likely to become corrupt as “roaming profiles” are. Logins are faster and management of profiles is simple.

A public library can publish a load-balanced desktop across several Citrix servers, and the local profile on each server of the librarian, or the “library user”, remains the same. The public uses the desktop, browses the internet, types, prints or saves, but leaves behind nothing, and doesn’t expect to see their own data, or desktop changes, waiting there for them the next day. In an environment like this, the local profiles can become locked-down “mandatory” profiles that do not accept changes, and so do not become corrupt. Renaming the ntuser.dat to ntuser.man was the simple step to make a local profile a “mandatory” profile.

But most internal organizations need to provide regular access to personal data, and personal application and printer settings changes, accessible across multiple, load-balanced, application presentation servers. Microsoft’s alternative to local profiles is something called “roaming profiles”; the profiles are tied to the individual AD user accounts, and each user owns a private directory share, where their profile is centrally store. This profile is then downloaded and cached on each Citrix application server, changes can be made, then the profile is copied back up to the central location, to be pulled down to the next application server the next time.

To configure a roaming profile on a Windows 2003 Domain Controller, the user account in AD is modified on the “Terminal Services” tab, and a UNC can be used to the share on a central file server.

But once roaming profiles are implemented, several steps must be taken to avoid having the roaming profiles become corrupt, so that the user either can’t log in, or out, and an administrator ends up having to re-create the profile.

The Microsoft free downloadable utility called “UPHClean” is recommended for any terminal server, to clean up all the user profiles that come and go on a daily basis.

In the PSC printing policies, the printer properties can be forced to be stored on the client device, instead of the roaming profile; this can cut down on profile corruption.

Delete cached roaming profile

And if roaming profiles are implemented, Citrix recommends running several “Group Policies” along with them, to maintain stability in the implementation. By default, these roaming profiles DO copy up to a central location when a user logs out, but they also remain behind on each Citrix server, “cached” for ease of use in the future. The problem is that with the load managed, published application model, users could conceivably log in to multiple servers at once, and log out of them in a different order, and this would eventually lead to corruption through time-stamp illogic.

Citrix recommends having the roaming profiles deleted by running a GPO, located in the “computer” section, under “administrative templates”, “system”, “user profiles”, and when we enable it, we are recommended to enable two others: “do not detect slow network connections”, and “wait for remote profile to load”.

Folder Redirection

The problem, now, with “roaming profiles” is that by default they can become large, with “My documents” and IE’s cached bitmaps and cookies, and “Desktop” all part of the profile. In order to avoid sending a user’s entire home folder over the wire to be cached on an application server, “folder redirection” can be implemented through Windows GPO’s, to keep the profile from becoming unmanageably large. Folder redirection is implemented through Windows GPO’s, in the “user” section, under “windows settings”. Once implemented, large portions of the formerly “roaming” profile now remain stable on the central “home” directory, available for retrieval through whatever methods the Citrix administrator has provided, when needed, instead of the default design, which was to download all the documents a user had ever saved to each server the day they log in to that server.

Another feature of Windows 2003 GPO’s is something called “profile size quotas”. Users are allowed to grow their profile until it gets larger than a preset value. The problem with implementing this setting is that when the user passes the profile size quota, they are unable to complete a logout, because they can’t complete the copying back up of the profile to the central location, and they have to call the help desk.

Even with folder redirection in place, the profiles in an enterprise Citrix deployment can become large, due simply to a high volume of applications that all require bits of a profile.

Citrix Consulting has come up with a custom scripting solution called “hybrid profiles”, where they look at just how much of the profile requires changing, and script a solution that cuts way down on how much of the profile actually travels back and forth, “roaming”, and leaves the reset as a permanently cached “local mandatory” profile on each Presentation Server. “FLEX” profiles are a free downloadable tool to develop scripts on your own that render your large roaming profiles “hybrids”.

Stay tuned for part 2…

CM, Citrix Training Instructor
Unitek Citrix Training

1. WI/CSG
2. XML
3. STA
4. TS licensing server
5. License server and data store

When we talk to Citrix administrators and first ask about their Citrix implementation, they may tell us they have 2 or 3, 4 or 5 servers. With the exception of one machine running the Web Interface, the rest of the Citrix servers are assumed to be pretty much equal, serving apps.

But the truth is there are several components in the Citrix farm that are single points of failure, with varying levels of tolerance for disconnection. All the Citrix servers are therefore not equal. Some application servers going down may only create additional load on the rest of the servers. Other application servers may be involved in more unique and critical functions as well, such as XML server, or STA, for the Web Interface.

1. WI/CSG

If the WebInterface machine, which runs over IIS, goes down, there may be no other method of external access to the applications on the LAN. By default, the Citrix Web Interface is not fault tolerant. It takes only minutes to “create a site” when first configuring the Citrix servers, but by itself that site is a single point of failure.

The first thing that could be done is to create a second site on a second Web Interface machine. By itself this would not provide for a smooth failover; users would loose connectivity to the first site, then have to enter a different URL or IP address to get to the second site, before reconnecting to their ICA/CGP sessions.

Originally the only thing Citrix said we could do about failover was get a hardware load balancer, but eventually Microsoft Clustering was supported. The same is true of the Citrix Secure Gateway - the SSL software that comes with WebInterface for free, to secure the ICA data stream via SSL/TLS certificates.

2. XML

The Web Interface needs to talk to at least one “designated XML server” for each farm that it supplies credentials to. In the configuration utility for the site there is an option to add additional servers to a list of designated XML servers, and decide whether you want all the servers contacted on a regular basis, or, simply a main server and a list of backups. Either way, more than one - strategically chosen - Presentation server should be configured. The only requirement of the servers chosen is that they have the same port configured to be used for XML.

Even if there are two websites and two WebInterface machines, both using the same configuration with the same single XML server, though functional - and common - would be a single point of failure.

3. STA

If you’re using the WebInterface, you’re probably using the Citrix Secure Gateway software, or the Citrix Access Gateway hardware network appliance, to secure the ICA/CGP traffic via SSL over untrusted networks like the internet. Either way, your security box is using one of your Presentation Servers to both issue and authenticate “1-time-only tickets”, which are passed from the Web Interface to the client device and back to the Presentation Servers. It’s part of how the single-sign-on effect works within WebInterface, without exposing credentials to untrusted networks. Logistically, the same one server has to authenticate all the tickets that it issues.

And being a single DLL to do the job, it isn’t very hard, and Citrix tells us we’ll never need more than one for performance, but this is also a very dangerous single point of failure. That one Citrix server that happens to have been chosen as the STA - Secure Ticket Authority - goes down, and nobody can get in from outside.

Solving the single STA problem is about as easy as solving the single XML server problem; there is an option where the STA is configured to add more than one, and to allow the list to be used for “load balancing” or failover. This has to be done carefully, however, as multiple interfaces have to be configured with identical information, one interface telling the system where to make the certificates, and the other telling the system where to authenticate them. If these do not always match, that is also a big single point of failure. Without an STA, everyone using the Web Interface just gets a red error.

4. TS licensing server

Logging in successfully to the application server requires not only a Citrix License Server and a concurrent user Citrix License for the version of Citrix trying to be accessed, but also a Terminal Services CAL, which has to be stored on a Terminal Services Licensing Server. There is usually at least one TS Licensing server, possibly the Domain Controller, for the whole Citrix Farm.

There are two different methods of licensing available for TSCAL’s - per user and per seat. The per user licensing is preferable, because you are only on your honor, and if some disconnect occurs between the Citrix servers and the TS License server, there is no technical issue.

But per-seat licensing is another story. Being unable to get a TSCAL, after a set amount of time, can stop a user from getting in to a Citrix session, when the method of Terminal Services licensing on that Citrix server is set to per-seat. If this is the case, the TS Licensing server is another dangerous single point of failure.

5. License server and data store

These are actually two separate issues, but they have a lot in common; both are 30-day fault-tolerant single points of failure. Anyone good enough to check their Event Viewers on the Citrix Servers at least once a week will see the red “X” and the number of grace hours remaining until catastrophic failure, in there once an hour for the whole 30-day countdown.

The Citrix License server has to be up, and the license file has to be available, over port TCP 27000, by default, to all Citrix Presentation Servers. The license file has the case-sensitive name of the License server hard-coded and digitally signed, so if licensing is installed somewhere else and the farm is pointed to the new license server, there is still a 30-day countdown. Citrix can re-allocate the license for you on MyCitrix.com, but it only takes two reboots to rename a server in honor of the old license server, assuming that it’s not going to cause any other problems for other things hosted on the server to be renamed. Citrix supports the use of Microsoft Clustering for the Citrix License server.

The IMA data store is an older and more complicated story. Holding all the settings for all the published apps, policies, and servers in the farm, this heart of the Citrix implementation may reside in an Access database on any one of your Citrix Presentation Servers - by default, on the first one in the farm. Then again, and in most situations, the IMA Data Store resides on a separate SQL server, with the outside chance it is sitting on Oracle or DB2.

If it’s sitting on an external box, there are two single points of failure, by default, just in the case of Data Store disconnection - there’s the SQL server itself, of course, but then there’s the one server with the DSN file to that database server. By default, IMA configures the first server in the farm to connect to the data store, and the rest of the servers go through that first server, in what Citrix calls an “indirect” IMA connection. Our option, and a Citrix best practice, is to add DSN files manually to several other Citrix servers, in order to maintain connection to the Data Store under all circumstances.

Having the data store itself backed up goes back to the beginning of the article, the idea that, whether on Access or on SQL, and whether there are professional daily backups running or not, there should be a separate, “last known good” backup of the data store, on a flash drive, in the possession of the lead administrator or integrator, and a process in place to get back to that Data Store state in the event of Data Store failure.

CM, Citrix Training Instructor
Unitek Citrix Training