NetScaler Web-Based Authentication

An article by Sachin Gadhave from Citrix Blogs

In high security applications, the use of two-factor authentication (2FA) is often a hard requirement to provide enhanced security and meet more stringent compliance requirements.

With 2FA, users are required to provide two means of identification credentials for authentication. The most common example of 2FA is the use of traditional user name and password credentials in combination with a personal identification number (PIN) or token.

2FA can be implemented using RADIUS, which is an industry-standard protocol for providing authentication, authorization, and accounting services. The RADIUS server matches data from the authentication/authorization request with information in a trusted database, such as RSA SecurID, SQL or LDAP. If a match is found and the user’s credentials are correct, the RADIUS server sends a “success” response to the client, which is then allowed access to a corporate resource. A similar solution can be deployed using a Web Authentication server, which connects to a trusted backend database with user security information, where user credentials are sent through HTTP headers.

NetScaler version 10.5 and later with the AAA-TM feature can now authenticate users to a Web Authentication server, providing the credentials that the web server requires in an HTTP request and subsequently analyzing the web server response to determine that user authentication was successful.

Previously, a similar exercise would be done using the HTTP Callout feature, where a client would send the user name and password through HTTP headers in the request. A typical implementation of an HTTP callout would include creating an HTTP callout on the appliance and configuring it with details about the external server and other required parameters, configuring a responder policy to analyze the response and then creating a callout agent on the remote server.

The new Web Authentication feature now simplifies this process, where configuration is similar to creating a standard authentication server and a policy that can be bound to a virtual server for single FA or 2FA.

As with other types of authentication policies, a Web authentication policy is comprised of an expression and an action. After creating an authentication policy, you bind it to an authentication virtual server and assign a priority to it. When binding it, you also designate it as either a primary or a secondary policy.

To set up web-based authentication with a specific web server, first you create an Authentication WEB Server that contains the following items:

  • Name—Name for the Web Authentication action.
  • Web Server IP Address— The IP address of the authentication Web server.
  • Port— The port of the authentication Web server.
  • Protocol—HTTP (for unencrypted web authentication) or HTTPS (for encrypted web authentication).
  • HTTP Request Expression— An expression in NetScaler default syntax that contains the user’s credentials in the format that the Web server expects.
  • Expression to validate the Authentication—An expression in NetScaler default syntax that matches the web server response string that signifies that the user authenticated successfully.

Authentication Rule & Expression to validate the Authentication are the most important items in the list above, which have to be formatted precisely to ensure the NetScaler request and response matches the exact POST expression that the Web server expects. In this example we will use a sample POST request and response to configure Web authentication on NetScaler 10.5. At high level we need to complete following 5 steps:

  1. Create a Netscaler Gateway VIP or AAA-TM Virtual Server and associated configuration.
  2. Create Web authentication server “HTTP Request Expression” & “Expression to validate the Authentication”
  3. Create Web authentication server and tie in the details from step 2.
  4. Create Web authentication policy and associate it with the Web Authentication Server.
  5. Bind the Web Authentication Policy to the Netscaler Gateway or AAA-TM VIP in question.

We will assume, at this point, that you are implementing this solution because of a specific requirement where the credentials from Netscaler Gateway or AAA-TM needs to be sent to a specific server in a specific manner that requires this approach.

At this point, one should also validate that the basic Netscaler Gateway ICA proxy functionality is working with standard LDAP based authentication. Once done, it’s now time to get to the exciting stuff!


Read More


Learn How StoreFront 3.0 Supports Google Chrome without NPAPI

An article by Feng Huang from Citrix Blogs

A couple of months ago, I blogged here to give a head-up about the disruption of user experience for Receiver for Web when Google Chrome disables NPAPI and to provide some temporary workarounds. I indicated that we were actively working on new technology to remove the dependency on NPAPI.

