AUTOMATION OF A XENDESKTOP/XENAPP DEPLOYMENT – PART 3


This article will cover how to install the Citrix Studio component.  For those of you who are unfamiliar this will act as your centralized point of control for your Citrix environment.  You can also interact with it as you’ve seen in previous examples through command line operations as well.

In order to install the Studio for management the process is straight forward.  Run the executable with a few switches –

[C:\Downloads – “Your download location”]\x64\XenDesktop Setup\XenDesktopServerSetup.exe /PASSIVE /NOREBOOT /CONFIGURE_FIREWALL /COMPONENTS DESKTOPSTUDIO

Once your Studio component is installed, you can validate the installed components by reviewing their accessibility form your server where the command was executed.

Studio

Next up would be installing your StoreFront component.  This will provide front end access to your delivered applications and desktops.

StoreFront

The process is the same.  Utilizing your Citrix installed, you will call the following executable with the following switches:

[C:\Downloads – “Your download location”]\x64\StoreFront\CitrixStoreFront-x64.exe -silent -logfile “%am_logpath%\StoreFrontSetup.log”

For adding additional Storefront servers to a load balanced group, you can utilize a variety of different scripts to determine if the server is already part of a group, and if not join it.

Creates a script to review if the Citrix services are running on the server where the scripts are executing, and if so join the new StoreFront sever to a group. If not create a group of its own.

Set a conditional statement to evaluate the value of this being returned, and execute one of the following scripts.

For Creating:

Set-DSInitialConfiguration -hostBaseUrl [Hostname]-farmName [FarmName] -port [ListeningPort] -transportType [TransferType] -sslRelayPort [RelayPortforSSL] -servers [ServerToAdd] -loadBalance [LoadBalancer] -farmType [FarmType] -clusterId [ID]

 

Or, For Joining an Already Existing:

Obtain the passcode and store value –

Start-DSClusterJoinService

$Passcode = (Get-DSClusterJoinServicePasscode).Response.Passcode

and finally join,

Start-DSClusterJoinService

Start-DSClusterMemberJoin -authorizerHostName $ExistingNode -authorizerPasscode $JoinPass

 

The final portion would really only be interesting if you were automating the same process over and over again.  This is where a product like Login AM which organizes your scripts, and variables would become handy.  If you are interested in any information about Login AM or automation of Citrix Deployments please reach out and let me know or drop and comment I would like to have meaningful conversations about automation, and increase my understanding of the products as well.

The curious case of NetScaler access with error message ” The Connection to “Desktop” failed with status (Unknown client error 1110)”


I was pulled into to look at a problem for one of our customers with their Netscalers which stopped the user connections intermittently throwing a very “helpful” error message ” the connection to the desktop failed with status (unknown client error 1110).

The customer description was “it only started to happen a few weeks ago and these days its quite impossible to land a successful connection from the outside of our corporate network”

I managed to get a couple of screenshots of error messages from the users and they appeared like below. When queried, the internal access via Storefront is working fine.

image001

Looking at the error message, there are a multitude of reasons why you would get that and i am outlining the common areas to look in such cases.

  • Check if the Root certificates and intermediate certificates are available on the client devices. If frequently patched, the client will most probably have the latest and update Root CA’s from various public CAs. Check the IE’s / Other browsers’ certificate store to verify the Root and Intermediate CA SSL certs
  • If using non-IE browsers for connectivity, switch over to IE to see if it connects. IE is the safest bet when it comes to connectivity to Citrix environments.
  • Check for SSL ciphers attached to the NetScaler Gateway vServer. If high security ciphers are used, this issue may occur. relax the cipher suites to see if that makes a difference. Again, if cipher suites are an issue, the issue will occur every single time when you connect and not sporadically.
  • Check the STAs on the NetScaler and ensure that it matches with the STAs configured on the  WI/Storefront. This is one of the most important setting to check and probably the first one to check if the issue occurs only sporadically. There is a high possibility of an STA mismatch as it turned out to be in my case.
  • Check the FW from the NetScaler to the VDA – As the title says ensure that the Citrix ports to the VDA are open from the Netscaler

XenApp & XenDesktop 7.x – Citrix Director Load Balancing using NetScaler


Here is a quick and easy way to load balance your Citrix Director instances in a XenApp or XenDesktop environment.

Below is my environment

  • Citrix Director servers ( Controller servers in most cases) – director-1 and director-2
  • A NetScaler HA pair ( you can do this on a stand alone NetScaler as well)

 

Monitors

Firstly, create a monitor for the Director services

Navigate to Traffic Management >Load Balancing >Monitors and click Add

mon1

Give it a name and select type as HTTP ( if there are no SSL certificates installed on the Director servers). Click on the Special Parameters tab and under the HTTP Type box, enter GET /Director/LogOn.aspx?cc=true

mon3

