Working with Cisco AnyConnect 2.5 Client Profiles

The Cisco AnyConnect 2.5 client in conjunction with ASA ASDM version 6.3 bring several new features to Cisco’s SSL VPN implementation. Some of the more interesting features are:

• Post Log-In Always-on VPN – VPN session is auto-established after user logs into PC.
• Connect Failure Policy – Determines if user is allowed to access internet if Always-On VPN is enabled and AnyConnect cannot establish VPN session.
• Captive Portal Hotspot Detection/Remediation – Detects “pay for internet access” types of portals seen in hotels or airports and allows users timed access to establish connectivity.
• Quarantine – Restricts client PCs that are out of compliance and allows remediation options (AV updates, etc).
• AnyConnect Profile Editor – Provides GUI-based profile editing via ASDM instead of XML-only editing.

Here is my setup:

• 2 x ASA 5510’s in active/active cluster
• ASA version: 8.2(1)
• ADSM version: 6.3(1)
• Security Plus license
• AnyConnect Essentials license (total VPN peers: 250)

Building the client profiles is easy enough, in ASDM you just select the Remote Access VPN tab and drill down to AnyConnect Client Profile under Network (client) Access. Select Add, give the profile a name, and configure your policy.

Once the XML file is created on the ASA you can set your policy options:

The Always on piece is set on the Preferences(Cont) page. Here you can get really restrictive by having the AnyConnect client detect the PC’s network state and apply actions based on it. If the client detects a trusted network (defined in the profile), VPN will disconnect, if the network is untrusted it will connect (Trusted Network Detection/TND). You can allow or disallow disconnection of the VPN session by the user and set a connect failure policy. When the connect failure policy is set to closed the user will be unable to even browse the internet from their home network unless VPN is established. Setting to Open reverses this behavior. If you build split tunnels into your group policy then only traffic destined to the specified corporate resources will flow over the VPN tunnel. Anything internet related can go out whatever internet connection they are connected to. You can, of course, force all traffic over the VPN tunnel.

The part where this breaks is when you attempt to assign the profile to a group policy via ASDM[unless, as someone pointed out in the comments, you are running ASA 8.3(1)]. This screenshot actually shows the correct sequence of commands being executed although I have seen it try to apply the profile from the global webvpn sub menu. In any case this has not worked for me through ASDM after multiple attempts with different profiles and group policies [because I am on ASA version 8.2(1)].

Assigning your ASDM-configured client profile via the ASA CLI works fine. ADSM is essentially trying to do the same thing but it just doesn’t work [for me].

1) Register the client profile XML as a global profile package:

ASA1(config)# webvpn
ASA1(config-webvpn)# svc profiles TestProfile disk0:/TestProfile.xml
ASA1(config-webvpn)# exit

2) Confirm the package is available to the group policy “VPN_GroupPolicy”:

ASA1(config)# group-policy VPN_GroupPolicy attributes
ASA1(config-group-policy)# webvpn
ASA1(config-group-webvpn)# svc profiles value ?
config-group-webvpn mode commands/options:
Available configured profile packages:
TestProfile

3) Assign the profile package to the group policy:

ASA1(config-group-webvpn)# svc profiles value TestProfile

Once the user logs into the appropriate group on their AnyConnect client they will pull down the profile XML which gets stored in c:\ProgramData\Cisco\Cisco AnyConnect VPN Client\Profile. Per the enabled settings above this is what the client state looks like in a trusted and untrusted network:

As you can see the result of the closed Connect Failure Policy on the right, the user will have to establish VPN before being allowed to even get out to the internet on a home or public network.

Microsoft has a similar solution with their DirectAccess implementation. DirectAccess abilities are built into Windows 7 Enterprise and Ultimate so require no additional clients. I started to go down that road first but got scared away by the list of requirements and infrastructure changes I would have to make on the backend to implement. AnyConnect is an excellent alternative that comes with the peace of mind of Cisco security plus there is no additional infrastructure to set up. SSL VPN is not free, however, and comes in two flavors: premium and essentials. The essentials license for my 5510 cluster, which supports a max of 250 VPN peers, was under $100. Premium lics are several times more expensive.

*It should be noted that if you intend to upgrade your ASA to 8.3(1) then you may need to also increase the amount of DRAM in your appliance. Cisco upped the default amount in all devices purchased after Feb 2010. Link.

