Now install the client using the commands:

sudo dpkg -i ~/Downloads/icaclient_*.deb ctxusb_*.deb
sudo apt-get -f install # Install missing depends.

Next, configure the client:

sudo /opt/Citrix/ICAClient/util/configmgr &

Without executing this command I would get a brief pop-up and then the Citrix client would simply disappear – no errors were displayed.

Using FireFox? Check here for specific instructions: https://help.ubuntu.com/community/CitrixICAClientHowTo#A7._.2864-bit_only.29_Fix_Firefox_plugin_installation

SSL configuration for GlobalSign SSL (if you’re using a different CA you can skip this / retrofit to meet your needs).

Download GlobalSign Root CA crt files from: https://support.globalsign.com/customer/en/portal/articles/1426602-globalsign-root-certificates

wget https://secure.globalsign.net/cacert/Root-R1.crt
wget https://secure.globalsign.net/cacert/Root-R2.crt
wget https://secure.globalsign.net/cacert/Root-R3.crt

Convert to PEM format using openSSL:

openssl x509 -inform DER -in Root-R1.crt -out Root-R1.pem -outform PEM
openssl x509 -inform DER -in Root-R2.crt -out Root-R2.pem -outform PEM
openssl x509 -inform DER -in Root-R3.crt -out Root-R3.pem -outform PEM

Copy these to: /opt/Citrix/ICAClient/keystore/cacerts

sudo cp *.pem /opt/Citrix/ICAClient/keystore/cacerts/

Rehash the ICA Client certificates:

sudo c_rehash /opt/Citrix/ICAClient/keystore/cacerts/

Citrix “official” instruction are available here: http://docs.citrix.com/en-us/receiver/linux/13/linux-secure-wrapper/linux-secure-connect-secure-gateway-ssl-relay.html

If you get SSL Error 61 :: “Contact your help desk with the following information: You have not chosen to trust “GlobalSign RootCA”, the issuer of the server’s security certificate (SSL error 61).”

You haven’t imported / rehashed the necessary SSL certificates for your servers certificate.

We modified this registry key to 180 seconds and applications would then launch, workaround in-place, but what was really causing the issue?

After a LOT of troubleshooting it was discovered that there were 100+ profile folders on the servers. We scripted cleanup of these profiles using the script below, login times dropped to ~25 seconds.

You’ll need to ensure you modify the list of profiles you want to keep, as defined in the first line of the script – I’m not responsible for any data lost – you are! You should, no must, test this in a lab first…

The following script can be used, and scheduled, to cleanup stale profiles. 

$arrNames = "admin","All Users","Classic .NET AppPool","Ctx_StreamingSvc","Default",     "Default User","limssched","Public","Waters","sophosupd","SUSR_UDA","NetworkService","LocalService","systemprofile" $profiles = Get-WmiObject Win32_UserProfile  foreach ($profile in $profiles) {     $username = $profile.LocalPath.split('\\')[-1]     If ($arrNames -NotContains $username) {    write-host "Will delete profile for USER: $username, ***PATH:" $profile.localpath}     If ($arrNames -NotContains $username) {    $profile.delete } }

For the purposes of this article I wanted to see how easy it would be to ‘profile’ (or package) Microsoft Office 2010 for streaming using XenApp 6.5, including configuring offline access.

The solution I have used below is purley KMS licensing centric, you can get a MAK license to work (witha little more effort) but that is outside the scope of this article.

Note that you can only profile Microsoft Office 2010 x86, the 64-bit version does not/will not work.

Contents

1. Preparing the Profiling Computer

2. Preparing Client Computers

3. Customise Microsoft Office 2010 Setup

4. Profling Microsoft Office 2010

1. Preparing the Profiling Computer

I would always profile on a ‘clean’ Virtual Machine that represents the platfom your users will be running the streamed application from; so in my case I built a fresh Windows 7 x64 VM.

You can always use snapshots to revert back to the clean state when you have finished profiling an application.

2. Preparing Client Computers

In order to make activation easy both Microsoft and Citrix reccomend that you install the Microsoft Office 2010 Deployment Kit for App-V (yes I know it says App-V, but trust me, it will work with Citrix too!)

You have a few options for deployment, Group Policy, System Center 2012 Configuration Manager (or an equivalant) or good old fashioned manual installation.I used a manual install for my single test machine, I suggest you look at one of the more intuitive solution for an en-mass roll-out.

The command I used to deploy the deployment kit was:

{code lang:ini showtitle:false lines:false hidden:false}msiexec /i OffVirt.msi PROPLUS=1 KMSSERVICENAME=”kmssrv.domlocal.net” KMSSERVICEPORT=1688 TRANSFORM=OffVirt64Custom.mst{/code}

You can obtin the transform files from the following locatoin: http://support.citrix.com/article/CTX130331

You then need to confirm that the ‘Office Software Protection Platform’ is started and that the startup type is set to Automatic.

{code lang:ini showtitle:false lines:false hidden:false}sc config osppsvc start=auto
sc start osppsvc
{/code}

3. Customise Microsoft Office 2010 Setup

On the profiling machine open a command prompt and change directoryto the Microsoft Office 2010 setup files. Remember these should be the 32-bit version as the 64-bit version will not work!

Execute the command setup /admin to launch the setup customisation wizard:

Select the product you wish to customise and click OK:

Unless you want to change the default file types select the keep current settings:

Now, under “Install Loation and Organization Name” enter your company name:

Under Licensing and User Interface select ‘I agree the terms of the License Agreement’

Under ‘Set feature Installation States’ configure every application you will provide users access to as ‘Run all form My Computer’ – ruin on first use will not work when using application streaming!

Finally, to make the user experience that much nicer, under Modify user Settings > Microsoft Office 2010 > Privacy > Trust Center set ‘Disable Opt-In Wizard on First Run’ to ENABLED (the screensot below is wrong – but illustrates the loctaion!)

Now File > Save and save the MSP file under the Updates folder in the location contining the Microsoft Office 2010 installation files.

4. Profling Microsoft Office 2010

Download, install and launch the Citrix Streaming Profiler tool, in this example I used version 6.6.0.16.

Select the ‘New Profile’ option:

Click Next to begin the profiling Wizard:

Name the Profil Office 2010:

Do not enable User Updates and select Next to continue:

Do not enable support for 6.0 Offline Plugins unless you have these versions deployed.

There are no linked profile requirements for this deployment, but your environment may differ:

Select your Target Operating Systems, I selected WIndows 7, Windows 7 64-bit and Windows Server 2008 R2 64-bit edition (not all shown below). The server edition of the OS was selected to that the applictaion could be streamed to the XenApp Server to support clients such as Apple iPads.

You should also select the languaged you wish to support.

Select Advanced Install and click Next:

Select ‘Run install program or command line script’ and click next:

Browse tot he folder containing your Microsoft Office 2010 installation files and select the setup.exe file, then click Next:

Click Launch Installer to begin Microsoft Office 2010 setup:

Run through setup as you normally would, the Streaming Profiler will monitor the installation and capture it into a package:

Click Close, the Streaming Profiler will then perform a ‘virtual restart’ (takes ~1 second):

We’re nearly ther,e we just need to add some additional files to the installation. Select the ‘Perform additional installations’ option:

Choose the ‘Select files and folders’ option:

So it’s now better to group the files you need up manually first.

1. Create a folder on the root of C: named ‘RequiredFiles’
2. Copy the following files to this folder:

Now, using the wizard, in the left hand folder view select your C:RequiredFiles folder, then copy the files as follows:

Click Next when finsihed, and then select the option to “Finish the Installation”:

Citrix Streaming Profiler will now discover all of the deployed applictaions:

Now run the core applictaions to ensure they worl as expected.

You’ll see the status change to ‘Application Run’:

Review the list of application, then click ‘Next’

You don’t  need to create a VHD unless you are using VDI:

If you have a Document Signing certificate you can sign the profile, if not then click Next:

