PS4.0 Farm hosted on Citrix Web Interface 5.4

Well just started working in a new company and for some reason, they still have PS4.0 running in Prod…

By default, Citrix Web Interface 5.4 will not allow for PS4 connectivity. However there are some tricks you can do to get this working

  • Go to the site’s root normally located under C:\inetpub\wwwroot\Citrix\NameOfSite\conf\
  • Open WebInterface.conf
  • Look for the RequireLaunchReference syntax
  • Set the setting to “Off” (RequireLaunchReference=Off)

Once that is done, you will be able to open PS4.0 apps directly from your WI 5.4 implementation for both CSG (CAGs/NetScalers) or direct WI connections.

If you are utilizing the new Receiver Client, you may run into an issue where apps do not open. I did run into it on one of my Windows Laptops (Mac worked as usual :P)

  • Uninstall all Citrix Online Plugins or Receiver
  • Delete folder c:\program files\citrix
  • Delete following registry key : HKLM/HKCU/Software/Citrix
  • Install Citrix client
Advertisement

More Citrix Web Interface 5.4 customizations

I recently accepted a job in a large enterprise company… I had to put the developers hat on and customize a new set of Web Interface 5.4 sites I set up.  I don’t know, but I can not leave the standard stuff up.  Where is the fun in that? 😛

Well after working on the site I found many places where it makes sense to modify a bit of code.  Below is what I changed.  The end result looks great.  I also made a ton of changes to the web webinterface.conf file.  Will post those as a new post as it will be a little lengthy… 🙂

Lets stat by editing the logout process of WI.  When a user log’s off, you have to click once again to relog in.  Why do that?  Instead you can redirect WI to go directly to the logon page (Makes sense right?)

Well here is the process

** Edit the Loggedout.aspx file in C:\inetpub\wwwroot\Citrix\sitename\auth

All the way at the end… make sure you have the following syntax

// A new Session will have been created for this page request as it has already been

// abandoned while logging out.

// Abandon this new session otherwise the session will remain active until timeout.

// Avoid session fixation by checking that it’s a new session which is abandoned

if (wiContext.getWebAbstraction().isNewSession()) {

wiContext.getWebAbstraction().abandonSession();

}

Response.Redirect(“login.aspx?CTX_FromLoggedoutPage=1”);

%>

** Now lets get some funky stuff going…

The file below is under your Citrix site root’s \app_data\include\fullstyle.inc

Fullstyle.inc Edits:

**Remove CTX tagline – only use if not changing tagline text. Otherwise, see “Change CTX Default Tagline Text” below.

#hor1izonTagline {

color: #F2F2F2;

font-size: 180%;

font-weight: normal;

margin: 50px 0 0 0;

padding-bottom: 10px;

text-align: center;

display: none;

}

** Remove all footer images and text (this includes the HDX and Citrix logos, and also any Footer text you may have specified in the Web Site Appearance Wizard)

#footer img

{

padding: 0 8px;

vertical-align: middle;

display: none;

}

.horizonPage #hdxLogo {

display: inline;

display: none;

}

.horizonPage #footer p {

color: #F2F2F2;

display: none;

}

**Change SysMessage text size and bold

#sysMessage

{

width: <%=wiContext.getString(“PageWidth”)%>;

margin: 0 auto;

padding-top: 8px;

font-size: 12px;

font-weight: bold;

}

<%

// The width is set shorter than the background width

%>

#sysMessage p

{

text-align: left;

padding: 10px 0;

font-size: 14px;

font-weight: bold;

}

**Change Tagline to smaller font

#horizonTagline {

color: #F2F2F2;

font-size: 120%;

font-weight: normal;

margin: 50px 0 0 0;

padding-bottom: 10px;

text-align: center;

}

Graphics Changes:

**Replace CTX XenApp top logo with YourLogo.png

  • replace \media\CitrixXenApp.png
  • replace \media\CitrixXenAppLoggedoff.png

**Remove computer screens graphic

  • rename \media\Devices.png to Devices_orig.png
  • rename \media\Devices.gif to Devices_orig.gif
  • rename \media\DevicesLoggedoff.gif to DevicesLoggedoff_orig.gif
  • rename \media\DevicesLoggedoff.png to DevicesLoggedoff_orig.png

