Finetuning a Citrix StoreFront deployment
In this short blogpost I gathered some fine tuning tips I came across with when migrating a Webinterface deployment to Storefront with Netscaler Gateway. The deployment had the following main goals :
- Access from Receiver for Web and all the Native Receiver versions (Windows, IOS, Android, etc)
- Security on the client side is important, access takes place from unmanaged and public devices
- Performance needs to be comparable with the Webinterface deployment
- Customized branding for each Netscaler VIP
In this blogpost I will cover the following :
- Prevent users from saving passwords
- Shorten the login token lifetime
- Increase performance (page load times, etc)
- Modified homepage for different VIPs on the Netscaler
- Workspace Control in combination with XenApp published desktops
Prevent users from saving passwords
Saved passwords may give users easy access to the environment, but it decreases the security of the environment, especially on unmanaged and public devices where it’s unknown how the devices are used and by who. To turn password saving off :
For Receiver for Web :
This is done automatically by the login page from Netscaler by telling the browser not to use the autocomplete feature. Most browsers respect this setting but IE 11 ignores it, you can read more about this here. It is recommended to always use 2-Factor authentication for external access when possible. To expensive? Take a look at SMS2, it’s free and the RADIUS extension works pretty neat in combination with Netscaler Gateway.
For Native Receivers :
Open the Authenticate.aspx file (default location : C:\inetpub\wwwroot\Citrix\Authentication\Views\ExplicitForms) and comment the SaveCredentialsRequirement statement like this :
This will prevent the save password option from showing in the Native Receivers.
Shorten the login token lifetime
When a user logs on through the Native Receiver, the credential wallet service of Storefront will keep your token alive for 20 hours by default. When a user closes his application or desktop but doesn’t logoff the Receiver, it’s possible that someone else can click on the icon to log back on within this time period. This is not really secure when users are sharing devices or leave them unattendant. Receiver for Web is somewhat resticter, by default the page will timeout after 20 minutes idle time.
If you only publish a desktop and your users doesn’t need to click on published application icons the whole day, you can make the life time as short as possible without affecting the user experience. In the following example I will change the token life time to 5 minutes for both Native Receiver and Receiver for Web.
For Receiver for Web :
Open the web.config file in the Receiver for Web site folder (default location : C:\inetpub\wwwroot\Citrix\yourwebstore) and search for the session state timeout.
The value is in minutes :
For Native Receivers :
Open the web.config file in the authentication folder (default location : C:\inetpub\wwwroot\Citrix\Authentication) and search the maxLifetime values till you found the correct one, see this example :
After making this changes, users have to authenticate again after 5 minutes idle time.
Increase performance (page load times, etc)
After some tweaking the Storefront performance is good and acceptable, but it will not be as quick as Webinterface. I also think this isn’t possible because of the design differences. I changed 2 things to speed up Storefront : Enable socketpooling and disable signature verification (the latter will lower the security a bit).
On Marius Sandbu’s and Richard Egenas blog you can read more Storefront performance tips.
Modified homepage for different VIPs on the Netscaler
This deployment needed a customized branding for each Netscaler VIP, I will not go into detail how to configure this because there is already a very detailed article from Citrix here. It comes down to redirecting users based on the entered FQDN with Responder policies, while this works great the article doesn’t mention that it will break the access from the Native Receivers to the VIP where the responder policy is active. To prevent this change the responder policy expression to include :
When you create this exclusion, the Responder policy will not kick in when the User-Agent contains CitrixReceiver, allowing the Native Receivers to successfully connect.
Workspace Control for XenApp published desktops
When you publish a desktop through XenApp you will notice that Workspace Control isn’t working like expected in Storefront. This is because the desktop is shown on the Desktop tab and Workspace Control isn’t enabled there. Instead autolaunch is enabled which is also killing for single session control. If you want to use Workspace Control you need to treat the desktop as application by using the TreatAsApp keyword. You can read more about Workspace Control in combination with Storefront in great detail in a previous blog post : Deeper look into Workspace Control and it’s challenges.
Conclusion
I must say I like Storefront, it’s stable (talking about the latest versions of course), looks good and gives users an unified login experience, but I have some wishes left so in case someone from Citrix read this, here are my feature requests for Storefront :
- More options in the GUI, manual editing the web.config files feels a little silly and can be error prone. If the goal is to keep the console simple, then I would suggest an option to switch to advanced view
- More informative messages for the users, for example Webinterface shows when a Desktop is (re)starting and cleaner messages when applications are disabled etc
- Redirect users to a specific Store (when using Native Receiver), now the user gets a popup to select a store but it will be nice to control this in a session policy or directly in Storefront
Please note that the information in this blog is provided as is without warranty of any kind.
BramWolfs.com 