Today, I can announce that the new solution is included in the StoreFront 3.0 Tech Preview. In this article, I will show you how to set up the Tech Preview environment to test-drive this new solution to help you prepare for the change.

When StoreFront 3.0 finally releases, we expect that the new solution will be applied to Google Chrome and Microsoft Edge. The user experience for other browsers will not be affected. We also expect that the new solution will work for both the new UI and the classic green bubble UI. This is to help you minimize disruption for your users. In the Tech Preview, however, please note that the solution only works for the new UI with Chrome on Windows.

Now, let’s begin setting up the Tech Preview environment to support Chrome without NPAPI.

First, I would like to turn on auto fallback to Receiver for HTML5. This is optional but it will take you through the full user experience.

  1. Open the StoreFront Admin Console
  2. Select Receiver for Web node in the left pane
  3. Select the Receiver for Web site you would like to use in the middle pane
  4. Select the Deploy Citrix Receiver task in the right pane
  5. Select Use Receiver HTML5 if local install fails as shown in the screenshot below
  6. Select OK and close the Admin Console

The default Receiver for Windows download link in Receiver for Web refers to the official Citrix download site. As the new solution requires the Tech Preview version of Receiver for Windows, we have to set it up manually. Also, the solution is disabled by default in the StoreFront 3.0 Tech Preview and hence we have to enable it by editing the configuration file. These steps will not be necessary in the official release of StoreFront 3.0 and Receiver for Windows 4.3.

  1. Download Receiver for Windows 4.3 Tech Preview here (if you have not done so)
  2. Copy it to the StoreFront installation location (typically C:\Program Files\Citrix\Receiver StoreFront\Receiver Clients) and rename it to CitrixReceiverWeb.exe
  3. Open web.config under the Receiver for Web site (typically C:\inetpub\wwwroot\Citrix\<StoreName>Web) in your preferred text editor
  4. Locate the line <win32 path=”” />
  5. Change the value of path to be the server local path, which is /Citrix/StoreWeb/clients/CitrixReceiverWeb.exe in my case
  6. Locate the line <protocolHandler enabled=”false” platforms=”Windows NT.*Chrome/([4-9][2-9]|\d\d\d);Edge”
  7. Change the value of enabled to be true

  8. Save the file and close the text editor

Read More


vSphere Replication and Bandwidth Requirements

An article by VMware SMB from VMware Blogs

By: Ivan Talley, Systems Engineer at VMware Customers often ask me how much bandwidth they’ll need for VMware vSphere Replication. It’s a pretty typical question, especially when they’re using vCenter Site Recovery Manager (SRM) for disaster recovery. In general, I’m not a fan of ambiguous answers from vendors. Unfortunately, this is a case where the […]]> By: Ivan Talley, Systems Engineer at VMware

Customers often ask me how much bandwidth they’ll need for VMware vSphere Replication. It’s a pretty typical question, especially when they’re using vCenter Site Recovery Manager (SRM) for disaster recovery.

In general, I’m not a fan of ambiguous answers from vendors. Unfortunately, this is a case where the ambiguous answer is correct — we just don’t know what you’ll need. It depends on how many virtual machines (VMs) you intend to replicate, how frequently you intend to do so, and how much their data changes. Each variable impacts the actual amount of data that needs to be moved. This calculation must be performed before you can determine your bandwidth needs.

You’ll need to do some math to determine the optimal connection speed because replication likely isn’t the only traffic on your connection.

You can find a free tool, one I often suggest to customers, at a lesser-known VMware site. It’s a “fling,” an unsupported software project that our engineers delve into on occasion, but it always fills a need for someone, somewhere. Sometimes flings even become product features.

Anyways, the fling you’ll need is available at Search this page for “replication” to find the replication tool. You should find the following summary:

The vSphere Replication Capacity Planning Appliance allows administrators to model the network impact of a virtual machine replication without producing actual replication traffic. The appliance provides command-line tools to configure replication for any VM in a vSphere Virtual Center. The replication is established in preview mode and thus requires no storage space. Networking traffic, required for the replication, is measured and displayed in an easy-to-understand graphical format that allows you to estimate the network bandwidth required.

Use this tool to get an accurate calculation on how virtual machine replication will impact your network. Once you do this, you should get a better estimate on how much bandwidth you’ll need as well. I hope this was helpful, and if you find yourself needing additional estimates or tweaks, I’d suggest checking the fling site out.

Of course, if you’re ever in need of something, don’t hesitate to drop us a line.

For future updates, follow us on Twitter and Facebook


Ivan Talley has over 20 years of experience as a Network Engineer in medium size business data centers. His expertise also includes multiple verticals such as consulting engineering, contract electronics manufacturing, waste management, and legal services.


A Different Approach to a Single FQDN for StoreFront and NetScaler Gateway

An article by Brooks Cunningham from Citrix Blogs

How can users be educated to use a single URL, while still having a StoreFront base URL that is different from the NetScaler Gateway URL? We’re going to show you.

Please keep in mind this solution works best for Receiver for Web. This solution does work with the Native Receiver, but the Provisioning file would be the easiest way to configure the Native Receiver in my opinion.

In this scenario, I will use for external access to the Citrix environment. will be used for internal access to the Citrix environment.

Here is an overview of the requirements for the scenario:

  1. SAN certificate for and
  2. will resolve to the publicly accessible NetScaler Gateway VIPs.
  3. will resolve to the internal StoreFront Load Balanced VIPs.
  4. CNAME on the internal DNS. –>
  5. Responder Policy to redirect from to

Now for the magic of creating the single FQDN that users need to know.

In this example, the “single URL” for users is On the internal DNS infrastructure, create a CNAME for to point to Then, on the NetScaler appliance, create a Responder Policy that redirects traffic with the HTTP Host header of “” to “”. Bind this policy to the StoreFront LB VIP on NetScaler.

So, what is the expected user behavior?

A user on the internal network types into their browser. resolves as a CNAME for The user will resolve After obtaining the IP address for, the user connects to the SF LB VIP using the IP address and the HTTP host header The Responder policy redirects the user to The user’s browser follows the redirect and is able to access the StoreFront LB VIP. By using a SAN certificate with the names we need, the user will not receive a certificate warning.


Read More


How to install vSphere 6 ESXi using the Interactive Installer

An article by Graham Daly from VMware Blogs

Interactive installations are recommended for small deployments of four or less hosts. Installation using this method involves booting from the ESXi 6.0 installation media by inserting the media in to the host and following the prompts from the installation wizard to choose a destination disk in the host and begin the installation. Our video today […]]> Interactive installations are recommended for small deployments of four or less hosts. Installation using this method involves booting from the ESXi 6.0 installation media by inserting the media in to the host and following the prompts from the installation wizard to choose a destination disk in the host and begin the installation. Our video today demonstrates how to install vSphere 6 ESXi using the Interactive Installer.

The ESXi installation media can be connected to the host in a few different ways:

  • Inserting the CD/DVD in to the DVD-ROM drive in the server
  • Plugging in a bootable USB device
  • Mounting an ISO remotely

When instructed to begin, the installer reformats and partitions the target disk and installs the ESXi boot image. If you have not installed ESXi on the target disk previously, all data located on the drive is overwritten, including hardware vendor partitions, operating system partitions, and associated data.

Note: The formatting and partitioning done by the ESXi installer is permanent and overwrites existing data. To ensure that you do not lose any data, migrate any important data from the host to another machine before you install ESXi. If you are installing ESXi on a disk that contains an installation of ESXi/ESX or a VMFS datastore, you are presented with upgrade options.

For additional information, see VMware Knowledge Base article Methods for installing ESXi 6.0 (2109708).


Setting a Default Landing Folder for Receiver for Web

An article by Feng Huang from Citrix Blogs

