Storefront 3.1 Technical Preview and configuration options

With the release of Storefront 3.1, Citrix made alot of options which were earlier only available in PowerShell or a configfile available in the GUI, which makes alot more sense since WebInterface has always had alot of options available in the GUI. Now I was a bit dazzled with the numerous options that are available, so what do they all mean?? Hence this post which is used to explain what the different options do, and even what error messages that bit appear because of them.
First of let’s explore the store options in Storefront.

Store Options

User Subscription (This defines if users are allowed to Subscribe to applications or if applications are being mandatory)


For instance Self-service store (GUI Changes to this)


Mandatory Store (GUI Changes to this)


Kerberos Delegation (Allows ut to use Kerberos Constrained Delegation from StoreFront to Controllers)


Optimal HDX Routing (Defines if ICA traffic should be routed to Netscaler Gateway even if users are going directly to the StoreFront) We can define a Gateway and attach it to a Farm/Controller, so if we have multiple controllers on different geographic regions we can specify multiple gateways and attach it to the correct delivery controller.

We can also define Direct Access (Which we can enable for each Optimal Gateway) which defines if users which are trying to authenticate internally direct against storefront will also have traffic redirected to the Gateway.

We can also define Optimal Gateway and attach it with Stores which are part of XD 7.7


Citrix Online Integration (Defines if GoTo applications should appear in the Store)


Advertise Store (Defines if the Store should be available to select from Citrix Receiver client, if we choose to hide the Store the only way to access the store is to setup manually, or using provisioning file)


Advanced Settings (Address Resolution Type: Defines which type of address the XML service will respond to Storefront with, by default it is DNS based return, or we can change this to IPv4)

Allow font smoothing: Defines if font smoothing should be enabled in the ICA session

Allow Session Reconnect: Also known as Workspace control, which defines if users can reconnect to existing sessions without restart applications

Allow special folder redirection: Defines if \Document & \Desktops on the local computer should be used in the redirected session. By default the servers profile \Documents \Desktop folder are used

Time-out: Define how long time it should go before the connection times out.

Enable Desktop Viewer: Defines if the Desktop Viewer should be visible in the connection

Enable Enhanced Enumeration: If we have a Storefront configured with mulitple stores, Storefront will contact these Stores in sequencial so if there are alot of resouces this might take some time. With Enhanced Enumeration, Storefront will contact these Stores in Parralell

Maximum Concurrent enumerations: How many concurrent enumeration connections to the Store resources, by default this is 0 which means unlimited

Override ICA client name: Overrides the default ICA client name

Require token consistency: Validates authenticaiton attempts on the Netscaler Gateway and on the Storefront Server, this must be enabled if we want to use Smart Access. This is typically disabled if we want to disable authentication on the Netscaler and do authentication directly to the Storefront server


Server Communication attempts: How many times Storefront should try to communicate with a Controller before it marks it at down (default: 1)

Next we also have web site receiver configuration in Storefront

Receiver Experience (If we should use the regular Green bubble theme or using the unified experience) Disabling classic experience will also give other options such as configuring apperance as well.


Authentication methods (Defines what kind of authentications we can use against Storefront)


Website Shortcuts


If you wish to add Storefront to another web portal using for instance as an iFrame(will be shown as this)
you need to enter the URL which is allowed to connect to Storefront as an iFrame in the WebSite Shourtcuts.image

Deploy Citrix Receiver (what kind of Receiver should Storefront offer to the authenticated user)


And if we choose install locally we have a number of options



Session settings (How long a session is active before it times out against Storefront)


Workspace Control (What should do if a clients is inactive/logs out) Here we can define so that if a user moves from one device to another the user should reconnect to their existing session)


Client interface settings (Here we can define certion options such as, if a desktop should be auto launched, if Desktop viewer should be enabled, if users are allowed to download Receiver configuraiton from within Receiver for web, and also what kind of panes should be default and shown within Receiver for web)