Misc. Changes:

**Change CTX default tagline text

  • copy \program giles\citrix\web interface\5.4.0\languages\accessplatform_strings.properties to \inetpub\wwwroot\citrix\<site name>\languages.
  • Edit file:
    • #HorizonTagline=Your Windows desktops and apps on demand – from any PC, Mac, smartphone or tablet.
    • HorizonTagline=<Whatever you want here>

**Add logo to Login box (Thanks Jon Woods!)

\inetpub\wwwroot\Citrix\XenApp\app_data\include\loginMainForm.inc
<% // LoginType set to Explicit, but only if it is allowed
if (viewControl.getExplicitDisabled()) {
%>
value=””>
<% } else { %>
value=”<%=WIAuthType.EXPLICIT%>”>
<% } %>
<%
}
%>
<% // added table row and cell for logo %>
<table>
<tr><td rowspan=”6″ valign=”Top” align=”left”><img src=”../media/Your Logo Filename Here.png” alt=””></td></tr>
<% // end table row and cell for logo %>
<%
if (viewControl.getShowLoginTypeOptions()) {
%>

**Add the desktop Viewer (Drop-down toolbar) to Virtual Desktops (Be careful, this has been known to mess with Dual Displays):

In the sites webinterface.conf file, add line – “ShowDesktopViewer=On”

**Override the styles:

read the posting on this forum string from “efontan512″. Really good stuff.

**Add logo to top left:

\inetpub\wwwroot\Citrix\XenApp\app_data\include\header.inc
before:
<div id=”headerWrapper”>
<div id=”header”>
<table id=”headerLeft” cellspacing=”0″>
<tr>
<%
after:
<div id=”headerWrapper”>
<div id=”header”>
<table id=”headerLeft” cellspacing=”0″>
<tr>
<td>
<img id=”headerLogo” src=”../media/AtosLogoHeader.png” alt=”Seiten-Header” title=””&gt;
</td>;
<%

Web Interface 5.4 slow start up times (not a thing of the past)

When Cirix WI 5.0 first came out, and all the Citrix geeks where jumping of joy (I was) about the new “black” look and feel, well there was sort of an issue with slow load times for the fist users hitting the site after either a reboot of your WI boxes or an iisreset.

The “problem” remains the same with WI 5.4, however lets be clear that this is not really an issue with Citrix Web Interface, but rather with the way Applications Pools are started in IIS (This by way does not happen if you run WI on Apache or WI on the NetScaler nCore firmware)

The reason for this is in the background… as the different IIS worker processes (Application Pools) need time to get started. And the .NET framework does his magic thing.

To speeds up things a little bit, you can disable the check for digital signatures.

And here we go…

Open the file: “C:\Windows\Microsoft.NET\Framework (or Framework64)\v2.0.50727\Aspnet.config

Add the line: <generatePublisherEvidence enabled=”false”/> (Watch out for the “” if you copy/paste the line)

image

Reboot the server or give a iisreset. Now the first user doesn’’t have to wait.

But there is more. If you have a dedicated Web Interface server and the available resources aren’t that important. You can change the default 20 minutes of idle time per Application Pool to, for instance, 60 minutes.

image

XenDesktop\XenApp NetScaler set up guide (POC)

Let me start by saying that the Citrix folks were great at providing me the steps of this post.   Without them, I would of had to take a million screen shots.  Please note this set up should not be considered for production, and should help you set up at least a Proof of Concept.

Ok… so I have been working with XenApp since the WinFrame and MetaFrame days.  Back then we had to create ALTADDR and NAT entries on the firewall to allow connections from the Internet.  Later, we moved into CSG (Citrix Secure Gateway),  that allowed only 443 and a single IP address to be exposed to the Internet to access the internal Presentation Server farm.

Nowadays, the preferred method is Access Gateway on NetScaler (or at least traditional CAGs).  The trouble is, for a traditional XenDesktop\XenApp person , NetScalers can be overwhelming at times specially if you don’t have a good network background .  I’ve seen co-workers express total fear while inside the NetScaler console… literally shaking.  I normally have to tell them, “it is just a NetScaler, but please don’t bring things down (again)”

One time we made a mistake to use the same SNIP on 2 appliances and BOTH NetScalers assumed that they were primary, and they both attempted to handle traffic!  Boy did we learn something from that day. My point is… be very careful inside the console.

This post will cover only the basics for getting NetScaler up and running to support XenDesktop\XenApp. It in no way will help you do some other more advanced NetScaler stuff.

MIPS’s and SNIP’s and NSIP’s and VIP’s, WHAT?!?!?!

Before we get started, let’s get some terminology out of the way.  The main thing to know is the four different IP addresses that the NetScaler uses.

MIP – Mapped IP address.  You use MIP addresses to connect to the back-end servers and Reverse Network Address Translation (NAT). The MIP address is one of the NetScaler owned IP addresses. You must specify at least one MIP address when you configure the appliance for the first time.

SNIP – Subnet IP Address. This is an IP address that enables you to access a NetScaler appliance from an external host that exists on another subnet. When you add an SNIP address, the appliance adds an entry in the routing table.  The SNIP enables the NetScaler appliance to connect to the subnet, which is different than that of the MIP and NSIP addresses, similar to local.

NSIP – NetScaler IP Address.  The NSIP address is the IP address at which you access the NetScaler for management purposes. The NetScaler can have only one NSIP, which is also called the Management IP address network of the appliance.

VIP – Virtual Server IP Address.  A VIP is the IP address associated with a virtual server. It is the public IP address to which clients connect. A NetScaler managing a wide range of traffic may have many VIPs configured.

The below diagram shows how the MIP and SNIP are used.  In the diagram the NetScaler is on the same LAN as 10.1.1.0.  It uses the MIP of 10.1.1.8 to access these servers.  However, is uses the SNIP of 10.2.2.9 to access servers on the 10.2.2.0 network.

How Do I Install This Thing?

Obviously, the first step is to get NetScaler up and running.  For this post, I am using the NetScaler VPX.  That is the virtual appliance version of NetScaler.  This can be downloaded with your MyCitrix account.  There is a NetScaler VPX for XenServer, Hyper-V, and VMW ESX.  For this post, I am going to use XenServer (shocker).  If you are using a physical appliance, you can skip this step.

Go download the XVA file from MyCitrix.

Now, with the XVA file downloaded, it is time to import that virtual appliance into XenCenter.  From XenCenter choose, File -> Import.

Browse to your XVA file, then click Next.

Select the desired host, then click Next.

Select the desired storage, then click Import.

Select the desired network interface.  In some cases this will be more than one.  Also, you may want this in your DMZ.  Click Next.

Review the import information.  Also, check the box for Start VM(s) after import.  Click Finish.

I Got the Appliance Imported, Now What?

In order to access the appliance via the console remotely, it must have an IP first.  Once IP’d all management is done via a web browser.

Go to the console of the newly created NetScaler virtual appliance.  The console should be prompting for an Ipv4 address.  The IP address it is looking for is the NSIP (NetScaler IP Address).  This is the management IP of NetScaler.

Enter the desired IPsubnet mask, and default gateway of the NSIP.  Once completed choose Option 4to Save and Quit.

Once the NetScaler appliance has an IP, the rest of the NetScaler services will start.  This takes about a minute or so.  Once the console shows “Login:”, that should indicate that you can now access the device through a web browser.

Open Internet Explorer and type the NSIP into the address bar.  The default credentials for a NetScaler device is user nsroot for both username and password.

Note: The NetScaler web console requires a Java plug-in.  If prompted by IE, allow the plug-in to run.

Once into the console, launch the Setup Wizard located towards the bottom of the web console.

The Network Config step of the wizard is used for adding MIP’s and SNIP’s.  Click on the Subnet IPradio button and enter your SNIP.  Click Next to continue.  Select Skip this step on the Choose Application tab.  Click Next, then Finish to add the SNIP.

You can always review the IP information (NSIP, SNIP, VIP) by clicking on Network -> IPs in the console tree on the left.

Yes, You Do Have to License This Thing…

For the XenDesktop\XenApp dummies out there, such as myself, licensing does not work like we know it to work.  Essentially, you don’t point NetScaler to a License Server.  Instead you load the LIC file directly on the NetScaler.  When requesting the LIC from from your MyCitrix site, you need to know the hostname of the NetScaler.

Important: The hostname of the NetScaler is not what you saw in the previous step where we added the SNIP.  The hostname needed for licensing is actually the MAC address of the NetScaler.

To find the hostname (MAC Address), log onto the console of the NetScaler appliance.  If you haven’t changed the password the username and password is nsroot.  Once logged in, type shell.  This will exit the NetScaler CLI and enter the system CLI.  To get the hostname type the following command:

lmutil lmhostid -ether

The result of the command will be The FLEXnet host ID of this machine is.  The text in quotes will be the host name that is used for licensing.

Once the LIC file has been downloaded from your MyCitrix account, navigate to System -> Licenses.  Click on the Manage Licenses button at the bottom of the screen.  Click the Add button to browse for and add your LIC file.

Now that the license should be loaded (may need a reboot to show up), we need to enable the features that are required for our setup.  In the NetScaler web console, navigate to System -> Settings.  click onConfigure Basic Features.  For our needs, enable SSL OffloadingLoad Balancing, and Access Gateway.

Configuring Web Interface…Finally Something Interesting

Now we finally get to the part we care about.  Adding Web Interface and XML to the NetScaler.  After this step you will be able to hit the Web Interface page through the VIP that we create.

From the NetScaler Web GUI navigate to Load Balancing -> Servers.  Click the Add button at the bottom of the screen.  Type the name and IP address of one of your Web Interface servers then click Create.  Do this step for each Web Interface in your environment.  Hopefully you have at least two.  Once the Web Interface servers are entered, they should show as Enabled.  At anytime, a server can be manuallyDisabled for maintenance reasons.

Now, we need a create an HTTP service for the NetScaler to communicate to these servers with.  Navigate to Load Balancing -> Services.  Click the Add button at the bottom of the screen.  Give the service a name.  Usually the name is the name of the server and the port it is using.  For example if your server name is DDC1, the service name could be service_DDC1_80.  Next, select the server you created in the previous step in the Server drop-down field.  Choose HTTP for the Protocol and type 80 for thePort.  Finally, select the http monitor and click Add.  Click Create to add the service.  An HTTP service needs to be added for each Web Interface Server.

Note: The HTTP monitor uses port 80 to ensure that the server is up and running.  Ping could also be used, but using the correct monitor for the service ensures that the server is running properly.  If the monitor detects that it cannot communicate with the server, it will mark it as down.  Also, multiple monitors can be used.

With the servers and services created, we need to create a load balanced virtual server.  The virtual server will use a VIP that all clients will use to access the Web Interface through the NetScaler.  The VIP is a brand new address that can be tied to a DNS entry for users to type into their browser.

To create the virtual server navigate to Load Balancing -> Virtual Servers. Click the Add button at the bottom of the screen.  Give the Virtual Server a name. Enter the IP address that will be used as the VIP for the two Web Interface Servers.  Choose HTTP for Protocol and enter 80 for the Port.

On the Services tab check the boxes for the two Web Interface services created earlier.  On the Method and Persistence tab choose Least Connection for the Method and COOKIEINSERT for the Persistence.

At this point, it is a good time to save the configuration if you have not been doing so already.  Click theSave button at the top of the NetScaler Web GUI page.  With the Virtual Server and VIP created, you should not be able to hit the VIP from an IE browser.

Don’t Forget about XML

Another great use of NetScaler is to create a VIP for your XML servers.  Once a VIP is created, this can be used in the Web Interface configuration for XML.  The benefit to using NetScaler to manage this is that it has the ability to monitor the XML service to ensure that it is up.  It does this by more than looking for service up\down state.  It sends an XML request on a regular interval and retrieves the farm name.  This proves that not just the service is running, but is also functional.

In order to use these feature, a new monitor has to be created.  This new monitor uses XML to send a request to the XenApp farm.  It should be noted that this only works for XenApp and not XenDesktop.

To create the monitor navigate to Load Balancing -> Monitors.  Click the Add button at the bottom of the screen.  Give the new monitor a name and select CITRIX-XML-SERVICE as the Type.  Click on theSpecial Parameters tab.  Specify the name of a published application in your environment.  I have seen some people publish notepad to the XML servers with a published application name of “XML Test”.  ClickCreate to create the new XML monitor.

The next step is to create a VIP that can be used in the Web Interface configuration.

From the NetScaler Web GUI, create a Server entry for each XML server.  Do this the same as you did earlier for the Web Interface servers.  Then, create the Services entries for each XML server.  This time use TCP as the service and enter the port that is being used for XML.  Use the newly created XML monitor for the Monitor.  Finally create a VIP that combines all the XML Services just created.  Ensure that TCPis selected for the VIP protocol.  This VIP can now be used in the Web Interface configuration for XML services in the farm.

Access Gateway FTW (For the Win)

Now that we configured NetScaler to load balance between multiple Web Interface servers and even XML servers, it is time to setup external access into your XenDesktop\XenApp environment.  Honestly, this is what you are here for anyway.

Certificates…The Bane of Every IT Person’s Existence

When it comes to Access Gateway, the only way you can connect is via SSL (443) with a certificate.  This means that any Access Gateway implementation must start with installing a certificate, and if necessary, the certificate chain.

For the purpose of this blog, I am going to use an internal Microsoft CA (Certificate Authority) for the certificate.

The first step is to create a certificate key.  Navigate to SSL in the NetScaler GUI.  Click on Create RSA Key.  Use the following for inputting to the required fields:

Name: AG.key (or anything that makes sense to you)
Key Size (bits): 2048
Key Format: PEM
PEM Encoding Algorithm: DES3
PEM Passphrase: password (or any password that you like)

Next, we need to create a request that we are going to send over to the CA.  Navigate to SSL in the NetScaler GUI.  Click on Create CSR (Certificate Signing Request).  Use the following for inputting to the required fields:

Request File Name: AG.req (or anything that makes sense to you)
Key File Name: AG.key (browse for the key created in previous step)
Key Format: PEM
PEM Passphrase: password (same password used to create the key in the previous step)
Common Name: access.xendesktop.lab (this is the name that users will type into their browsers)
Organization Name: Citrix (use the name of your organization here)
State\Province Name: DC (use your own state)

Now, we need to download our request file to use for importing to the CA.  Navigate to SSL in the NetScaler GUI.  Click on Manage Certificates / Keys / CSRs (found under the Tools section).  Find the request file (AG.req) created in the previous step then click Download.  In the Download Files window click Browse then save the file somewhere convenient.

Now, let’s submit the request to the CA.  Open a web browser and type in http://<yourCAname>/certsrv.  Click on Request a certificate -> advanced certificate request -> submit a certificate request by using a base-64… Open the request file (AG.req) in notepad and copy all the contents.  Paste the contents into the Saved Request box.  Under Certificate Template select Web Server (If Web Server does not show try opening Internet Explorer as an “administrator”).  Click Submit to continue.

Now, time to download the certificate that the CA created for us.  Click the radio button for Base 64 encoded, then click Download certificate chain.

Now, the next part can be confusing.  The file we just downloaded is a P7B package.  Essentially, this is a file that contains all the certificates.  It will contain the actual certificate we requested plus the root CA certificate, and any intermediates (if present).  Double-click to open the new certnew.P7B file.  The certificates window will show all certificates inside the P7B file.  First, open the file that has the common name of the certificate request you created earlier (for me this is access.xendesktop.lab).  Click theDetails tab, then click Copy to File.

This will launch the Certificate Export Wizard.  During the wizard choose Base-64 encoded X.509 (.CER)when prompted.

Save the file somewhere convenient.  Make sure to name the file something that you will know what it is earlier.  For example, save it as AG.cer.  Remember, this is the actual certificate for the Access Gateway site.  The other certificates we are going to export are the root and any intermediates.

Now that we have the certificate exported, do the same for any other certificates that are part of the P7B package.  At a minimum, you will have a root certificate to export.  Again, naming these files is important.  The root can be named root.cer.  Any intermediates can be Int1.cer, Int2.cer, etc.

Ok, now let’s get these certificates uploaded to the NetScaler.  Navigate to SSL in the NetScaler GUI.  Click on Manage Certificates / Keys / CSRs (found under the Tools section).  This time choose Upload.Upload each certificate file fromt the previous step.  This includes the certificate, root, and all intermediates.

Simply copying the file does not mean that it is installed.  We must now install the certificates.  Navigate to SSL -> Certificates in the NetScaler GUI.  Click on Install at the bottom of the screen.  Use the following for inputting to the required fields:

Certificate-Key Pair Name: AG-Cert (or any name you want)
Certificate File Name: AG.cer (browse for the certificate from the previous step)
Private Key File Name: AG.key (browse to key file created much earlier)
Password: password (or whatever password you created for the key earlier)
Certificate Format: PEM

Ok, almost done, I promise.  Repeat the above step for each certificate that was part of the original P7B file.  This means load the root certificate and any intermediate certificates.  Finally, we need to link the server certificate (AG.cer) to the root certificate (root.cer).  To do this navigate to SSL -> Certificates.  Click on the server certificate that was installed earlier (AG-Cert).  Next, click on Link at the bottom of the screen.  Choose the root CA from the drop-down, then click OK. This same step has to happen if there are intermediate certificates as well.  However, link the intermediate to the root, and any sub-intermediates to the intermediate above it.

Finally Done With Certificates, Now Let’s Do Some Access Gateway Stuff

We need to create an Access Gateway virtual server and VIP.  To do this, navigate to Access Gateway ->Virtual Servers. Click Add at the bottom of the screen.  From the Create Access Gateway Virtual Serverscreen enter the Name of the new Access Gateway site.  This should match the common name of the certificate created earlier.  Assign an IP Address that will be used as the VIP for this connection.  Finally, add the certificate created earlier (AG-Cert).

Now that we have an Access Gateway virtual server and VIP created, let’s try to access it.  Open a web browser and go to the https://access.xendesktop.lab (obviously use the FQDN that you created).  Make sure to use HTTPS when accessing the site.  The Access Gateway will not listen on HTTP (port 80).  Keep in mind to hit the FQDN that you created, an entry in DNS (or host file) must be created pointing to the new VIP.  The page should show without any certificate warnings.  If there are warnings, check the certificate chaining.

As of now, the Access Gateway site is not going to do much.  We still need to configure the Access Gateway for Web Interface and LDAP authentication.

Let’s Add Some Authentication…LDAP

To add LDAP to the Access Gateway virtual server, we start my creating an LDAP server on NetScaler.  To do this, navigate to System -> Authentication. Click on the Servers tab then click Add at the bottom of the screen.  Use the following for inputting to the required fields:

Name: AD (or whatever name you want to give it)
Authentication Type: LDAP
IP Address: 192.168.12 (use the IP address of one of your domain controllers)
Base DN: DC=xendesktop,DC=lab (use the DN for your domain)
Administrator Bind DN: xendesktop\UserAdmin (does not need to be an admin.  Use domain\user for the format)
Administrator Password: password (the password to the above user)

Click the Retrieve Attributes link to test the connection.

Now, let’s go create the LDAP policy that NetScaler needs to bind to the Access Gateway virtual server.  To create the policy navigate  to System -> Authentication. Click on the Policies tab then click Add at the bottom of the screen.  Use the following for inputting to the required fields:

Name: policy_LDAP (or any name that you like)
Authentication Type: LDAP
Server: AD (this is the server created in the previous step)
Expression: Match Any Expression -> General -> True value (then click Add Expression)

Finally, let’s get this bound to the Access Gateway Virtual Server.  Navigate to Access Gateway ->Virtual Servers. Open your Access Gateway virtual server and open the Authentication tab.  Click Insert Policy and select the LDAP policy created above.

At this point you should be able to log into the Access Gateway site.

We Are At The Home Stretch.  Time For Web Interface.

In most cases, you are going to want to create a new Web Interface site for use with Access Gateway.  In fact, to get Access Gateway to be the authentication point, your only option is to create a new site as this cannot be changed after a site is created.

So, from your Web Interface server, open the Citrix Web Interface Management console.  Right click onXenApp Web Sites and select Create Site.  Make the site path something that specifies Access Gateway.  For example: /Citrix/AccessGateway.  There is no need to set this as the default page for IIS as NetScaler is going to do that for us.

The next step is important.  For Specify Point of Authentication choose At Access Gateway.  This will allow the LDAP stuff we setup earlier to handle the authentication.

For Authentication service URL type:https://access.xendesktop.lab/CitrixAuthService/AuthService.asmx.  Make sure to change access.xendesktop.lab to the FQDN of your Access Gateway site.  If you are thinking that there should just be a button or something that fills that path in for you, I agree.

Once complete, leave the check-box Configure this site now checked.  For configuring the XML, use the NetScaler Load Balanced VIP that we created much earlier.  This is better to use as NetScaler controls the load balancing and HA.

Once the new site is created, we need to set the access type to use Access Gateway.  Right click on the new site and select Secure Access.  Click the Default IP Address and select Edit.  Change the Access method to Gateway direct.

After changing the Access Method to Gateway Direct, click Next.  In the Specify Gateway Settingsscreen enter the Address (FQDN) as access.xendesktop.lab (do not put the HTTPS:// part in).  Ensure that Port is set to 443.  Click Next to continue.

From the Specify Secure Ticket Authority Settings (STA) screen click Add.  Type the path to the STA as http://xa.xendesktop.lab/scripts/ctxsta.dll (again, substitute your own XenApp server in there).  Also, just like before, I agree there should be a nice button or something to add that path.

Add other XenApp or XenDesktop servers as necessary.

At this point we have Web Interface fully configured for use with Access Gateway.  Now, back on the NetScaler GUI, we need to add the STA’s to the Access Gateway Virtual Server.  Navigate to Access Gateway -> Virtual Servers. Open your Access Gateway virtual server and open the Published Applications tab.  Under the Secure Ticket Authority section, click the Add link. Type http://192.168.1.14 (substitute your IP to the STA’s in the previous step) into the URL box.  Add other STA’s that were used in the previous step.  After adding the STA’s, click OK to leave the virtual server configuration.  Go back in and notice that the State should show UP for the STA’s.

Ok, we have reached the final steps.  About time, right?  We need to create a Session Policy and Profile to redirect Access Gateway to Web Interface.  To do this, navigate to Access Gateway -> Virtual Servers. Open your Access Gateway virtual server and open the Policies tab.  Click on Insert Policy, then choose New Policy in the yellow drop-down box.  Use the following for inputting to the required fields:

Name: SessionPol_AG (or any name that you like)
Expression: Match Any Expression -> General -> True value (then click Add Expression)
Request Profile: Click New and look at next step.

For the Request Profile, click New in the Create Access Gateway Session Policy window.  Click on thePublished Applications tab.  Use the following for inputting to the required fields:

ICA Proxy: ON
Web Interface Address: http://192.168.1.239/Citrix/AccessGateway/auth/login.aspx (Use the Load Balanced VIP we created earlier for the WI address.  Also, use the path we created earlier on the Web Interface server).
Single Sign-on Domain: xendesktop.lab (FQDN or your AD domain)

Ok, this is the last step. I promise, this is it.  Click the Security tab and set the Default Authorization Action to ALLOW.

So now, if you open a web browser and go to the HTTPS of your Access Gateway site, you should be able to log in and launch an application.  If your NetScaler is in a DMZ or behind a firewall, create a NAT entry that points to the Access Gateway VIP.  Enable HTTPS (443) to that VIP from the Internet.  Now, you should be able to connect from the outside world.  Well, if you have the root certificate loaded on your client machine that we placed on NetScaler earlier.

Oh, by the way, don’t forget to save your configuration on the NetScaler. Everything we have done is running in Running Config.  If the NetScaler reboots, you lost everything.  And that would just suck.

Well, that is it.  I hope this helps others.

Customize and Brand Citrix CloudGateway Express / Citrix Receiver for the Web

I found this great video on how to customize and brand the CloudGateway Express (AKA Web Interface)

Pretty straight forward if you follow it step by step.