Creating a NetScaler in Azure Resource Location for your Citrix Cloud

Background Information

The old limitations of using a single IP on an interface for a NetScaler Gateway solution in Azure are no more.

You may have heard that now the NetScaler is able to have one interface with multiple IP addresses, one interface with one IP address, Multiple interfaces with single IPs and Multiple interfaces with multiple IPs. What does this mean?

Well, the old methods of putting a load balancer in front to NAT 443 addresses to 4443 gateway IPs is no longer required. You can still use it if you wish, and will need the Azure Load Balancer if doing the HA setup.

I can have multiple IPs and assign them to a single NIC on the NetScaler Azure VPX. This is known as multi-IP architecture.


In Azure, assigning multiple IP’s to an interface looks like this:

Above, you can see that I have a single IP address “ipconfig1” which is my NetScaler NSIP. (I removed the public IP that was assigned).

In a multi-NIC, multi-IP Azure NetScaler VPX deployment, the private IP associated with the primary (first) IPConfig of the primary (first) NIC is automatically added as the management NSIP of the appliance. The remaining private IP addresses associated with IPConfigs need to be added in the NetScaler appliance as a VIP or SNIP.

You can see that I have added a SNIP IP and my Gateway IP with a internal and public IP.

So why am I focusing on having a Gateway in Azure?

Well, something I stress about going to the Citrix Cloud is having a NetScaler and StoreFront in your Resource location. Why?

You lose Cloud access and you lose the ability to broker connections to your VDA machines in Resource locations. This is about having a way to access your resources in that event.

You will still be able to access and broker connections in your resource location because the Citrix Connector Servers also act as proxy brokers, and they contain the Local Host Cache. (Please check out my webinar at the Virtual Expo for more on this.) So, even placing one NetScaler Gateway appliance in an Azure Resource location acts as a bit of resilience for your Citrix Cloud solution.

Typically, it is more likely that a customer’s internet connectivity will be interrupted (which could be due to 3rd party factors such as ISP or power problems), versus the highly reliable and redundant Citrix Cloud management plane running in Azure.

There are plenty of articles on creating NetScalers in a traditional environment and I will highlight some here by some other fellow CTPs:


The art of building a NetScaler in Azure is less known. Hopefully, this article will provide some enlightenment, and you can start forming your resilient Citrix Cloud solution using an Azure resource location.


Before you create your NetScaler in Azure, here are some prerequisites you should know about.

  • Create a resource Group for your NetScaler Instance. (A resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group.)

TIP – In a Citrix Azure world, I put the NetScalers in one resource group, Infrastructure in another and VDAs in a separate Resource Group.

Generally, add resources that share the same lifecycle to the same resource group so you can easily deploy, update, and delete them as a group.

Also something to keep in mind, for compliance reasons, is that you may need to ensure that your data is stored in a particular region.

More on Resource Groups can be found here –

  • Pre-create PIP (Public IP) for the gateway and the NSG (Network Security Group) in your appropriate Resource Group:

NSG inbound outbound rules can be defined as below – You can make this more restrictive if you like.

This is just an example:

You can then simply add these objects when you create the NetScaler in the Azure market place.

  • Have your Vnet and Subnets in your virtual network pre-created.
  • Have any internal VIP (Virtual IP) addresses ready and your internal Gateway IP. Know your infrastructure IPs for LDAP, Service account passwords, Storefront URLs, STA IPs and DNS so you are able to configure the Gateway wizard set up.
  • Have your Certificates ready for 443 connections and do not forget to have all the intermediates!
  • Have your public DNS configured for your Gateway URL. You can do this as you can create your PIP for the Gateway in your Resource Group before VPX deployment in Azure.

The Configuration

So how do you build this Appliance?

First you choose your appliance In the Azure Market Place.

I have my own license so I chose the machine below –

Review and click create.

Next simply go through some basic configuration steps.

Name your NetScaler. My preference is name of NetScaler – Domain – Region. (example – NS01-CITXEN-UKS)

Choose your password, disk type, resource group and location.

Click OK.

Next, you can choose the machine specification you will use for the NetScaler instance.

VPX virtual appliances can be deployed on any instance type that has two or more cores and more than 4 GB memory. Remember to size appropriately for your particular environment.

Next you can choose a lot of settings such as Availability Set, Storage account, virtual network, subnet and NSG.

