If you have noticed the Restart button for published desktops in Citrix Virtual Apps and Desktops 7 1912 LTSR recently and wondered why in the world Citrix would give users access to users to restart machines, you are not alone. Make no mistake, this is a perfectly fine setting to be enabled out-of-the-box for VDI deployments where just Desktop OSes are being published or on the delivery group that contains Desktop OSes. You would want your users to be able to restart the desktop every now and then anyway.
Now after going through the Citrix SDK documentation, I found the below notes for the -AllowRestart argument that governs the restart button.
AllowRestart (System.Boolean) Indicates if the user can restart sessions delivered from the rule’s desktop group. Session restart is handled as follows: For sessions on single-session power-managed machines, the machine is powered off, and a new session launch request made; for sessions on multi-session machines, a logoff request is issued to the session, and a new session launch request made; otherwise the property is ignored.
So, it isn’t too bad to have that button available for RDSH delivery groups but should probably be called something else. The name “restart” has a negative vibe to it in multi-session world. lol
The option\button will appear like the below.
How would you remove the Restart option?
You will need to do this via Powershell.
Find the delivery group that has RDSH based published desktops and take a note of the Name parameter. You can do this on all the delivery groups if you want to disable this button for all published desktops, both RDSH and VDI.
Run the below command to find the value for the delivery group that you want to turn OFF the setting for. The parameter we are looking for is AllowRestart. When the value is True, Restart button is shown. Setting it to False will remove the button from Storefront.
If you have implemented DirectAccess for your users so that they could connect to corporate network whilst they work from home, you might have come across this issue while using Citrix. Users would be able to connect to Storefront portal and authenticate themselves but when they try to launch applications it fail. Users will also notice the below Citrix Receiver dialog with no apparent error messages.
The users who connect directly to Storefront without DirectAccess have no issues to launch applications.
When you have DirectAccess enabled on user PCs, it expects hostname/FQDN values for initiating traffic between the client and the DA gateway. By default, Citrix XenApp tries to connect on IP addresses to bypass the infrastructure reliance on DNS. So, we will need to find a way to switch that behaviour to an FQDN based connection initiation.
Let’s look at the .ICA files to see what’s in there. The below screenshot is of an ICA file that shows IP addresses. This setup will NOT work for DirectAccess connections.
To fix this, you will need to change a DNS parameter in XenApp/XenDesktop 7.x farms.
You will need to change the value from False to True
Set-BrokerSite -DnsResolutionEnabled $True
Running a Get-BrokerSite after that will show that the value has been changed from False to True
Now, let’s inspect the ICA file again. You can find the ICA files from your User profile folder. I had mine under
There are times you would want to create a SAN (Subject Alternative Name) certificate for your deployments in the organization. This is a much more secure approach as compared to using a wildcard as it allows only a limited number of servers to send and receive traffic. Unless you specifically compromise one of the machines specified in the certificate, it’s too hard to impersonate and do any real harm.
In this blog post, I will show you how to create a CSR (Certificate Signing Request) using any Windows machine in the organization that’s domain joined and subsequently, use the request file to issue a certificate using the internal Certification Authority (CA) server.
Create a Certificate Signing Request (CSR)
The first step is to create a CSR file and you can use any domain joined Windows server in the organization. I have used the Citrix Storefront server in this example.
Open the MMC console and add the Certificate snap-in to it as Local Computer. Right Click Personal node on the left and Select All Tasks–>Advanced Operations–>Create Custom Request
Choose Proceed without enrollment policy and Click Next. Choose No Template Legacy Key for compatibility reasons. Use PKCS#10
Click Next and click Properties
Give a friendly name for the certificate and a description. Ensure that you hit Apply as soon as you are done with the tab.
Click on Subject tab and add all the hostnames under “Alternative Name“
Under Subject Name, enter the Common Name (CN), Organizational Unit (OU), Organization (O), State (S) and Country (C) values. Click Apply
Under the Extensions tab, expand Extended Key Usage (application policies) and select Server Authentication and Client Authentication
Under the Private Key tab, set the Key size to 2048 under Key options
P.S – Using a key size of 4096 or above will cause issues with NetScaler monitors failing if VPXs are used. MPXs don’t have this issue.
Tick Make Private Key exportable
Select Exchange as the Key type
Click Apply. Click OK
Select a location to save the file. Choose the file format as Base 64
Send the Certificate Request
Now navigate to the URL of the internal Certificate Authority (CA) server. Replace your CA server name for the <certauthority> value.
Click the Request a Certificate link.
Click the Advanced certificate request link.
Click Submit a certificate.
Paste the contents of your CSR file into the Saved Request text box. (Open the CSR file (with a .req extension) in Notepad and copy the contents without any leading or trailing spaces.)
For the Certificate Template drop-down list, select Web Server.
You get the below once you click submit.
Issue the Certificate
Connect to the server where the Certification Authority is installed, if necessary.
In the Certification Authority (Local) tree, select Your Domain Name > Pending Requests.
Select the CSR in the right navigation pane.
In the Action menu, select the ID number of the request > Issue.
Close the Certification Authority window.
Download the Certificate
In your web browser address bar, type the IP address of the server where the Certification Authority is installed, followed by certsrv.
Click the View the status of a pending certificate request link.
Select the certificate request with the time and date you submitted.
Select the encoding format for the downloaded certificate, such as Base 64 for a PEM certificate.
Click Download CA certificate to save the certificate. The certificate will have .CER extension
Install the Certificate
Navigate to the server where the certificate needs to be installed.
Open a MMC console as Administrator and add Certificate snap-in under Local Computer
Expand Personal node and right click the Certificates node.
Select All Tasks –> Import
Locate the downloaded certificate file
Place it under Personal node
Note – The installed certificate in Certificate MMC shows a little key symbol and a badge. You gotta see these 2 things for the certificate to work or show up in IIS Manager in later steps.
Export the certificate as a .PFX file
Now, you need to export the certificate as a PFX file so that this could be installed on all the other servers which doesn’t have any clue of the privaty key used while requesting the CSR. If you recall, we did the CSR from one of the Storefront servers. The PFX certificate files contains the private key which is paramount for SSL deployments.
Navigate to the server where the certificate has been already installed.
Open a MMC console as Administrator and add Certificate snap-in under Local Computer
Expand Personal node and right click the Certificates node.
Select All Tasks –> Export
Export the private key
Under the Personal Interchange Format, PKCS#12, Tick all except for “delete the private key after successful export”
Give it a password of your choice (make sure that you remember this; This is required for installing the certs on other servers)
Specify a file name to save it in a location
Bind the website in IIS
Open IIS Manager and expand the Server name and choose the Default Web Site
Under Actions, select Bindings
Add the https and select the newly installed certificate
Install the exported PFX certificate on the other servers and change the binding to https following the steps above. That’s all to it folks.
If there is anything that’s unclear, please feel free to comment or provide feedback in the comment section below.
It’s been a while since I wrote on my blog so let’s get straight into the post without much mucking around. This time we will discuss how to go about setting up Storefront load balancing using NetScalers. This can be configured on a standalone NetScaler or a NetScaler pair in HA. The recommendation is obviously to get this setup on a HA NetScaler pair so that NetScaler outage wouldn’t result in Storefront also being unavailable.
My Storefront version is 3.11 and have a cluster with 2 Storefront servers. NetScaler version is 11.1 but the NS version shouldn’t matter much as the steps would be more or less the same for other NetScaler firmware versions – newer or older. (unless you are too far behind)
To configure Storefront load balancing we need the following –
2 or more Storefront servers
an IP address for the virtual server that hosts the LB configuration
SSL certificate that points to the intended load balanced URL of Storefront – the certificate can be a wild card or a named certificate
First Things First
Logon to your NetScaler and navigate to System — Settings — Configure Basic Features. Ensure that Load Balancing is selected, if not select it and click OK
Give the Storefront server a name and enter the IP address of the server. Ensure that “Enable after creating” is selected. Click Create
Add the second Storefront server following the above steps. If you have more than 2 servers, add all of them.
New NetScaler version come with a built-in Storefront monitor so we are going to make use of it here. Go to Traffic Management –Load Balancing — Monitors and click Add
Here I am only going to create a single monitor to probe all my Storefront servers. You can choose to create multiple monitors depending upon the number of Storefront servers that you have. In my case, i will create just one.
Give a name to the monitor and select the type as STOREFRONT
Now select Special Parameters tab and provide the name of the Store that you have created in Storefront. Check the 2 entries – Storefront Account Service and Check Back End Services.
Click on the Standard Parameters tab. Ensure that Secure is selected as below. Click Create
Create Service Groups
Go to Traffic Management –Load Balancing — Service Groups
Give a name to the service group and select the protocol as SSL. Check the entries below
AppFlow Logging (only if you have NetScaler MAS in your environment)
Under Service Group Members, add the server entities that we created earlier. Once done, they will look like the below
Under Settings, type the Header as X-Forwarded-For
Under Monitors, bind the monitor that we created before
Under SSL Parameters, setup the settings as below
Under Ciphers, setup the ciphers based on your company security policy.
Once done, Service Group for Storefront should look like this
Now, it’s time to create the Virtual Server
As mentioned in the pre-requisites section , we need an IP address for this. If the NetScalers are sitting in the DMZ, a DMZ IP address is required. In my case, NetScalers are hosted internally so i will use an internal unused IP address.
We will also need the SSL certificate here.
Go to Traffic Management –Load Balancing — Virtual Servers
Give a Name to the virtual server and select the protocol as SSL
Specify the IP address under IP Address field and specify the port # as 443
Click More and specify the settings as below (note, that AppFlow logging only needs to be enabled if you have a NetScaler MAS setup or other monitoring solutions that could make use of AppFlow logs)
Under Services and Service Groups, click on Load Balancing Virtual Server ServiceGroup Binding
Click Add Binding and select the Service Group that you created in the previous step. Click OK
Once completed, the page should look like the below. Click Close and click Done
It’s time to attach the certificate. Go to Traffic Management — SSL — Manage Certificates / Keys / CSRs
Click on Upload button and upload your certificate file to NetScaler
Go to Traffic Management — SSL — Certificates — Server certificates
Under Certificate, click on Server Certificate and then Install
Give a certificate key-pair name and choose the certificate that was just uploaded in the previous step. Click Install
Now, go back to Traffic Management –Load Balancing — Virtual Servers
Select the Virtual server created for Storefront and click Edit. Under Certificates, select Server Certificate and then Click Add Binding
Under SSL Ciphers, select the ciphers that you would like to be in place. I am going with the default one. This is not the most secure for a production setup so go with something that’s secure enough for your organization.
Under SSL Parameters, configure the settings as below. Click OK
Under Method, Select LEASTRESPONSETIME for the Load Balancing Method. Configure a Backup LB Method, I choose LEAST CONNECTION
Under Persistence, select COOKIEINSERT for Persistence with a time-out value of 0. You can also read why I selected the timeout value of 0 here
Under Backup persistence, select SOURCEIP with a timeout of 60. Fill in the Netmask as in the picture
Click OK and then Done
We have now completed almost 90% of the config. There are a couple of things left so hold on tight.
The configuration so far will ensure that load balancing will be performed between the Storefront servers ( I know, i know I haven’t setup the DNS entries for the load balanced VIP)
If someone type in the http URL of LB Storefront in their browser, it will not go anywhere. It will show them the IIS page instead. So how do we ensure that the users are redirected to the correct Storefront page (https version) every single time? We will setup another virtual server on port 80 with a redirect URL configured.
Let’s do that now.
Under Traffic Management –Load Balancing — Virtual Servers, Click Add
Under Basic Settings, give the virtual server a Name and select protocol as HTTP
Specify the same IP address as for the Storefront LB VIP and provide 80 for the Port #
Under Persistence, select SOURCEIP with a timeout of 2 mins
Under Protection, type in the correct HTTPS URL that you would want the users to be redirected to under Redirect URL field
Click OK. Then click Done
You will notice that the virtual server will be marked as down
Now head over to the DNS server and open the DNS Console
Create an A record pointing to the Storefront LB name with the IP address configured on the vServer for LB configuration.
This is the last step, I promise. Head over to the Storefront servers and it’s time now to run some Powershell commands
Now, the monitors that we created earlier will be marked as Down if we didn’t perform this step prior to creating them on the NetScaler. That’s because the monitor created was based on HTTPS and by default, Storefront monitoring is done on HTTP
To change this to HTTPS. We need to configure the monitor service to use HTTPS instead. On all the StoreFront 3.0 servers perform the following steps.
Run PowerShell as an administrator.
Navigate to the Scripts (C:\Program Files\Citrix\Receiver StoreFront\Scripts) folder via the Powershell on the Storefront server,
Run the below command
Now, type the below to setup the Storefront Monitor on HTTPS
I was recently afforded the unique opportunity to collaborate on a project to test capacity out of a Citrix XenApp on AWS deployment. The goal of the project was to independently determine the maximum user density for a few different EC2 instance types running XenApp 7.14.
EC2 instances are on-demand and elastic hosted server resources. Which means that they are provisioned dynamically within a pool of available resources, and with an OS you deploy ontop. Amazon provides a variety of templates to easily install Windows, Linux or your other favorite OS. EC2 instances are broken down into a few varieties. They are optimized for storage, memory, compute or graphics. The designation before the name of the instances illustrates their configuration. G3 indicates graphics optimized instance third generation.
The other difference between instance type is the cost. If you are provisioning a 2vCPU 4GB of RAM machine the price per hour would be significantly less than that of a 16vCPU 64GB of RAM machine.
This would allow the customer to match the exact machine size to the purpose of their deployment, and optimize the amount of money they were spending on their hosted application solution.
Utilizing Login VSI’s virtual users I ran a predetermined user count against a Citrix XenApp deployment managed from Citrix Cloud.
For this blog, I will only discuss one data point, and the Citrix Cloud configuration on AWS. We have a significant amount of results, and we will make those available on www.loginvsi.com/blog.
For those of you not familiar Citrix Cloud is providing Citrix capabilities traditionally delivered on premise through a HTML web based user experience therefore installing a receiver is no longer required.
Some of the key components as they move into their cloud forward offerings are StoreFront / Netscaler and Studio.
StoreFront and NetScaler are completely managed now through a web page. This completely removes the administrator’s responsibilities of configuring hardware / software solutions for Citrix. You simply fire this up, attach it via their “Citrix Cloud Connector” and configure to start deploying your desktops or apps. It works completely flawlessly.
Studio is managed through the connector as well, and provides the Citrix HTML 5 receiver for management access through the Citrix Cloud web portal.
During my time working with it, it proved to be very flexible, easy to configure and reliable for all testing. I would recommend this to any administrator looking at future proofing their Citrix deployments. It is truly ready for market.
Some images below of the management interface:Some images below of the management interface:
There will be a management icon within your Citrix Cloud Dashboard. Select “XenApp and XenDesktop Service” “manage”
You will then go to the management interface for XenApp / XenDesktop; you have two options Creation and Delivery. Creation – Studio / Delivery – StoreFront / NetScaler:
Management interface for Studio. Notice the Citrix Receiver icon in the middle. Studio is provided through the Citrix HTML 5 receiver. Interesting touch.
Management for Citrix NetScaler / StoreFront:
AWS Configuration for demonstration purposes:
Delivery group configuration:
There is only one XenApp host in each delivery group. This is to determine the maximum amount of users for one M4.
2XLarge instance backing the XenApp host. We are delivering Office 2016 applications, and the standard set of VSI Knowledge worker actions.
It is very easy to change the instance type in EC2. You simply select the “Instance” and change the “Instance Type” through the context menu.
There are a variety of different configuration, which allows you to really get the most out of the testing. If you are aiming for user density numbers you can size it exactly. This allows you to pay for EXACTLY what you need as opposed to over provisioning. This will help drive the cost of VDI / SBC deployments down ultimately, and increase end user experience quality.
If you are sizing your images with Login VSI and backing them up with EC2 AWS instances you are getting an optimal user experience exactly sized right for your needs.
For our testing purpose we provisioned a m4.2xlarge machine on EC2. This instance has a machine profile of 8 vCPU and 32 GB of memory. This is either running a XENO E5-2686 or 2676. Mostly a general use machine which is balanced.
Our testing configuration was 50 test users over the course of 48 minutes. We utilized the industry standard Knowledge Workload. This mostly presents a large portion of the VDI / SBC user base. Office application and standard office applications like Adobe Reader.
Application start times are all over the place for the most part, but staying for the most part under 12 seconds. Which would be reasonable for the users. Login process takes under 16 seconds even under VSI Max settings.
What does the backend look like?
When the CPU is at 100% the VSIMax is being reached within the user session. This means the numbers are indicating the bottleneck to be the CPU provisioned for the M4.2Xlarge instance which is approximately.
Seeing is believing and after testing it I can confirm that Amazon EC2 is ready for the prime time. We were able to support 42 concurrent users on a M4.2Xlarge and we were able to have a continuous level of excellent user experience while doing so.
Amazon is ready to supplement your traditional on premise solutions with readily available and quickly scalable resources in the cloud. Using Citrix Cloud services you can very easily scale your delivery out to support your user base as it dynamically changes.
Using VSI you can validate your configurations with support your users and put a check box next to user experience.
Using these three solutions you can future proof your company, and deliver on a promise of value & experience
Finally, if you are looking for some testing for your deployment please reach out to me here or email@example.com.