Advertisements

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

Advertisements

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.

How To Brand Citrix Receiver for Web

Since Citrix is officially discontinuing the Citrix Web Interface we have all loved for many years.

It seems the focus now will be on the NetScaler Web Portals and of course the new CloudGateway.  I was able to find a good article that explains how to customize the new interface.  Thanks for the Citrix fellas for putting this out.

There have been numerous requests asking how to brand Citrix Receiver for Web.  You have only to look at the Citrix Service Providers group on LinkedIn to know that this is a topic that has generated lots of interest.

Jeroen Tielen has already done a lot of the heavy lifting when it comes to branding Citrix Receiver for the Web — see his blog post on how to customize the branding: http://www.jeroentielen.nl/customizing-the-cloud-gateway-logon-screen/

I’m providing a step-by-step guide on how to do this, and also how to extend it.  CSPs have also said they want to provide a list of URL links, for example links to helpdesk/support sites, feedback mechanisms, etc…

In other words, let’s start with this:

The “Before” web site

And end up with something like this:

The “After” web site

Branding the Web Interface:

Let’s start by creating a new Storefront site for a white label reseller.  This also isolates all of our changes to just this new site, and so we can always revert back to the default Citrix branding.

  1. Run the Citrix XenApp Server Role Manager and then click on the Edit Configuration link for the Receiver Storefront.  This will start the MMC snap-in for Citrix Receiver Storefront.
  2. In the left-hand tree view click on Receiver for Web, and then in the far right-hand pane click on Create Website.
  3. Change the web site path to whatever you want as the URL path for your reseller.  In the screenshot above you can see I chose “/Citrix/TenantACME”.

Now that we have a new web site created, let’s take a quick look.  If you’re using a default environment you’ll see that it created a new folder at C:\inetpub\wwwroot\Citrix\TenantACME, and that within this folder there is a \css folder, a \media folder, a \scripts folder, and a \uiareas folder.  These seem promising!

Let’s start with the background.  If you’ve already read Jeroen’s blog post you’ll know the file we want to change is at C:\inetpub\wwwroot\Citrix\TenantACME\media\bg_bubbles.jpg.  Just replace that file with a different JPG image with the same name.  Here’s an example:

Citrix Receiver for Web - New Background with white text

Not bad, but the white text is a little hard to read.  We’ll start with the username/password and change that to black.

Open up C:\inetpub\wwwroot\Citrix\TenantACME\css\Default.htm.style.min.css in a text editor like Notepad, and do a search for “#logonbox-logonform label” (it will be near the end).  You’ll find a section of text that looks something like this:

#logonbox-logonform label{color:white;display:table-cell;font-size:12px;height:20px;vertical-align:bottom;}

All you have to do is change the part the highlighted text from “white” to “black”:

#logonbox-logonform label{color:black;display:table-cell;font-size:12px;height:20px;vertical-align:bottom;}