The NSG  (Network Security Group) assigned to your resource Group acts like a firewall. If this is created before the NetScaler market place wizard, you can simply choose the NSG and assign it to the NetScaler’s NIC.

Option to choose virtual network below.

Options to choose or create subnet.


Options to create or choose NSG.


Click OK

Click create.

In about five minutes, your NetScaler will be deployed as you can see below.

Now you need to navigate to your interface via the newly created machine’s Networking menu and then click on the highlighted Network Interface in the right pane.

Next go to IP Configurations and click Add.

Now, you configure your additional IP’s on the interface.

Create your SNIP IP.

Do the same for the NetScaler Gateway Virtual IP (VIP).

Set the IP to static and choose your Public IP that you created before set up.

In the end you should have three static IPs assigned to your NIC as seen below.

Remember to set up your external DNS so your URL can resolve to the Gateway!

At this point you should be able to access your NetScaler from your internal network and via your public management IP (if you added inbound rule port 80 to your NSG) and proceed with the initial configuration setup, upload licencing and your SSL certs and proceed with your Gateway wizard setup. (After configuration, I usually remove the PIP from the management IP).

There is no requirement for an Azure Load Balancer in this Single deployment method. If I was deploying my VDAs in a Resource Location in Azure as part of a Citrix Cloud Solution this solution would suffice for that little extra reassurance against losing your connection to the Cloud Management Plane.

Look up my blog where I  run through the configuration of Netscalers in HA (High Availability) in Azure using the new NetScaler 12 HA template.

Hope this helps somebody!

Carpe Diem!

Follow me on Twitter @CitXen

Office 365/FSLOGIX with Roaming Licences without ADFS in Cached Exchange Mode for VDI

Today we will step in to the world of “Why am I not using this solution already!?

I am going to write about FSLOGIX and in particular two features that when it comes to profile management, provide you with a win win. Happy administrators and happy users.

The end result of any implementation should be about the user experience. If this is not acceptable the hard work you made putting in the solution is ignored.

Profile Containers and Office 365 containers to the rescue!

In a nutshell all your folders and files are mounted at user logon in one single VHD/VHDX file. The system only sees a single VHD/VHDX file to attach to the user. There are two container (VHD/VHDX) files.

The Profile Container – No faffing about on what to include or exclude with the profile, no slowness of logon owed to folder redirection.

The Office 365 Container – OST and office data and even One Drive can be cached in a single VHD/VHDX file so you can have lightning experience with office apps including searching and indexing! (Imagine the case with a chatty OST/PST across the network causing issues with your VDI/RDS users or whenever the users search or do something within outlook. Lots of resources being hogged and network and shared users affected).

One thing to note – Space, you will need space. SAN, Storage, file server you name it you will require space to store the profiles. This is not so costly anymore and  in today’s terms this should not be a problem. Remember size appropriately.

From a user perspective and experience this is A+.

I had the fortunate experience of meeting some of the FSLOGIX team and they really know their onions!

So what will I cover?

  • Office 365 Installation
  • Image Checks
  • FSLOGIX Install
  • Image Preparation
  • GPO Setup
  • How FSLOGIX Works
  • Troubleshooting
  • FSLOGIX Container Management
  • Conclusion

Office 365 Installation

Once you have the master image prepared and optimised for the best user experience by a your preferred consultant we can then begin the office 365 install on the image.

The office install is done by using the ODT tool (office deployment tool).

You simply download this from the website –

Once the executable is downloaded simply run it on a network share.

You should then see the following files.

Next, you need to create a new configuration.XML file.

This is easily done by going to the wonderful GITHUB.

You are able to exclude the products you do not wish to download. (One Drive is usually recommended to not be redirected to the containers historically. However, this can be done).

This is pretty intuitive. What you need to be aware of is the following –

  • Disable Updates
  • Do not have any other office products on your image
  • Display level None
  • Accept the EULA
  • Shared Computer Licensing should be YES

Once you have your configuration file sorted simply download and replace the one in the profile share.

You should end up with something similar to the below.

Next you need to download the office files.

This can be done remotely from your Win 10 master image or any other machine.

Open up an administrative command prompt and run the setup from the location the files are in and download the files to the share.

\\Server\Share\setup.exe /download \\Server\Share\configuration.xml

Once this is done you will see extra files in your profile share –

Now from your master image you need to install the office files.

So first step is to download to a share and second step is to install from that share.