*A quick note about TND, it can indeed be spoofed. The 2 criteria that the AC client is looking for is the trusted domain name and DNS server address list. If you configure these 2 items to match what is expected in the AC client profile, the AC client will think the network is trusted. If you change or add DNS servers to your corporate DHCP server scopes, this will break TND. The AC client profile must match what is given to the client via DHCP (or statically) for this to work.

Here is my client profile XML, for reference:

<?xml version="1.0" encoding="UTF-8"?>
<AnyConnectProfile xmlns="http://schemas.xmlsoap.org/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/encoding/ AnyConnectProfile.xsd">
<ClientInitialization>
<UseStartBeforeLogon UserControllable="false">false</UseStartBeforeLogon>
<AutomaticCertSelection UserControllable="true">false</AutomaticCertSelection>
<ShowPreConnectMessage>false</ShowPreConnectMessage>
<CertificateStore>All</CertificateStore>
<CertificateStoreOverride>false</CertificateStoreOverride>
<ProxySettings>Native</ProxySettings>
<AutoConnectOnStart UserControllable="true">true</AutoConnectOnStart>
<MinimizeOnConnect UserControllable="true">true</MinimizeOnConnect>
<LocalLanAccess UserControllable="true">true</LocalLanAccess>
<AutoReconnect UserControllable="false">true
<AutoReconnectBehavior UserControllable="false">ReconnectAfterResume</AutoReconnectBehavior>
</AutoReconnect>
<AutoUpdate UserControllable="false">true</AutoUpdate>
<RSASecurIDIntegration UserControllable="false">Automatic</RSASecurIDIntegration>
<WindowsLogonEnforcement>SingleLocalLogon</WindowsLogonEnforcement>
<WindowsVPNEstablishment>AllowRemoteUsers</WindowsVPNEstablishment>
<AutomaticVPNPolicy>true
<TrustedDNSDomains>domain.com</TrustedDNSDomains>
<TrustedDNSServers>10.10.10.10,20.20.20.20</TrustedDNSServers>
<TrustedNetworkPolicy>Disconnect</TrustedNetworkPolicy>
<UntrustedNetworkPolicy>Connect</UntrustedNetworkPolicy>
<AlwaysOn>true
<ConnectFailurePolicy>Closed
<AllowCaptivePortalRemediation>true
<CaptivePortalRemediationTimeout>20</CaptivePortalRemediationTimeout>
</AllowCaptivePortalRemediation>
<ApplyLastVPNLocalResourceRules>false</ApplyLastVPNLocalResourceRules>
</ConnectFailurePolicy>
<AllowVPNDisconnect>true</AllowVPNDisconnect>
</AlwaysOn>
</AutomaticVPNPolicy>
<PPPExclusion UserControllable="false">Disable
<PPPExclusionServerIP UserControllable="false"></PPPExclusionServerIP>
</PPPExclusion>
<EnableScripting UserControllable="false">false</EnableScripting>
<EnableAutomaticServerSelection UserControllable="false">false
<AutoServerSelectionImprovement>20</AutoServerSelectionImprovement>
<AutoServerSelectionSuspendTime>4</AutoServerSelectionSuspendTime>
</EnableAutomaticServerSelection>
<RetainVpnOnLogoff>true
<UserEnforcement>AnyUser</UserEnforcement>
</RetainVpnOnLogoff>
</ClientInitialization>
<ServerList>
<HostEntry>
<HostName>ac.domain.com</HostName>
<HostAddress>ac.domain.com</HostAddress>
</HostEntry>
</ServerList>
</AnyConnectProfile>

How to control DNS resolution for an external domain

I recently had a situation come up where I needed to change the traffic flow on my LAN for Outlook Anywhere clients that were going out to the internet to connect to our email provider (outlookanywhere.domain.com). Our provider is also accessible internally via a disparate and complicated network so the internet method was preferred due to less complexity. The Outlook Anywhere public facing servers were having problems, denying my client connections, so I needed to force the connections internally.

Caveats:

• I still want my clients to be able to access Outlook Anywhere outside the office so I can’t disable it or change the address it connects to
• HOSTS files are unmanageable
• I do not own the namespace of the servers that Outlook Anywhere connects to
• I will have to statically route to each destination in the provider’s namespace (from my core network) as our networks are connected but not well routed