While you’re in that file you’ll also want to change some other things as well.  For example any messages will also be in white.  So search for “.ctxsui-messagebox{height:142px” (near the top) and change the color to black as well:

.ctxsui-messagebox{height:142px;min-width:388px;max-height:300px;width:510px;display:table;color:black;}

The Citrix Receiver logo is also really hard to read since it’s white.  That’s an image, so all we have to do is replace C:\inetpub\wwwroot\Citrix\TenantACME\uiareas\Authentication\media\logo_notagline.png with a different image, just like we did for the background image.  We’ll also change the “Screen_SemiTranslucent.png” image (the light bar going across the middle) and the “VerticalGreenBarOnly.png” image (the vertical bar on the far left) as well, since our background has more of a blue theme.

Our web site now looks like this:

Citrix Receiver for Web - new background with black text

This looks a lot nicer!  You can see that we branded it for the reseller with the “Provided by ACME” tagline in the logo image.  So far though we haven’t really introduced anything new.  All we’ve done is tweak some images and some minor CSS.  Now let’s tackle the fun stuff: adding links!

Adding Links on the Login Page

Before we jump in, let’s take a quick look at how the page is structured. If you’re using IE or Chrome hit the F12 key to follow along. The web page is structured as a series of nested tags. These divide the page into logical sections. It’s laid out like this:

Citrix Receiver - DOM model

You can see the major Divs, and the one that is of interest to us is “authentication”. This is the only Div that is visible initially (the others are set to “display:none”).  The way this page works is that it toggles these Divs on or off – for instance after you login the “authentication” Div will become hidden and the “resources” Div will become visible.

You can see that the “authentication” Div is further comprised of other Divs. What we’re going to do is insert yet another Div into the “authentication” Div. So our code will be visible only when the authentication screen is shown, and hidden otherwise.

Create a new text file called “HelpLinks.js” in your C:\inetpub\wwwroot\Citrix\TenantACME\scripts folder.  We’re going to add our javascript code in its own file so that we can keep it isolated from the main code.  In this file copy-and-paste all of the following:

var SetLinks = function() {
    var content = '\
        <div style="position:fixed; top:500px; left:20px;"> \
            <a href="http://www.helpdesk.com">HelpDesk</a><br /> \
            <a href="http://www.feedback.com">Feedback</a> \
        </div>';
    var newDiv = $(content);
    newDiv.insertAfter('#logonbelt-bottomshadow');
};

What this does is add some HTML (the part that is highlighted) right after the “#logonbelt-bottomshadow” Div in our page.  It needn’t be exactly there, but the important thing is that our new Div is added somewhere inside of the “authentication” Div.

But so far this code isn’t linked up to anything.  Let’s open C:\inetpub\wwwroot\Citrix\TenantACME\Default.htm in a text editor like Notepad and add a reference to our new Javascript file.  Find this line in the html page (near the top):

<script src="scripts/Default.htm.script.min.js" type="text/javascript"></script>

Now add another line right before it:

<script src="scripts/HelpLinks.js" type="text/javascript"></script>

This references our new javascript, but doesn’t invoke it.  To do that we modify the C:\inetpub\wwwroot\Citrix\TenantACME\scripts\Default.htm.script.min.js file in Notepad.  Search for the following:

$(document).ready(function(){CtxsApplication.preinit();

Now modify this so that it looks like this:

$(document).ready(function(){SetLinks();CtxsApplication.preinit();

Let’s take a look now.

Citrix Receiver for Web - New background with links

Nice!  Let’s see what has changed in the structure of our page.

Citrix Receiver for Web - DOM model with new Div

You’ll notice that our new Div was added right after the “logonbelt-bottomshadow” Div.

The rest is just a matter of polish.  Some things that you might want to do.

  1. Our helpdesk and feedback links look a little naked.  You can modify the HTML in HelpLinks.js to decorate those links with some images (as in the “After” image at the top of this article).
  2. After the user logs in and sees the apps you will notice that the white text on a light background can be a little hard to read.  To update the text color search for “#resources-header #header-userinfo{float:left;”, “#resources-header #header-logofflink{float:left;”, and “.myapps-name{padding-top:6px;” in the Default.htm.style.min.css file and update each of them to a darker color.
  3. The background frame around each of the apps likewise might need a little tweaking due to the light background.  Update the image at C:\inetpub\wwwroot\Citrix\TenantACME\uiareas\Store\media\MainAppIcon_normal.png if you want to change it.

You may have noticed that generally you’ll have an easier time if you stick with a dark background.  Also, depending on your installation and version, some of the file names might be slightly different.  For instance the Citrix logo image might be called “logo_tagline.png” instead of “logo_notagline.png”

What if you don’t want the links on the authentication page, but rather *after* the user logs in?  That can be done using the same principles in this article:

  1. Look at the structure of the web site.
  2. Find where you want to place your new HTML (in a new sub-div within the “resources” Div in our case)
  3. Add some Javascript to insert your new HTML after an existing Div element of the page (inserting after the “resources-footer” Div would work)
  4. Call your Javascript from Default.htm.script.min.js

I’ll leave that as an exercise to the reader.  If you’re having trouble let me know in the comments section, and also maybe an enterprising individual will post their answer!

(Caveat Emptor: None of this is officially supported by Citrix, take it as-is.)
(Thanks go to Scott Novack who also helped with this article.)

Customizing Citrix Web Interface 5.4

 

An article by sbarnes from Riverlite

During the last few months I had to do several searches on how to  customize our cloud VDI POC portal. This article will explain the many steps that we used to create and edit a new WI 5.4 finished article.

I know the new CloudGatway express is out… I will post the code changes as soon as I get more info.  Seems some web developers from Citrix will putting a good guideline soon

Before:

Before Customization

After:

After customization

Section 1 – the logon page

This area is the first thing that users will see, so it needs to look as good as possible, but still be functional. We opted for an all white theme and keeping the centre logon area in-tact, including the images of the various devices. This mean that we now needed to pick apart everything else that needed changing:

1. Page Title

By default the logon page has a title of “Citrix XenApp”, we decided to change this to a custom string (Riverlite vCloud). This text can be found in:

“C:\Program Files (x86)\Citrix\Web Interface\5.4.0\languages\common_strings.properties” at lines 7 and 8:

2. Header Graphic

By default the web interface will show a “Citrix XenApp” or “Citrix XenDesktop” logo (dependent on which product installed WI), we had an in-house PhotoShop expert adjust our Riverlite vCloud logo to a total white background and make the image a decent size (opted for 454×60) in preparation for the change over. Although we could edit the config files to direct WI to load an alternative image we opted for just renaming the image to the same name as the original image, this ensures less complexity and also less likely for Citrix support to ever say that the configuration is not supported in the event of a support call. The header logo is:

“C:\inetpub\wwwroot\Citrix\SiteName\media\CitrixXenApp.png” (or XenDesktop.png depending on product)

To facilitate the change I renamed CitrixXenApp.png to CitrixXenApp_OLD.png and then dropped our image in as CitrixXenApp.png.

3. Log on box text

As standard the log on box displays the phrase “log on”, this was changed to “Riverlite vCloud” by using the following steps within the Web Interface Management console:

  • Find the XenApp Web Site
  • Right click it and select “Web site appearance”
  • Click “Content”
  • Click “add” and select the correct language
  • Tick the “logon screen text” box
  • Enter your desired text in the “title” section

4. Slogan

Citrix add “Your Windows desktops and apps on demand – from any PC, Mac, smartphone or tablet” as a slogan, however as our vCloud solution is about more than this we decided to remove this. This can either be customized or removed, customize the text by editing “C:\Program Files (x86)\Citrix\Web Interface\5.4.0\languages\accessplatform_strings.properties” at line 29:

Removal can be achieved by editing “C:\inetpub\wwwroot\Citrix\SiteName\app_data\include\fullstyle.inc” at line 1179 and changing this to “display: none;”.

5. Footer Images

By default Citrix add Citrix and HDX logos to the footer of the page, to replace them with custom branding I replaced “C:\inetpub\wwwroot\Citrix\SiteName\media\CitrixWatermark.png” with my new logo. This logo has a hyperlink attached to it which can be edited in “C:\inetpub\wwwroot\Citrix\SiteName\app_code\PagesJava\com\citrix\wi\controls\FooterControl.java” at line 16

Removing the HDX logo can be achieved by editing “C:\inetpub\wwwroot\Citrix\SiteName\app_data\include\fullstyle.inc” and changing line 886 to have a value of “display: none;”.

6. Changing the background colour

By default the background is made up of a handful of images, however we decided that it would be better to utilise standard hex colors. The background is referenced in:

“C:\inetpub\wwwroot\Citrix\SiteName\app_data\include\fullstyle.inc”

By default the top pane uses the image “HorizonBgTop.png” and the bottom pane uses “HorizonBgBottom.png”. To utilise colors instead the following configuration change was made:

Section 2 – the applications/desktops page

Once the user has authenticated they will be presented with their available applications and/or desktops. We decided that as this page will be used for demonstration purposes by large numbers of users that we should make it as clean and simple as possible. We decided to again implement some custom branding, but also remove the “messages” and “settings” options. Here is the original heading layout and the original header logo:

And here is the after:

1. Replacing the header logo

Again we had to use some PhotoShop expertise to get the color matching correct (the default WI header background is #95A2AC – as defined in “c:\inetpub\wwwroot\Citrix\SiteName\app_code\PagesJava\com\citrix\wi\pageutils\Branding.java”). The image that needs replacing is:

“C:\inetpub\wwwroot\Citrix\SiteName\media\CitrixLogoHeader.png”

2. Removing the “messages” option

Open “C:\inetpub\wwwroot\Citrix\SiteName\app_data\include\header.inc” and change line 62 as per the below to comment out the configuration item. Ensure that the change is made at both the open and close tags as highlighted below.

3. Removing the “settings” option

Open “C:\inetpub\wwwroot\Citrix\SiteName\app_data\include\header.inc” and change line 81 as per the below to comment out the configuration item. Ensure that the change is made at both the open and close tags as highlighted below.

Section 3 – the logged off page

The logged out page uses a different set of logos and configuration entries, as such a separate set of customizations is required.

Before:

After:

1. Changing the header graphic

We utilized the same header logo that is used on the logon page by simply copying and renaming the file to:

“C:\inetpub\wwwroot\Citrix\SiteName\media\CitrixXenAppLoggedOff.png”

 

2. Changing the footer graphic

We utilized the same footer logo that is used on the logon page by simply copying and renaming the file to:

“C:\inetpub\wwwroot\Citrix\SiteName\media\CitrixLogoDarkLoggedOff.png”

 

3. Customizing the background color

We decided to keep a clean white theme throughout the site, but keep the greyed out devices picture. This configuration is stored in:

“C:\inetpub\wwwroot\Citrix\SiteName\app_data\include\fullstyle.inc”

Before:

Changing the background values to “#000000″ will provide a white background, as per the below:

Section 4 – Other useful adjustments

1. Favicons

By default a Citrix favicon is utilized:

This can be changed by placing an icon (16×16 size) with the filename of:

“C:\inetpub\wwwroot\Citrix\SiteName\media\IcaComboAll.ico”

2. Removing the “devices” image from the logon page

Browse to “C:\inetpub\wwwroot\Citrix\SiteName\app_data\include\fullstyle.inc”

Change line 1184 to set the background to “none”

3. Remove the devices image from the logged off page

Browse to “C:\inetpub\wwwroot\Citrix\SiteName\app_data\include\fullstyle.inc”

Change line 1209 to set the background to “none”