Advanced settings


 Enable Fiddler Tracing: Enables use of fiddler between Receiver for web and other storefront services. Loopback must also be disable.

Enable Folder view: If folders should be used in Receiver for web

Enable loopback communication: Storefront uses adapter for communication between Receiver for web and other storefront services

Enable protcol handler: Enables use of client detection in Google Chrome

Enable strict transport security: Enables the use of HSTS

ICA file cache expiry: The amount of seconds before an ICA file should be stored in memory

Icon resolution: Default pixel size of an application

Loopback port when using HTTP: Which port should be used for communicaiton with loopback adapter for other storefront services

Prompt for untrusted shortcuts: Prompt the user for permissions to launch apps shortcuts from sites that have not been directly setup as trusted.

Resource details:

Strict transport security policy duration: Time policy for HSTS

No last but not least there are some new interesting features on the authentication site, first of there is the password expiration option under Password Options



When a user logs inn it will look like this.


Another new option is the Password validation feature, in a regular scenario we might now have storefront in the same domain as Xenapp or XenDesktop services, and we might not always be able to setup Active directory trusts, instead we need to setup XML service-based authentication, which will allow Storefront to communicate with XML instead of Active Directory and leave the autheticaiton process to the DDCs. Which is typically the case if we have multi-tenant enviroments.


Another option that we have is when defining Gateways in Storefront, we can now define if Gateways should have the role of HDX routing only, Authenticaiton only or both. If we choose HDX routing only, we cannot use this gateway for remote access for the store.


As we see here (It does not show) The reason for that is that if we want a regular ICA proxy setup to work with Receiver for web and regular receiver we need to configure auth at the Gateway, which means that we need to define auth at the Gateway to be able to use it for remote access against the store.


The latest COOL features which is now part of the GUI Storefront is the ability to do User farm mapping. Which in essence Is used to assign a group of users to a selection of Sites/farms. So if we have multiple farms we can define a certain group of users which should be mapped to that farm. This is done on the controller settings


Then choose map users to controllers


Define AD group


Then define which controllers it should contact to display resources.


And voila! alot of cool new features in the TP which I makes it to GA soon!
There are some bugs in the GUI but I think we have a fully WI replacement!

#citrix, #optimal-gateway, #storefront, #storefront-3-1-technical-preview, #xendesktop

Multitenant guide setup for Storefront and Netscaler with ICA-proxy

This is something I have been working on for quite some time… Fact it has been quite a pain in the ass to setup, but I think I finally managed to solve it properly. If anyone sees any issues or something that I haven’t adressed, please leave me a comment either below in the post or on twitter @msandbu
  One of the issues with trying to setup Netscaler and Storefront in a multi-tenant are in some cases the:

  • Amount of authentication policies needed to hit all the specific domains in a multi-tenant enviroment
  • Theme customization, this is by default set at a vServer level, which means that we need a vServer pr customer if we want customization
  • We could solve this with multiple Gateway vServers, but with Multiple vServers also means that we need many IP-addresses, which we might not have.
  • Multiple customer domains

Now it is possible to bypass Netscaler authentication, and setup the Gateway vServer just act as a ICA-proxy, so authentication happens at the Storefront but this setup does not work for Receiver. Since in a Netscaler Gateway setup, the Receiver needs to authenticate against the Gateway first.

NOTE: This might not be a supported configuration from Citrix, but it works and it requires a regular Netscaler for it to function (Not Gateway VPX)