Recently I implemented a customization for a customer to set a default landing folder for Receiver for Web 2.6. As this may be useful for customers who used to follow CTX119550 to customize Web Interface to get this functionality, I am making it available here.

First, follow the instruction here to configure the related Store to be a mandatory store.

Then, configure the Applications view as the default view for the Receiver for Web site as described here.

After that, append the following code snippet to custom.script.js in the contrib folder under the Receiver for Web site (typically C:\inetpub\wwwroot\Citrix\<Store-Name>Web\contrib) and change the value of landingFolderPath in the code to be the path of your desired landing folder.

$(document).ready(function () {
        var landingFolderPath = '/Microsoft/Office/2013';
        $.ctxs.ctxsMyApps.prototype._renderMyApps = function() {
            var self = this;
            var path = $.localization.string('MyAppFolderRootPathName') + landingFolderPath;
            self.element.wrap('<div id="myapps-scroller"></div>').parent().ctxsMakeScrollable();

Your desired landing folder will be displayed after users log in to Receiver for Web.

Read More


Delivering Contextual Security with SmartControl

An article by Kurt Roemer from Citrix Blogs

Control is a core requirement for delivering on the promises of security – but how can enterprise control align with a threat landscape that is constantly changing due to seemingly unbounded user and usage situations? And, how can this access be unified across all internal and external applications to both enforce security and provide for a superior user experience?

Today’s enterprise security control has to be effected across dynamic access situations that involve combinations of devices, networks, services, applications, locations and the policies designed to protect sensitive enterprise data. These situations can change multiple times throughout the day, as users work from different locations, utilize different devices and networks and access enterprise, SaaS and cloud-based applications to do their jobs.

In the “good old days” before rampant mobility and consumerization, access controls were applied just at the point of login. The evolution of access into highly dynamic usage scenarios has highlighted the need for contextual security, which enables security measures to match the situational-specific policies required to protect sensitive data.

Read More


Cookbook to Upgrade from Receiver 3.4 for Windows to Receiver 4.2.100

An article by Mayunk Jain from Citrix Blogs

If you have been using Receiver 3.4 Enterprise for Windows, your mobile workspace is due for spring-cleaning and the Citrix Receiver crew is here to help.

As Dave Coleman reminds us in this blog series–aptly titled “Spring Forward”–on fresh user-experience enhancements, this is the season for change, for rejuvenation, and for embracing the new.

Upgrade to the latest Receiver 4.2.100 for Windows that enables the best performance for graphics-intensive 3D professional applications, USB redirection with published apps, Microsoft Lync virtualization, local app access, app shortcuts, pass-through authentication, and more. Receiver 4.2.100 for Windows provides over 45 fixes and enhancements, making it even simpler for end users to consume IT apps. To benefit from the new features and bug fixes in the recently released XenApp and XenDesktop 7.6 Feature Pack 1, you must plan your upgrades to the latest versions of StoreFront and Receiver as soon as possible.

The new Receiver is a major upgrade over Receiver 3.4 Enterprise, and does not support in-place upgrade by the end-user. The IT administrator must prepare the environment, so all users on the network can complete the upgrade successfully to Receiver 4.2.100. Generally this would happen in the background, when the users restart their clients after the upgrade has been pushed out. There are a number of steps that go into configuring this properly, and maintain the familiar user interface of Receiver 3.4 while upgrading to the new release. We have compiled the best practices in an easy-to-read cook-book that helps IT administrators complete this upgrade with minimum disruption. Once the user base is upgraded to Receiver 4.2, it will make future upgrades easier.

The guide is divided into two parts: if you are already on StoreFront, only refer to the first part; the second part is meant for those still using the older Web Interface. In both cases, there are instructions to upgrade both the IMA-based XenApp 6.5 environment as well as the FMA-based 7.6 environments. A birds-eye view of the instructions looks something like this:

1) Uninstall Receiver 3.4 using group policies (GPO)

2) Use scripted-install to deploy Receiver 4.2.100 with pass-through authentication

3) Use GPO to configure global application shortcuts to Start Menu and Desktop

