Configure Citrix NetScaler 10.0 for High Availability

Having configured a few Citrix NetScaler 9.x appliances in high availability in the past, I noticed that I haven’t actually written a blog post so this serves to demonstrate the steps required to configure a pair of NetScaler 10.0 in HA for redundancy.  The appliances I’ll be using for the demonstration are NetScaler VPX 1000s hosted on VMware vSphere hosts.

Note that if you would like to read more into Citrix’s documentation, you can do so in the following URL:

Configuring High Availability
http://support.citrix.com/proddocs/topic/ns-system-10-map/ns-nw-ha-cnfgrng-ha-con.html

Preparation and Prerequisites

Prior to beginning the configuration, you’ll need to ensure you have the following:

Licenses:

As per the following blog post:

NetScaler Licensing Dissected
http://blogs.citrix.com/2011/04/12/netscaler-licensing-dissected/

… two NetScaler licenses are required for the an HA configuration so make sure you’ve allocated and downloaded 2 licenses for the NetScaler HA pairs.

NetScaler IP Addresses and Names:

Decide on whether you’re configuring a single or two armed configuration and configure each node’s IP addresses as required.  For the purpose of this example, we’ll be using a 2 armed configuration so the IP addresses will be as follow:

Node 1
Name – SVR-CNS-01
NetScaler IP Address – 172.16.36.65
Mapped IP Address – 172.16.36.66

Node 2
Name – SVR-CNS-02
NetScaler IP Address – 172.16.36.68
Mapped IP Address – 172.16.36.69

SSL Certificates:

If you’re publishing a Citrix Web Interface Server for remote access clients, ensure that you have requested and installed a SSL certificate onto the first node appliance.

Access Gateway Virtual Server IP and Servers:

If you’re going to be publishing a Citrix Web Interface Server for remote access clients, configure the virtual IPs you’ll be using as well as the virtual server:

Remove Unnecessary Default Routes:

As this is a 2 armed topology, a default route would be added for the internal and external leg segments which would cause incorrect traffic routing so remove the default route for the internal leg’s network and added static routes for networks in your internal network that you would like the NetScalers to access.

Configure Remote Pair

With all of the prerequisites configured, begin by logging onto your first node with the virtual server configured and navigate to System –> High Availability:

Click on the Add button:

Enter the NetScaler IP of the second node:

Then click on the OK button to allow the first node to initiate an HA pairing with the second node:

Once the pairing completes successfully, you would be presented with the following message:

High Availability pair has been setup.

For functional High Availability setup, please make sure that RPC passwords are same for both primary and secondary nodes.

You should also now see the second node listed in the GUI:

Ensure that the Synchronization State is labeled as SUCCESS to validate the second node is synchronized with the settings:

With both nodes paired in a HA configuration, you should be able to navigate to Network –> IPs and be able to see the same NetScaler, Mapped and Virtual IP addresses:

You’ll also notice that when you log onto the secondary node’s management GUI, you’ll receive the following message:

You are connected to a secondary node; configuration chanes made in this session will not be propagated to, or saved on, other nodes (primary node IP address)

With this in mind, ensure that you don’t accidentally make any changes on this node.

Now that we’ve verified that the pairing was a success, proceed with saving the configuration on the active node:

Forcing Failover

It’s always important to test your HA pair now that you’ve completed the configuration and there are 2 ways to do this.  The first way is to use the Force Failover button in System –> High Availability:

The second method is to actually reboot the NetScaler and I recommend to try doing both because your NetScalers are most likely not in production and now is probably the best time to test this.  You’ll notice that the failover is almost instantaneous when using the Force Failover button while actually rebooting the appliance will show the Master State and Node State and others as UNKNOWN:

As soon as the rebooted node comes back online, the UNKNOWN states should revert back to normal.

Through the testing that I’ve done with several NetScalers, I’ve noticed that I would only lose 1 ping packet when performing a failover regardless of the method.  I won’t go as far as to say that everyone would experience the same but the failover is fairly quick.

Extra Items to Check

One of the first items I check at this point is that the virtual servers are still up as I’ve had a few situations where both nodes would lose the certificate I installed which leaves you with your virtual servers in a Down state:

If this is the case, you should be able to regenerate the certificate with the keys you previously used.  See the following blog post if you need more information:

Recreating SSL certificate on a Citrix NetScaler VPX 1000 with the private key and CA issued certificate crt file
http://terenceluk.blogspot.com/2012/06/recreating-ssl-certificate-on-citrix.html

VMware View 5.1.1 printer redirection with ThinPrint no longer works after upgrade from 5.0

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Update December 17, 2012

I received an update from the engineer I was working with on this case today to inform me that the new 5.1.2 agent was out and to try it and it looks like upgrading the agent:

VMware View Agent Version: 5.1.1.799444

… to:

VMware View Agent Version: 5.1.2.928164

… fixes the issue as the TPAutoConnect.exe no longer crashes.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Just last weekend on Sunday December 9, 2012 was when I had a scheduled VMware View 5.1.1 – Build 799444 upgrade:

… for a client that was still on VMware View 5.0 and as well as the upgrade went, I was informed by the client on Monday morning that their remote users were no longer seeing their local printers in their home office.  This prompted me to log into my own virtual desktop from remote to have a look and I immediately noticed that I too as well did not see the local printers I had available from my laptop.  Subsequent logins would sporadically show the following window:

ThinPrint AutoConnect component

ThinPrint AutoConnect component has stopped working

Windows can check online for a solution to the problem.

Check online for a solution and close the program

Close the program

Problem Event Name: APPCRASH

TPAutoConnect.exe

Application Version: 8.8.734.1

Browsing through the event logs also showed the following event logged upon restarting the virtual desktop and logging on:

Faulting application name: TPAutoConnect.exe, version: 8.8.734.1, time stamp: 0x4f97fe6d

Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000

Exception code: 0xc0000005

Fault offset: 0x00000000

Faulting process id: 0x1530

Faulting application start time: 0x01cdd734dcd7ce35

Faulting application path: C:\Program Files\VMware\VMware Tools\TPAutoConnect.exe

Faulting module path: unknown

Report Id: 215ff1d9-4328-11e2-a1e8-005056be7ab3

Doing a few searches on Google revealed one or two forum posts with other users complaining but no solution so once I realized this was probably something I couldn’t personally troubleshoot and fix, I opened up a support ticket.  It took a few days until I was able to speak with the support engineer assigned to my case and it looks like this was a known issue with VMware View 5.1.1 with the VMware View Agent 5.1.1.799444:

I was asked to review the following KB:

Printer redirection fails when using PCoIP with the View 5.1.1 Agent
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2036725

… which I was sort of surprised that I didn’t come across but then realized that it was dated December 10th (one day after the upgrade).

I have since uploaded the VMware View Agent logs to VMware via the following KB:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1017939

… so that the engineer can confirm.  From what I was able to ask the engineer during our short phone conversation, it doesn’t look like I can downgrade the VMware Agent to fix this and the only workaround is to use RDP instead of PCoIP.  I have since done a test by switching the protocol to RDP and the printer redirection began to work.

Disabling Outlook 2010’s: “The Windows Search Engine is currently disabled.” warning with Group Policy

As most VMware View administrators know, VMware’s Windows 7 Optimization Guide:

VMware-View-OptimizationGuideWindows7-EN.pdf

… suggests that the Windows Search service should be disabled and executing any of the provided scripts will do so:

What happens when this service is disabled is that Outlook 2010 begins to display the following warning window:

Microsoft Outlook 

The Windows Search Engine is currently disabled. Outlook will not be able to provide fast search results using the Instant Search functionality unless this service is running.

Do not show this message again

The problem I’ve continuously encountered with VMware View environments is that users will misinterpret this message as search not being available in their Outlook mailboxes thus generating support calls to the service desk.

I searched through the available settings in the Office 2010 ADM template but was unable to find a setting that prevented this window from displaying to users but as it turns out, we can actually use the following registry key to accomplish this:

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Options\General

Name: PONT_STRING
Type: REG_SZ
Data: 53

**Note that some registries may not have the General key as shown here:

… but you can manually create it by right clicking on the Options key then select New –> Key:

With the General key created, proceed with creating the new String Value as such:

Name the key as PONT_STRING and set the value to 53:

With this key present, Outlook will no longer prompt you with the warning message:

Using Active Directory Group Policy to Create the Key

