citrix load balancer loadbalancer Netscaler sharepoint

Configuring Citrix Netscaler for SharePoint SSL Offloading

I came across an interesting issue today and found that there was not a lot of info on the web about it, so as with lots of things on this blog I thought as it was not really noted about before I would document it here.

The scenario was SSL (HTTPS) connections from the outside of a company to their SharePoint site are required – so no HTTP connections. But inside the company it is all HTTP connections to different SharePoint sites! Therefore SharePoint has been set up such that the Citrix Netscaler is doing SSL Offloading and presenting a HTTP connection to SharePoint, but that SharePoint knows to return HTTPS in all the URL’s so that connections from outside remain working.

The problem here is that users on the outside had been typing in the host name for the site without HTTP and as the Netscaler was not listening on port 80 the connection was timing out. The client wanted the HTTP connection to redirect to the HTTPS version of the site.

So first the redirection. This is quite easy – you create a new virtual server for HTTP (TCP port 80) that is not bound to any service but is listening on the same IP address that the HTTPS virtual server is bound to. In the advanced tab of the HTTP virtual server you enter the value to redirect to if the service is unavailable. This URL should be the https:// url for the site.

Once the HTTP virtual server is configured it will appear as down as there are no services bound to it – this is fine. As the virtual server is down it will redirect to the specified URL. Note that rewriting rules can also be used to achieve the same end.

The following picture shows the HTTP and HTTPS service. The HTTPS service is listening on 443 but going to a service on port 80 – in other words SSL offloading.

Virtual Servers

And this one shows the 443 listener connecting to the HTTP service


The problem with this is that the user connects to port 80 and is redirected to port 443, which redirects to port 80 on SharePoint and as SharePoint does not know about the SSL offload in place returns a HTTP link to the home page. The user is redirected to the home page on port 80 and is redirected to port 443, which redirects to port 80 on SharePoint and as SharePoint does not know about the SSL offload in place returns a HTTP link to the home page. The user is redirected to the home page on port 80 and is redirected to port 443, which redirects to port 80 on SharePoint and as SharePoint does not know about the SSL offload in place returns a HTTP link to the home page. The user is redirected to the home page on port 80 and is redirected to port 443, which redirects to port 80 on SharePoint and as SharePoint does not know about the SSL offload in place returns a HTTP link to the home page. The user is redirected to the home page on port 80 and… …etc. etc. Internet Explorer and Chrome just keep going around and around and never get anywhere. If you turn on the developer tools in both browsers IE will show you each redirect on the network tab. Chrome will just show it failing to connect. It was from IE that we saw the issue.

We need to tell the HTTPS virtual server that it is to add a header to the session telling SharePoint that SSL offloading is in place. This header is “front-end-https” and the value is “on”. Neither the header or value are case sensitive.

To turn on this header on the HTTP request (that is, the connection from the user to SharePoint) then you need to go to the Policies tab of the HTTPS virtual server and add a new Rewrite Request.

The following picture shows this in place, but what you need to do is add to this rewrite policy a rewrite action check that this action is working


The rewrite policy needs to have a name and a new action. The action needs a name and a type. The type is INSERT_HTTP_HEADER and the header name is”front-end-https”. Note this is not case sensitive, but also is not Front_End_Https which has been used with Exchange Server in the past. The value for the header is needed in quotes and is “on”.

If you click Evaluate to check the action you will need to enter a test expression and a HTTP sequence of data. For testing purposes I use !HTTP.REQ.HEADER(“front-end-https”).EXISTS which reads to evaluate to true if the header does not exist. To test the rule enter HEAD fqdn and a line feed. The blank line is important or you get protocol errors. If the HTTP protocol text does not contain front-end-https: on then the rule will evaluate to true and add the header.

The following picture shows the action settings:


And the following shows the rule settings:


Once your policy has been created you should be able to browse to HTTP for SharePoint, be redirected to HTTPS/SSL and have SharePoint know to offload the SSL to the load balancer, and so respond with a HTTPS link even though the connection was over port 80.

2010 citrix exchange https load balancer loadbalancer Netscaler networking owa update upgrade

HTTPS Load Balancer Issues with Exchange 2010 SP2

When you install Service Pack 2 (and maybe SP1 too) on Exchange 2010 it resets the SSL flag on the root directory of the IIS website. You might have removed this setting for a number of reasons, mainly to do with having a HTTP to HTTPS redirect, but it can also be removed if you are doing SSL Offloading to a load balancer and that load balancer checks the state of the client access server by doing HTTP requests for the root home page. The Citrix Netscaler is one such load balancer that has this as a default setting.

