Tag Archives: Citrix

Puppet – Deploying CVAD 1912 CU1 Delivery Controllers

Puppet – Deploying CVAD 1912 CU1 Delivery Controllers

Introduction

This article explains how to use Puppet to perform unattended installations of a Citrix Virtual Apps and Desktops 1912 CU1 Delivery Controller automatically.

Test Environment

For this article I’ll be using an already deployed Puppet Master server on CentOS which has a very basic manifest configured to Domain Join any Windows machines when the puppet agent contacts the server.

My manifest files is named lab-setup.pp and is stored under /etc/puppetlabs/code/environment/production/manifests.

Active Directory is also configured in the environment with DNS and a network share created to hold the CVAD 1912 CU1 installation files so that they can be called as part of the Puppet manifest directives.

The CVAD Delivery Controller Server itself is a flat install of Windows Server 2019 Standard Core Edition (Not supported by Citrix) which already has the puppet agent installed, configured, and running on it. The server has also been joined to the Domain via puppet (see my article Creating A Domain Join Declaration For All Windows Machines for details on how to do this) and the DOT Net 4.5 Core feature applied as part of my standard OVF build for deploying servers through Bolt.

Installing the Delivery Controller using Puppet

The following steps will allow a Citrix Delivery Controller to be installed automatically using Puppet. The installation selects only the Controller and Director components to be installed.

  • Connect to the Puppet server over SSH
  • Open the lab-setup.pp file (I use vi as I’m on CentOS)
  • The First thing to do is declare the nodes this resource will apply to:
######################################
# LAB-DDC Servers Configuration
######################################