Click to terminate all processes, then click Next:

Click Finish to start the profile creation:

Needless to say the pocess is fairly quick and fairly simple, click the jump to read more.

 1. Supported Upgrade Paths

2. HA Considerations

3. Pre-requisites

4. Perform the Upgrade

4.1 Standalone / Secondary HA Node

4.2 Primary HA Node

5. Testing

6. Access Gateway – Receiver Theme

1. Supported Upgrade Paths

It is possible to upgrade form version  8.0, 8.1, 9.0, 9.1, 9.2, or 9.3 to versoin 10. Upgrades from thes versions do not require a new license.

Just an idea, power off your NetScaler VPX devices and snapshot them prior to performing the upgrade – that way if the ‘wheels fall off’ so to speak you have a good roll back plan. Sorry – this won’t work should you be using the Hardware NetScaler devices that are available.

2. HA Considerations

In a NetScaler HA Pair you should upgrade the Secondary NetSCaler FIRST, then upgrade the Primary. You can chose to force a failoverover once the secondary node upgrade is complete – remember this will reset connections to the NetScaler HA pair.

3. Pre-requisites

Download the following files from My Citrix: build-10.0-54.7_nc.tgz (NetScaler ADC > Firmware > Get Firmware) ns-10.0-54.7-doc.tgz (NetScaler ADC > Firmware > Show Documentation and then click Get Documentation)

Logon to the NetScaler using WinSCP:

Create a 10nsinstall subdirectory in the /var/nsinstall directory. Change directory to /var/nsinstall/10nsinstall, create a directory named build_547, and change to this directory.

Finally copy the upgrade files to the NetScaler using WinSCP;

4. Perform the Upgrade

4.1 Standalone / Secondary HA Node

Logon to the console and enter the following commands:

• • save config

• • shell
  • cp /nsconfig/ns.conf /nsconfig/ns.conf-523

Download this file using WinSCP for safe keeping!

Extract the downloaded firmware:

• • cd /var/nsinstall/10nsinstall/build_547
  • tar zxvf build-10.0-54.7_nc.tgz
  • tar zxvf ns-10.0-54.7-doc.tgz

 Execute the installns script: ./installns

Once the NetScaler VPX upgrade has completed you’ll be prompted to restart the device.

Once the reboot has rebooted (this will take a few minutes!) you can logon to the web interface and verify the configuration.

Note, if you are running a standalone NetSCaler VPX then you’re done for section 4.

If running HA you should be prompted about the fact you are logged onto the secondary node:

From the console you can verify the Sync / Propogation is disabled using the command “show ha node” – this is normal as the versions don’t match between the devices:

If running HA, you have the option here of performing a force failover using the command “forcefailover” form the Secondary NetScaler console – bear in mind if you do this sessions are not being sync’d between the NetScaler devices – i.e. you will lose your session tables and users will have to reconnect/authenticate, so plan to do this at a convienient time!

If you perform the failover then test as per section 5, if not then perform the upgrade of the Primary Node in section 4.2, then perform your testing.

4.2 Primary HA Node

Perform the upgrade as above on the Primary device (which, if you forcefailover, is now secondary)

Once complete verify the sync/propagation is working.

5. Testing

If using ha, run the command “show ha node” from the console to verify the Sync and Propagation are working:

Finally test your applictaions you serve up through your NetScalers:

6. Access Gateway – Receiver Theme

If you are using the Access Gateway feature then take a look at the article below, this will advise on how to install the new Storefront/Receiver theme onto Access Gateway – looks MUCH better!

http://support.citrix.com/proddocs/topic/access-gateway-10/agee-client-connect-cr-new-theme-page-tsk.html

This article assumes you have deployed the NetScaler Appliance (instructions here) and configured basic Network Settings including a DNS Nameserver.

Contents

1. Deployment Environent

1.1 NetScaler Deployment

1.2 XenApp Deployment

1.3 SSL Certificates

1.4 Active Directory Domain Information

2. Deployment Considerations

3. StoreFront 1.1 Setup

3.1 Basic Setup for Internal-only use (i.e. no access Gateway)

3.2 StoreFront Access Gateway Configuration

4. Access Gateway / NetScaler Configuration

4.1 Enable Access Gateway Feature

4.2 Import / Install SSL Certificate(s)

4.3 Create Authentication Policy / Server

4.4 Create Session Policies and Profiles

4.4.1 Receiver Web Session Policy / Profile

4.4.2 Storefront_Services Policy / Profile

4.4.3 PNA_Services Policy / Profile

4.5 Create Access Gateway Virtual Server(s)

5. Testing Access Gateway

6. Problems? 

1. Deployment Environent

1.1 NetScaler Deployment

Two node HA-pair of NetScaler VPX devices configured in a two-arm topology;

• • NS1 – 192.168.0.230/24
  • NS1 – 192.168.0.231/24

Internal network on NetScaler devices is 192.168.0.0/24, ‘External’ network is 192.168.209.0/24.

NetScaler MIP is 192.168.0.235.

Virtual Server IP Addresses and required DNS records (internally managed for LAB):

• • 192.168.0.247 – ctx.domlocal.net (Load Balancer)
  • 192.168.0.248 – ag.domlocal.net – Internal Access Gateway
  • 192.168.209.248 – ctx.cb-net.co.uk (managed using split-DNS) – External Access Gateway

More info on the two-Access Gateway configuration below.

1.2 XenApp Deployment

Single XenApp 6.5 Server running Storefront 1.1 (in a production environment I’d separate these roles and have multiples of each!)

• • CTX1.domlocal.net – 192.168.0.102/24

The Citrix XML service on the XenApp server is set to run on port 8081.

External URL for Access Gateway will be configured to https://ctx.cb-net.co.uk

1.3 SSL Certificates

Finally, SSL certificates;

• • Use a third-party SSL certificate on the Access Gateway Virtual Server – the whole idea of Access Gateway is to facilitate easy access to internal Citrix systems, with a certificate from you internal PKI you’ll reduce functionality as the Receiver Client wont work without being hacked and slashed.
  • If you opt for the two Access Gateway setup then an internal PKI certificate is fine for the intranet facing Access Gateway, alternatively add the SAN of the internal access gateway to your third-party SSL cert.

Both of these certificates should be SAN certificates, I used the following certificates:

• • External Access Gateway certificate SANs – ctx.cb-net.co.uk 
  • Internal Access Gateway certificate SANs – ctx.cb-net.co.uk, ctx, ctx.domlocal.net, ctx1.domlocal.net, ctx1

I used the Internal Access Gateway Certificate on the StoreFront Server’s IIS Default Website.

1.4 Active Directory Domain Information

Domain Name: domlocal.net

Domain Controller: DC1.domlocal.net

2. Deployment Considerations 

There are two ways you can approach this deployment;

1. Configue the Access Gateway on an ‘External’ IP address (in this example 192.168.209.x/24)
2. Configure the ACcess Gateway on an Internal IP address (in this example 192.168.0.x/24)

The first option appears to be the most logical, however there is a caveat; the Storefront Server will attempt to perform an authentication request with Access Gateway, the Access Gateway will not respond to authentication requests on an external interface, therefore an INTERNAL interface must have Access Gateway configured as well, for use in Authentication. In a single-arm, or internally addressed Access Gateway setup this is not an issue – more details (a little more!) here.

I’ll detail how to configure both simply because it took me a while to figure out how to get it working, but question the sanctity of deploying two essentially identical Access Gateway’s!

Additionally, I would avoid installing StoreFront on a Web interface Server.

3. StoreFront 1.1 Setup

3.1 Basic Setup for Internal-only use (i.e. no access Gateway)

Download StoreFront 1.1 from My Citrix > Downloads, so long as you have an active trial license or commercial XenApp license this should be available.

Important note here, if you want to use SSL then Install IIS and assign an SSL certificate to the default website before proceeding any further.

