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.

Automation of a XenDesktop/XenApp deployment – Part 2


As I discussed during my previous blog there are many parts necessary for a fully functional Citrix XenDesktop / XenApp environment.  In this part of the series we are going to cover the Citrix Licensing server.

The blog will be shorter than the previous blog due to the fact that there is only one component to the Citrix Licensing server. However, we will also cover how to deal with a known issue during automation which is related to automation leaving the license location in the License server empty.

The command line switches for automation of the license component is again very straight forward.

XenDesktop/XenApp Licensing Server

Example – C:\{Location}\x64\XenDesktop Setup\XenDesktopServerSetup.exe /COMPONENTS LICENSESERVER /NOREBOOT /QUIET /CONFIGURE_FIREWALL

This will install the License Server portion of a XenDesktop/XenApp deployment silently and defer the reboot.  You can run this string as many times as you would like and the end result will be the same.

Based upon my experience with automation I have discovered a known issue which is that within the License Server configuration the location of the specified license file will be blank.  This can lead to issues with functionality.

Know Issue with unattended installation

We can automate address this issue through PowerShell.  Below I will outline how to do so.  The company that I work for make a software solution for managing your PowerShell solutions.  This will provide you with a centralized location for management of your scripts, and assist with WHEN the scripts will be executed.  Additionally, you can design your solution 1 time and utilizes the solution anywhere when deploying XenDesktop / XenApp.

  1. Stop the Citrix License Server service
    1. This is done through a net stop command
  2. Parse through the license server configuration xml file located at
    1. C:\Program Files (x86)\Citrix\Licensing\LS\conf\server.xml
    2. This can be done by piping the contents of the XML file into a variable
    3. $serverxml = [xml] (Get-Content -path “C:\Program Files (x86)\Citrix\Licensing\LS\conf\server.xml” )
    4. You have now captured the contents of the XML file
  3. Locate within the XML file where the license file is specified, under the following value and assign it to a variable
    1. $element = $serverxml.configuration.licenseServer.vendorDaemons.daemon
      1. Where-Object {$_.executable -eq “CITRIX”}
    2. Write the value of your licensing file into the XML file
      1. $element.license = “The location of your license file”
    3. Save the server.xml file
      1. $serverxml.Save
    4. Start the Citrix License Server service

 

Bonus points – You could also utilize this level of automation to quickly replace the licensing file within your deployment in an automated method vs. manually going through the License Server web interface.  IE – Whenever it would be time to change out your license file simply replace the file and run the script.

In my next article in the series we will be outlining the process for deployment of the Citrix Studio portion of your XenDesktop / XenApp.  If you have any tips or tricks that could be helpful.  Please share I would love to share ideas, and share any information you are aware with the rest of my readers.

Automation of a XenDesktop/XenApp deployment


There are many pieces involved in deploying Citrix XenDesktop/XenApp.  For simplification purposes while discussing automation, let’s focus on a single feature of a Citrix deployment- the Delivery Controller.

The Delivery Controller is responsible for delivery of either applications or desktops to end users.

The components of a Delivery Controller are:

  • Database – SQL – Pre-requisite
  • Application – Citrix Delivery Controller

Installing each of these components individually is straight forward.  The applications are packaged in such a way that you can utilize a few switches to install the software.

SQL

Example – C:\{Location}\setup.exe /QUIET /IACCEPTSQLSERVERLICENSETERMS /ACTION=install /FEATURES=SQL,Tools /INSTANCENAME=MSSQLSERVER /SQLSVCACCOUNT=”NT Authority\Network Service” /SQLSYSADMINACCOUNTS=domain.local\Administrator /AGTSVCACCOUNT=”NT Authority\Network Service”

This will install SQL on a Windows Server OS silently, and create a database named MSSQLSERVER.

The same can be done with the Delivery Controller.

XenDesktop/XenApp Delivery Controller

Example – C:\{Location}\x64\XenDesktop Setup\XenDesktopServerSetup.exe /PASSIVE /NOREBOOT /CONFIGURE_FIREWALL /COMPONENTS CONTROLLER /NOSQL

This will install the Delivery Controller portion of a XenDesktop/XenApp silently, deferring the reboot and not installing SQL. You can run this string as many times as you would like and the end result will be the same.

Now, let’s get fancy.

In order for the Delivery Controller to function a “Site” must be present.  A site contains all of the data necessary for a Delivery Controller to function, and is stored in your SQL database; this includes configuration and logging information.

A site is the first step necessary to deliver resources with Citrix for your end users.  With PowerShell you can configure this without user interaction, thus enabling you to automate the deployment process.

You will need 3 databases:

  • “Site”
  • “Configuration”
  • “Logging”

 

You can utilize PowerShell to create these with the “New-XDDatabase” command.  This is a function of the “Citrix.XenDesktop.Admin.V1” PowerShell snap-in.  This will enable you to create the three database necessary for a “Site” to function properly.  Once the databases are created, you can create your “Site”.

You can utilize PowerShell to create your “Site” with the “New-XDSite” command.  This is a function of the “Citrix.XenDesktop.Admin.V1” PowerShell snap-in as well.

XDDatabase

Combining packages from Microsoft, Citrix and PowerShell, you are able to automate the process of creating your first “Site” for a critical component of your Citrix deployment, the Delivery Controller.

There are many platforms for managing, and executing your collection of automation frameworks.  Some of the popular ones are Chef, Puppet and Login AM.  It creates a logical organization structure for doing so, variables necessary and provides an interface for management.

If you are interested in finding out more about this, please get in touch with me.

Also, if you have any neat tricks with PowerShell please share them in the comment section.  Happy automating.

I will be following this post up with articles about the remaining components of Citrix.

Article 2 in the series is now live! See it here – Automation of a XenDesktop/XenApp deployment – Part 2

Article 3 online – Automation of a XenDesktop / XenApp Deployment – Part 3

Stay-Tuned-button-1024x192

What happens when you reset Citrix Receiver?


Hello Folks,

Have you ever wondered what happens when Citrix Receiver is reset?  There are times when Receiver needs a bit of love and care from the Citrix admins. I came across an issue recently where I had to reset Receiver client and thought I should put this down on what gets removed and what gets retained for future reference.

Resetting Receiver to factory defaults removes the following items:

  • All accounts and stores.
  • All apps delivered by the Self-Service Plug-in, along with their icons and registry keys.
  • All file type associations created by the Self-Service Plug-in.
  • Cached files and saved passwords.
  • Per-user registry settings that are user preferences and, for per-machine installations, all user-specific registry settings.
  • NetScaler Gateway registry settings for Receiver.

 

Resetting Receiver does not impact the following items:

  • Receiver or Plug-in installation.
  • Per-machine ICA lockdown settings.
  • GPOs.

How do you reset Receiver?

CLI Method

You can also use the  command line interface to reset Receiver or try and create a script for the same:

“C:\Program Files (x86)\Citrix\ICA Client\SelfServicePlugin\CleanUp.exe” -cleanUser”

GUI Method

Right click the Receiver icon in the notification area and select Advanced Preferences

In the dialog, select Reset Receiver and click OK

receiver

Quick shout out to Trishanka Saikia from Citrix Technical Support for this info.

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