Before you click Create, ensure that it is enabled and Secure box is ticked if SSL certs are being used.

mon4

Click Create

Servers

  • Second step is to create Servers

Navigate to Traffic Management >Load Balancing >Servers and click Add

mon5

Add your Director servers here

mon6

Similarly, add the second Director servers as well

Service Groups

  • Now create the Service Group

Navigate to Traffic Management >Load Balancing >Service Groups and click Add

mon7

Give the Service Group a name and protocol is HTTP and click OK

mon8

Now Edit the service group that was just created and click on Service Group members and add the newly created services, director-1 and director-2

mon9

Once added, it will look like the below

mon10

 

Click Close. Click on the Monitors link as below and add the monitor that was created in Step 1

mon11

Once add the screen will look like the below. Click Close

mon12

The service group will look like the below once the above steps are completed.

mon13

Click Done

Responder Policy

A Responder policy needs to be created to redirect the users from the root of the IIS web server to the Director page.

Please note that Responder feature may need to be enabled first before you can use it.

Click on the + sign next to AppExpert and select Responder. Right click and choose Enable Feature. The yellow exclamation mark will disappear when you do that.

Once enabled, Navigate to AppExpert >Responder > Actions

mon14

Now think of a nice name to call the load balanced Director instance. you will need to add a DNS host entry later on for this name. the name that i have chosen is director

Give it a descriptive name and use the drop down for Type to select Redirect

Under Expressions, type the string here with the quotes as below

"http://director.domain.co.nz/Director"

mon15

Click Create

Time now to create the Responder policy. The one that we created earlier was a Responder action.

Give a descriptive name to the Responder policy and under the Action drop down menu, select the name of the action that was created in previous step. Under the Expressions field,  type

HTTP.REQ.URL.CONTAINS(“Director”).NOT

mon16

Click Create

Virtual Server for Load balancing

Reserve an IP address to use for the virtual server.

On the left, navigate to Traffic Management >Load Balancing >Virtual Servers and click Add on the right. Give it a name and select the Protocol as HTTP

Specify the IP address for virtual server and the port number as 80. Click OK.  Note that in production environments, use secure Director access by using an SSL certificate. For the purpose of demo, we are using an unsecure connection

mon17

On the page where it says, Services and Service Groups, click No Load Balancing Virtual Server ServiceGroup Binding

mon18.PNG

Add the service group that was created in earlier steps

Click Continue

On the right hand side under Advanced Settings, Click Persistence

Select SOURCE IP as the Persistence and change the timeout value to 245 ( the default time out value for Director is 245 mins). Leave the rest of the settings as defaults and Click OK

mon19

Now, move on to the right hand side again and select Policies

Select Responder as the policy and Type as Request and click Continue

mon20.

Select the redirect policy created earlier and click Bind

mon21

Click Done

Ensure that the virtual server is marked as UP in green.

DNS Config

Create a host A record in DNS for the name which in my case is director

Test the Director URL and ensure that it redirects you to the correct URL and also login and confirm that Director is usable.

That’s all you need to do to setup Director load balancing using NetScaler.

 

 

 

 

Filter applications in Storefront or Receiver for Web


There are times when you want to only show selected applications in Storefront (Receiver for Web). the below is how it can be achieved.

Firstly, update the keywords for all the application that you want to be showed in Receiver for Web. For eg, I updated the description field to KEYWORDS:ShowOnly

Secondly, logon to Storefront server and navigate to the scripts folder and run the below commands

C:\Program Files\Citrix\Receiver StoreFront\Scripts> .\ImportModules.ps1

Then run the below command

C:\Program Files\Citrix\Receiver StoreFront\Scripts> Set-DSResourceFilterKeyword -SiteId 1 -VirtualPath /Citrix/Legacy -IncludeKeywords @("ShowOnly")

Thats all you need to do. the applications with the description updated to KEYWORDS:ShowOnly will be the only apps that will be shown. /Citrix/Legacy is the path of the Storefront store.

If you are wondering how to get rid of the + sign at the left of the Receiver for Web page, then disable the User Subscription for the store.

The above has been tested on Storefront 2.6 and the same should work on other Storefront versions but please apply these with caution on Storefront versions other than 2.6.

Storefront Multi-Site and High Availability – Guidelines for an Active-Active datacenter design


I am currently working on a XenDesktop 7.6 project that is designed to span 2 datacenters, Auckland and Sydney. One of the critical customer requirement is to redirect the user connections to their primary site regardless of their location first and failover to secondary site if the primary site is down. They also have a bunch of call center users in Manila, Philippines who should be assigned to primary site Sydney and Auckland as a failover site. Auckland users must be directed to Auckland XenDesktop site and Sydney users must be redirected to Sydney datacenter for their primary apps and desktops. There were also some additional requirements that are outlined below. In summary, the below are the technical requirements

  1. Redirect users to their nearest NetScalers
  2. Provide single published application icons for the same applications across both sites so that the application access is seamless to the user
  3. Users will be mapped to a primary site( Auckland or Sydney) and will need to failover to the secondary site in case of primary site unavailability
  4. Provide a single URL for application access for the users in all the sites, Auckland, Sydney and Manila.
  5. Any unique applications from both sites should be enumerated.
  6. There are certain applications that should be launched from one particular site for all the users due to the application backend requirements (limitations)