Install StoreFront 1.1, this is really simple:

When completed the MMC Snap-In will load and prompt for the deployment scenario you wish to use. For the purposes of this lab select a single-server deployment:

You’ll now be prompted for URL you wish StoreFront to be accessible on. If you have assigned an SSL certificate with a Common Name that represents the URL of choice as the Subject Name the prompt should be populated with the correct URL already.

For this deployment the internal FQDN is correct; https://ctx.domlocal.net

You’ll now be presented with a step-by-step configuration wizard of sorts.

First on the hitlist is authentication, click ‘Create Service’ and then tick all three authentication types, then click Create:

Now we’ll create a store, click ‘Create Store’ from the main window; enter a Store Name – for this example I used CB-Net XenApp Store;

Add the Data Collector Citrix XenApp server from one of your Citrix farms, esnure you set the correct port for the XML service. Importantly, unless you are sharing the XML service with IIS ports, make sure you select HTTP as the protocol!

The store has now been created, and for Internal Clients can now be accessed using the Receiver Client (not Receiver Web Site as we haven’t made that yet).

Now we can create the Receiver for Web IIS Website, form the main snap-in window select ‘Create Site’

3.2 StoreFront Access Gateway Configuration

 We have already enabled the required Authentication tyoe for Access Gateway in step 3.1 (Pass-through form Citrix access Gateway)

From the StoreFront snap-in select Gateways and then, in the action pane, select ‘Add Gateway Server’

In this example I entered the following configuration details for the Access Gateway:

• • • Display Name: NetScaler MIP
    • Gateway URL: https://ctx.cb-net.co.uk
    • Deployment mode: Appliance
    • Tick ‘Set server as Access Gateway Enterprise Edition’
    • Subnet IP Address: 192.168.0.235 (this is the NetScaler MIP)
    • Logon Type: Domain Only 

You’ll then be prompted to enter a silent authentication URL. This comes back to my earlier point – this must resolve to an ‘Internal’ Access Gateway Virtual Server, i.e an IP address that would be accessible through the NetScaler’s management interface.

• If you opted for a single Access Gateway Virtual Server on the Internal Interface then enter your external FQDN as the address (use your internal DNS to point this at the INternal NetScaler IP) – in this example I would use https://ctx.cb-net.co.uk
• If you opted to go for the multi-Access Gateway deployment then this should be set to the internal FQDN of the internal Access Gateway Virtual Server (again use internal DNS servers) – in this example I would use  https://ag.domlocal.net 

Next is the Secure Ticket Authority definition. Importantly the list you use here MUST match the list you later use on the NetScaler/Access Gateway configuration. In this example I defined a single STA – https://ctx1.domlocal.net:8081

Ensure you enter the correct port number – this is the XML service port.

Next, on the Storefront configuration, define your external beacons. Essentially beacons are used by the Receiver Client to identify if it is on the Internal Network, and therefore not to use the Access Gateway, or on an external network, and therefore to use the AG.

Click on beacons form the Storefront snap-in, then from the action pane select ‘Manage beacons’ – I then used two external beacons, the first being the external Access Gateway URL, the second being the corporate website:

OK, so were nearly there on the StoreFront configuration, there are two remaining actions;

1. Enable Legacy Support (required by iOS, Android and Mac devices
2. Enable Remote Access

To enable Legacy Support browse to Stores and select the Store you created earlier, then form the action pane select ‘Configure Legacy Support’

Select the ‘Enable Legacy Support’ tick-box, change the Default Store to your new store then click OK:

Now form the action pane select ‘Enable Remote Access’

Tick the NetScaler MIP Access Gateway you created earlier and then select the Netscaler MIP as the default gateway:

StoreFront is now configured to support Access Gateway, we just have to configure the Access Gateway now!

4. Access Gateway / NetScaler Configuration

4.1 Enable Access Gateway Feature

First you’ll need to enable the NetScaler Access Gateway feature, browse to System > Settings > Configure Basic Features:

4.2 Import / Install SSL Certificate(s)

Now you need to import and install the SSL Certificate you’ll use on the Access Gateway Virtual Server(s).

Export the certificate you are using on the storefornt server using the Certificates MMC snap-in, ensure you export both the Public and Private Key.

Next, browse to the SSL folder in the left-hand menu and click on Import PKCS#12;

• • Browse your local file system for the exported certificates
  • Use an Output File Name of ‘Storefront_SSL’
  • Enter the password you used when exporting it

Next, browse to SSL > Certificates and select ‘Install..’ from the bottom of the window:

• • Enter a name of Storefront_SSL
  • Browse the APPLICANCE for the certificate you just imported
  • Enter the correct password
  • Set a notification window of your choice

4.3 Create Authentication Policy / Server 

Now we need to create an Authentication Policy and Server

Browse to Access Gateway > Policies > Authentication and click ‘Add…’ at the bottom of the window.

I named the policy ‘LDAP domlocal.net,’ selected an authentication type of LDAP and then clicked ‘New…’ next to Server:

Enter the following configuration details:

• • Name: DC2.domlocal.net
  • IP Address: 192.168.0.190
  • Port: 636 (LDAPS)
  • BaseDN: DC=domlocal,DC=net
  • Administrative Bind DN: use the distinguishedName of a normal user account in AD DS – there is no need ot use an administrative account.
  • Password: Password of above account

Click Retrieve Attributes to ensure the connection is working then click ‘Create’.

Under Expression in the Authentication Policy window click the ‘Advanced Free-Form’ button and then enter ‘ns_true’ into the expression field. Then click ‘Create:’

4.4 Create Session Policies and Profiles

Browse to Access Gateway > Policies > Session and click ‘Add…’ at the bottom of the window:

One important thing to note here is that the DNS names used in the Session Profiles point to a Load Balancer Virtual Server IP address; 192.168.0.247, this can also be configured ot point to a Storefront Server directly.

 We need to create 3 session policies, one for Receiver, one for Storefront and one for Legacy Connections to PNAgent.xml to support iOS, Android and Macintosh devices.

4.4.1 Receiver Web Session Policy / Profile

Enter the following details:

• • Name: Receiver_Web
  • Expression: Click the ‘Match any expression’ button and then select Advanced Free-Form; enter REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver

Then click New next to ‘Request Profile’

Under the Client Experience tab configure:

• • Clientless Access: Allow
  • Single Sign-On to Web applicance: Enabled

Under Published Applications configure the following, then click Create:

• • ICA Proxy: ON
  • Web Interface Address: https://ctx.domlocal.net/Citrix/CB-NetXenAppStoreWeb
  • Single Sign-On Domain: DOMLOCAL

4.4.2 Storefront_Services Policy / Profile

Create a new Session Policy under Access Gateway > Policies > Session – click ‘Add…’ at the bottom of the window.

Enter the following details:

• • Name: Storefront_Services
  • Expression: Click the ‘Match any expression’ button and then select Advanced Free-Form; enter REQ.HTTP.HEADER X-Citrix-Gateway EXISTS

Then click New next to ‘Request Profile’

Under Client Experience:

• • Clientless Access: Allow
  • Single Sign-On to Web appliance: Enabled

Under Published Applications configure:

• • ICA Proxy: ON
  • Single Sign-On Domain: DOMLOCAL

4.4.3 PNA_Services Policy / Profile

Create a new Session Policy under Access Gateway > Policies > Session – click ‘Add…’ at the bottom of the window.

Enter the following details:

• • Name: PNA_Services
  • Expression: Click the ‘Match any expression’ button and then select Advanced Free-Form; enter REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver && REQ.HTTP.HEADER X-Citrix-Gateway NOTEXISTS

Then click New next to ‘Request Profile’

Under Client Experience:

• • Single Sign-On to Web applicance: Enabled

Under Published Applications configre:

• • ICA Proxy: ON
  • Web Interface Address – use the URL that was generated when you enabled legacy mode on the store: https://ctx.domlocal.net/Citrix/CB-NetXenAppStore/PNAgent/config.xml

4.5 Create Access Gateway Virtual Server(s)

Browse to Access Gateway > Virtual Servers and click ‘Add…’ at the bottom of the window.

• • Enter an IP address (if you use an external IP on this VS remember you;ll have to duplicate the steps below using an INTERNAL IP address as well so that Storefront Authenticatoin requests are processed correctly)
  • Bind the correct SSL Certificate to the VS

Under Authentication add the LDAP Authentication policy you created earlier:

Under Policies add the three Session Policies you created earlier, in the following order:

• • Priority 80 PNA_Service
  • Priority 90: Storefront_Services
  • Priority 100: Receiver Web

Now click the Clientless button in the policies window. We need to create a rule to ensure that Storefront traffic is not subject to any rewriting.

Click ‘Insert Policy…’ at the bottom of this window:

Name the policy CVPN_NoRW, enter an expression of true ahen click ‘New…’ next to Profile:

 Name the new Profile CVPN_NoRw and click OK (there are no additional settings required):

Close the remaining Clientliess Access Policy Window to return to the Access Gateway Virtual Server configuration.

Finally, under Published Applications add the same STA(s) that you added to the Storefront configuration earlier:

• • http://ctx1.domlocal.net:8081/scripts/ctxsta.dll

If you just created your Access Gateway VS on an Internal IP then proceed ot the next step, if it’s configured on an External IP address perform the exact same setup as above using an internla IP address as well.

5. Testing Access Gateway

Once you have configured your external DNS and NAT (if applicable) to allow external access to the Access Gateway Virtual Server you are then ready to test. You could also use your internal DNS/host file to perform a mock test

I configure my Access Gateway to be accessible at https://ctx.cb-net.co.uk 

Login with a user that has access to applications in the store:

You’ll then be redirected to the Storefront webpage:

You will not have to enter any other credentials, they get passed through via the Access Gateway:

Proceed to add an application:

Finally, test the application works:

And that’s it… not the shortest of configuration articles, but the process is fairly logical.

Problems?

Using Storefront 1.2 you may encounter an issue when you add the Access Gateway to the Storefront configuration and you are also load balancing Storefront IIS servers – for internal-only access for example . This happens because the source of the load balancer will be the same as your Access Gateway, so Storefront expects the traffic to be handled in a specific way and it is not. Perform the following steps to use a specific IP for Access Gateway related traffic, this way standrad load balanced traffic will still work:

1) Create a secondary SNIP
2) Create an additional Load Balancer for the Store Front Servers (not AGEE)
3) Finally, create NetProfiles for Internal and External traffic. Use one SNIP for the Internal, and the other for the External Load Balancer. Details on how to do this here: http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-map/ns-lb-clienttraffic-usespecifiedsrcip-tsk.html