node /^(lab-ddc01|lab-ddc02).lab.lost-it.org$/ {
  • The next piece is to add the package resource as follows:
package {"Citrix Virtual Apps and Desktops 7 1912 LTSR CU1":
     ensure => installed,
     source => "\\\\lab-shares\\software\\CVAD-1912-CU1\\x64\\XenDesktop Setup\\XenDesktopServerSetup.exe",
     install_options => ['/COMPONENTS',
     'CONTROLLER,DESKTOPDIRECTOR',
     '/disableexperiencemetrics',
     '/nosql',
     '/quiet',
     '/configure_firewall']
     }
  • The final piece is to add in a reboot as follows:
reboot {'ddcserver_reboot':
 message => 'DDC Install has requested a reboot',
 when => pending,
}
  • Save and exit the manifest file

Puppet Code Explanation

Below is a breakdown of the CVAD DDC Server install code piece by piece to show what means what and why it’s being used:

  1. node /^(lab-ddc01|lab-ddc02).lab.lost-it.org$/ { – Node declaration using pattern matching to apply to two different DDC servers
  2. package {“Citrix Virtual Apps and Desktops 7 1912 LTSR CU1: – The Display Name for the application as shown in Control Panel as this is what is used by the Puppet package resource to check if the software is installed.
  3. ensure => installed, – Used to check that the software is installed and if not execute the install
  4. subscribe => Class[‘domain_membership’], – Subscribes to a previous class resource to ensure that PVS Server is only installed once the server has joined the domain.
  5. source => “\\\\lab-shares\\software\\CVAD-1912-CU1\\x64\\XenDesktop Setup\\XenDesktopServerSetup.exe”, –
  6. install_options => [‘/COMPONENTS’, – Defines the install options to be passed to the installer. The square bracket is used to allow specifying sets of options on different lines. The important part for using this method is that puppet will put double quotes around each of the following lines and separates them with a space.
  7. ‘CONTROLLER,DESKTOPDIRECTOR’, – Selects only the Controller and Director components to be installed.
  8. ‘/disableexperiencemetrics’, – Disables CEIP, participation in the Customer Experience Improvement Program.
  9. ‘/nosql’, – Does not install SQL Express on the server.
  10. ‘/quiet’, – Defines that a silent installation is to be performed.
  11. ‘/configure_firewall’] – Automatically adds the Firewall Rules to the server.
  12. } – Closes the package function.

Final Thoughts

I’m still learning Puppet and finding my way around the different methods and code options so this is very much a first working attempt. There are community modules out there to do it but for me, I prefer to learn by doing !

Tested On

This piece of puppet code has been tested installing Citrix Virtual Apps and Desktops 1912 CU1 LTSR Delivery Controller on the following:

  • Windows Server 2019 Core Edition – Not Supported by Citrix
  • Windows Server 2019 Desktop (GUI) Edition

Citrix ADC – “Cannot Complete You Request” StoreFront Error

Citrix ADC – “Cannot Complete You Request” StoreFront Error

I recently deployed an ADC in to my lab environment and ran in to the dreaded “cannot complete your request” error when trying to logon.

After chasing my tail for a few days and going through all the articles under the sun to troubleshoot StoreFront and ADC settings I finally came across an article https://vhorizon.co.uk/citrix-adc-13-64-35-cannot-complete-your-request-error/ by Dale Scriven on vhorizon.co.uk which gave three lines of config to resolve the issue.

Continue reading Citrix ADC – “Cannot Complete You Request” StoreFront Error

Puppet and Windows Package Names RTFM Moment

Puppet and Windows Package Names RTFM Moment

After writing the article on how to install Citrix Provisioning Services Server 1912 CU1 using Puppet last month I promptly powered off the VM as it wasn’t needed for my lab environment at that time. Fast forward a month or so and I needed it to work out some things so I powered it on and configured the Farm etc which was all good. What I soon realised though was that the PVS Services were stopping without warning on the server and I had to hop on and start them again.

Continue reading Puppet and Windows Package Names RTFM Moment

Linux VDA – Creating the Machine Catalog and Delivery Group in Studio

Linux VDA – Creating the Machine Catalog and Delivery Group in Studio

  • Linux VDA – Introduction and prerequisites
  • Linux VDA – Building the base CentOS virtual machine
  • Linux VDA – Post build tasks and Linux VDA 1912 preparation
  • Linux VDA – Joining the server to Active Directory
  • Linux VDA – VDA software installation and configuration
  • Linux VDA – Creating the MCS master target
  • Linux VDA – Creating the Machine Catalog and Delivery Group in Studio
  • Sections

    This next article covers the steps to create the Machine Catalog and Delivery Group for deploying Linux VDAs using Machine Creation Services (MCS).

    Create the Machine Catalog

    The first step in this article in the series is to create the Machine Catalog using the master image VM which was created in the previous article. In this article we will create a Machine Creation Services catalog consisting of two VDAs and using the snapshot taken in the last article.

    To create the Machine Catalog perform the following steps:

    • Open Studio, click on Machine Catalogs in the left hand pane, and then select Create Machine Catalog in the right hand action pane.
    • On the Operating System page select Multi-session OS as shown below and then click on Next:
    • On the Machine Management page select The machines are power managed and Citrix Machine Creation Services (MCS) as shown below and then click on Next:
    • On the Master Image page select the snapshot created in the previous article as shown below and then click on Next:
    • On the Virtual Machines page select how many VDAs you want to create and the size of RAM as shown below and then click on Next:

    I didn’t set the cache for temporary data as I’m not sure if Linux VDAs can leverage that technology (Maybe another play and another article later)

    • On the Active Directory Computer Accounts select the option Create new Active Directory accounts, select the OU you want to place them in, and configure you Account naming convention as shown below and then click on Next:
    • On the Summary page enter the name you wish to give the Machine Catalog and a description if required as shown below and then click on Finish
    • The catalog creation process will now begin and in this example create two VDAs named Lab-LinuxVDA01 and Lab-LinuxVDA02

    Create the Delivery Group

    Once the Machine Catalog has been created the last piece is to create the Delivery Group for the Linux VDAs as shown below:

    • Open Studio, click on Delivery Groups in the left hand pane, and then select Create Delivery Group in the right hand action pane.
    • On the Machines page select the Machine Catalog create in the previous steps as shown below using the example MC-CentOS-MCS-Catalog, select the number of machines to add, and then click on Next:
    • On the Users page either add the users / security groups in you wish to provide access to or leave as any authenticated users as shown in the example below and then click on Next:

    Publish applications

    Up until this set of articles I was under the impression that only desktops could be published from Linux VDAs but whilst stepping through creating this Delivery Group I thought I’d see if it can publish applications. I was very surprised when I click on Add and selected from the start menu that Studio powered on the VDA and once registered presented me with applications from the VDA. To published applications from the Linux VDA perform the following steps:

    • Click on Add and then select From start menu as shown below:
    • Studio will now power on the VDA and then once registered list the applications it has discovered. Select the apps you want to publish from the list and then click on OK as shown below:
    • The applications selected will be displayed on the Apps screen as show below. Click on Next to continue

    Linux VDA – Creating the MCS master target

    Linux VDA – Creating the MCS master target

  • Linux VDA – Introduction and prerequisites
  • Linux VDA – Building the base CentOS virtual machine
  • Linux VDA – Post build tasks and Linux VDA 1912 preparation
  • Linux VDA – Joining the server to Active Directory
  • Linux VDA – VDA software installation and configuration
  • Linux VDA – Creating the MCS master target
  • Linux VDA – Creating the Machine Catalog and Delivery Group in Studio
  • Sections

    Prepare the master image VM

    The official documentation lists the following steps to perform as part of preparing the VM to be a master image:

    Install the EPEL repository

    From the list of preparation steps the first one not already performed in the previous articles in this series is to enable the EPEL repository. To enable the EPEL repository perform the following steps:

    • Execute the following in a shell session:
    yum install -y epel-release

    Set up the runtime environment

    The next step before running the deploymcs.sh script is to prepare the runtime environment. To prepare the runtime environment perform the following steps:

    • Edit the file /etc/xdl/mcs/mcs.conf
    • Change the line dns1= to your DNS server IP address. In the example below I am setting it to 192.168.1.100 which is my AD DNS server:
    dns1="192.168.1.100"
    • Check the line AD_INTEGRATION= is set to winbind as used in the previous article to set up AD integration:
    AD_INTEGRATION="winbind"
    • Save and exit the file

    Execute deploymsc.sh

    The next step is to run the /opt/Citrix/VDA/sbin/deploymcs.sh script to prepare the master image ready for creating additional VDAs using Machine Creation Services.

    The script installs several packages as part of it’s execution and does not require any user input.

    Shutdown and snapshot the VM

    The last step in the process of creating the MCS master target is to shut down and snap shot the VM.

    I named my snap shot Linux-VDA-MCS-Build-01 so that it can be easily identified in the next article.

    Linux VDA – VDA software installation and configuration

    Linux VDA – VDA software installation and configuration

  • Linux VDA – Introduction and prerequisites
  • Linux VDA – Building the base CentOS virtual machine
  • Linux VDA – Post build tasks and Linux VDA 1912 preparation
  • Linux VDA – Joining the server to Active Directory
  • Linux VDA – VDA software installation and configuration
  • Linux VDA – Creating the MCS master target
  • Linux VDA – Creating the Machine Catalog and Delivery Group in Studio
  • Sections

    The first step in the installation and config for the Linux VDA software is to ensure that it’s dependencies are installed to the same or higher versions. The list of dependencies can be found in the Citrix documentation here.

    To identify which packages require installing from the dependencies list for RHEL / CentOS 7 perform the following steps:

    • Check each package in turn using rpm -qa as shown below for the postgresql-server package:
    rpm -qa postgresql-server
    • Any packages which do not return anything using rpm -qa are not installed and require installing.
    • The following list are the packages which were not installed as part of the test build
    postgresql-server >= 9.2
    postgresql-jdbc >= 9.2
    ImageMagick >= 6.7.8.9
    motif >= 2.3.4
    foomatic-filters >= 4.0.9
    gperftools-libs >= 2.4
    • To install the packages listed above using yum execute the following command:
    sudo yum install -y postgresql-server postgresql-jdbc ImageMagick motif gperftools-libs

    Configure Postgresql

    The piece is to perform the basic configuration of Postgresql by performing the following:

    • Execute the following command to initialise postgresql:
    service postgresql initdb
    • Configure the service to start automatically and then start it by executing the following:
    chkconfig postgresql on
    service postgresql start

    Install Microsoft Dot Net

    The next part of the process is to install Microsoft Dot Net on to the server by performing the following steps:

    • Add the Microsoft CentOS 7 yum repository by executing the following:
    rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm
    • Install the Dot Net Core Runtime packaged by executing the following:
    yum install dotnet-runtime-3.1

    Full details of installing Dot Net on to CentOS 7 can be found at https://docs.microsoft.com/en-us/dotnet/core/install/linux-centos

    Download and install the Linux VDA package

    The first step in this article of the series is to download the Linux VDA package from Citrix.  To download the package follow the steps below:

    • Log on using your Citrix Account to https://www.citrix.com/account/
    • Once logged in click on the Downloads tab, enter Linux Virtual Delivery Agent 1912 in the Search Downloads box as shown below, and press enter:

    citrix-downloads

    • From the search results click on the Linux Virtual Delivery Agent 1912 (RHEL 7.7 CentOS 7.7) link

    Centos-VDA-1912-Download

    • On the Linux Virtual Delivery Agent 1912 download page expand the Linux Virtual Delivery Agent 1912 (RHEL 7.7 CentOS 7.7) option and click on Download File.

    Centos-VDA-1912-Download-File

    • Once downloaded copy to the /tmp folder of your CentOS server
    • Logon to the CentOS server and open a terminal session as root
    • Install the VDA package using yum by executing the command below:
    yum install -y /tmp/XenDesktopVDA-19.12.0.50-1.el7_x.x86_64.rpm

    Configure the Linux VDA

    For this article I performed a prompted configuration of the VDA software on the VM.  To perform a prompted configuration of the VDA software perform the following steps:

    • Logon to the CentOS server and open a terminal session as root
    • Run the prompted configuration by executing the command below:
    ./opt/Citrix/VDA/sbin/ctxsetup.sh
    • During the prompted install I answered the following to the prompts:
      • CTX_XDL_DOTNET_RUNTIME_PATH = Accepted the default /opt/dotnet
      • CTX_XDL_SUPPORT_DDC_AS_CNAME = Accepted the default 
      • CTX_XDL_DDC_LIST = Configured as lab-sifliky01.lab.lost-it.org
      • CTX_XDL_VDA_PORT = Accepted the default 80
      • CTX_XDL_REGISTER_SERVICE = Accepted the default Y
      • CTX_XDL_ADD_FIREWALL_RULES = Accepted the default Y
      • CTX_XDL_AD_INTEGRATION = Select 1 for Winbind
      • CTX_XDL_HDX_3D_PRO = Accept the default N
      • CTX_XDL_VDI_MODE = Accept the default N
      • CTX_XDL_SITE_NAME = Accept the default None
      • CTX_XDL_LDAP_LIST = Configured as lab-lokse.lab.lost-it.org:389
      • CTX_XDL_SEARCH_BASE = Accept the default None
      • CTX_XDL_FAS_LIST = Accept the default None
      • CTX_XDL_START_SERVICE = Accept the default Y

    • The final piece I performed was to reboot the VDA

    Check the VDA Services a Running

    The final part once the VDA has rebooted is to check that the VDA services are running.by performing the following:

    • Execute the following commands:
    service ctxhdx status
    service ctxvda status

    Puppet – Deploying PVS 1912 CU1 Server Software Using Puppet

    Puppet – Deploying PVS 1912 CU1 Server Software Using Puppet

    Change Log

    • 16-11-2020 – Updated the package resource section after finding an issue with the naming used.
    • 16-11-2020 – Added the package resource section for installing the Provisioning Services 1912 CU1 Console.

    Introduction

    Citrix Provisioning Services (PVS) is software streaming technology that delivers patches, updates, and other configuration information to multiple virtual desktop endpoints through a shared desktop image. It centralizes virtual machine management while reducing the operational and storage costs of a virtualized desktop environment.

    Puppet is a Configuration Management tool that is used for deploying, configuring and managing servers. Puppet uses a Master Slave architecture in which the Master and Slave communicate through a secure encrypted channel with the help of SSL.

    This article explains how to use Puppet to perform unattended installations of both the Citrix Provisioning Services server and console.

    Test Environment

    For this article I’ll be using an already deployed Puppet Master server on CentOS which has a very basic manifest configured to Domain Join any Windows machines when the puppet agent contacts the server.

    My manifest files is named lab-setup.pp and is stored under /etc/puppetlabs/code/environment/production/manifests.

    Active Directory is also configured in the environment with DNS and a network share created to hold the PVS installation files so that they can be called as part of the Puppet manifest directives.

    The Provisioning Services Server itself is a flat install of Windows Server 2019 Standard Desktop Edition (GUI) which has already has the puppet agent installed, configured, and running on it. The server has also been joined to the Domain via puppet (see my article Creating A Domain Join Declaration For All Windows Machines for details on how to do this) and the DOT Net 4.5 Core feature applied as part of my standard OVF build for deploying servers through Bolt.

    The Issue

    Installing PVS server and the console silently is well documented in the current release product documentation below:

    https://docs.citrix.com/en-us/provisioning/current-release/install/install-wizard-silent.html

    It’s straightforward enough to perform using the basic command line switches as shown below :

    PVS_Server_x64.exe /S /v "/qn" 

    The issue I encountered was when trying to pass the options through as it would always start the gui when I ran a puppet apply. I tried as a normal install_options setting, escaping the double quotes around /qn, and replacing the single quotes with double ones, and setting them as a variable which I then passed to the options but nothing worked. In the end I came across a page on the web about using square brackets to break out the options.

    This finally worked and allowed me to deploy a new VM which joined the Domain and then installed PVS server without any interaction.

    Installing Provisioning Services Server using Puppet

    To install the Provisioning Services Server software using Puppet follow the steps below:

    • Connect to the Puppet server over SSH
    • Open the lab-setup.pp file (I use vi as I’m on CentOS)
    • The First thing to do is declare the nodes this resource will apply to:
    ######################################
    # LAB-PVS Servers Configuration
    ######################################
    
    node /^(lab-pvs01|lab-pvs02).lab.lost-it.org$/ {
    • The next piece is to add the package resource as follows:
    package {"Citrix 1912 LTSR CU1 - Provisioning Server x64":
     ensure => installed,
     subscribe => Class['domain_membership'],
     source => "\\\\lab-shares\\software\\PVS-1912-CU1\\Server\\PVS_Server_x64.exe",
     install_options => [
       '/S /v',
       '/qn',
       ],
    }
    • The final piece is to add in a reboot as follows:
    reboot {'pvsserver_reboot':
     message => 'PVS Install has requested a reboot',
     when => pending,
    }
    • Save and exit the manifest file

    Puppet Code Explanation

    Below is a breakdown of the PVS Server install code piece by piece to show what means what and why it’s being used:

    1. node /^(lab-pvs01|lab-pvs02).lab.lost-it.org$/ { – Node declaration using pattern matching to apply to two different PVS servers
    2. package {“Citrix 1912 LTSR CU1 – Provisioning Server x64: – Updated 16-11-2020 to use the Display Name for the application as shown in Control Panel as this is what is used by the Puppet package resource to check if the software is installed.
    3. ensure => installed, – Used to check that the software is installed and if not execute the install
    4. subscribe => Class[‘domain_membership’], – Subscribes to a previous class resource to ensure that PVS Server is only installed once the server has joined the domain.
    5. source => “\\\\lab-shares\\software\\PVS-1912-CU1\\Server\\PVS_Server_x64.exe”,
    6. install_options => [ – Defines the install options to be passed to the installer. The square bracket is used to allow specifying sets of options on different lines. The important part for using this method is that puppet will put double quotes around each of the following lines and separates them with a space.
    7. ‘/S /v’, – Sets the first two options which are passed by puppet as “/S /v”
    8. ‘/qn’, – Sets the quiet no gui options which are passed by puppet as “/qn”
    9. ], – Closes the square bracket used to define the install options.
    10. } – Closes the package function.

    Installing Provisioning Services Console using Puppet

    To install the Provisioning Services Console software using Puppet follow the steps below:

    • Connect to the Puppet server over SSH
    • Open the lab-setup.pp file (I use vi as I’m on CentOS)
    • The next piece is to add the package resource as follows:
    package {"Citrix 1912 LTSR CU1 - Provisioning Console x64":
     ensure => installed,
     subscribe => Package["Citrix 1912 LTSR CU1 - Provisioning Server x64"],
     source => "\\\\lab-shares\\software\\PVS-1912-CU1\\Console\\PVS_Console_x64.exe",
     install_options => [
       '/S /v',
       '/qn',
       ],
    }
    • Save and exit the manifest file

    Puppet Code Explanation

    Below is a breakdown of the PVS Console install code piece by piece to show what means what and why it’s being used:

    1. package {“Citrix 1912 LTSR CU1 – Provisioning Console x64: – Set to the same as the Display Name for the application as shown in Control Panel.
    2. ensure => installed, – Used to check that the software is installed and if not execute the install
    3. subscribe => Package[“Citrix 1912 LTSR CU1 – Provisioning Server x64”], – Subscribes to a previous class resource to ensure that PVS Console is only installed once the PVS Server software has been installed.
    4. source => “\\\\lab-shares\\software\\PVS-1912-CU1\\Server\\PVS_Console_x64.exe”,
    5. install_options => [ – Defines the install options to be passed to the installer. The square bracket is used to allow specifying sets of options on different lines. The important part for using this method is that puppet will put double quotes around each of the following lines and separates them with a space.
    6. ‘/S /v’, – Sets the first two options which are passed by puppet as “/S /v”
    7. ‘/qn’, – Sets the quiet no gui options which are passed by puppet as “/qn”
    8. ], – Closes the square bracket used to define the install options.
    9. } – Closes the package function.

    Final Thoughts

    I’m still learning Puppet and finding my way around the different methods and code options so this is very much a first working attempt. There are community modules out there to do it but for me, I prefer to learn by doing !

    Tested On

    This piece of puppet code has been tested installing PVS Server 1912 CU1 LTSR on the following:

    • Windows Server 2019

    Local Policy Session Printing With CVADS

    Local Policy Session Printing With CVADS

    Recently on site I came across my first requirement for a Citrix Session Printer Policy when migrating from an on-premises 7.15 Site to CVADS.

    At first I simply tried copying the policy in to the Cloud Studio but when I came to select the printer it was unable to connect. The first step was to eliminate firewall rules as usual so I got the SMB ports opened between the Cloud Connectors and the Print Servers but this didn’t resolve the issue.

    Luckily I was working with Citrix at the time and so a quick check through Slack turned up Citrix Article https://support.citrix.com/article/CTX220345 which says “Because limitation of Citrix Cloud and Connector, in certain scenarios, communication with some of the on premises components, there is a need for some customers to manage the Citrix polices locally”.

    The article itself was straightforward enough and geared towards using an Active Directory Group Policy which was duly created but still failed to apply. Closer inspection showed that because the customer uses AppSense for user personalisation they didn’t have the “user group policy loopback processing mode” enabled.

    Continue reading Local Policy Session Printing With CVADS

    Citrix Depreciate On-Premises Cloud Support

    Citrix Depreciate On-Premises Cloud Support

    With the release of the latest Current Release (CR) of Virtual Apps and Desktops (CVAD) version 2003 Citrix has announced that they have deprecated on-premises support for VDA workloads hosted on the following Clouds:

    • Amazon Web Services (AWS)
    • Microsoft Azure
    • Cloud Platform
    Continue reading Citrix Depreciate On-Premises Cloud Support

    Citrix – Making CentOS Look Like Windows 10

    Citrix – Making CentOS Look Like Windows 10

    As part of my testing with the CVAD 1912 Linux VDA I came across the B00merang desktop themes which makes a Linux desktop look like Windows 10. I decided to explore whether the theme could be applied to Citrix sessions and after to some googling, got it up and running .

    Continue reading Citrix – Making CentOS Look Like Windows 10