How do we achieve the above? This was something that was impossible to do with Citrix Web Interface up to versions 5.4. Wait, there is some hope.

XenDesktop Site Details

Auckland XenDesktop site consists of XenDesktop 7.6 site alongside Storefront 2.6 cluster with 2 nodes and NetScaler 10.5 for GSLB.

Sydney site also has a distinct XenDesktop site with a SF cluster with 2 nodes and a NetScaler for GSLB ( All same versions as in Auckland)

Design

Let’s look at how each element should be designed to achieve the above stated requirements.

Requirement 1 – Redirect users to their nearest NetScalers

This is quite an easy one and we would have done this countless times in our previous projects – yes, the good old GSLB ( Global Server Load Balancing). I am not going to reinvent the wheel here as there are some fantastic literature about this already from Citrix and from Carl Stalhood. I recommend the one from Carl as he has the latest one based on NetScaler 10.5

Requirement 2 – Provide single published application icons for the same applications across both sites so that the application access is seamless to the user

I am sure this is quite new to a lot of people out there, at least for me it was. This is where Storefront comes in. Citrix has built some excellent intelligence around Storefront to achieve this quite easily. This feature is technically called Resource Aggregation. There is an good explanation on this from Citrix here which i recommend every one to read. The key for this to work is to keep the application and desktop names the same across both XenDesktop sites. The path of application executables must also match for this to work. if there are differences, then they will be shown up as separate applications.

Also please note that AppController applications cannot be aggregated via this method.

Here is an excerpt from Citrix edocs on the above with changes relevant to my setup “Where a desktop or application with the same name and path on the server is available from both Sydney and Auckland, StoreFront aggregates these resources and presents users with a single icon. This behavior is a result of setting the aggregationGroup attribute to AggregationGroup1 for both the Sydney and Auckland deployments. Users clicking on an aggregated icon are typically connected to the resource in their location, where available. However, if a user already has an active session on another deployment that supports session reuse, the user is preferentially connected to the resource on that deployment to minimize the number of sessions used.”

Requirement 3 – Users will be mapped to a primary site( Auckland or Sydney) and will need to failover to the secondary site in case of primary site failure

The idea here is to split the users into 2 groups and assign them a primary site – In the end, one group will have the primary site assigned as Auckland and the other with primary site assigned as Sydney.

The key here is to add the users to separate AD groups for each sites and configure the XenDesktop sites/farms in a specific order (Manage Delivery Controllers in SF) and use the word “Failover” in Storefront configuration. I will get to this in detail in the Setup section below.

Requirement 4 – Provide a single URL for application access for the users in all the sites, Auckland, Sydney and Manila.

GSLB could do this quite easily. Please refer to the above links

Requirement 5 – Any unique applications from both sites should be enumerated.

This is already explained in parts under Requirement 2. If there is a case where any unique applications are to be delivered from one site for all the users, all that is required to be done is to publish that application in the relevant site. The application will appear when the enumeration is done and clicking it will take the users to the site from where the application is published.

Requirement 6 – There are certain applications that should be launched from one particular site for all the users due to the application backend requirements (limitations)

This use case is relevant when there are 2 or more applications with the same name across datacenters and you would need your users to always go to one datacenter to launch it. if the application isnt available at the primary datacenter, then it will be launched from the secondary datacenter. This is done by adding “Primary” and Secondary” keywords in the application description. Doing this will override the application load balancing/Failover rules specified above and will attempt to launch first from the Primary site. if the primary site app isn’t available for any reason, launch it from the Secondary site.

How this is all setup in Storefront

All the configurations are made in Web.Config file residing on the Storefront servers. Please also note that the changes must be made to the config file of the Stores and not the Web version of the Stores.

Now before you get started with the configuration, there are a few things that you need to have beforehand to make your life easier. XML Notepad will be one of them and the other will be the sample configuration from Citrix which could be found here

I recommend using XML Notepad as it makes the Web.Config file look ridiculously simple.

Getting Started

Create the Store as you usually do via Storefront Console. Update the information under “Manage Delivery Controllers”. Also ensure that you add the secondary site info as well in here now. This piece is very important in the process as the names that are used here will be reused in the Storefront configs later on in the Web.Config file. Once you make changes to Web.Config file, you cant change the “Manage Delivery Controllers” section via the GUI anymore for that store.

