Overview
Even after all these years, there is still a lot of misconception out there about what exactly “Citrix” application publishing is. There are still CTOs and Infrastructure Managers who shy away from it after negative past experience or still don’t know precisely what it is; there are still many bad installations out there that function at a fraction of their potential; and there is still end-user resistance also caused by historical substandard encounters with the product.
Citrix, however, is just one very small piece of the over-all solution that provides end-users with published applications. IT people tend to label the whole configuration as “Citrix”, and the end-user community has now picked up this term. Application publishing may also be known as thin-client or server-based computing.
This article will delve into the most common areas that can make or break a successful application publishing solution: the applications themselves, the Windows environment, and the network. It targets those either who are maintaining an existing solution or who are considering implementing one.
The benefits of application publishing have been discussed enough so that they are now common knowledge in the IT industry: limited instance application management rather than on every workstation, reduction in the cost of application management, access from any location or device, additional and more granular application security.
In terms of their application publishing software, Citrix produces a product called XenApp, previously called Presentation Server, before that MetaFrame, WinFrame, WinView, and starting life as Multi-User. In its current iteration, it runs on a Microsoft Windows server and enhances its Terminal Services remote-control multi-user computing. It also provides tools to easily manage published applications (essentially enhanced shortcuts) and most aspects of the XenApp servers, and also to monitor alerts and provide reports. And that’s it. The tools are very useful and in my opinion, if you want to provide application publishing it is better to have Citrix than not to have it, but that is all it does.
The diagram below shows components that may be included in an application publishing solution. Note that of all the 32 components shown, Citrix software is responsible only for three (shown in red), and optionally another remote access component by Citrix, Access Gateway.
32 components that can make up an application publishing solution
Therefore, if there is a problem with published applications, odds are, it is not a problem with the 3 out of 32 components.
I used to say that Citrix is not an application where you just run “setup.exe” and you’re done. However, these days, in terms of pure Citrix, it is almost that simple. It is the design, configuration and tweaking of many of the other 29 components that take the time and skill to get the solution right.
For the remainder of this document, I will refer to a server hosting the applications and running Windows Terminal Services (and perhaps Citrix XenApp) as an “application publishing server”. When discussing technology specific to Windows Servers, Terminal Services, I will use the term "Terminal Server".
The Application
The first thing to realise is that not all applications will work well on a multi-user remote-controlled computer, an application publishing server. Some that spring to mind instantly are those that rely heavily on graphics or processing power, such as Computer-aided Design (CAD) or some (not all) insurance modelling programs. It is possible to publish and run these types of programs, but it will come down to end-user acceptance as to how “usable” the programs are in this environment, balanced with how cost effective it is. It may be that IT prefers to run all applications on Citrix, even if that means allowing only one instance of each per server. IT may calculate that the operational savings outweigh the added hardware expense for such an installation. Other applications are simply too old or badly written to function at all on a multi-user computer. Only thorough testing and User Acceptance Testing (UAT) will truly determine usability.
The majority of applications out there will, however, work quite well in a published environment, even most that are not officially supported by the vendor to “run on Citrix”. The key to this is to know the applications well, and to analyse them as you install, even supposedly “simple” ones such as WinZip or Adobe Reader. For more complex programs, it is always worthwhile having an application vendor specialist on hand during installation working side by side with the Citrix specialist.
An application must pass up to five technical criteria to work well in a multi-user remote-control computing environment: multi-user, multi-computer, multi-location, performance, and integration with existing Windows profiles.
Multi-User
An example of an issue that may occur when multiple users access the same application on the same computer, in this case, an application publishing server:
A fictitious application is multilingual, but it stores the user language settings in a “c:\windows\language.ini” file.
User1 logs on for the first time, sets her preferred language to English, uses the application, and then logs off. User1 logs on again; her English preference has been set as desired, and so she simply uses the application and later logs off. User2 now logs on for the first time and sets his language to German. This changes the “ini” file on C: drive of the server.
User1 logs back on. Whether or not User2 is still logged in, User1 will now see the application in German. She will have to figure out how to change to the language back to English again, via German menus; or more likely call the IT Help Desk. The same will occur for User2 when he logs on to English settings again.
This is obviously a simplistic scenario, as most applications these days would store such a setting in the HKCU registry hive, but it does display the types of issues to look out for. It also crystallises how the installer must know the application well when installing to Citrix. Maybe there is another “*.ini” file or registry setting that points to the location of the “language.ini” file, in which case it could be modified to point to each user’s individual copy of the “language.ini” file on their network Home Drive (and then a script would be required to ensure that each user has a copy of said file upon logon). Alternatively, maybe the location is hard-coded into the program and there is no way around this issue.
Note that this scenario would also occur on regular workstations if users swap desks. Many multi-user considerations are identical to those that should be analysed for imaged desktop rollouts or application streaming.
Issues include simple (i.e., colour selections) or critical (as in the example above) preferences, or basic application settings, such as pointers to data sources. Such pointers could be set on a per-user basis, but not in a multi-user capable manner. Obviously, such problems would lead instantly to data corruption. “Lock” files could be located on C: drive of the server, making the application unusable for any user after the first.
Working around these issues is where the skill of the installer comes in. Hopefully, the registry can store all such settings, in which case custom Active Directory (AD) Group Policy Object (GPO) Administrative Templates can be built, or Windows 2008 Group Policy Preferences (GPP) can be implemented, to ensure that any registry changes are centrally managed and controlled. Perhaps a logon script is required to manipulate file locations, names, or contents.
Many preferences don’t need to be controlled, but merely set into the Windows Default Profile so that each user doesn’t have to go through application “mini-setups” the first time they use it. For example, the clicking of Adobe Reader’s license acceptance, or telling WinZip not to provide hints every time. I will discuss the Default Profile later.
Multi-Computer
Multi-computer means multi-application-publishing-server in this context. Even if there will only be one such server available, these considerations will hold true when it comes time down the road to add another server or to migrate to a newer one. An example of an issue:
Citrix load balances applications according to, mainly, server capacity in terms of CPU usage and RAM. A user doesn’t necessarily use the same server in the farm each time.
User1 logs into a complex application where a user typically sets up many preferences before they begin using it. This can take up to five minutes, but then the settings should be set the next time they use the program.
This Citrix farm has 10 load-balanced servers. It is possible that User1 gets logged onto each one in the next 10 or 20 days, thus having to go through that preferences setup nine more times. The second or third time would generate a call to the Help Desk.
If such settings are stored in the user’s Windows profile, then the issue may be overcome using Roaming or Terminal Services Profiles, or redirected profile components. I will discuss these topics later in the Windows Environment section of this document. Perhaps the application handles it on its own with “*.ini” or small database files. Again, thorough analysis is required and, again, maybe it can be fixed with custom GPOs and/or scripts.
These types of issues and fixes would also absolutely occur in standard workstation builds with locally installed applications, where users may swap desks.
This is also where strong change control and standardisation is absolutely necessary for the success of the application publishing servers. All servers that are publishing the same applications must have those applications installed in exactly the same way and be at precisely the same version of Windows and application. A user may have a link to a file deep within their roaming profile (or otherwise centrally located settings) that points to a file on the server’s C: drive. If the servers are not the same and that file is not where expected, the application will fault and a Help Desk call is generated.
Ideally, the servers should be grouped by function and the entire build of all the servers in that function are identical, not just that specific application. One term for this is application silos. For example, Servers 1 through 4 publish Applications A through C, Servers 5 though 8 publish Application D and E, and Servers 9 and 10 publish “weird app.” F. All servers within those groups should be identical, to the extent that cloning them is a good idea (albeit with many Citrix-specific considerations to include when cloning such servers).
One Citrix farm with three application silos - three sets of identical servers
Multi-Location
A very simple and common example:
Application1 works fine for all users at Location1, but is horribly slow for users from all other locations from across a Wide Area Network (WAN).
Usually this issue would occur no matter whether the application is published from application publishing servers or locally installed at the workstations. If the application is only accessible from Citrix, then this is a perfect example how such a problem would be lumped in as a “Citrix problem” from the users’ perspective.
The obvious and usual issue is that the back-end data, whether files or an SQL database, is also at Location1. Users running the application from application publishing servers (or workstations) from other sites will experience delays. The easiest solution to this is to ensure that users from all locations use application publishing servers only at Location1. Otherwise, back-end data replication across sites will need to be analysed.
It’s more complicated if all users are using the application publishing servers at Location1 with no problems, but still the “remote” users only are experiencing slowness. This type of problem is usually related to those users’ Windows environment where perhaps their Home Drive is configured at a site other than Location1, or perhaps AD GPOs are redirecting portions of their Windows profiles to a server outside of Location1.
If the problem only occurs during logon or program launch, it is also likely a Windows environment issue pertaining to GPOs or login scripts referring to servers other than at Location1.
These types of issues will be discussed in detail later in the Windows Environment section of this document.
Performance
No example needed here, applications might appear to be slower when published from Citrix than when locally installed from workstations. If the workstations are on the same high-speed network segment as the back-end data and if the workstations are adequately powered, then the applications will in fact probably be faster from the workstations. Many factors can influence performance, so we will only scratch the surface in this section.
If the speed differences are almost negligible and it is simply down to users’ expectations, then there is often some tweaking that can be done to enhance speed in small increments. For example, reducing unnecessary colour depth, eliminating Windows “3‑D” graphical enhancements and unnecessary operating system (OS) services and processes, and removing certain unneeded application functions may be enough to bring the speed up enough for expectations. Small examples include removing any auto-update feature from application launch, Internet lookup features (for example, MS Office online Help), and disabling animation features (especially MS Office Assistant). These fixes are usually controlled through application vendor-provided GPO Administrative Templates (such as those that come with MS Office), with custom created ones, or with GPP.
Other performance issues were discussed in the previous section, Multi-Location.
Other issues could actually be down to the network. Network latency is the real thin-client killer, which will be discussed in detail in the Network section later in this document.
Co-existence with Existing Windows Profiles
This section pertains to environments with multiple Citrix farms, shared roaming profiles between application publishing servers and workstations, or redirected Windows profile portions used both when logging onto the servers or a workstation. This is especially relevant if the application in question is installed on the workstation as well as the Citrix farm, perhaps for remote access or Disaster Recovery (DR) use only.
Examples of problems that could arise with these configurations include those described in the Multi-Computer section and if it is an undisciplined IT environment, general application failures could occur.
It is possible to run published application servers with any of these configurations if due care is taken during installation and IT operations runs a tight ship. This will be discussed more in the Windows Environment section of this document.
Windows Environment
After application configuration, tweaking, and tuning, the next crucial area that most determines application publishing failure or success is the Windows environment. This includes Home Drive or Folder location; printing configuration; the location of “My Documents”; network drive mappings; and AD GPOs or Novell’s NDS ZENworks (referred to as only AD GPOs for the remainder of this document) components which include roaming or Terminal Services profile configuration and location, redirected Windows profile components, perhaps the use of a mandatory profile, and log on/off scripts.
In my experience, I find that after badly installed applications, badly configured Windows profiles are the most common source of “Citrix” malfunctions. It should also be noted that many of the Windows environment issues described here also apply to workstation Roaming Profiles or, more generically, workplaces where "hot desking" occurs.
Windows Profiles
Technologies that can be used to create or maintain Windows profiles include Roaming, Terminal Services, Mandatory, and local or central Default Profiles; redirected profile components and also hybrid profiles.
If more than one application publishing server is going to be used, then at least one of the technologies above must be used to allow smooth transition for a user to work first on one server and then another. It's a good idea even if only one server will be used, in order to allow for easier future server additions or replacements.
Local Default Profile............ Users logging onto a server for the first time will receive a mirror image of this default profile, located on the server's C: drive. In operating systems older than Windows Vista/7/2008, tweaking this profile was a good way to provide settings to users that they are later allowed to change.
Often, however, this profile is over-used as a mechanism to deliver custom settings to users and often profiles become corrupted or almost unusable. Furthermore, Microsoft is now frowning on the practice of over-writing the Default Profile - see this link.
(Windows Server 2008 now has the ability to use Group Policy Preferences (GPP, even if the AD infrastructure is still at the 2003 level), which allows distributed settings that users can then change temporarily or permanently.)
Central Default Profile.......... This works the same as a local Default Profile, except that it is located centrally at "\\AD_Domain_Name\NetLogon\Default User.v2". Windows knows to look there first if a new user has no existing local, roaming, or Terminal Services profile (and Windows Vista/7/2008 knows to look for the path with ".v2" at the end).
This has the advantage that only one Default Profile needs to be created and managed. The disadvantage is that there is only one Default Profile now available, which may not be applicable for machines of a different build or set of applications.
Mandatory Profile................. This is a centrally stored preconfigured profile that users must use and any changes made to it are not saved. It is only realistically possible to use such profiles for kiosk or guest computers. Business users need to be able to customise their applications to a degree, and these customisations are usually stored in their Windows profiles.
Roaming Profiles................... Roaming Profiles have been around since the Windows NT and even '95 days, and they have always received mixed reviews. Like application publishing, it is a technology that works really well when done right, and can go horribly wrong if not.
a. A user logs onto a workstation or Terminal Server for the first time. He has never logged onto the domain before. He gets his new local Windows profile built from either a local or centrally located Default Profile (Mandatory Profile not used).
b. Any tweaks made to the profile are stored in the local profile - in this example, setting the Desktop background to purple.
c. He logs off. His Windows profile gets copied up to a network location as defined either in his AD user account or in a GPO.
d. He logs on again to a different workstation or server. Unless there are other GPOs preventing the use of Roaming Profiles on that computer, his profile is copied down from the central location and loaded before presenting the Windows Desktop to the user. His Desktop background is magically purple.
When implemented correctly, this works really well. It works so well that, contrary to popular belief, the same profile can even be used between workstations and Terminal Servers, without the need for separate Terminal Services profiles (discussed below). This shared profile scenario will only work if the following conditions are true:
· Terminal Servers are being used for full "thin clients" - that is, the client is only a stripped-down DOS, Linux, or hardware device that has the sole purpose of connecting to a Terminal Server or Citrix farm and running applications or full Desktops. The local client must not also be using the same roaming profile. (Otherwise the central profile will always be updated when the client logs off, over-writing any changes made to the profile during the remote session.)
· The Terminal Servers and workstations are built in the same manner: the same base applications are installed in precisely the same way and using the same paths (thus, if a Citrix server is involved, it should also use C: drive as its system drive, or whatever drive configuration the workstations also use). It is all right if the workstations have more applications than the Terminal Servers, or vice versa, so long as those programs that are installed on both platforms are installed exactly the same.
· There are tight change control procedures in the IT department. On-the-fly changes will quickly corrupt this configuration.
· The workstation and Terminal Server operating systems are at the same basic level (NT4 Workstation and NT4 Server, Windows 2000, Windows XP and Server 2003, Windows 7 and Server 2008). These pairs of operating systems have the same folder structure (especially in user profiles), understand the same set of GPOs, and use the same technology.
The benefits to the scenario above are obvious: users experience exactly the same front-end experience no matter to which platform they log on. A user may not even realise that their old workstation was "upgraded" to be a Linux thin Citrix client over the weekend (except for the improved performance).
Problems with Roaming Profiles in general begin to occur when users travel from site to site making loading and unloading of profiles obviously very slow across a WAN, or if files are stored in the default locations of "My Documents" or the Desktop (both within the profile), making loading slow because of the excessive size of the profile. Redirection of profile components, discussed below, are required to ease both issues, and the implementation of what I call "semi-roaming profiles" can be set up with one profile per user per site using GPOs to define locations.
Other historical problems are usually caused by incorrect configurations or permissions on the profile folders.
Terminal Services Profiles..... Where it is not possible to share user profiles between workstations and Terminal Servers, which is usually the case, separate roaming profiles can be defined for users of Terminal Servers. They are used exactly the same way as Roaming Profiles except only when logging onto a Terminal Server. It is possible to use Terminal Services profiles only, or both Terminal Services and Roaming Profiles; but if Roaming Profiles are used without Terminal Services Profiles, then those Roaming Profiles will also be used on the Terminal Servers unless otherwise limited by GPO. When logging onto a Terminal Server, it will search for a profile in the following order:
a. Terminal Services Profile path specified in GPO
b. Terminal Services Profile path specified in the user object
c. Per-computer Roaming Profile path specified in GPO
d. Per-user Roaming Profile path specified in the user object
e. Local Profile
f. "\\AD_Domain_Name\NetLogon\Default User(.v2)"
g. "C:\Users\Default" (for Windows Vista/7/2008)
Component Redirection........ A form of redirection of Windows components has been around since 16-bit Windows "*.ini" files. We could always edit those "*.ini" files, and later the registry, to point components of Windows to somewhere other than C: drive. For example, program groups and icons in Windows 3.1 could be redirected to a shared read-only network location as could the Windows 95 Start Menu and Desktop.
The GUI for this finally came out in Windows 2000 GPOs, where we could redirect the Start Menu, Desktop, My Documents, and Application Data. Now for Windows 7/2008, we can redirect:
· AppData(Roaming) · Desktop · Start Menu · Documents · Pictures | · Music · Videos · Favourites · Contacts | · Downloads · Links · Searches · Saved Games |
Other folders, such as Cookies, can also be redirected using older methods such as custom administrative templates ("*.adm/x" files) or, better yet, in Windows Vista/7/2008 Group Policy Preferences (GPP) under Windows Settings, Registry.
Component redirection is almost a required technology to enable complete or semi-seamless roaming of users between workstations or application publishing servers, whether or not Roaming or Terminal Services profiles are also used.
· Rather than training users never to save files to "My Documents", redirect this to their network Home Drive. This not only keeps data off the un-backed-up workstation, but also reduces Roaming or Terminal Services Profile loading and unloading times (log on and off times).
· Rather than training users never to save files to the Windows Desktop, redirect this to a folder on their network Home Drive for the same reasons mentioned above.
· Redirecting Internet Explorer Favourites to a folder under their Home Drive makes these links available wherever they log on, Roaming Profile or not.
· Likewise, many (but not all) application preferences will also be readily available if the "Application Data" or "AppData" folder is similarly redirected.
Hybrid Profiles...................... These profiles use a combination of a Mandatory Profile and a third-party application to store certain saved settings. Products include TriCerat Simplify Profiles, Mancorp Managed Profiles, and Jumping Profiles, among others.
Self-Healing Profiles............. I first heard the term "self-healing" in one of Microsoft's earlier marketing blurbs, possibly under their "Intellimirror" umbrella. I use it to describe my own hybrid profile solution I often implement in demanding environments or for demanding applications.
Basically I use a combination of profile component redirection, a second hidden home drive for each user, and some complex login scripts. These scripts may match up with corresponding flag files in a hidden home folder, "\flags". A particular script will only run if its matching flag file does not exist. For example, a particular application may require a large set of files in the user's profile. Rather than placing them in a default profile, the script will place them there, preferably under a redirected portion of the profile or better yet, to a configurable location directly under the home or hidden home drive. If this part of the application gets broken, an IT technician can either remove the flag file or direct the user to do so if providing remote telephone support only. They log on again, the script re-runs, and that part, at least, is fixed.
A lot of this can go away now with the availability of Group Policy Preferences (GPP) for Windows Vista/7/2008.
So which technology should be used? I'll provide my own preferences for examples at each extreme possible and common scenario, both using Windows Server 2008 Terminal Services and possibly Citrix XenApp Server, and picking drive letters out of the air.
Items common to both scenarios:
· each user has an H: home drive
· each user also has an I: home drive, hidden but accessible (described below)
· profile component redirection for at least "My Documents", Desktop, and Favourites
· no customisations to the Default Profile, if possible
Scenario 1: brand new application publishing server cluster or farm, strong IT change control
· GPO loopback processing, Merge mode (described later)
· Terminal Services Profiles implemented and controlled by GPO
Scenario 2: other server farms to contend with, weak IT change control, multiple groups of IT administrators
· GPO loopback processing, Replace mode (described later)
· no Roaming or Terminal Service Profiles
· "self-healing" scripts in place to set up preferences or application requirements
· extensive use of GPP
Home Drive/Folder Location
Poor configuration here can manifest itself in several ways. The most common is described in the Multi-Location section above where remote users sharing the same application publishing servers experience performance issues while local users do not. This is likely because “local” users are those that have their Home Drive/Folder configured on a file server at the same site as the application publishing servers and “remote” users have theirs on a file server across the WAN from the farm.
A common tweak to make an application multi-user capable is to place its components or configuration files (or possibly even application cache files) on the user’s home drive. If this location is across the WAN from the application executable, performance will be slow.
Another problem can occur if users regularly access their Home Drive/Folder through Windows Explorer rather than just using “My Documents” (which might point directly to “h:\files” as shown to the right). Users must have at least Read, Write, and Delete rights to the configuration folder described in the last paragraph. If they see the folder and do not know its intention, they may simply delete it, thus negating the benefit of any multi-user tweaks and probably causing the application not to launch at all.
A good way around both of these problems is to create two user home drives: one visible that they use and can browse to and one hidden used for configuration details only. Ensure that at least the hidden home drive is on a file server local to the application publishing servers.
“My Documents” Location
Similar to Home Drive issues described above, it can be a problem if the user’s “My Documents” folder is redirected to a network location on another WAN site than the Citrix farm. Many applications, especially MS Office, default to opening or saving files to “My Documents”. This can make the application launch, opening and closing files go very slowly. Even if MS Office applications are told to store files at specific local locations via GPOs, this doesn’t actually work for all the applications or components of certain applications.
There is no perfect fix for this issue.
- One way is to set up a “My Documents” folder for each user at their home site where their home file server is and also on a file server at the Citrix site, which of course may leave the user confused as to where they should be storing documents and may generate a Help Desk call.
- Another option is to implement a form of file replication across the WAN and use a Distributed File System (DFS) Universal Naming Convention (UNC), a potentially expensive and complex project.
- Leave “My Documents” pointing to the default of the local Windows profile and train users to never use this location, but to use Home or shared drives and folders instead – not an ideal solution to enforce.
Drive Mappings
File server or "network" drive mapping issues are somewhat related to logon scripts, where a user’s “home” logon script may map drives on their “home” file server, which may in fact be remote from the published application servers. This may make application performance appear slow, when it is simply trying to handle files across a WAN.
It is important to have drive mappings, if necessary, on a file server close to the Citrix farm.
Printer Connections
Unlike network drive mappings, it is usually the case where the user should receive the same list of network printers on the application publishing server as they would on their own workstation. This is the preferred method of printing: the print job gets sent from the session on the Terminal Server (Citrix) to the print server nearest the user’s client workstation, processed on that print server and sent to the nearest network printer to the user.
Citrix does have a feature in its Independent Computing Architecture (ICA) protocol where it is possible to print directly from the user’s Citrix session, back through the ICA connection to the user’s client workstation, where it sends the print job to any configured printer, local or network. This has the advantage such that users can use non-networked locally-attached printers for Citrix printing, and is also useful for printing when connecting via remote access, but it is a slightly less reliable method of printing and it does use more bandwidth in the ICA session. Where network printers are available, it is best to use regular Windows printing from the application publishing server.
Centrally Controlled Settings
Centrally Controlled Settings are Windows registry values and other components controlled by a central database of configurations. The most common tools for this are Novell's eDirectory (formerly NDS, Novell Directory Services) ZENworks or Microsoft's Active Directory GPOs. This document will concentrate on GPOs.
One aspect critical to application publishing servers is the loopback processing mode, a machine setting. In order to maintain control and integrity of an application publishing server, users are typically "locked down" more on the server compared to the easier settings they receive at their workstations. Consider that most settings that control what an end-user can see or control in regards to the Windows or application interface are set in the User portion of the registry, and thus the user portion of the GPOs, how do we set more restrictive policies for the same user when they log onto an application publishing server as opposed to their normal workstation? Loopback Group Policy processing is enabled. This setting is defined in (in Windows Vista/7/2008):
Computer Configuration, Policies, Administrative Templates, System, Group Policy, User Group Policy loopback processing mode
In the example to the right, it would be set in Machine GPO C, linked to the Terminal Servers OU.
Policies get processed from the "top of the tree" and then "down", so in the normal scenario of a user at a workstation, the following occurs:
- The workstation boots up in the Computers OU and receives first Machine GPO A and then Machine GPO B.
- The user logs on in the Users OU and first receives the User GPO A and then the User GPO B.
When logging onto the application publishing server, the following occurs:
- The server boots up in the TS Servers OU and receives first Machine GPO A and then Machine GPO C.
- The user logs on in the Users OU and first receives the User GPO A and then the User GPO B.
and then one of the following two scenarios occurs:
If the loopback policy is enabled in Replace mode, this tells the Group Policy client extensions to disregard all settings so far and to start again at the top of the tree, taking user settings, but this time following GPOs down the tree in the path of the computer, as opposed to the normal behaviour of following the path of the user.
- In this case, the user would receive User GPO A and then User GPO C, and there would be no settings received from User GPO B.
Or if the loopback policy is enabled in Merge mode, this tells the Group Policy client extensions to keep all settings so far but to also start again at the top of the tree, taking user settings, but this time following GPOs down the tree in the path of the computer.
- In this case, the user would receive User GPO A, then User GPO B, then User GPO A again, and then finally User GPO C. If there is a conflict between any of the policies, the usual rule applies where the last one wins, in this case, GPO C.
Resource Placement
The most basic aspect of the network when designing the application publishing architecture is to keep the data close to the application publishing server, preferably via a 1 Gbps connection on the same network segment. The data in question includes any data used by the published applications themselves, such as an SQL database or Microsoft Exchange, shared files, files in Home drives, Roaming or Terminal Services Profiles, and any profile components or configuration settings redirected to hidden home drives.
Latency
The most important network aspect of application publishing server access from across a WAN or the Internet is network latency - not a lack of bandwidth, although a lack of bandwidth can also cause higher latency. Latency is the amount of time it takes for a packet to make a round trip between the server and the client. The easiest way to measure this is with the PING command and reading the “time=” column of the results. This is down to end-user acceptance, but in my experience Citrix performs well up to 250 ms, perhaps 300. End-user symptoms of poor latency include slow typing (where the user is waiting for the screen to “catch up” with keys pressed), slow image re-draws, and trailing mouse cursor movements.
Remote control protocols are typically efficient because traffic from the client workstation to the server consists of only mouse clicks and keyboard strokes and traffic the other way is only compressed image deltas of what the user sees on screen. No actual data is sent back and forth. The bandwidth requirements for either Microsoft’s Remote Desktop Protocol (RDP) or Citrix’ ICA protocols are published as requiring in the neighbourhood of 20 to 30 Kbps per session, whereas real world application requirements might more accurately require upwards of 300 Kbps per session. This allows for deep colour at 1920x1200 resolution with perhaps printing back through the ICA tunnel.
Dealing with poor latency can be a nightmare. The first thing to check is the bandwidth capacity. If there is not enough bandwidth available exclusively for these ICA or RDP sessions, high latency will occur. If the total bandwidth of a site is sufficient, perhaps Quality of Service (QoS) can be implemented to allocate a portion of the bandwidth exclusively for remote computing protocols. If both the server and client ends have ample bandwidth, then latency can be caused by crossing too many routers in between, usually meaning too many different communications carriers in between. The only fix is to deal with and perhaps change carriers, looking closely at latency SLAs. Some countries simply don't have the communication backbone to provide low latency. I have seen this with connections from Central America and specifically from the off-shore tax haven Labuan, a Malaysian island north of Borneo.
IT Operations
It won't be popular, but as an external consultant, I have to say that a common way I've seen a good application publishing environment destroyed is by the IT department themselves. Changes and "updates" are made on the fly with no change control or documentation, and only to the "problem server" and not to the whole farm; issues are fixed with work-around solutions rather than fixing the root cause; updates or bona-fide fixes are not technically tested nor tested for user acceptance; and other generally sloppy procedures can quickly wreck the product.
These practices will of course be detrimental to any IT infrastructure, but because application publishing is a little more demanding or fragile, it generally breaks first, thus giving "Citrix" its sometimes negative reputation.
Summary
The rest of the components shown in the diagram at the beginning of this document are fairly straight-forward to configure, and they are usually right or wrong with few "grey areas" in between. They were included simply to show all the areas that can break an application publishing solution. The most common problem areas are also those most complex to get right: application installation and configuration, and Windows profiles. Next in line is the Windows environment and network placement of resources, followed by IT departmental procedures. Many things must be absolutely correct to make the solution work, and it's usually not the Citrix product that breaks it.