So from an overview, how does it work?

  • We publish Storefront as a LB vServers behind the Netscaler (Meaning that Storefront is accessable from the external network)
  • We configure an Gateway vServer, which will handle the ICA traffic.
  • We use Responder, Rewrite policies to handle the redirect to the correct URLs.
  • We configure Optimal Gateway Routing with direct access on Storefront (Which basically means that all ICA traffic regardless of beacons will be redirected using a Gateway. This feature is not new, but with Storefront 3.1 tech preview this is available in the GUI. We also define that Gateways are being used for HDX routing only, all other auth will happen on Storefront.
  • We have one or multiple Storefront stores depending on the requirements for backend setup for instance if we have multiple isolated active directory, and we have defined password verification against DDCs instead of Active directory. This might vary from deployment to deployment but important to remember what are Store specific settings and what are Receiver for web specific settings.
  • We can have multiple Gateway vServers to handle communication, but customers still need one URL for storefront setup.

So if we look at the screenshot below, this is a test deployment I did. So when a user starts receiver for the first time and tries to configure his Receiver it will be communicating directly with the Storefront endpoint and configures properly. Depending on what kind of Store the user is accessing this might be done using DDC validation or using Active Directory. Same goes if using Receiver for web, the user connects and my typing his customer name is redirected to the customer website on Storefront. When the user tries to start an application or desktop session, the session will generate an ICA file contaning the Optimal Gateway setting (Which means that even thou in theory it is labeled as inside because of setup) the session will be routed using the Gateway.


So how to set this up?

  • First setup a load balanced vServer containing the Storefront servers, using HTTPS/443
  • Now I can’t address all configurations on the Storefront with stores and such so I gonna setup a generic Storefront setup where we have the Storefront in a untrusted domain using XML based auth against the DDC, and one simple store and where we have two customer URLs ( and

First of the base URL should not contain any customer specific reference so in case it should be just an indicator of the service, this is not something the enduser will see unless he for instance opens the receiver configuraiton file.

In my case its just (Setup a wildcard cert on the Storefront server or we can use a SAN or SNI based cert) in my case I have a wildcard cert for the domain


Create a Storefront Store with internal access only, leave everything at default as of now. Create the Receiver for web sites needed for the end customers.

NOTE: I did some changes on the different websites to show how this works from the end-user experience

Note: We can alter what we want for each website, portal customization can be done under the c:\inetpub\wwwroot\citrix\(nameofwebsite) or using the Storefront GUI.

Next we define the Gateway that this store is going to use, this can be done by going into the Store settings –> Optimal HDX Routing


Specify HDX routing usage only and add the external FQDN of the Gateway. (And no the Storefront does not need to be able to communicate with the Gateway, since Auth is done completely at Storefront. After you have added the gateway, click for Direct Access and define which controllers should be used against the optimal gateway


So after this is setup, we need to add rewrite rules and URL transformation for each customer to their website on the Storefront.

Rewrite rules: these are pretty simple just replaces a URL prefix at the end


Then I have an expression that looks at the host name and specificies that the URL must be at the root to it continue


These policies needs to be added to the Storefront LB vServer. Next we also need to have URL transformation policies to define HTTP to HTTPS rules.

Simplest is to add a Netscaler URL transformation profile and add the different URLs


when creating the URL Transformation Profile, the simplest way is to use the HTTP.REQ.IS_VALID expression, since this policy is only being applied once to a storefront vServer, before the end users are being redirected to the HTTPS version


Setup a HTTP vServer Storefront on the same VIP as the SSL based vServer and add the transformation policy. This means that when a user logs inn to (The HTTP vServer will respond and redirect the user to and the rewrite will add the /Citrix/Website URL at the end.

After this is setup we can verify that Reciever for web is working



NOTE: (ill come back with how to make the URL much more pretty… )

Now that we can verify that this works we need to configure the Gateway which we described earlier. Go into Netscaler Gateway and setup a new vServer with a VIP which responds on the FQDN that we used in Storefront.

Now you need to define a ICA only vServer, with SSL certificate and STA server. No need for session policies. Now when we log into Storefront and try to start an ICA session we can see the following:

InitialProgram=#TS $S1-1

So we can see that the ICA files indicates that we are going using the Netscaler Gateway. Problem solved!

So what are we losing in this setup?

  • All auth happens on Storefront, so if we need to have two-factor that has to be integrated with Storefront directly.
  • We are using Netscaler Gateway only for routing purposes, which means that VPN goes away.

#multitenant, #netscaler-gateway, #storefront

Setting up a secure XenApp enviroment–Storefront

So this is part two of my securing XenApp enviroment, this time I’ve moved my focus to Storefront. Now how does Storefront need to be secured ?

In most cases, Storefront is the aggregator that allows clients to connect to a citrix infrastructure. Im most cases the Storefront is located on the internal network and the Netscaler is placed in DMZ. Even if Storefront is located on the internal network and the firewall and Netscaler does alot of the security work, there are still things that need to be take care of on the Storefront.

In many cases many users also connect to the Storefront directly if they are connected to the internal network. Then they are just bypassing the Netscaler. But since Storefront is a Windows Server there are alot of things to think about.

So where to begin.

1: Setting up a base URL with a HTTPS certificate (if you are using a internal signed certificate make sure that you have a proper set up Root CA which in most cases should be offline. Or that you have a public signed third party CA. Which also in many cases is useful because if users are connecting directly to Storefront their computers might not regonize the internally signed CA.


2: Remove the HTTP binding on the IIS site. To avoid HTTP requests.

Use a tool like IIS crypto to disable the use of older SSL protocols on IIS server and older RC ciphers


You can also define ICA file signing. This allows for Citrix Receiver clients which support signed ICA files to verify that the ICA fiels they get comes from a verified source.

3: We can also setup so that Citrix Receiver is unable to caching password, this can be done by changing authenticate.aspx under C:\inetpub\wwwroot\Citrix\Authentication\Views\ExplicitForms\

and you change the following parameter

<% Html.RenderPartial(«SaveCredentialsRequirement»,
              SaveCredentials); %>

<%– Html.RenderPartial(«SaveCredentialsRequirement»,
                SaveCredentials); –%>

4: Force ICA connections to go trough Netscaler using Optimal Gateway feature of Storefront –> using this option will also allow you to use Insight to monitor clients connection to Citrix as well, and depending on the Netscaler version give you some historical data.

And with using Windows pass-trough you can have Kerberos authenticating to the Storefront and then have ICA sessions go trough the Netscaler –>

5: Use SSL in communication with the delivery controllers –>

6: Install Dynamic IP restrictions on the IIS server, this stops DDoS happning against Storefront from the same IP-address

 IIS fig4

7: Windows updated!  and Antivirus software running (Note that having Windows updated, having some sort of antivirus running with limited access to the server) also let the Windows Firewall keep runnign and only open the necessery ports to allow communication with AD, Delivery Controllers and with Netscaler.

8: Define audit policies to log (Credential validation, Remote Desktop connections, terminal logons and so on)

9: Use the Storefront Web Config GUI from Citrix to define lockout and session timeout values


10: Use a tool like Operations Manager with for instance ComTrade to monitor the Storefront Instances. Or just the IIS management pack for IIS, this gives some good insight on how the IIS server is operating.

11: Make sure that full logging is enabled on the IIS server site.

IIS Logging Configuration for System Center Advisor Log Management

Stay tuned for more, next part is the delivery controllers and the VDA agents.

#citrix, #storefront, #xenapp

Using Netscaler with UPN and Storefront

Had a case earlier today where a customer wanted to configure Netscaler to authenticate with UPN instead of SamAccountName. And using UPN instead of SamAccountName makes sense in many cases, since it easier for users to remember their email-address instead of their username.  So in this scenario my samAccoutName is msandbu and my UPN is

Now by default Netscaler is setup with samAccoutName under server logon name attribute. This defines what kind of account name you are allowed to logon with using Netscaler.

If you try to logon with UPN when SamAccountName is defined you will get this kind of error message on the StoreFront Server.


So Storefront strips the domain info sent from the Netscaler and tries to validate the credentials to Active Directory.

So how to fix this ?

You have to define the SSO name attribute in the LDAP credential, to samAccountName.


Then the Netscaler firstly validates the UPN, get the SamAccountName of the user and then forwards that to Storefront and logs in.

Important to remember that Storefront always tried to revalidate the info from Netscaler


#citrix, #gameslotpulsaonline, #netscaler, #storefront

Storefront monitor not working properly for HTTPS services in 10.5

Now I just recently became aware from Twitter that the 10.5 Netscaler monitor for Storefront is not working properly for HTTPS enabled Storefront servers.


The problem with the monitor is that it uses an IP based check (and not a hostname based check) which would allow the monitor to work properly since the digital certificate it presents does not match its IP-address.

NOTE: This only fails if the monitor is matched against a SSL based service and you have configured the monitor with secure


Now in older versions of the monitor it had an own “hostname” parameter, but that is now deprecated. Now all we have is a Store name setting there.

There is a workaround which was listed on the Citrix forums by a member there.

Here’s a workaround:

  1. Edit the file /netscaler/monitors/
  2. At line 23, insert the following before the current ENV line:


So let’s see if Citrix fixes this issue in the next release! Smilefjes

#citrix, #storefront

Performance tuning Citrix Storefront

This is something I wanted to write about for some time now, after the release of XenDesktop 7 but there are only 24 hours in one day so therefore I didn’t have the time before now Smilefjes

But the purpose of this post is to really say that Storefront is slow…..
Don’t get me wrong it not about Citrix but the combination of Storefront and IIS that makes it a bit complex and therefore this makes it a bit slow.

Now there are a couple of tricks that can tune the perfomance.

Socket Pooling
In Web Interface you could enable it from the console, but in StoreFront we have to change it in the store config. By enabling socket pooling, Storefront maintaines a pool of sockets instead of creating a socket each time a new user connects, this will give a better performance for SSL based traffic.

You can enable this by opening the web.config file under C:\inetpub\wwwroot\Citrix\storename\


And Change this to “on” after that you have to do an IIS reset.

Application Initialization

(NOTE: Make sure you backup the config files before making alterations)

With Windows Server 2012 we have a new feature in IIS called always running on the application pools, this allowed for IIS to make everything ready after an application pool has restarted, before this the previous IIS was set to start loading after the first user tried to login after a restart. This caused the first user to login after an application pool has restarted to take loooong time to login. With Server 2012 IIS we can change the application pool to always running.

With 2008 R2 not so easy. But we can make it happen Smilefjes
First we need to download the application initialization feature from Microsoft

After that is done and installed do a restart on the storefront server.

Then we have to make som changes to the config. First we need to change the application pool to always running (we cannot do this via the gui in 2008 R2)

Open the C:\Windows\System32\inetsrv\config\applicationHost.config on the storefront server. Locate the following setting /configuration/system.applicationHost/applicationPools

Then we have to add the always running paramter on each application pool for instance the authentication pane we need to add the startMode=”AlwaysRunning” on each ofthem.

<add name=»Citrix Delivery Services Authentication»
autoStart=»true» managedRuntimeVersion=»v2.0″
managedPipelineMode=»Integrated» startMode=»AlwaysRunning»>

And you might have the following application pools in the config that needs to have this paramter.

  • Citrix Delivery Services Authentication
  • Citrix Delivery Services Resources
  • Citrix Receiver for Web
  • Citrix Delivery Services

Now after we have done that in the same document we have to change under the /configuration/system.applicationHost/sites we need to add the preloadEnabled=”true” paramter. So for instance for the authentication application

<application path=»/Citrix/Authentication»
applicationPool=»Citrix Delivery Services Authentication»

This paramter needs to be added for all the Citrix Applications (Depending for instance if AG is setup)

  • /AGServices
  • /Citrix/Authentication
  • /Citrix/Roaming
  • /Citrix/<StoreName>
  • /Citrix/<StoreName>Web

After this is done save the config, do an IISreset and test the login to make sure that is it operational and that you don’t get any errors (check also under the web server event log)

Next we need to make changes to the following config files

  • C:\inetpub\wwwroot\AGServices\web.config
  • C:\inetpub\wwwroot\Citrix\Authentication\web.config
  • C:\inetpub\wwwroot\Citrix\Roaming\web.config
  • C:\inetpub\wwwroot\Citrix\<StoreName>\web.config

Under the section /configuration/system.webServer we need to add

<applicationInitialization skipManagedModules=»true»>
<add initializationPage=»/endpoints/v1″ />

On each of the following config files.

After this is done we need to change the Store config file which is located under C:\inetpub\wwwroot\Citrix\<StoreName>Web\web.config
Under the same section as those above we need to add the following parameters.

<applicationInitialization skipManagedModules=»true»>
<add initializationPage=»/Home/Index» />

After that is done save the config, and do an IIS reset.

Now if you are having trouble with Storefront, it generates its own events in Event Viewer under Citrix Delivery Services.
Also it is important to note that if you are having to much issues with a slow StoreFront you should go with 2012 since it is out-of-the box optimized ASP/IIS setup.

And it is also important to remember that Storefront should be on a dedicated server with atleast 2 GB of ram and 2 cores.

If you are having trouble with Storefront you can enable trace logging *This requires alot more CPU on the server”

Add-PSSnapin Citrix.DeliveryServices.Framework.Commands

Set-DSTraceLevel -All -TraceLevel Verbose

To disable you just need to set –TraceLevel off.
All the information will ge placed in C:\Program Files\Citrix\Receiver StoreFront\admin\trace folder on the storefront server.

#storefront, #xendesktop-7

Setup Netscaler for XenDesktop 7 and AppController 2.8

This is going to be a long one Smilefjes
Always wanted to document this myself but never had the time, so I figured why not knock two birds with one stone and blog it as well since many are probably wondering about the same thing.

This is a typical deployment for many right? You have your internal XA/XD which are tied to a StoreFront web server and for remote access you have Netscaler Gateway/AG

And depending on the setup you might have a Netscaler in DMZ behind a NAT firewall, or directly connected to the internet from the DMZ or you might have a double hop network where you have multiple DMZ sones and firewalls.

So how to tie them together ?
First I suggest you read my previous post regarding XenDesktop 7 with StoreFront and Appcontroller deployment.

Lets head over to our Netscaler deployment. We can start by cheching our network connection.

We have different types of networking within the NS, we have VIP( Virtual IP) which are typically tied to load balanced service. We have SNIP (Subnet IP) which are used to initiate a connection to the back-end servers (XenDesktop Servers, Storefront etc) and you have a NSIP (Netscaler IP which is used for management)

So for a user the connection will look like this.

User –> VIP –> SNIP –> XenDesktop (Servers)

Typical deployment is that you have a netscaler with two interfaces, one in to the DMZ and one into the backend servers. (In my case I have all interfaces connected to the same subnet.image

Next we can add authentication.
Go into Netscaler Gateway –> Policies –> Authentication –> LDAP –> Add


For named expression I choose General and True and choose Add.
((What does this do ? specifies that IF the traffic is going trough the NS appliance then this policy should be applied)

Then give it a name and choose new server and enter the information to the AD server. After you have entered the info “Press Retrieve Attributes”
Remember that this command uses the IP address of the server you are using the browser on.

If you are having trouble with authentication fire up console to the Netscaler Appliance type in shell then cd /tmp then type the command cat aaad.debug
This will display in real time information regarding the authentication tries.

After that is done, add a DNS server.


Now lets add a certificate (for this purpose I have a Enterprise Root CA on Windows Server 2012 which I used to create a web server certificate which contained the host name of the access gateway) nsgw.msandbu.local in my case and I choose to export it as a PFX file including the private key (You will need the private key!!) In production you should use a third party CA to isse a certificate to you.

You can upload the PFX file under Traffic Management –> SSL –> Manage Certificates –> then you can upload the PFX.


After this is done open Netscaler console and extract the certificate and the key from the PFX.
This can be done by running openssl from the Netscaler Console

openssl.exe pkcs12 -in publicAndprivate.pfx -nocerts -out privateKey.pem (Extract keys)
openssl.exe pkcs12 -in publicAndprivate.pfx -clcerts -nokeys -out publicCert.pem (Extract Certs)

After that is done you can install the certificate

Next we create a virtual server under Netscaler Gateway and assosiate it with an IP-address.
Since we just want ICA-proxy and no VPN (Smart Access solution) we can choose Basic Mode.
Under Protocol choose SSL (After this is done the service will go down unless you have a valid ceritificate installed)


If you go into the Authentication Tab (mark the Enable Authentication)
and under Primary Authentication Policiess choose insert policy. (By default the one we created earlier will appear)

Now if you wish to have two-factor authentication you can add another Primary authentication policy.


After this is done head over to policies. We need to add a Session Policy, here as well we use ns_true as an expression. Give it a name and press create New Request Profile.


Here we enter the information about the backend storefront servers. (NOTE I already have one stored there this is because I have created this earlier Smilefjes

Now there are a couple of options here we need to define.
First under Published Applications.
1: We have to define ICA-proxy, this will tunnel ICA traffic via port 443 back to the user.
2: Web Interface address this has to be Storefront web address.
3: Single sign-on domain should be your local AD domain. (Don’t enter anything here in case you have multiple domains)

Next is under Client Experience –>
Define Single Sign-ON to web applications using Primary Credentials, this allows the Netscaler gateway to authenticate to the Storefront site.


We have to define at the NS should use SSO to the storefront web adress using the Primary authentication mechanism which is AD in my case.

Last but not least, Security so we can allow users to actually enter.


You should also enable TCP profile for this virtual server set to nstcp_default_xa_xd_profile (This profile works best for internal usage and high bandwidth networks)


Then we also have to add STA (Of the XD controllers in my case) Go back to Published Applications.

Click Add and enter the URL of the XD controller. After you save and refresh the page it will show up like mine did now.


Remember to save the config! Smilefjes
After that is done we have head over to Storefront

Now there are a couple of things we need to fix there. First we need to add an authentication option from Netscaler.


This will allow the Storefront to authenticate users coming from  Netscaler. (To pass the credentials forward)

Next we have to go to Stores –> Enable Remote Access –> Choose Add netscaler appliance –>


Here enter the info regarding your netscaler.
SNIP here is the one that you entered inn earlier on the Netscaler, StoreFront uses this to validate that any incoming connections comes from a trusted host.
The CallBack URL is the Internal IP-address of the Netscaler.


Then you setup it as a NO VPN Tunnel and choose the Gateway appliance to use.
You also have to add the STA’s here as well.


And last but not least, Beacons.
Beacons are used to identify if the end-user comes from an internal or external connection.
For instance you can put an external beacon for a public accessable website and internal for a website that is ONLY available for internal users.

This is what decides if the ICA-file the end-user receives is going to be used via ICA-proxy or a plain ICA-connection straight to the server.


In this case since it’s a demo enviroment all are on the same network. But I could remove the nsgw as an external beacon. And just have and another external site.

Now since the AppController connected to the Storefront service we don’t need to anything else inorder to view Apps deployed from AppController.

NOTE: There is a couple of things if you are doing to deploy for instnace WorX apps from appcontroller and going to use mVPN solution to iOS and Andriod.

You will need to enable a couple of things here.
* Split-tunneling
* Clientless Access URL Encoding = Clear


You also need to enable Secure Browsing

After this is done, we can open up our virtual IP URL.
In my case it is https://nsgw.msandbu.local

Login with my username and password and start a desktop connection (For the purpose of this demonstration I have also added a weblink from AppController that points to



If you open resource monitor you can see that traffic is tunneled in port 443

And if we open resource monitor on the desktop I just launched I can see that the servers speaks via the session reliability port to the SNIP ip (Which is 60.114)

#appcontroller, #netscaler, #netscaler-gateway, #storefront, #xendesktop, #xenmobile