\\Server\Share\Setup.exe /configure \\Server\Share\configuration.xml

This process actually install office on to your image.

You will have to wait for a bit of time so get some pushups in!

Image Checks

At this stage do not launch your office apps. You do not want to activate office on the Master Image!

We have to go through a few tests to check all is good.

Check 1

Make sure the product is not activated on your image.

Check 2

Add the following registry keys and make sure shared computer activation is set to 1.

The registry keys are required to enable office licensing roaming.

Fslogix Install

We now install the fslogix agent.

This is easy.

Click Yes

Enter your product key.



The agent install does install a service.

You will also have 4 groups created for you.

The ODFC groups are user control for your Outlook containers.

The Profile groups are for your……yeah you  have it!

Remove the default groups

…. and add the users you want to have containers mapped when they log on to your VDI/ RDS solution.

Best practice – create 2 groups.



Put the users in to these groups and add the groups withing the FSLOGIX created groups.

Note – Exclude overides include.

The next thing you need to do is create a few reg keys.

FlipFlopProfileDirectoryName – Basically flip sid, username around to username, sid.

VHDLocations – The location of your share that will contain the Containers.

IncludeOfficeActivation – 1 = Office activation data is redirected to the container. 0 = Office activation data is not redirected to the container.

RoamSearch – Used to control the FSLogix Search Roaming feature. Set to ‘1’ or ‘2’ to enable the feature.

Image preparation


This will be your own set of best practices.

What I will say is there are 2 great tools to prep your images.

There are lots of other tweaks you can do – I follow this link for the machine template within VMware.

This link has a good vdi.bat file you use at the end of your image prep.

Once you finish preparing your image it is now over to your Horizon/Xenapp solution to deploy this out.

I will not go in to detail here for this part but this is using an image for MCS/ PVS /Linked clones etc etc.

GPO Setup

There are some GPO’s you can also use to configure settings.

Your VDI machines will be placed in the GPO that these rules apply to.


Office ADMX template

Setting to roam the 365 Token.

Set Computer Configuration Preferences.

Here are the keys we mentioned earlier but being set by GPO.

You will just have to put the ADMX/ and ADML files either in your local policy definitions location or the Sysvol Policy definitions location.


When FSlogix is working it will create VHD/VHDX files on your Container share under a user, sid folder location (Remember the FlipFlop setting) when a user logs in to the VDI.


This can be seen in the VDI Compmgmt console. So, you will get a mounted volume attached that resides on the file share as though it is local to the device.


Log files are located at Log Location for Agent = C:\ProgramData\FSLogix\ODFC

The log will indicate the setting being read/applied by GPO, the VHD being found for the user , VHD’s  being mounted to the specific folder of Office365.

If using UPM or other profile management tools in conjunction with FSLOGIX don’t forget to exclude the highlighted items.

UPDATE: More exclusions added – Thanks to Rene Bigler.

Outlook- \Users\<username>\AppData\Local\Microsoft\Outlook
Search- \Users\<username>\AppData\Roaming\FSLogix\WSearch (Only required when RoamSearch set to 2)
Skype4B- \Users\<username>\AppData\Local\Microsoft\Office\16.0\Lync
Licensing- \Users<username>\AppData\Local\Microsoft\Office\16.0\Licensing
One Drive- \Users\<Username>\<OneDrive folder name>

The status tray also highlights details and logs.

FSLogix Container Management

Mounting vhdx files so you can look at the contents is done with a tool – Frxcontent.exe, located in the following location – C:\Program Files\Fslogix\Apps

You install the tool using the command frxcontect.exe –Install

From the machine you installed this tool on you then browse to the VHDX files and right click and mount as shown below.

The container below shows the Office VHDX file.

The container below shows the users profile within the VHDX folder.

Two screens will pop up when mounted.

Registry and the Profile folders.


The next screen shot simply shows that I can drill in to the users desktop and see the folders that I created.


Simple, easy to implement and quick. Great user experience and solves issues with office 365 cached mode and Exchange online experience for corporate enterprises.

This solution will allow your license to roam in a non-persistent environment without ADFS.

More posts with FSLOGIX will be coming.

Carpe Diem!

Follow me or contact me on twitter @Citxen

Active/Passive Multi Nic Netscaler HA in Azure using ALB

I wrote an article in the Citrix User Group Community, where I highlighted deploying a single NetScaler in Azure to provide some resilience for a Citrix Cloud Solution.