My Sydney Storefront cluster store will look like this after configuration. Please also refer the order of the sites – very important. First one must be Sydney followed by Auckland.

Sydney Site is called SYD and Auckland site is called AKL

Capture7

Those who have keen eyes must also have noticed that the “Edit” button is missing from the above. This is the file after the changes are made.

My Auckland Storefront cluster will have the above settings reversed.

Now create 2 AD Groups – One to host Sydney users and another one for Auckland Users. Add the users accordingly to it.

Get the SID of these groups – I used Sysinternals PsGetSid tool

Now to the main part, Web.Config file changes

Web.Config file

All StoreFront store configurations can be found in the respective web.config file  .\inetpub\wwwroot\Citrix\\web.config.

This is where we add the configuration for StoreFront High availability.

For convenience, I made a backup copy of the web.config file before making any changes.

As you will be making a lot of changes it is much simpler to edit the file direct on the server and not have to keep copying it back and forth to your machine each time.

I recommend you copy the example configuration from Citrix from here

Then in XML notepad, expand citrix.deliveryservices –> resourcesCommon and delete anything underneath resourcesCommon

Then right click citrix.deliveryservices and click paste.

Your web.config should now look like this

Capture8

Delete 2 references to “equivalentFarmSet” under the node “equivalentFarmSets” and the config file should look like the below. You would also need to remove one “farm” and a backup reference. Overall It should look like the below. If it doesn’t, you are not going to achieve what you need.

Capture9

Now start populating the data values on the right and mine looked like the below after the config.

Capture10

The ones marked with red dots are descriptors so you could add what you like there.

Once you have done that, you have half of the logic in place. now for the other half, copy the node “UserFarmMapping” and paste it under “UserFarmMappings”. Look for the extra “s” XD

Once copied, you will need to reverse the entries for the failover to work. The copied part looked like this after the final config

Capture12

This is the final configuration below for the Sydney Storefront cluster. Save the Web.Config file. Close the file. Make sure that the changes are propagated to the other SF servers in the Sydney cluster using the GUI.

Capture13

Now, I will have to repeat the same process for the Auckland Storefront cluster in residing in Auckland datacenter

Just reverse all the settings that are made above and to those who are still confused on how it all should look like at the other end, below are a couple of screenshots from Auckland side.

Capture14

This is how the Store config is via the GUI in Auckland. Look at the order as I want the Auckland site to be processed first followed by Sydney controllers

Capture15

Citrix Studio Configuration

Add the Auckland_Test_Users AD group to the Delivery Group in Auckland site.

Capture16

Now how do you get the failover to happen to Sydney for Auckland users?? Well, create another 2 groups – one for Auckland and another for Sydney. use the Sydney group and add it in Auckland Delivery group. I didn’t talk about the extra 2 groups in the beginning to keep it simple. In fact you will need 2 AD groups per datacenter site. In my screenshot above, i used an account for testing – sydctxuser

Now the Sydney Delivery group is configured as below

Capture17

Please note that the Auckland account is added for failover. Use the second Auckland group in here in a production setup.

There you have it. You have a storefront that is intelligent enough enough to route the users based on their mappings and provide high availability. Also here is a copy of the configuration part of the web.config file as a sample below. Just change the items marked in BOLD except for “Default” entries

Capture18

 
<resourcesWingConfigurations>
        <resourcesWingConfiguration name="Default" wingName="Default">
          <userFarmMappings>
            <clear />
            <userFarmMapping name="Sydney_user_mapping">
              <groups>
                <group name="BCS\Sydney_Test_Users" sid="S-1-5-21-1752688384-406871208-1000598102-10304" />
              </groups>
              <equivalentFarmSets>
                <equivalentFarmSet name="SYDNEY" loadBalanceMode="Failover" aggregationGroup="AggregationGroup1">
                  <primaryFarmRefs>
                    <farm name="SYD" />
                    <farm name="AKL" />
                  </primaryFarmRefs>
                  <backupFarmRefs></backupFarmRefs>
                </equivalentFarmSet>
              </equivalentFarmSets>
            </userFarmMapping>
            <userFarmMapping name="Auckland_user_mapping">
              <groups>
                <group name="BCS\Auckland_Test_Users" sid="S-1-5-21-1752688384-406871208-1000598102-10303" />
              </groups>
              <equivalentFarmSets>
                <equivalentFarmSet name="AUCKLAND" loadBalanceMode="Failover" aggregationGroup="AggregationGroup1">
                  <primaryFarmRefs>
                    <farm name="AKL" />
                    <farm name="SYD" />
                  </primaryFarmRefs>
                  <backupFarmRefs></backupFarmRefs>
                </equivalentFarmSet>
              </equivalentFarmSets>
            </userFarmMapping>
          </userFarmMappings>
        </resourcesWingConfiguration>
      </resourcesWingConfigurations>