The configuration documentation for the Citrix Netscaler (found here) does not discuss changing the load balancer to use a different directory on IIS to monitor the availability of the site, so when you install SP2 for Exchange 2010 and that update resets the root directory to require SSL, your load balancer thinks the site is offline and does not pass through any traffic!



To fix this issue in the short term, just uncheck the Require SSL option on the root of the Default Web Site on each of your Client Access Servers. Your load balancer should notice within a few seconds and service will resume, for example the Citrix Netscaler checks the root directory via the monitor properties every five seconds for a HTTP success code (and not a HTTPS success code!).

To fix this issue in the long term you should make a new virtual directory on each server covered by the load balancer and get the load balancer to look at this directory to determine if the service is up or down rather than looking at the root directory. Your virtual directory will not be reconfigured by future Exchange service packs (or indeed any other application that you are load balancing that might reset the SSL option on the root directory).

To complete these steps do the following:

1. Create a folder in the inetpub directory called “monitor” or similar (in the examples below the folder is called “netscaler_monitor”).

2. Place an index.htm file in this folder that is a very simple webpage that when browsed returns the page. If you want to make the page more complex to include code (so that issues with the code are picked up by the load balancer then this is fine). A simple page would look like the following:

<title>Netscaler Monitor for Exchange 2010title>
<p>This page returns a success code to the netscalers if IIS is running. This page must always work over HTTP and never require an SSL connection.p>

3. In IIS require SSL and then uncheck require SSL – this forces a setting into the IIS config file (applicationHost.config) that says that this folder must always be over HTTP and not require SSL. If you do not do this then this folder will take the setting from the parent folder, and as we have already seen, this will cause the monitor folder to require SSL when you apply the service pack.

This SSL change will result in the following configuration at the bottom of applicationHost.config, which can be added directly to the config file rather than in IIS Manager.

    <location path="Default Web Site/netscaler_monitor">
<access sslFlags="None" />

4. Update your load balancer so that it has a new monitor for checking the service state on the managed machine. This monitor would be something like the following for a Citrix Netscaler, each load balancer being different. This monitor checks HEAD /netscaler_monitor/ and expects to get back a 200 status code. You need to change the folder name to match, but ensure the / is before and after the folder name.


5. Change the configuration for each client access server in the load balancer so that it uses the new monitor rather than the default HTTP monitor.


6. Save your changes to the load balancer. The next time you service pack Exchange 2010 the resetting of the SSL flag on the root directory will not cause you any issues.

citrix crm terminal server

How to Configure CRM 4 on a Terminal Server When Not All The Users Use Microsoft Dynamics CRM 4.0

The Microsoft Dynamics CRM 4.0 Outlook client software, when installed on a terminal server (Microsoft or Citrix) results in the CRM toolbar (which is part of the CRM Outlook Add-in) appearing for all users of the server regardless of whether or not they require the functionality of CRM and irrespective of whether or not they have an account on the CRM system.

The CRM toolbar appears because the Outlook CRM Add-in is loaded, and the add-in is loaded because of the following registry key:


Removal of this key from the users’ registry stops the add-in appearing under Outlook and stops the add-in loading. There is though one problem with this. At the users login a program runs that recreates this key if it is missing, so that registry key needs to be removed as well. This one is:

HKLM\SOFTWARE\Microsoft\Windows\Current Version\run and the deletion of the MSCRM value (keeping a copy of the data in this value for later).

For all users logging into a computer running the CRM Outlook client would now only get the add-in if the first registry key above exists, so existing CRM users are not affected by this change. Remove the first registry key above from any user who does not use CRM and remove the second key one from the machine and all new users will not get CRM. To give new users the CRM Outlook add-in just run the command line that was the data of the MSCRM registry value (where x is the drive where the CRM software is installed):

x:\program files\microsoft dynamics
crm\client\configwizard\crmforoutlookinstaller.exe /activateaddin

All the above works fine on a standard client, but if you need to do the above on a terminal server then you need to be aware of the shadow copy of the registry keys that terminal servers use to create the initial users profile the first time they login. Because the CRM client is initially installed with the CHANGE USER /INSTALL command active the registry stores a copy of the first registry key above so that it can be applied to users when their profile is created. This registry key needs to be removed as well. You will find this key at:

HKLM\SOFTWARE\Microsoft\Windows NT\Terminal

Note that you do not need to be in change user install mode when you make this change, as we are not uses these changes to affect existing user profiles, just stopping new user profiles from loading the CRM add-in if they do not need to. To change existing user profiles just delete the first registry key above from their profile using a script or manual action or whatever method you prefer. Of course you will need to have done the other steps above before this or the registry key will be recreated the next time they login.