Although I prefer modifying the master image to prevent this warning from being presented to the user because I never liked having too many policies applied to users when they log in, you can’t actually modify HKCU on the master image because the key belongs to the logged on user and the only way to do that is to use a local policy so in this situation, it would make more sense so the following demonstrates how to create the GPO.

Begin by creating a new Group Policy in Group Policy Management Console and edit the policy:

Navigate to User Configuration –> Preferences –> Windows Settings –> Registry and create a new Registry Item:

Fill in the fields as follow:

Action: Create
Hive: HKEY_CURRENT_USER
Key Path: Software\Microsoft\Office\14.0\Outlook\Options\General
Value name: PONT_STRING
Value type: REG_SZ
Value data: 53

**Note that you will probably not find the key by clicking on the Key Path browse button because Office 2010 is most likely not installed so instead of browsing, copy and past the path into the Key Path field.

With the policy configured, proceed with applying it to the user objects of users that you want to prevent this warning message from displaying.

Can VMware View Agent 5.1 connect to a 5.0 Connection Server?

I’ve recently been asked a few times over the last 2 months as to whether it is possible to update the VMware View Agent to 5.1 if the View Connection server was still at version 5.0 because as most of us know, a VMware View Client 5.1 can connect to a View Connection Server 5.0.  I haven’t actually tested this because as the VMware View 5.1 upgrade guide (view-51-upgrades.pdf) states in the Prerequisites section on page 47:

Verify that at least one View Connection Server instance in the replicated group has been upgraded to
View 5.1. View Connection Server must be upgraded to version 5.1 so that the secure JMS pairing
mechanism can work with View Agent 5.1.

Since I have an environment I’m upgrading this weekend, I figure I’d do a quick test to see what error is thrown and the following is what you’ll see if you decide to recompose a desktop that has the VMware View Agent 5.1 in a VMware View environment with the Connection server still at 5.0:

Error

Not network communication between the VDM Agent and Connection Server. Please verify that the virtual desktop can ping the Connection Server via FQDN.

Hope this helps anyone looking for a quick answer as to whether this was possible.

Upgrading VMware View Client from 5.0 to 5.1 with Active Directory Group Policy

To follow up one of my previous posts:

Extracting the msi file from VMware View Client installation executable and installing it via Active Directory Group Policy
http://terenceluk.blogspot.com/2012/02/extracting-msi-file-from-vmware-view.html

… a few of my colleagues asked me whether we could do the same when upgrading Windows based VMware View Client from 5.0 to 5.1, whether settings such as the Connection Server:

… would be retained if this was used and the answer is yes.  I’ve used this method to update old Windows XP desktops a few times and haven’t had any issues with it.  To do so, begin by executing the VMware View Client install:

Wait till the following installation wizard window is displayed:

Then proceed to open the Run window and open the %temp% folder as such:

From within the temporary files folder, look for a folder named with a GUID and followed by a ~temp:

C:\Users\tluk\AppData\Local\Temp\{1AA39F1E-0098-41f9-9DDC-9CB7B47C9441}~setup

Copy all of the files:

• Core.cab
• instmsiw.exe
• ThinPr~1.cab
• TSSO.cab
• USB.cab
• vcredist_x64.exe
• vcredist_x86.exe
• VMware View Client64.msi

… into a network share where your desktops can access.

Log onto a domain controller and open up the Group Policy Management Console and create a new policy:

Name the policy appropriately:

Edit the newly created policy and navigate to the node Computer Configuration –> Policies –> Software Settings –> Software installation and then right click in the right window, select New –> Package:

Within browser, navigate to the VMware View Client64.msi file via the UNC path:

Once you’ve clicked on the Open button, you’ll be prompted with the following window. Select the Assigned radio button and click OK:

As shown in the screenshot, the msi package has now been published:

Proceed with assigning this policy to an OU containing the physical Windows desktops’ computer objects and either wait for replication or force it with gpupdate /force and then reboot the computer.  Note that this is a computer policy that is applied upon start up of the desktop rather than a user policy which is installed when a user logs in.  Most environments I work in have a few extremely old desktops that take forever to load and so a computer policy works a bit better.  For more information about switches allowed with the MSI file, see the following document’s page 117:

VMware View Installation
http://pubs.vmware.com/view-51/topic/com.vmware.ICbase/PDF/view-51-installation.pdf