To pull this off there are a few available options:

• Leverage conditional forwarders to the affected namespace
• Create a new primary DNS zone for this namespace, add the host record I need to redirect
• Create a new primary DNS zone for each FQDN that I want to redirect

The first option is the simplest, I could just route all of the requests to this domain directly to its internal DNS servers. The problem with this is that I’ll have to also statically route to every possible server/host in that network that users might access. There are too many.

The second option would also work but then I’d need to create A records for any other hosts in that namespace or clients would be unable to resolve them.  The routing problem exists here too so this is a bad option for me.

The third option is the money ticket. Using this method I can simply create a new forward lookup zone for outlookanywhere.domain.com and in that zone create a nameless A record with the internal IP of that server. Easy. I still have to statically route to this server but all other public facing resolutions will continue to work without issue. This solution will work for any external namespace if you need to redirect your internal clients somewhere else.

Review: Symantec Endpoint Protection 11

According to most industry comparative sources, two of the top 10 enterprise antivirus products are EndPoint Protection by Symantec (SEP) and NOD32 by Eset. These products often occupy the top two positions, again depending on your source. Av-comparatives.org gave its product of the year award to Symantec for 2009 and NOD32 has earned back-to-back VB100 awards since 2002. Personally, I have been well protected using SEP, formerly SAVCE (Symantec Antivirus Corporate Edition), for over a decade but am always open to better solutions if they exist. NOD32 is well-known on the internet by PC-enthusiasts as a purportedly bullet-proof AV scanner, so the enterprise solution must be as equally impressive right? I decided to find out. Having recently gone through a new enterprise antivirus rollout, I thoroughly vetted Nod32 v4 and SEP 11. I’ll share my review of NOD32 for the enterprise in another posting.

First up the incumbent, SEP, which has seen many changes since the days I first started using SAVCE, back when client management was NetBIOS dependent. AD-integration is now seamless, Server 2008 R2/ Windows 7 are fully supported, and the legacy requirements of WINS are long gone. Installation of the the management server piece is still as easy as it was years ago, all controlled from a single media source where the client bits also live. Setup allows you to launch the server or client installs from the installation media. Simple.

The SEP manager component is web-based now with a Java front end so you will need to install the JRE on your server. The manager runs happily in IIS which will be configured for you during setup, assuming you have the role and requisite services installed.

 

By default the server is setup to use tcp/8443 for the server port and tcp/9090 for the web console port. 8443 is what is used when logging into the manager console itself while 9090 hosts links and the download for the Manager console.

Once logged in, you are immediately presented with a well laid out dashboard that includes risk detections, client definition status, as well as the current Symantec ThreatCon level and links to pertinent info.

Let’s start at the bottom with the Admin tab and work up. Here you choose which components to work with, assigning admin rights, domain and server management, and manipulation of installation packages. In the domains section, by default, there is only a single domain defined called Default. Any deployment packages you created during the server install will assign clients here. You can manage multiple domains if you have a disparate environment but if not I recommend you disable the Default domain and add your own right away. To switch between domains you need to select the domain at the top and click the Administer Domain button down below. Now only the clients and policies assigned to the active domain will be displayed under those tabs. If you need to move clients between management domains at some point you can either uninstall/reinstall the client that points to the correct domain, or run the sylink drop tool which can move an existing client from one domain to another. If you use AD-integration your clients will show up only in their real OUs on the Clients tab.

 

Also within the Admin tab you can set the console administrators, control SEP server options like mail and directory servers, and create client install packages. Install packages consist of 3 main parts:

• the base client package itself (x86/ x64)
• Install settings: silent or interactive installation, upgrade settings
• Install feature set: which components of the client to actually install

Once the install settings and feature sets are defined, custom clients can be pushed from the console or migration wizard, or exported from the install packages screen.

On the clients tab you will see any non-AD SEP folders you created as well as the currently active domain under My Company. The functionality here is logical but not as useful as it could be. There is no consolidated client view here, you have to drill down into each OU to see your clients or run a “search clients” operation to pull the entire list broken out into several pages. Green bubbles mean that a client is online and communicating with the server. Important to note is that if a client is a member of the actively managed domain, it cannot live outside this structure in a non-AD SEP group.

The policies client tab show everything active for a given container. Here you can see that all policies are inherited and which are currently applied to this OU.