I promised a follow up at the end of the article and here it is.

I have decided to highlight how to deploy a NetScaler Gateway In Azure using Active/Passive mode and a multi NIC Configuration using high availability.

The Azure Market Place has a ready to go template to help you deploy this solution.

It will deploy the following –

  • 2 NetScaler’s
  • 1 Azure Load Balancer
  • 6 Network Security Groups
  • 6 NICS
  • 3 Public IP’s
  • 1 Availability Group
  • 1 storage account


Have the Gateway IP PIP (Public IP) already defined. This way you can sort out your external DNS before template deployment and simply add the public IP to the Azure Load Balancer. More on this later.

You can create the resource Group/Subnets beforehand if you wish. You need 3 subnets, or the template will create 3 for you.

The Build

Search for the NetScaler template on the Azure Marketplace.

The template outlines the following –

Citrix NetScaler 12.0 High Availability (HA) Azure Resource Manager (ARM) template is designed to ensure easy and consistent way of deploying NetScaler pair in Active-Passive mode. This template increases reliability and system availability with built in redundancy. This ARM template supports Bring Your Own License (BYOL) or Hourly based selection. Choice of selection is offered during template deployment.

Citrix NetScaler is an all-in-one web Application Delivery Controller (ADC) that makes applications run faster, reduces web application ownership costs, optimizes the user experience, and makes sure that applications are always available.

Citrix NetScaler offers many tools for application deployment. Some of the primary tools are:

  • Application Acceleration and Application Security
  • HTTP Compression and HTTP Caching
  • Web Application Firewall (WAF)
  • L4-7 Load Balancer
  • Global Server Load Balancing (GSLB)
  • SSL Acceleration
  • Server Offloading
  • Server Consolidation
  • Content Switching and Content Caching
  • High Availability
  • Remote Access and Remote Monitoring
  • Policy Engine with Multi-Tenancy
  • Data Loss Prevention
  • Session Persistence

This template will guide through deployment of Citrix NetScaler HA Active-Passive mode. Preconfigured to include components and setting to deliver seamless HA experience. Details of topology can be found at On successful deployment, Pair of NetScaler will be pre-configured in HA-INC mode. NetScaler 12.0 VPX HA template support different SKU’s of NetScaler such as BYOL and hourly license such as VPX 10, VPX 200, VPX 1000 and VPX 3000.

Next you have the option to choose or create a Resource Group.

Put in your preferred username/password combination and it is here you can choose the licencing method. I have opted for BYO (Bring your own) which I will upload to the device and configure with the Mac ID of the VPX system once known.

You can also choose the virtual machine sizes. The recommended size is 2 x Standard DS3 v2 machines.

Next screen gives you the option of choosing or creating the vnet (virtual network) and your subnets. It is here you can choose the vnet/subnets you already created or let the template configure a new vnet and 3 subnets.

In the screen shot below I had 3 subnets already created.