Use the following article to install and configure Storefront for internal use first.

Contents

1. Lab Environemnt

2. SSL Certificate Requirements

3. Service Group Definition

4. Virtual Server Definition

5. DNS Configuration

6. Testing

1. Lab Environemnt

The environment for this example configuration is as follows:

• CTX1.domlocal.net – 192.168.0.102/24 – Citrix XenApp 6.5 Server with Storefront 1.1 Locally Installed (in a production environment I would seperate Storefront onto it’s own server)
• CTX2.domlocal.net – 192.168.0.102/24 – Citrix XenApp 6.5 Server (as above!)
• Two-arm NetScaler HA Pair also using VMAC’s:
  • NS1 – 192.168.0.230/24
  • NS2 – 192.168.0.231/24

I have allocated 192.168.0.247/24 as the Load Balancer IP address for Storefront.

I’m using an Internal IP address for the Load Balancer, this could equally be an external IP address (an IP address that corresponds to a NIC other than the one that the NetScaler IP is served from).

2. SSL Certificate Requirements

I woud suggest you generate or purchase a SAN SSL certificate for the Load Balancer Virtual Server. In this lab environment I’m using the following Subject Names:

• ctx1.domlocal.net
• ctx2.domlocal.net
• ctx1
• ctx2
• ctx.domlocal.net
• ctx

As I plan on using the LB internally only an internal PKI/AD CS certificate is fine, even for my Access Gateway setup as it’s the endpoint connetcion SSL certificate that is key. Importantly, all internal devices trust the RootCA, hence the issued cert will work as required.

The image below shows I’m using a Common Name of ‘ctx.domlocal.net’ for the Certificate Subject name, with DNS Alternative Names (including ctx.domlocal.net and those listed above) :

3. Service Group Definition

Browse to Load Balancer > Service Groups and click ‘Add…’ at the bottom of the window.

Enter a name of Storefront_SSL and select SSL as the protocol, then for each server add the Storefront Server IP address with a port of 443.

Add the https-ecv montior then click OK to create the Service Group:

Under Advanced enable the Compression override:

Note; You don’t need to add the SSL Certificate to the Service Group, we’ll add it to the Virtual Server in a minute.

4. Virtual Server Definition

Browse to Load Balancer > Virtual Server and click ‘Add…’ at the bottom of the window.

Set Protocol as SSL and add an IP address, in this example 192.168.0.247:

Add the Service Group you just defined.

Under LB Method select Least Connection & under persistance set SOURCEIP:

Finally, bind the SSL Certificate you imported for the Storefront Server to the Virtual Server

5. DNS Configuration

Create a DNS A Record that matches the name of a SAN in your certificate; the IP address for the record is that of your Virtual Server. For this lab I created; ctx.domlocal.net 192.168.0.247

All receiver clients should be configured ot use this DNS name.

6. Testing

Confirm you can browse to the StoreFront URL (note that you will have to enter the complete URL, not just the FQDN). In this example I’d browse to http://ctx.domlocal.net/Citrix/CB-NetStoreWeb

Confirm that you can point the receiver client at the Load Balancer and it works as expected.

Create an account; enter the URL as https://ctx.domlocal.net

Logon (I haven’t configured SSO yet):

Test access to applications:

Contents

1. Obtain License File

2. Installation of XenApp 6.5

3. XenApp License Server Configuration

4. Configure XenApp License Settings

5. Create or Join a XenApp Farm

1. Obtain License File

It’s possible to get trial licenses for XenApp 6.5 – simply obtain a trial license key using Citrix XenApp Trial, then activate this key in the My Citrix console, much as per my NetScaler Deployment, albeit for XenApp as opposed to the NetScaler devices.

Just ensure you enter the license server hostname as per the way the name is displayed in Computer Properties on the server itself as the name is CaSe Sensitive.

2. Installation of XenApp 6.5

Now for the purposes of this article I’ll be creating a new, single server farm – something which you’re unlikely to deploy in produciton. That said this will give you a feel for the deployment of XenApp 6.5 and what to expect – I’ll point out the differences for adding additional nodes to this farm should you wish to do so.

Start the Autorun form the ISO file/DVD to begin the installation, unsurprisingly you need ot select ‘Install XenApp Server’

Click OK to install .NET 3.5 as part of the setup;

When the Citrix XenApp Server Role Manager starts up select ‘Add Server Roles’ – you’ll be getting familiar with this role manager console:

Select the correct edition for your license, in this case Advanced Edition:

Accept the license agreement to proceed:

We’ll chose not to install the Web Interface or Storefront as the 1.0 release is ‘broken’ as of the 1st of April (you can’t open the Storefront MMC console as it will generate a .NET error!). We’ll manually deploy Storefront 1.1 afterwards:

Select to install the Single-Sign-On Plug-in. In this example I WON’T be shating the XML service with IIS – there are pro’s and cons to doing this.

• • Pro – can leverage HTTPS XML communication due to IIS ISAPI plugin;
  • Con – requires IIS on Citrix Server (for this lab not a issue, but in production this may be an issue for you) 

Review the pre-requisite requirements and click Next

Click Install to begin the installation process:

Review the installation and click finish, then wait for the XenApp Role Manager window to load (may take a couple of minutes)

Click on ‘Reboot’ to initiate a reboot (surprise!), XenApp Role Manager will automatically load after the reboot:

Continue the installation by clicking ‘Install’

Once complete review progress and then click Finish.

XenApp Role Manager will load,  click on ‘Configure‘ next to License Server (ignore the screenshot where it contains Storefront, this was before I relaised the 1.0 version was broken!):

3. XenApp License Server Configuration

In order to finalise the XenApp server configuration you need ot configure the License Server – now this may not apply as you may have a License server capable of licensing XenApp 6.5, if not then this step will apply!

In the previous step we click ‘Configure’ on the License Server role, this will load the Configuration Utility, set a password you won’t forget and click OK – that was easy!

Now we’ll install the XenApp license you downloaded from My Citrix earlier. Form the Start menu browse to All Programs > Citrix > Management Consoles > License Administration Console, this will load the web interface as follows:

Click on Administration at the top right, enter admin and then the password you set earlier, then click on ‘Vendor Daemon Configuration’ form the menu on the left:

Browse for your downloaded license file and click Import License:

Hopefully the import will work, click OK then close the web browser.

Now open services.msc and restart the Citrix Licensing service, this will allow the License Server to add the licenses:

Finally open the License Administration Console and check that your licenses are listed:

We’re now able to proceed with the XenApp configuration.

 4. Configure XenApp License Settings

From XenApp Role Manager click ‘Specify Licensing’ next to XenApp, once completed this will allow us to configure licensing and then create/join a farm.

Confirm the license server FQDN and port number (27000 is default, so unless you changed it in the previous step of this article leave as-is)

Select the licensing model that’s right for your environment, in this case XenApp:

We’re now ready to create or join a XenApp farm!

5. Create or Join a XenApp Farm

From XenApp Role Manager select ‘Configure’ under the XenApp heading:

Choose to either create a new farm (you have no other XenApp servers of a suitable version) or join an existing farm, in this case select ‘Create a new server farm’:

Specify the new farm name and first XenApp Administrator account:

If you have a remote database you want to use choose this option (suggested for server farms – use a SQL cluster or database replication for resilience of this database!). For this lab I’ll get XenApp to install SQL Express locally:

Specify administartive credentials to deploy SQL:

Click Next to proceed:

Configure Shadowing permissions (will vary between organisations) – remember if you disable this now you cannot re-enable it!

Select Active Directory as the Central Store (unless you want to use an NTFS Share):

I this example I have configured the XML service to use port 8081, leave it as 8080 if you want to:

Finally(!) click apply, when the server is rebooted this configuration will then be applied. If you are joining an existing farm now is the time to clone your server! If you are creating a new farm with a local SQL database I wouldn’t suggest you clone this server, clone the subsequent server you join to the farm.

• • NetScaler : Load Balancing Exchange 2010
  • NetScaler : Configuring High Availability

What are VMACs are why use them?

VMAC’s are a useful addition in the NetScaler high availability tool set. In brief a VMAC creates a virtual MAC address that can ‘failover’ between devices. VMACs can be used to compliment the built-in HA or to create an active/active NetScaler pair.

By virtualising the MAC address there is no drop in network connectivity during failovers as the MAC address is shared across NetScaler devices – this means that the CAM table in the upstream switches does not require any update. As a result, failovers between NetScaler devices should be faster and less intrusive with regards to user sessions/connections.

VMAC’s work using a ‘priority’ – the higher priority determines ownership of the VMAC between devices. In a NetScaler HA configuration the priority of the VMAC between devices is the same, without HA it is configurable. For example if we had two NetScalers not using HA, NS1 and NS2, and a single VMAC configured on each we could set NS1 to have a priority of 100 and NS2 to have a priority of 90. NS1 would have ‘ownership’ of the VMAC because of its higher priority.

There are a couple of options when configuring VMAC’s:

1. If you are using the built-in NetScaler HA then you will continue to get Active/Passive HA
2. If you chose not to use the built-in HA feature then you can get Active/Active HA

One key benefit of using HA as well is that it synchronises the session tables across devices, without HA a failover of VMACs will disconnect Outlook Web Access users as their sessions is lost at failover, with HA sessions are kept, there is just a brief interruption to the user before they can carry on.

It is also possible to assign a VMAC to a single IP address, or group multiple IP addresses into a single VMAC. The first option allows for granularity when assigning ownership as you can assign each VMAC to a device of your choice whereas grouping the IP’s into a single VMAC reduces configuration but also reduces the options you have for splitting traffic. One option could be to group the IP’s into VMACs that represent services, so if you are load balancing multiple services via your NetScalers create a VMAC per service, i.e. Exchange 2010, Citrix Access Gateway etc.

How to Configure VMACs

If you are using the built-in NetScaler HA functionality you only need to perform this configuration on the Primary device.

In this example we’ll define 3 VMAC’s, one for each of the Exchange Virtual Servers we configured in the previous articles.

Create the VMACs

To configure VMACs browse to Network > VMAC and click ‘Add…’ at the bottom of the window:

• Enter a Virtual Router ID, I would normally chose the number from the last octet of the IP address you wish to assign the VMAC to. The choice is yours!
• Do not bind an interface to the VMAC
• Enable Preemption and Sharing
• Click OK

Perform these steps for each VMAC you want to create, if you are NOT using the built-in HA you will also need to define the same VMACs on the secondary device, using different priority. In this example I configures three VMACs (note the state of the VMAC will read INIT until an IP address is bound to the VMAC):

These will be used for the following IP addresses:

• • 192.168.209.240 – Exchange 2010 OWA Virtual Server IP
  • 192.168.209.241 – Exchange 2010 RPC Virtual Server IP
  • 192.168.209.245 – Exchange 2010 SMTP Virtual Server IP

One other thing to consider, if you wish to utilise Active/Active high availability on your NetScaler pair then you should set the VMAC priority accordingly on each device – i.e. some VMACs on the first device should have the highest priority and some VMACs on the second device should have a higher priority. For example, if I was not using HA then I could configure my VMAC as follows in order to share the workload between devices:

NS1

• • • VMAC 240 – Priority 100
    • VMAC 241 – Priority 90
    • VMAC 245 – Priority 100

NS2

• • • VMAC 240 – Priority 90
    • VMAC 241 – Priority 100
    • VMAC 245 – Priority 90

Remember this only applies if you are NOT using the built-in HA functionality.

Assign the VMACs to IP Addresses

Now we must assign each VMAC to an IP address; browse to Network > IPs.

1. Right-click an IP address and select ‘Open’
2. In the Virtual Router ID select the VMAC you wish to assign to this IP address

Perform this for each IP address, then confirm the state of the VMAC on each NetScaler device under Network >VMAC.

• In a built-in HA configuration the Primary device should has a state of MASTER, the secondary should have a state of BACKUP.
• In a non-HA configuration ensure that the MASTER and BACKUP state reflects the configuration you want.

In this article I’ll illustrate how to add a secondary NetScaler device and configure High Availability to ensure you have a resiliant NetScaler deployment.

Environment

Depending on how you decided to configure your NetScaler devices, either in a single-arm or two-arm topology, review the IP addressing information below as it is used in the configuration example.

Single Arm Topology

The following IP afddresses are assigned to the primary NetScaler:

• • 192.168.0.230 – NS1
  • 192.168.0.235 – NS1 MIP
  • 192.168.0.240 – SSL and EAS vServer
  • 192.168.0.241 – RPC vServer
  • 192.168.0.245 – SMTP vServer

A second NetScaler device, “NS2,” has been deployed (as per instruction in NetScaler Deployment) with the following IP addresses:

• • 192.168.0.231 – NS2
  • 192.168.0.236 – NS2 MIP

Two-Arm Topology

The following IP afddresses are assigned to the primary NetScaler:

• • 192.168.0.230 – NS1
  • 192.168.0.235 – NS1 MIP
  • 192.168.209.240 – SSL and EAS vServer
  • 192.168.209.241 – RPC vServer
  • 192.168.209.245 – SMTP vServer

A second NetScaler device, “NS2,” has been deployed (as per instruction in NetScaler Deployment) with the following IP addresses:

• 192.168.0.231 – NS2
• 192.168.0.236 – NS2 MIP 

 No additional configuration is required on the secondary NetScaler as the HA wizard will install any SSL certificates and configure the secondary NetScaler to be a carbon copy of the primary.

Pre-Reqs

In order to ensure that the HA pair functions as expected confirm that:

• The nsroot username and password match on both NetScaler devices

Single-Arm Differences

For single-arm deployments ONLY; disable (in the NetScaler configuration utility) any unused Interfaces – if you are using a single-arm topology the likelyhood is that you won’t be using one of the two NICs created by default.

HA Configuration

On the original NetScaler browse to System > High Availability, then click ‘Add…’ at the bottom of the Window to define the secondary NetScaler device:

• Enter the IP address of NS2; 192.168.0.231
• Ensure the “Configure Remote System to participate in High Availability Setup” option is enabled
• Enable the “Turn off HA Monitor if interfaces/channels are down

When you click OK on the above window you’ll be presented with the High Availability window showing the Primary NetScaler (NS1) in an ENABLED state, and the secondary NetScaler in a “IN PROGRESS” state – this is because the secondary NetScaler is being configured as per the Primary.

Leave some time for the HA pair to synchronise, the status of NS2 should then read “SUCCESS”: 

You can verify the configuration by inspecting the Monitors, Service Groups and Virtual Servers  now exist on the Secondary NetScaler device. Also, under Network > IPs the secondary NetScaler will list the IP addresses assigned to the Primary as “Passive”:

Note that you will be unable to configure HA Monitoring on any Interfaces, if you try you will receive an error “Operation not permitted” – this is by design on NetScaler VPX devices.

Finally, SAVE your configuration on NS1!

Failover Testing

Initiating a Failover

Now lets perform some failover testing; I disconnected the NIC in use on NS1 to cause a failover to NS2. The status of NS1 becomes UNKNOWN on NS2, and NS2 becomes the Primary device:

The IP Addresses also change from PASSIVE to ACTIVE on NS2:

If I run a constant ping when failing over the devices I drop around 2 packets:

What About Fail-back?

When NS1 is re-connected to the network it Synchronises with NS2 and will NOT automatically become the Primary device again. You can force failback by right-clicking NS1 under System > High Availability and selecting Force Failover.

Alternatively use the following command from the console to force a failover: forcefailover

Again, you’ll drop a couple of packets during the failover.

Using VMACs with High Availability

It is also possible to utilse VMAC’s with HA; using VMACs ensures that there is no need to update the CAM table in any switches to which the NetScaler connects to. This will, in all likelyhood, mean that fewer packets are dropped during failover events.

Article to follow on configuring VMAC’s.

Troubleshooting HA

From the command line use the following command to view the HA status of each NetScaler: show ha node

This guide assumes you have deployed the NetScaler VPX and configured an IP address – for information on how to do this see the NetScaler Deployment Article.

Contents

1. One-Arm or Two-Arm Topology?

2. Environment Specifics

2.1 Two-Arm Differences

3. Enable Basic Features

4. Enable Advanced Features

5. Confirmation of USNIP Setting

6. Create, Export and Import the Exchange Certificate

6.1 Creating and Exporting the Certificate

6.2 Importing the Certificate to the NetScaler

6.3 Installing the Certificate

7. Configure Exchange Servers

7.1 Configure IIS Virtual Directories

7.2 Configure RPC Ports

8. Configure Service Monitors

8.1 RPC EP-MAP

8.2 RPC Address Book

8.3 SMTP

9. Define Service Groups

9.1 SSL

9.2 RPC

9.3 SMTP

10. Define Virtual Servers

10.1 SSL

10.2 SMTP

10.3 RPC

10.4 EAS

10.5 Two-Arm Differences

11. Configure the HTTP to HTTPS Redirect

12. Final Steps

12.1 Create DNS Entries

12.1.1 Two-Arm Differences

12.2 Define and Assign the CAS Array in Exchange 2010

12.3 Save the Configuration!

13. Test Functionality

13.1 OWA

13.2 Outlook Client

14. Configuring High Availability

1. One-Arm or Two-Arm Topology?

• A one-arm topology is the most simple design and is suitable for most environments where IP routing (Layer 3) switches or routers link client and server subnets.
• A two-arm topology can be used to obscure servers by sitting them ‘behind’ the NetScaler devices, form a security perspective all client traffic must pass through the NetScaler in order to reach the server. Arguably this may or may not improve security.

A one-arm topology is probably easiest to implement as you dont need to re-cable or redefine any networks in order to create the second network required by the NetScaler for a two-arm deployment. It is definately the quickest way to get a NetScaler into a production Network with minimal changes. That said, your environment may demand a two-arm topology, for example if you want to use VMACs this requires Promiscuous mode to be enabled on the vSwitch, this is not idela on a large-scale subnet that all servers share, so it’s better to define a seperate subnet for VMACs/Virtual Servers to use.

There is no need for either topology to use a public network address space on any interfaces, NAT is a perfectly reasonable alternative to what is depicted in any of the design scenarios in the Citrix eDocs.

For load balancing most Exchange 2010 environments that consist of CAS/HT and Mailbox servers either topology will work.

2. Environment Specifics

You’ll need to know the IP addresses of your CAS and HT servers for the configuration. In the environment for this guide I’m using multi-role CAS and HT servers witht he following IP addresses:

• Exch1.domlocal.net – 192.168.0.191/24
• Exch2.domlocal.net – 192.168.0.192/24

I have deployed a single NetScaler device, NS1 which is configured with IP address 192.168.0.230/24.

You’ll also need a couple of IP addresses for the Load Balanced services (clients will connect to these addresses). For the purposes of this guide I’m using:

• 192.168.0.240 – SSL and EAS
• 192.168.0.241 – RPC
• 192.168.0.245 – SMTP

Using multiple IP addresses also facilitates interesting Active/Active configurations using VMACS which I’ll cover in a later guide.

All servers and clients are a member of the domlocal.net domain, using IP’s from my chosen address space – you environment will be different so adapt scripts, commands, IP Addresses and names accordingly.

2.1 Two-Arm Differences

So here are the first differences if you decide to go with a two-arm configuration; first create an assign VLAN’s to all Network Interfaces. By default VLAN1 will be untagged on Interfaces 0/1 and LO/1 – don’t worry too much about the VLAN ID here, it can match you environment, it can also be random as it is ‘untagged’ any traffic entering the Interface or leaving it will not actually be tagged with the VLANID you select.

You need to deciede upon an address space, for the purposes of this article I’ll use 192.168.209.0/24. Importantly this is a routable subnet, both clients and servers can access this address space, unrestricted.

Browse to Network > VLANs and then select ‘Add…’ at the bottom of the window:

• Enter a new VLAN ID, in this example ‘2’
• Select the Interface that you wish to bind the VLAN to, in this example 1/1

3. Enable Basic Features

Our Exchange 2010 Load Balancing configuration will require several core features that the NetScaler supports; Load Balancing (!), Rewrite, Compression, SSL Offloading and Content Switching.

Browse to System > Settings > Enable Basic Features

Enable the required features and select ‘OK.’

4. Enable Advanced Features

We’ll be  leveraging the Responder feature so we must enable this.

Browse to System > Settings > Configure Advanced Features

Ensure that the Responder feature is enabled.

5. Confirmation of USNIP Setting

This configuration requires that the “Use Subnet IP” mode is enabled. Browse to Settings > Configure Modes to verify this:

6. Export Exchange Certificate