Important to note here is the “Communications Settings” button whose contents are inherited from the parent My Company. At the parent level you can change the method in which clients communicate with the server. By default Push mode is used which keeps an open channel between clients and the management server so that policy changes can be quickly propagated. Running a netstat –an on the management server will reveal every open TCP session to all connected clients.

The policies tab provides access to control policies for all installed components in your client. Multiple policies can be created and assigned at different levels either to local SEP groups or OUs in your AD. LiveUpdate is set to run on the management server every 4 hours by default but make sure to assign a LU policy to your clients.

All fields in each component of the client can be clearly and easily set in a policy along with line item lockout so the item can’t be changed by the end-user. This is extremely straight forward, as it should be.

Centralized exceptions can be set either through administrative policy or as user-defined. We obviously don’t want users excluding potentially unsafe items so you can lock them out from this. In previous builds of SEP you could open the AV client on a user’s PC and see the admin-defined exceptions but this has since been removed, by customer request according to Symantec. You have to look at the policy serials numbers, as reported by your clients, and trust that these exceptions are making it in as all that is visible from the client is the user defined exceptions.

Reporting is robust, beautiful and can be created ad-hoc or on scheduled a basis. Detailed break-outs of risks, compliance, and status (among others) are all available.

 

 

Environment monitoring is further detailed in the Monitors tab which provides summary pie charts, access to logs, the status of any commands issued in the console,  and notification options. Every condition you would expect to want to be notified about is available and configurable here.

Add-on security components like firewalls and heuristic scanning usually result in problems so I don’t install anything but anti-virus and malware protection in my environments. There are posts all over the internet of people looking for help on how to remove these products and clean up from their aftermath.

All things considered I give SEP 11 a solid 9 for the enterprise. It works exactly how I expect my corporate AV solution to. Despite a few configuration items being somewhat hard to find and buried in the GUI, the functionality is fantastic and features a true “set it and forget it” type of system. The architecture features classic web and data tiers for management and a full featured client capable of much more than I will use it for. Client management, reporting and alerting are robust which are absolute requirements. It would be nice if there was a consolidated client view that displays all clients and their status regardless of which OU they live in. Currently you have to either drill into each OU or run a search. Either way is functional but undesirable. It would also be nice to be able to optionally view administratively-defined centralized exceptions on the clients themselves.

Design and Review: Citrix XenApp 5 on Server 2008

Citrix currently has 4 flavors of XenApp (XA) being actively sold on the open market: XenApp Fundamentals for server 2008, XenApp 5 for Server 2003, XenApp 5 for Server 2008, and XenApp 6 for Server 2008 R2. For the most part these all look and feel the same from an end user experience perspective. The value for XenApp in my environment is twofold: managing legacy “problem” applications centrally and providing a secure remote access alternative to traditional VPN for my users. While it’s tempting to jump straight to XA6, my first objective prevents this as many of my problem business applications won’t run on Server 2008 R2 (Windows 7) nor on a 64-bit OS. 

Another tool in the Citrix arsenal is application streaming which is the new, and only, version of application isolation. Streaming is available on Advanced, Enterprise, and Platinum versions of XA and there is a special installation method to enable this on Advanced. Streaming is similar to VMware’s ThinApp product where apps are built (profiled) separately on a workstation but published through Citrix. Another advantage is that you can stream directly to the client which will use the client’s hardware resources to run the app taking the load off of the server. Some published limitations exist for streamed apps, however, that include anything requiring special drivers or certain .NET apps.

Planning and design

Unlike XA Fundamentals, the full version of the product contains several roles which can all be distributed depending on your environment. The basic server functions in a XA farm are infrastructure servers and application publishing servers. Infrastructure servers handle the functions not related to directly presenting applications to end users. These roles include licensing, data store, zone data collector, web interface, and XML service broker. These roles are well documented and all relate to farm communication and user application presentation. Best practice is to have at least one infrastructure server that will not publish apps to your users and then at least one publishing server. This design model scales easily depending on the size of your organization and performance requirements.

 

My deployment will consist of 5 servers, all server 2008 R1 x86, all VMs, running on a highly-available ESX4 cluster. 1 x infrastructure server, 3 x publishing servers, and 1 Citrix Secure Gateway (CSG) server. My infrastructure server will host all core roles including the Web Interface (WI) to publish the PNAgent config.xml. Given the size of my organization I have no need to house the data store in a full blown SQL server so I will use the local SQL Express option. Even smaller organizations can use an Access database as well.