4) Alternatively, configure per-app settings for Start Menu and Desktop shortcuts

5) Execute the group policies to upgrade Receiver and push the settings to end-points


When the end users login to their clients, the group policies kick in and it takes a few minutes for the upgrade to complete. At that point, end user has to exit, and login to their Windows session once. The Single Sign-On service will securely record the credentials, and on subsequent login the user will be authenticated all the way to the published apps and desktops using Windows Authentication pass-through. In the ‘shortcuts only’ mode, users never have to go through the self-service app selection. They will find their mobile workspace apps under the familiar Start Menu or Desktop folders, as desired, same as locally installed apps.

Using copious screenshots and step-by-step recipe, this cookbook is your one-stop reference to deploy and upgrade Receiver for Windows.

Read More


NetScaler Troubleshooting with Citrix Insight Services

An article by Andrew Redman from Citrix Blogs

Citrix has developed tools and online analysis capabilities to help you collect environment information, analyze that information and receive tailored recommendations based on your Citrix environment and configuration.

The tools are focused on a single mission–data collection–and their impact to your environment is minimal in terms of disk space, prerequisites and performance impact during the data collection process.

Citrix Insight Services analyzes the data captured in the support bundle and provides you with Tailored Recommendations, specific to your environment. To leverage Citrix Insight Services, you’ll need to harvest a NetScaler tech support bundle.

The tech support bundle captures critical system data about the performance of the appliance, error logs and a host of other extremely important data that can be used for analysis.

To create a new tech support bundle that can be analyzed for potential issues on the appliance, simply log into NetScaler via your favorite SSH client and enter the command: > show techsupport

The tech support file will be generated and stored on the hard drive of NetScaler in the /var/tmp/support directory and the file name will start with collector_P or S

You can log into NetScaler via WinSCP and navigate to the /var/tmp/support directory to transfer the collector file to your local computer.

IMPORTANT NOTE: If this appliance is part of an HA pair, make sure that you log into the SECONDARY appliance and collect a tech support bundle on it as well. Citrix Technical Support will use both support bundles to correlate issues between the HA pair.

Citrix Insight Services


Once you log in and the support bundle has been uploaded, you’ll see lots of details that you can investigate.

Read More


Performance Tip: Disabling Mouse Shadow for XenDesktop and XenApp

An article by Rachel Berry from Citrix Blogs

Until I joined HDX and started researching them, I had no idea how complicated and troublesome a little arrow could be! Citrix XenDesktop and XenApp both involve constructing a desktop on a server and then remoting the pixels of the desktop to an end-client device; that end-client device could be a Windows workstation, a Linux thin client, an iPad or a smartphone. This means there are two potential places a cursor can be added on top of the desktop, 1) on the server or 2) on the client device.

Server-Rendered Cursors

Server-rendered cursors are expensive for virtualised desktops. Every time the user moves their mouse, that message is sent to the server, so the desktop can be redrawn and then the new desktop is sent back to the user. This can generate high-bandwidth and if the desktop is very complex (e.g. a complex CAD model where the application is recalculating the part) this can become a bottleneck. It can also result in a lot of redrawing of transient intermediate frames that are unnecessary, intermittent information that a user doesn’t need e.g. when they are scrolling or moving a window rapidly.

Client-Rendered Cursors

Client-rendered cursors involve the instruction to redraw the mouse being done on the client and simply overlaid upon the “background” desktop.

Recognising A Server-Rendered Cursor

In XenApp, it is very easy to recognise a server-rendered cursor by dragging the mouse to the edge of an application window. If the tail is chopped off then the mouse is server rendered, a client-rendered mouse being overlaid would retain its tail.

Mouse Shadow

Read More