As we’re using the SSL Offloading feature we need to import the SSL certificates that we would have used on the Exchange Client Access Servers. It may even be necessary to generate a valid certifiate.

6.1 Creating the Certificate and Exporting

Use the following code to generate an Exchange SSL certificate with the following Subject Alternate Names (SANs) – your SANs will vary:

• casarray.domlocal.net
• mail.cb-net.co.uk
• autodiscover.cb-net.co.uk
• exch1.domlocal.net
• exch2.domlocal.net
• exch1
• exch2

New-ExchangeCertificate -FriendlyName 'CAS Array' -GenerateRequest -PrivateKeyExportable $true -KeySize '2048' -SubjectName 'C=GB,S="Cambridgeshire",L="Cambridge",O="CB-Net",OU="IT",CN=casarray.domlocal.net' -DomainName 'exch1.domlocal.net','exch2.domlocal.net','casarray','casarray.domlocal.net','exch1','exch2','mail.cb-net.co.uk','domlocal.net','autodiscover.cb-net' -Server 'EXCH1'

You’ll need to either complete this request using a local Active Directory Certificate Services CA, or a third-party CA, when you have completed the request on all Exchange Servers you intend to Load Balance export the Certificate, with Private Key in PFX format ready to import to the NetSCaler device.

To complete the request open up the Exchange Management Console, browse to Server Configuration and select the server you generated the Certificate Request on. Right-click the Certificate Request that is Pending and select “Complete Pending Request…”

Enter a path to the completed certificate request (either provided by the third party or downloaded form your AD CS CA):

Completed the request by clicking ‘Complete’

Use the following Exchange Shell command to identify the thumbrint of the Certificate you wish to export

get-exchangecertificate | ft

Now export the certificate using the following commands, when prompted for credentials enter a random username (this is not used) – the password is important though!:

$cert = Export-ExchangeCertificate -Thumbprint <from previous output> –BinaryEncoded:$true -Password (Get-Credential).Password
Set-Content -Path "C:ExportCert.pfx" -Value $cert.FileData -Encoding Byte

6.2 Importing the Certificate to the NetScalers

Browse to SSL and select  “Import PKCS#12”

Enter a name for the certificate “Exc2010-CASArray_Cert,” browse for the PFX file (if you used the commands earlier this will be C:ExportCert.pfx) and enter the password you used when exporting it.

6.3 Install the SSL Certificate

The last step for preparing the SSL certificate for use is to Install it. Browse to SSL > Certificates and select ‘Install…’  at the bottom of the window.

• Enter a Certificate Name of Exc2010-CASArray
• Browse for the Certificate File Name
• Browse for the Certificate Private Key File Name
• Enter the password you used when you exported the Certificate form the Exchange Servers
• Enable the Notify Period, enter 14 (for 2 weeks notification)
• Click Install

7. Configure Exchange Servers

There are a few jobs that must be completed in order to successfully offload SSL.

7.1 Configure IIS Virtual Directories

When you  deploy Exchange 2010 connections to Exchange related IIS content all require SSL. As we are offloading the SSL we must allow the NetScalers to connect using HTTP. The following commands, obtained from here automate this configuration:

Import-Module webadministration

Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/OWA"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/ECP"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/OAB"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/EWS"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/Microsoft-Server-ActiveSync"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/Autodiscover"

iisreset /noforce

7.2 Configure RPC Ports

Run the following PowerShell commands on all CAS servers you intend to load balance using the NetScaler. This will set the RPC port to 59600 and the RPC Addressbook port to 59601:

New-Item -Path "HKLM:SYSTEMCurrentControlSetservicesMSExchangeABParameters"
New-ItemProperty "HKLM:SYSTEMCurrentControlSetservicesMSExchangeABParameters" -Name "RpcTcpPort" -Value 59601 -PropertyType "String"

New-Item -Path "HKLM:SYSTEMCurrentControlSetservicesMSExchangeRPCParametersSystem"
New-ItemProperty "HKLM:SYSTEMCurrentControlSetservicesMSExchangeRPCParametersSystem" -Name "TCP/IP Port" -Value 59600 -PropertyType "DWord"

Restart the Exchange Server when complete, then run the following commands to ensure the server is listening on the correct ports:

• netstat -an | find “59600”
• netstat -an | find “59601”

8. Configure Service Monitors

Monitors are what the NetScaler uses to confirm services on remote servers are actually up – you wouldn’t want the NetScaler to try and use an Exchange Server that has crashed, so Monitors are used to verify remote service functionality; we need 4 Monitors for our Load Balanced Exchange 2010 environment.

Browse to Load Balancing > Monitors then click ‘Add…’ at the bottom of the window.

8.1 RPC EP-MAP

The first Monitor will be called ‘Exc2010-RPC-EPMAP‘ – this is used to verify TCP port 135 connectivity on the Exchange 2010 CAS’. This port is used to negotiate the RPC port that the client will connect with.

• Select a Type of TCP
• Enter a Destination port of 135

8.2 RPC

The next Monitor will be called “Exc2010-RPC“, this will be used to verify TCP port 59600 connectivity on the Exchange 2010 CAS’; this port is used for Outlook RPC connections:

• Select a Type of TCP
• Enter a Destination port of 59600

Address Book

The next Monitor will be “Exc2010-RPC-AddressBook” – this will monitor TCP port 59601 which is the client RPC connection to the Address Book service.

• Select a Type of TCP
• Enter a Destination port of 59601

8.3 SMTP

The final Monitor will be called “Exc2010-SMTP” – unsurprisingly this will monitor TCP port 25 on the Hub Transport servers.

• Select a Type of SMTP

Then select the ‘Special Parameters’ tab;

• Browse for the  nssmtp.pl script
• Enter 127.0.0.1 as the Dispatcher IP
• Enter 3013 and the Dispatcher Port

For SSL/HTTPS service verification there are built-in NetScaler Monitors we can use rather than defining new ones.

9. Define Service Groups

Service Groups represent the Exchange 2010 features we want to Load Balance using the NetScalers. You could define individual Services rather than Service Groups, however you would have to create an individual Service per Exchange 2010 server, rather than a single Service Group that contains multiple servers. The choice is yours, but the latter seems more logical to me

Browse to Load Balancing > Service Groups.

9.1 SSL

Our first Service Group will be “Exc2010-SSL” – this will represent all HTTP (not that Client connections to the NetSCaler will be HTTPS, those from the NetScaler to the Exchange Servers they will be HTTP – this is HTTPS offloading.)

• Select a Protocol of HTTP and add “IP Based” members, one for each Exchange 2010 CAS using port 80 (not 443!)

Select the Monitors tab and ad the http-ecv monitor:

Under the Advanced tab enable the “Settings” Override Global and select the ‘Compression‘ override:

9.2 RPC

The second Service Group is named Exc2010-RPC. This is service will listen on all TCP ports due to the very nature of RPC. Select a protocol of TCP and then, as per the previous server group, add your IP Based members, with a port of *

 Select the Monitors tab and add the three RPC monitors we created earlier, Exc2010-RPC, Exc2010-RPC-EPMAP and  Exc2010-RPC-AddressBook:

SMTP

Our final service group is Exc2010-SMTP. Protocol is TCP, add IP Based Members with a Port of 25:

Add the Exc2010-SMTP Monitor we created earlier:

10. Define Virtual Servers

We now have all of the foundations in place for our Exchange 2010 Load Balancing, it’s now time to create the Virtual Servers to which clients will connect to.

If you are using a two-arm topology ensure you read the notes at the end of this section…

Browse to Load Balancing > Virtual Servers.

10.1 SSL

Click ‘Add…’ at the bottom to create the first Virtual Server “Exc2010-SSL”

• Protocol is SSL
• Port is 443
• IP Address is 192.168.0.240 (this is a new IP Address, as defined in the first section of this article)

Under Service Groups tick the Exc2010-RPC Service Group we created earlier:

We need to create a rewrite for clients that try to connect directly to this IP address or the root directory of this IP address (i.e. http://192.168.0.240 instead of http://192.168.0.240/owa) in order to direct the to the OWA Virtual Directory. To do this:

• Select the “Policies” then Rewrite (Request), then click Insert Policy near the bottom of this window.

• Select New Policy, give the policy a name of “Exc2010-OWA-Rewrite“
• Next to ‘Action’ click ‘New’ to define a new Rewrite Action

• Name the Rewrite Action “Exc2010-OWA“
• Select a Type of ‘REPLACE’
• Under ‘Expression to choose target text reference’ enter; HTTP.REQ.URL
• Under ‘String expression replacement text’ enter (including quote marks); “/owa” then click ‘Create’

Finally, under the Rewrite Policy Expression enter; HTTP.REQ.URL.EQ(“/”) then click ‘Create’

The Policies tab, under Rewrite (Request), should now look as follows:

Now select the Method and Persistence tab;

• Under LB Method select  “Least Connection”
• Under persistence select “COOKIEINSERT”

Under SSL Settings select the SSL certificate you imported earlier:

10.2 SMTP

We’ll now create the next Virtual Server, Exc2010-SMTP. Add another virtual server named “Exc2010-SMTP”

• Protocol is TCP
• Port is 25
• IP Address is 192.168.0.245 (this is another new IP Address, as defined in the first section of this article)

Under Service Groups select the Exc2010-SMTP Service Group we created earlier:

Under Method and Persistence select the Round Robin LB Method and Persistence Type of NONE:

10.3 RPC

We’ll now create the Virtual Server for RPC connections, EXC2010-RPC. Add another virtual server named “Exc2010-RPC”

• Protocol is TCP
• Port is *
• IP Address is 192.168.0.241 (this is another new IP Address, as defined in the first section of this article)

Under Service Groups select the Exc2010-RPC Service Group we created earlier:

Under Method and Persistence select the Least Connection LB Method and SOURCEIP for Persistence:

10.4 EAS

Now for the final Virtual Server, Exc2010-EAS. This is an odd configuration tat you wont find in the NetScaler Exchange 2010 documentation, however it was put together by a colleague in order to ensure that Exchange Active Sync connections receive the correct persistence type (Exchange Persistence Types)

Add another virtual server named “Exc2010-EAS”

• Protocol is SSL
• Port is 445
• IP Address is 192.168.0.240 (this is another new IP Address, as defined in the first section of this article)

You may be wondering why we’re using port 445 as Exchange CAS/HT servers don’t listen on this port for Exchange Active Sync.

This is where the NetScalers come in. We can setup a Virtual Server on any IP, on any port, then bind it to a real service on a remote server that is on a different IP address and port. We’ll configure a redirect that points any Exchange Active Sync requests to this Virtual Server which in turn applies the correct Persistence type to the client connections and then sends all requests back to the CAS IIS instances running on port 80. Still confused? … just bear with me for now!

Under Service Groups select the Exc2010-SSL Service Group:

Under Policies select Responder, then click ‘Insert Policy” > New Policy – here we’ll create the redirect that tells clients to use the EAS Virtual Server for Active Sync data. We use a responder because Responder Rewrite that a Responder should be used to redirect a client, not a rewrite.

• Name the policy “Exc2010-EAS-Responder”
• Next to Action click New

• Name the new Responder Action “Exc2010-EAS-ResponderAction”
• Type should be set to “Respond with”
• Target should be set to: http://mail.cb-net.co.uk:445/Microsoft-Server-Active-Sync
• Tick the ‘Bypass Safety Check’ option then click Close

• Under Expression enter: HTTP.REQ.URL.ENDSWITH(“/Microsoft-Server-Active-Sync”)
• Click Create to complete the responder action.

Your completed Policy should look as follows:

Under Method and Persistence select RULE and enter the following rule text: HTTP.REQ.HEADER(“Authorization”)

Under “SSL Settings” add the certificate we used in the Exc2010-SSL Virtual Server:

10.5 Two-Arm Differences

In a two-arm configuration you’ll need to ensure you use IP addresses from your second subnet for all Virtual Servers; using the subnet I selected earlier (192.168.209.0/24) I would suggst:

• SSL / EAS – 192.168.209.240
• RPC – 192.168.209.241
• SMTP – 192.168.209.245

IP Addresses are the only variation in the configuration required for a two-arm setup.

11. Configure the HTTP to HTTPS Redirect 

In order to ensure that clients that attempt to browse via HTTP are automatically rediected to HTTPS I’ve used Content Switching. The method supplied in the original Citrix deployment document is ‘OK’ however it replies upon a Virtual Server that is in a down state that has a redirect setup on it. Beacuse the Virtual Server is down the redirect is actioned. To me this looks a bit crap, so I opted to use Content Switching as detailed below:

Browse to Content Switching > Virtual Servers (note we enabled Content Switching at the beginning of this article)

Click ‘Add…’ at the bottom of the Window

• Name: Exc2010-HTTP-HTTPS
• IP Address 192.168.0.240
• Under Policies select Responder
• Select ‘Insert Policy’ at the bottom of this window

• Name the Responder Policy ‘Redirect HTTPS’
• Under expression enter: true
• Next to Action click New

• Name the Responder Action ‘Redirect HTTPS’
• Enter target as: “https://”+HTTP.REQ.HOSTNAME+HTTP.REQ.URL
• Select the ‘Bypass Safety Check’ option and click Create on both the Create Action and Create Policy windows

Your new Content Switching Virtual Server is ready to redirect!

12. Final Steps

12.1 Create DNS entries

Create the following DNS entries:

• casarray.domlocal.net – 192.168.0.241 (points to the RPC Virtual Server)
• mail.cb-net.co.uk – 192.168.0.240 (points to the SSL Virtual Server, use NAT to allow external clients connect to this for OWA)

12.1.1 Two-Arm Differences

Obvisouly you used different IP addresses for your two-arm configuration, these should be reflected in your DNS entries:

• casarray.domlocal.net – 192.168.209.241 (points to the RPC Virtual Server)
• mail.cb-net.co.uk – 192.168.209.240 (points to the SSL Virtual Server, use NAT to allow external clients connect to this for OWA)

12.2 Define the CAS Array in Exchange 2010

So you are probably wondering how you users will actually use the load balancers… thats where the Exchange 2010 Client Access Array comes in. Essentially we define a CAS Array and bind it to a mailbox database, therefore all mailboxes within the mailbox database will (via Autodiscover) use the CAS Array. If you manually configure a profile you must use the Client access Array once it has been assigned to the mailbox database.

A design consideration when deploying Client Access Array’s is that there can only be one CAS Array per AD DS site.

Use the following Exchange Shell commands to create a CAS Array named UK-CASArray in Exchange 2010, with a Fully Qualified Domain Name of casarray.domlocal.net assigned to the Active Directory Site Default-First-Site-Name (change these to suit your environment!):

New-ClientAccessArray –Name “UK-CASArray” –Fqdn “casarray.domlocal.net” –Site “Default-First-Site-Name”

Assign the new CAS array to a Mailbox Database, making sure you change the FQDN and Mailbox Database name to match your environment:

Set-MailboxDatabase DAGDB01 –RpcClientAccessServer “casarray.domlocal.net”

12.3. Save you NetScaler Configuration!

Don’t get caught-out, ensure you save the NetScaler configuration!

13. Test Functionality

Create a new mailbox in the Mailbox Database to which you assigned the CAS Array.

13.1 OWA

Test OWA functionality from a machine on the domain by browsing to http://mail.cb-net.co.uk – this should redirect to HTTPS and present the OWA login page. Test you can also login as the user you just created.

13.2 Outlook Client

Configure the Outlook Client on a domain machine, using casarray.domlocal.net as the Exchange Server and the mailbox user you just created:

14. Configuring High Availability

The NetScaler Single-Arm HA details how to configure HA for a single-arm NetScaler Deployment.