My 3 publishing servers will be configured in dual-mode to host both published and streamed apps. 2 of the servers will host identical applications so connections can be load-balanced while the third will be used to host a business application that can only be used with Office 2003. I plan to stream these 2 apps together but I also want to be able to publish these apps externally via a web interface.

My CSG server will be configured to run the gateway and WI for external users to connect to. It will  be configured in a single-hop DMZ design. Dual-hop would separate the CSG from the WI on different servers in different DMZs but I don’t have a need to do that now. The firewall will need to be configured to allow the CSG server to talk to each of the publishers via TCP/1494 (ICA), TCP/2598 (session reliability), and TCP/80 for the XML service (optionally configured to use HTTPS). The CSG will also need to be able to talk to the infrastructure server on TCP/80 for XML/ STA (Secure Ticket Authority) services. There is no need to open anything further to the infrastructure server.

Here is the logical architecture for my deployment:

  

Infrastructure Server Installation

There are plenty of walk-throughs that take you step-by-step through the install process, check out http://www.dabcc.com for some good ones. I want to discuss some of the less documented gotchas that I ran across during my build-out. One of my big complaints with XA5 is the handling of pre-requisites. While this is much improved in XA6, XA5 is pretty painful in this regard depending on which components you install. There are 3 main roles that will be needed on the infrastructure server: terminal services, application server, and web server. My TS licensing is hosted on another server so I only need to install the actual TS component. Please note that EVERY XA server that you turn up, including the infrastructure server, requires terminal services to be installed. Even though your infrastructure server will not be publishing apps, it will be fully capable of doing so. XA cannot be installed without the TS role installed first!

Each component of the XA setup wizard will prompt you for the role services that it needs for the install to complete, but you will have to restart the wizard each time if you are missing anything.  To save you the trouble ensure that the following IIS role services are installed before you launch setup (make sure to also enable Windows Authentication under security, not shown):

Optionally add the COM+ Network Access role service to the Application Server role if you want to be able to remotely manage your server from the Access Management Console (AMC):

You will also need the latest x86 JRE installed for the licensing server component. Important to note is that you will need the x86 JRE even on an x64 server!

If you plan to use SQL Express for the data store, go ahead and get this ready now as well because the setup wizard will not do it for you. Run SetupSqlExpressForCPS.cmd in DVDRoot\Support\SqlExpress_2005_SP2. It will instal SQL Express 2005 SP2 and create a database called CITRIX_METAFRAME that the XA setup will look for if you choose the SQL Express installation option. Citrix strongly recommends that you do not install SQL Server on your XA server, only Access or SQL Express.

With those pieces installed you should be good to kick off the XA installer. XA5 doesn’t really break out individual roles like “XML broker” or “zone data collector”, much of it is implied. Such as the first server in a farm automatically becomes the XML broker, STA, and zone data collector. All servers will run the XML Service but only the XML broker will be running IIS which can share the same port. Any of the servers are capable of becoming the Zone Data Collector, controlled via election preferences, which is controlled in the Advanced Configuration tool. If you are installing Advanced Edition and plan to use Application Streaming, you must run the Platinum Edition installer! The server edition will be changed later in the AMC.

Select the Application Virtualization option next which will launch the installer for all common components. On your infrastructure server enable all options, for you publishers all you need is the Access Management Console and XenApp:

 

Here is why you run the Platinum installer with the intention of ultimately running Advanced Edition, the Advanced installer does not have this option available:

Each component will install separately and can be upgraded individually. This will provide you with the base install. There are 2 additional categories of installables after the base install: hotfixes and feature packs (FP). Hotfixes are provided per OS platform and are installed sequentially, each requiring a reboot. The feature pack, currently FP3 for XA5, includes upgrades to individual server components installed individually, such as the AMC, License server, plugins, Secure Gateway, and WI. Install your required hotfixes then upgrade the individual components included in the FP. You may not need everything in the pack. For Server 2008 R1 x86 I have the following hotfixes installed on each server in my farm. There will eventually be a hotfix rollup that bundles these but not as of this writing. I installed these in order:

XAE500W2K8005.msp
XAE500W2K8017.msp
XAE500W2K8018.msp
XAE500W2K8030.msp
XAE500W2K8042.msp
XAE500W2K8049.msp