One for management, one for Infrastructure and one where I placed my VDA (Xenapp/Xendesktop machines.

Once you have defined each subnet the template wizard prompts you to review your subnet configuration.

Click Ok.

I came across the below error. This was because my subscription only allows a certain number of cores. I removed some machines and I was able to run it again successfully.

Second attempt I was able to proceed and create the HA environment.

Azure lets you know the deployment is happening once you click create.

Again, in my deployment there was a failure but the template did deploy.

Then this message pops up informing me the template is deploying.

The error details I received are here.

Once deployed you should see the following virtual  VPX machines in the Resource Group Location.

The Azure objects I highlighted already will also be created in your chosen Resource Group.

Now you should connect to the internal management IP’s of your NetScaler appliance on your chosen management subnet.

The IP’s again can be identified by drilling in to the virtual machines and going to the Networking setting –

You will see your IP’s and the NSG rules set on the Interfaces. If you want to connect to your Public IP (PIP) for management, it is here you will need to relax the NSG rules to allow the access.

There is a public IP and an internal IP that is shown at the top of the screen shot.

Once you obtain your management IP’s from both devices you will be able to connect to the internal management IP’s (NSIP).

Here the fun stuff of configuring your two VPX devices will begin!

One thing to note is that when you log in you will see that your HA is set up and all nicely configured and can successfully failover.

  • Obtain your licensing and upload.
  • Import your certificates. Don’t forget the complete chain!
  • Upload the CA certs to your NetScaler and then install them.


Choose the Intermediate certificate.

Now import your Server Certificate. Mine is in PFX format.

Upload to the NetScaler device.

Click Install.

Choose the PFX certificate.

Put in your certificate password and click Install.

Your Server certificate should appear as below.


One more time – Do not forget to link the chain!

Bind the Server certificate to the Intermediate.

Click OK.

Now you have the appropriate licencing on both your HA appliances and Certificates are uploaded you can proceed with the install of your Netscaler Gateway VIP’s (VIRTUAL IP).

The Xenapp/ Xendesktop Gateway wizard process is well documented so I will not outline this process here. Please check out my CUGC blog at the top for links to other CTP members posts on this process.

Additional Configuration after Template Deployment

This additional configuration after the template deployment needs to be carried out.

First of all you need to create 2 NetScaler Gateway’s.

You can create this using the Xenapp and Xendesktop wizard on the Netscaler.

You can easily deploy a second NetScaler after the first one by clicking on the highlighted icon below.

Once again, I will not run through the NetScaler Gateway configuration as this is well documented.

On the virtual machine Interfaces in the Azure portal, the Gateway IP’s must be assigned.



Make sure your NSG (Network Security Group) on both interfaces is allowing port 443 inbound. The NSG acts like a firewall.

This needs to be done for both machines (VPX0 and VPX1) and the NICS the Gateway is assigned to.

The reason you need to create 2 Gateways in an Active/Passive deployment is that you can only assign one IP to one interface in Azure.

For example, if I was to assign to VPX0/NIC1, I would be unable to assign that IP to VPX1/NIC1.

As the gateway IP is a floating IP shared between two VPX devices, we need two Gateways with the same configuration so we can assign different IP’s to the NICS so the Azure Load Balancer can point to the Gateway.

Azure Load Balancer Configuration

You need to assign your public IP (PIP) for your NetScaler Gateway to a Frontend load balancer.

In an on-premises environment if the primary NetScaler goes down, the secondary node will flood the subnet with ARP to take over the IP address of the VIP and SNIP to restore the connection. In Azure GARP doesn’t work therefore we use the ALB in front and have a single public IP which health probes against the backend NetScaler’s and if one of the NetScaler’s goes down, the HA function in NetScaler will (when configured with INC) will set the virtual server as up on a separate IP address and the ALB will start to failover traffic to the second VIP on the second NetScaler.

More on Azure Load Balancer can be found here –

Access the ALB (Azure Load Balancer) via your Resource Group that contains the deployed resources.

You then need to create your Frontend configuration and assign the PIP (Public IP) to it.

Remember you can create your PIP before deployment so you are able to sort out your SSL certificate and external DNS before implementation day.

You simply click ADD and you get the option to configure a Frontend LB.


The next thing you need to do is create your backend Pools. This will be the machines and target IP’s the Frontend Load Balancer will connect to within your environment.

Simply click ADD and configure as necessary. If you don’t see your target IP you may not have assigned this on your machines NICS in Azure. Remember the IP’s defined within your NetScaler ADC configuration must exist on the NICS of the virtual machines in Azure.

The Backend IP’s can be seen below and they are pointing to the individual Gateway IP’s assigned to each NIC. (Remember 2 Gateway’s).

Lastly we need to configure the load balancing rules. This is the glue if you like, that will make your Frontend Load Balancer pass on 443 connections to the Backend you just configured.

Click ADD.

One thing that caught me out when I was configuring this set up was the Health Probe. I used the probe that was assigned by default. I could never hit the Gateway logon page and I was scratching my head for a while. When I created an additional Health Probe on 443 I was able to hit the Gateway externally. Before I did this I could not get a TELNET response from the Gateway externally.


In Azure SNIP IP’s are not floating. This means your SNIP IP can be different across appliances.



Make sure you have a SNIP for each subnet you communicate to. This then needs to be assigned to the Azure VM interface. Remember you cannot assign the same IP to more than one NIC.


Remember to add both your Gateways to Storefront. You can simply download the configuration file here and import it in to your Storefront.

That is basically it. You should now have a NetScaler HA active/passive solution in Azure.

This is front ended by an Azure Load Balancer.

Simply connect to your Public URL and log in and you are good to go.

The next article will highlight the Active/Active approach in Azure.

Follow me on Twitter @CitXen

Carpe Diem!