Don’t forget to also upgrade the online and offline plugins on all XA servers! 

[Advanced only] Once installation is complete and all desired components are updated, launch the AMC, run the discovery process, navigate to your server and set the server edition to Advanced. This will allow proper licensing to work and make your publishers streaming capable:

Repeat this process on all XA servers and you’ll be ready to start installing and publishing apps. The first time you run the AMC it will run discovery on the environment, uncheck the Password Manager piece or you will get errors, unless you installed single-sign on with Platinum. The very next thing you should do is create the XenApp Services Site that clients using the online plugin will connect to. Under the Citrix Web Interface Console, right-click the XA Services Site and click create site. Once the PNAgent site is set up, right click it in the WI Console for a number of configuration options. I chose to enable pass-through authentication and made it the default, as well as enabled dual-mode for resource types, for starters. Publishing apps is fairly self-explanatory. Install the on/offline plugins on your client’s PCs and when they are granted access to applications they will see them either in the plugin, the start menu, desktop, or all three.

Citrix Secure Gateway

Both the Citrix Access Gateway (CAG) and Secure Gateway solutions accomplish the same thing, the difference being that the CAG is an appliance (not free) and the CSG (free) runs on a Windows server. The installation process is similar although you can skip right to the latest versions of both the WI and CSG. You will need a valid SSL cert on this server as it will be public facing and accepting only secure connections. When you generate your Cert request (CSR) make sure to choose at least 2048-bits as most CAs are requiring this as a minimum now. This will generate a 256-bit certificate for your site.

My goal was to provide an HTTP redirect to the gateway, so clients can connect to http, as well as host the WI on a TCP port not opened to the world. By default the WI will install into the default IIS site bound to TCP/80. I created a new site, bound to tcp/8080, where the WI would live. I left a single page in the default site that performs a simple redirect to tcp/443. The CSG is the only service that should be listening on this port. Run the WI installer first and create your XenApp Web Site in the new IIS site with port 8080. Once your new certificate is installed on your server you can run the CSG Configuration Wizard. It should find your new cert. Most of the defaults in the configuration wizard can be accepted. You will need to specify your STA server (infrastructure), as well as specify where the WI lives. If you follow my example you will need to tell the CSG that the WI is installed on the same server on TCP/8080.

Make sure to set up your WI site properly with your farm info and the appropriate secure access method. Direct is the simplest unless you’re using NAT between your DMZ and inside networks in which case you’d use gateway alternate or gateway translated. Customize your WI appearance how you like and assuming all firewall changes are in place you should now be able to access the WI externally.

At a high-level that’s it for my architecture. Citrix is a deep well and there are obviously a ton of other options and features that one could deploy. Another consideration worth pondering is user profiles. Citrix recommends using roaming TS profiles centrally stored on NAS or SAN to ensure a consistent user experience. This is easily enforced via GPO which I have employed and it works well. In combination with folder redirection this provides a very solid solution for managing your Citrix resources.

While it is ok to mix x86 and x64 servers in your XA farm, consider the implications this will have on program installations and user profiles. Published apps are defined via paths to their executables so if these paths are not the same on all of your servers you will have to make special concessions (c:\program files vs c:\program files (x86)). There are also additional differences in appdata folders used by some applications for x64 or x86 platforms. Many have had luck using the Flex Kit for managing profiles in these environments.

Although not cheap, XenApp 5 provides a very slick application delivery solution. XA5 Advanced costs in the neighborhood of $250/CCU and you also need to buy TS CALs as well. Enterprise and Platinum Editions increase costs significantly. The basic RemoteApp functionality baked into Server 2008 works well but at the sacrifice of granular presentation management, detailed performance tuning, and easy scalability. Citrix doesn’t care how many servers you put in your farm or what roles you run where, it’s all about the CCU licenses. Citrix and Microsoft have a very cohesive relationship going way back so XenApp will integrate seamlessly into your environment. One thing to watch out for is XenApp component changes to your servers after installation. I’ve noticed some finicky behavior specifically with regard to the license server component and having to reinstall it to get it working correctly again. 

Resources:

Application Streaming with XenApp Advanced

XenApp 5 Installation Guide

Citrix Secure Gateway Admin Guide

Web Interface 5.0.1 Admin Guide