All Citrix products can be automated. This article covers the Citrix StoreFront unattended installation and configuration with PowerShell.

In case you want to configure StoreFront settings and you are looking for the corresponding PowerShell commands, see my article Translating the Citrix StoreFront console to PowerShell.

Change Log 01.02.2018: updated the Complete script for configuring Citrix StoreFront. The function DS_BindCertificateToIISPort now also works with wildcard certificates (e.g. *.mydomain.com) as well as Subject Alternative Name (SAN) certificates. Many thanks to Julian Mooren (@citrixguyblog) for reporting this issue to me. The function DS_CreateStoreFrontStore has two new parameters, CertSubjectName and AddHostHeaderToIISSiteBinding.

Table of Contents Introduction Part 1: Install Windows Roles and Features (optional) Complete script for installing Roles and Features Part 2: Install Citrix StoreFront Complete script for installing Citrix StoreFront Part 3: Configure Citrix StoreFront StoreFront configuration steps Install (SSL) certificates (optional) Create the StoreFront deployments, stores, and farms Disable CEIP (optional) StoreFront deployment scenarios (examples) Scenario 1: create a single-site deployment with a single store and a single farm Scenario 2: create a single-site deployment with multiple stores and one farm per store Scenario 3: create a single-site deployment with one store and multiple farms Scenario 4: create a single-site deployment with two stores, two farms per store, and two Receiver for Web sites Scenario 5: create a multi-site deployment (two IIS sites) with one store per deployment and two farms for each store Complete script for configuring Citrix StoreFront Translating the Citrix StoreFront console to PowerShell (separate article) Customizing StoreFront with PowerShell (will come in Q2 2018) Conclusion

Introduction

Before continuing with this article please be aware of the following:

• The version of Citrix StoreFront in this article is 3.13 released in Q4 2017.
• StoreFront is part of the XenDesktop installation, but can also be downloaded separately. In this article, I will work with the stand-alone installer.
  • The XenDesktop ISO file can be downloaded here: https://www.citrix.com/downloads/xenapp-and-xendesktop/product-software/xenapp-and-xendesktop-716.html.
  • The stand-alone source files can be downloaded here: https://www.citrix.com/downloads/storefront/.
• In this article, StoreFront is installed on a separate machine (and NOT on a machine with the Delivery Controller role installed).
• The installation and configuration scripts are designed for the following operating systems:
  • Microsoft Windows Server 2008 R2 SP1
  • Microsoft Windows Server 2012 (R2)
  • Microsoft Windows Server 2016
• The installation and configuration scripts in this article have been tested on the following operating systems:
  • Microsoft Windows Server 2016 version 1607
• Make sure to execute the scripts in this article on a server that has been pre-installed with one of the aforementioned operating systems including all latest hotfixes and .Net Framework 4.6.x. Also, you should at least have PowerShell 4.0 installed on the system, although I recommend using the latest version.

I strongly urge you to read the following article:

• StoreFront 2308 through 3.5 – Basic Configuration – by Carl Stalhood
  This article explains the manual installation of StoreFront step-by-step (very detailed!).

This article consists of three parts:

• Part 1 focuses on the installation of the Windows Roles and Features;
• Part 2 deals with the installation of Citrix StoreFront;
• Part 3 describes the configuration of Citrix StoreFront.

Part 1: Install Windows Roles and Features (optional)

Before we install Citrix StoreFront, you may want to install some commonly used roles and features. These roles and features are optional.

Internet Information Services Please be aware that Internet Information Services (IIS) is a prerequisite for StoreFront. IIS is installed automatically during the installation of StoreFront and is NOT installed in this section of the article.

In this example, we will install the following features:

• .Net Framework 3.5.1 (for W2K8R2 only)
• .Net Framework 4.5.x (for W2K12 and W2K16 only)
• Desktop experience (for W2K8R2 and W2K12 only)
• Group Policy Management Console
• Remote Server Administration Tools (AD DS Snap-Ins)
• Remote Desktop Licensing Tools
• Telnet Client
• Windows Process Activation Service

You can remove or add any role or feature you need. Please be aware though that not all features can be installed at the same time. Some features need a reboot. After that, other features can be installed.

In PowerShell, roles and features are installed using the Add-WindowsFeature (Windows Server 2008 R2) or Install-WindowsFeature command (Windows Server 2012 and higher). For example:

Windows Server 2008 (R2):

Windows Server 2012 (R2):

Windows Server 2016:

In some cases, the names of the individual roles and features differ between the various operating systems:

• .Net Framework:
  • Windows Server 2008 R2 only offers version 3.5.1 (Add-WindowsFeature command NET-Framework-Core).
  • Windows Server 2012 (R2) offers both the versions 3.5.1 and 4.5.x (Install-WindowsFeature command NET-Framework-Core and NET-Framework-45-Core), but I only install the 4.5.x version.
  • Windows Server 2016 only offers version 4.5.x (Install-WindowsFeature command NET-Framework-45-Core).
• Desktop-Experience:
  This feature no longer exists as a separate item in Windows Server 2016. Let me clarify; when you use the full version of Windows Server 2016 (not the core/nano version), desktop experience is included out-of-the-box.
• Remote Desktop Licensing Tools:
  In Windows Server 2008 (R2), the abbreviation of this feature is called RSAT-RDS-Licensing. In Windows Server 2012 and higher, this feature is called RDS-Licensing-UI.

To establish the version of the running operating system, I use the following PowerShell command:

Complete script for installing Roles and Features

In case you use my installation template, this is what the complete script, including logging, looks like:

Execute the script as follows:
powershell.exe -executionpolicy bypass -file %Directory%\Install_Citrix_StoreFront_Roles.ps1

Log files are created in the directory C:\Logs\Citrix_StoreFront_Roles, but you can change this to any directory you want (see lines 105 and 106).

Note: The installation of the roles and features may require a reboot. The reboot is NOT part of the example script. You can either add it to the script yourself or if you use a deployment tool such as Microsoft SCCM, you can add a reboot task in the task sequence.

If you want to go one step further and create an SCCM package as well, please follow the step-by-step explanation in the article Deep dive creating SCCM packages for Citrix.

Part 2: Install Citrix StoreFront

The second part of this article focuses on the installation of the Citrix StoreFront. So how do you start?

• Create an installation directory on the local computer or on a file share (UNC path). For example: C:\Temp\Citrix\StoreFront.
• Create a subdirectory called Files.
• Download and copy the StoreFront stand-alone installer CitrixStoreFront-x64.exe to the folder Files in the installation directory.
• Copy the complete PowerShell script at the end of this paragraph to a new PS1 file (e.g. Install_CitrixStoreFront.ps1) and add this file to the root of your installation directory (not in the subdirectory Files).
• Execute the PowerShell script:
  powershell.exe -executionpolicy bypass -file C:\Temp\Citrix\DeliveryController\Install_CitrixStoreFront.ps1

In case you prefer to use the XenDesktop ISO instead of the StoreFront stand-alone installer, the basic command line to install StoreFront is:

When using the stand-alone installer (used in this article), the command is as follows:

By default, the installation creates three log files in the directory C:\Windows\Temp\StoreFront. These are:

• CitrixMsi-CitrixStoreFront-x64-%Date%_%Time%.log
• CitrixMsi-TelemetryServiceInstaller_x64-%Date%_%Time%.log
• CitrixMsi-TelemetryServiceInstaller_x64-%Date%_%Time%.log

In the complete PowerShell script at the end of this paragraph, these log files are copied to the custom log directory defined in line 347 in the script.

During installation, the path to the StoreFront PowerShell modules (C:\Program Files\Citrix\Receiver StoreFront\PowerShellSDK\Modules) is added to the environment variable PSModulePath.

This means that no reference to the specific directory is required when importing StoreFront PowerShell modules in a script. For more information please see the section File locations in the article Understanding PowerShell fundamentals.

StoreFront 3.13 contains a total of 206 cmdlets. The following command lists all cmdlets:

The following command counts the total number of available cmdlets:

Note: The installation of StoreFront requires a reboot. Without the reboot, the StoreFront PowerShell modules cannot be loaded, which is required for the configuration of StoreFront in Part 3 of this article. The reboot is NOT part of the example script. You can either add it to the script yourself or if you use a software deployment tool such as Microsoft SCCM, you can add a reboot task in the task sequence.

Complete script for installing Citrix StoreFront

In case you use my installation template, this is what the complete script, including logging and error handling, looks like:

Execute the script as follows, for example:
powershell.exe -executionpolicy bypass -file C:\Temp\Citrix\StoreFront\Install_CitrixStoreFront.ps1

Log files are created in the directory C:\Logs\Citrix_StoreFront_(installation), but you can change this to any directory you want (see lines 347 and 348).

Part 3: Configure Citrix StoreFront

The third part of this article focuses on the configuration of the Citrix StoreFront.

If you have created the installation directory as described in Part 2, you can continue as follows:

• Copy the complete PowerShell script at the end of this part to a new PS1 file (e.g. Configure_CitrixStoreFront.ps1) and add this file to the root of your installation directory (not in the subdirectory Files).
• Optional: copy your certificate files to the installation directory in the subdirectory Files.
• Execute the PowerShell script:
  powershell.exe -executionpolicy bypass -file C:\Temp\Citrix\StoreFront\Configure_CitrixStoreFront.ps1

StoreFront configuration steps

The configuration of your StoreFront server depends on your environment. StoreFront can be deployed as a single-site and a multi-site deployment (multiple IIS sites) You may want to create multiple stores in a single IIS site and perhaps even multiple farms and Receiver for Web sites per store. Besides this multitude of architectural scenarios, each of the aforementioned StoreFront components contains many detailed settings.

It is impossible for me to offer you a 100% “one-size-fits-all” solution or script. What I can offer you are some ready-to-use PowerShell functions and some practical examples of how to use these functions. This will allow you to configure your environment to your requirements.

At the end of this article, I have prepared a complete PowerShell script that offers all functions required to create a single-site and multi-site deployment containing one or more stores, farms, Receiver for Web services, and more. In the following paragraphs, I explain the script in detail by going through each of the main sections, which are:

• Install (SSL) certificates (optional)
• Create the StoreFront deployments, stores, and farms
• Disable CEIP (optional)

Note: In this article and in the complete PowerShell script I offer only minimum customizing of the store, farm, and Receiver for Web settings. The main focus of this article is to get your StoreFront configuration up and running. I am preparing a separate article that deals with the detailed configuration of StoreFront. This article will be ready in February 2018. A link to this article will be added to this article.

Install (SSL) certificates (optional)

For those of you who would like to connect to StoreFront using SSL, continue reading.

Before creating the StoreFront deployment, the complete PowerShell script first installs the necessary certificates on the StoreFront server. These can be Trusted Root, Intermediate, personal certificates, including wildcard and Subject Alternative Name (SAN) certificates, and more. Certificate installation is handled by the function DS_InstallCertificate. The function excepts the following command line parameters:

• StoreScope
  This parameter determines whether the local machine or the current user store is to be used (possible values are: CurrentUser or LocalMachine).
• StoreName
  This parameter contains the name of the store (possible values are: CA, My, Root, TrustedPublisher, and more).
  • My = Personal
  • Root = Trusted Root Certificates Authorities
  • CA = Intermediate Certificates Authorities
  • TrustedPublisher = Trusted Publishers
• CertFile
  This parameter contains the name, including path and file extension, of the certificate file (e.g. C:\MyCert.cer).
• CertPassword
  [Optional] This parameter is optional and is required in case the exported certificate is password protected (e.g. password = “abcdef”). Please see the article Encrypting passwords in a PowerShell script to learn how to avoid plain-text passwords in your scripts.

Note: I would be remiss to mention that you can also choose to use a Microsoft Group Policy to deploy your certificates to your servers.

You can add the certificate files to the directory Files of the StoreFront installation directory as described in Part 2 of this article. Here are a couple of examples of how to call the function:

• DS_InstallCertificate -StoreScope “LocalMachine” -StoreName “Root” -CertFile “Files\MyRootCert.cer”
  Install the root certificate ‘MyRootCert.cer’ in the Trusted Root Certificates Authorities store of the local machine.
• DS_InstallCertificate -StoreScope “LocalMachine” -StoreName “CA” -CertFile “Files\MyIntermediateCert.cer”
  Install the intermediate certificate ‘MyIntermediateCert.cer’ in the Intermediate Certificates Authorities store of the local machine
• DS_InstallCertificate -StoreScope “LocalMachine” -StoreName “My” -CertFile “Files\MyPersonalCert.pfx”  -CertPassword “mypassword”
  Install the password-protected personal certificate (including private key) ‘MyUserCert.pfx’ in the Personal store of the local machine.

The complete PowerShell script at the end of this part includes the import of one root certificate and one personal certificate in lines 1088 to 1096.

Create the StoreFront deployments, stores, and farms

In case your infrastructure requires certificates, please make sure to install them on your StoreFront server before starting with your deployment. See the previous paragraph Install (SSL) certificates (optional) for more information.

The complete PowerShell script includes the function DS_CreateStoreFrontStore, which is responsible for creating your deployment. This function is the heart of the script and supports all kinds of deployment scenarios, such as:

• Single-site deployment (= basic deployment) with one store and one farm
• Single-site deployment with one or more stores and one or more farm per store
• Multi-site deployment* (= multiple IIS sites) with one or more stores per deployment and one or more farms per store:
  • In case the host base URL is different than any of the existing ones, the function automatically creates the IIS site.
  • Port bindings and SSL certificate bindings are automatically configured.

The function can be called multiple times to create multiple configurations on the same local server. In case a deployment, store, farm, Receiver for Web, or PNAgent service already exists, the function recognizes this and simply skips this step and continues with the next one.

*Since StoreFront 3.8, Citrix officially supports multi-site deployments. Multi-site deployments are multiple IIS sites on one StoreFront server. Each IIS site contains one or more stores and each store consists of one or more farms. Please be aware that when you implement a multi-site deployment, you can no longer use the StoreFront console!

This also means that you cannot use the console to propagate changes to other StoreFront servers in the StoreFront group. You have to use PowerShell to configure each of your StoreFront servers.

The function DS_CreateStoreFrontStore is quite a complex one and comes with many parameters (listed below). The execution process of the function is as follows:

• Import the required StoreFront and IIS PowerShell modules
• Check if a StoreFront deployment exists:
  • If not, create the first deployment using the Default Web Site (= IIS site ID 1):
    • Delete any existing bindings on the Default Web Site
    • In case the variable $HTTPSPort was populated, bind the certificate specified in the parameter $CertSubjectName to the HTTPS port of the Default Web Site. In case the $CertSubjectName parameter is not used, the value of $HostbaseUrl is used instead.
    • Add the URL to the host header of the Default Web Site if the variable $AddHostHeaderToIISSiteBinding is set to $True, otherwise do not set the host header (= default).
    • Create the first StoreFront deployment using the PowerShell cmdlet Add-STFDeployment.
  • If yes, check if the host base URL (= hostname on the IIS site, see Edit Bindings) exists.
    • If yes, continue with that particular IIS site.
    • If not, create a new IIS site (= multi-site deployment):
      • The name of the IIS directory is defined in the variable $IISSiteDir (e.g. C:\inetpub\MyFarm). In case this optional parameter was not used, the function automatically generates a new directory name based on the new IIS site ID, for example, C:\inetpub\wwwroot2.
      • Create the IIS site directory
      • Create the IIS site with the port bindings as defined in the variables $HTTPPort and $HTTPSPort. The name of the IIS site (as visible in the IIS Manager) is the farm name, defined in the variable $FarmName.
      • Retrieve the site ID of the new site.
      • In case the variable $HTTPSPort was populated, bind the certificate specified in the parameter $CertSubjectName to the HTTPS port of the new IIS site. In case the $CertSubjectName parameter is not used, the value of $HostbaseUrl is used instead.
      • Add the URL to the host header of the new IIS site if the variable $AddHostHeaderToIISSiteBinding is set to $True, otherwise do not set the host header (= default).
      • Create the new StoreFront deployment using the PowerShell cmdlet Add-STFDeployment.
  • Determine the virtual paths for the Authentication and Receiver for Web service.
  • Determine if the Authentication service exists (Get-STFAuthenticationService).
    • If yes, continue with the next step.
    • If not, create it (Add-STFAuthenticationService).
  • Determine if the store service exists at the path defined in the parameter $StoreVirtualPath in the corresponding IIS site.
    • If yes, continue with the next step and check if the farm, as defined in the parameter $FarmName, already exists.
      • If not, create the new farm (Add-STFStoreFarm) using the parameters $FarmName, $FarmType, $FarmServers, $SSLRelayPort (XA 6.5 only), $LoadBalanceServers, $XMLPort, and $TransportType.
      • If yes, continue with the next step.
    • If not, create the store, the authentication service, and the first farm of that store (Add-STFStoreService) using the parameters $FriendlyName, $SiteId, $StoreVirtualPath, $authentication, $FarmName, $FarmType, $FarmServers, $SSLRelayPort, $LoadbalanceServers, $XMLPort and $TransportType.
  • Determine if the Receiver for Web service exists (Get-STFWebReceiverService).
    • If yes, continue with the next step.
    • If not, create it (Add-STFWebReceiverService) using the virtual path defined in the parameter $receiverVirtualPath.
  • Determine if the PNAgent service exists (Get-STFStorePna).
    • If yes, enable it if the parameter $EnablePNAgent is set to $True. Also configure the logon method ($LogonMethod), whether or not the user is allowed to change their password ($PNAgentAllowUserPwdChange), and whether or not the PNAgent is to be set as default ($PNAgentDefaultService).

The function DS_CreateStoreFrontStore includes the following parameters:

• FriendlyName
  [Optional] This parameter configures the friendly name of the store, for example, “MyStore” or “Marketing”.
  If this parameter is omitted, the script generates the friendly name automatically based on the farm name. For example, if the farm name is MyFarm, the friendly name would be Store – MyFarm.
• HostBaseUrl
  [Mandatory] This parameter determines the URL of the IIS site (the StoreFront “deployment”), for example, “https://mysite.com” or “http://mysite.com”.
• CertSubjectName
  [Optional] This parameter determines the Certificate Subject Name of the certificate you want to bind to the IIS SSL port on the local StoreFront server.
  If this parameter is omitted, the Certificate Subject Name (the DNS name) will be automatically extracted from the host base URL (see the previous variable HostBaseUrl). Two commonly used values are:
  • $($env:ComputerName).mydomain.local -> for certificates where the subject name is the same as the local machine name.
  • *.mydomain.local -> for wildcard certificates or Subject Alternative Name (SAN) certificates. SAN certificates contain more than one subject name.
• AddHostHeaderToIISSiteBinding
  [Optional] This parameter determines whether the host base URL (the host header) is added to IIS site binding.
  If this parameter is omitted, the value is set to ‘$false’ and the host header is NOT added to IIS site binding.
• IISSiteDir
  [Optional] This parameter contains the directory path to the IIS site. This parameter is only used in multiple deployment configurations whereby multiple IIS sites are created.
  If this parameter is omitted, a directory will be automatically generated by the script.
• Farmtype
  [Optional] This parameter determines the farm type. Possible values are XenDesktop | XenApp | AppController | VDIinaBox.
  If this parameter is omitted, the default value “XenDesktop” is used.
• FarmName
  [Mandatory] This parameter contains the name of the farm within the store. The farm name should be unique within a store.
• FarmServers
  [Mandatory] This parameter, whose data type is an array, contains a list of farm servers (XML brokers or Delivery Controller). Enter the list comma separated (e.g. -FarmServers “Server1.fqdn.com”,”Server2.fqdn.com”,”Server3.fqdn.com”).
• StoreVirtualPath
  [Optional] This parameter contains the partial path of the StoreFront store, for example: -StoreVirtualPath “/Citrix/MyStore” or -StoreVirtualPath “/Citrix/Store1”.
  If this parameter is omitted, the default value /Citrix/Store is used
• ReceiverVirtualPath
  [Optional] This parameter contains the partial path of the Receiver for Web site in the StoreFront store, for example: -ReceiverVirtualPath “/Citrix/MyStoreWeb” or -ReceiverVirtualPath “/Citrix/Store1ReceiverWeb”.
  If this parameter is omitted, the default value /Citrix/StoreWeb is used
• SSLRelayPort
  [Mandatory] This parameter contains the SSL Relay port (XenApp 6.5 only) used for communicating with the XenApp servers. The default value is 443 (HTTPS).
• LoadBalanceServers
  [Optional] This parameter determines whether to load balance the Delivery Controllers or to use them in fail-over order (if specifying more than one server). Possible values are: $True | $False.
  If this parameter is omitted, the default value $False is used, which means that fail-over is used instead of load balancing.
• XMLPort
  [Optional] This parameter contains the XML service port used for communicating with the XenApp\XenDesktop servers. Default values are 80 (HTTP) and 443 (HTTPS), but you can also use other ports (depending on how you configured your XenApp/XenDesktop servers).
  If this parameter is omitted, the default value 80 is used.
• HTTPPort
  [Optional] This parameter contains the port used for HTTP communication on the IIS site. The default value is 80, but you can also use other ports.
  If this parameter is omitted, the default value 80 is used.
• HTTPSPort
  [Optional] This parameter contains the port used for HTTPS communication on the IIS site. If this value is not set, no HTTPS binding is created.
• TransportType
  [Optional] This parameter contains the type of transport to use for the XML service communication. Possible values are HTTP | HTTPS | SSL.
  If this parameter is omitted, the default value HTTP is used.
• EnablePNAgent
  [Mandatory] This parameter determines whether the PNAgent site is created and enabled. Possible values are: $True | $False.
  If this parameter is omitted, the default value $True is used.
• PNAgentAllowUserPwdChange
  [Optional] This parameter determines whether the user is allowed to change their password on a PNAgent. Possible values are: $True | $False.
  Note: this parameter can only be used if the logon method for PNAgent is set to ‘prompt’.
  !! Only add this parameter when the parameter EnablePNAgent is set to $True
  If this parameter is omitted, the default value $True is used.
• PNAgentDefaultService
  [Optional] This parameter determines whether this PNAgent site is the default PNAgent site in the store. Possible values are: $True | $False.
  !! Only add this parameter when the parameter EnablePNAgent is set to $True
  If this parameter is omitted, the default value $True is used.
• LogonMethod
  [Optional] This parameter determines the logon method for the PNAgent site. Possible values are Anonymous | Prompt | SSON | Smartcard_SSON | Smartcard_Prompt. Only one value can be used at a time.
  !! Only add this parameter when the parameter EnablePNAgent is set to $True
  If this parameter is omitted, the default value “SSON” (Single Sign-On) is used.

Here are a couple of examples of how to call the function:

• DS_CreateStoreFrontStore -HostBaseUrl “https://myurl.com” -FarmName “MyFarm” -FarmServers “Server1″,”Server2” -EnablePNAgent $True
  Creates a basic StoreFront deployment, a XenDesktop store, farm, Receiver for Web site, and a PNAgent site. The above example uses only the 4 mandatory parameters and does not include any of the optional parameters. In case the HostBaseUrl is different than an already configured one on the local StoreFront server, a new IIS site is automatically created. The other settings are configured automatically:
  • The name of the store (the friendly or display name) will be set to “Store – $FarmName”
  • The IIS site directory will be C:\inetpub\wwwroot if it is the first deployment on the local StoreFront server. Otherwise, the directory will be C:\inetpub\wwwroot$SiteID, for example, C:\inetpub\wwwroot2.
  • The farm type will be set to XenDesktop.
  • The store virtual path will be set to /Citrix/Store.
  • The receiver virtual path will be set to /Citrix/StoreWeb.
  • The XML port will be set to 80 and the transport type to HTTP for communication with the delivery controllers.
  • On the local IIS site, ports 80 and 443 will be bound.
  • The PNAgent will be enabled and set to default. The login method is set to Single Sign-On (SSON).
• DS_CreateStoreFrontStore -FriendlyName “MyStore” -HostBaseUrl “https://myurl.com” -CertSubjectName “$($env:ComputerName).mydomain.local” -FarmName “MyFarm” -FarmServers “Server1″,”Server2” -StoreVirtualPath “/Citrix/MyStore” -ReceiverVirtualPath “/Citrix/MyStoreWeb” -XMLPort 443 -TransportType “HTTPS” -HTTPSPort 443 -EnablePNAgent $True -PNAgentAllowUserPwdChange $False -PNAgentDefaultService $True -LogonMethod “Prompt”
  Creates a StoreFront deployment, a XenDesktop store, farm, Receiver for Web site, and a PNAgent site. The communication with the Delivery Controllers uses port 443 and transport type HTTPS. An SSL port is added to the StoreFront (IIS) site (variable HTTPSPort). The subject name of the certificate that will be bound to that HTTPS port is set in the variable CertSubjectName and is different from the host base URL. PNAgent users are not allowed to change their passwords and the logon method is “prompt” instead of the default SSON (= Single Sign-On). In case the HostBaseUrl is different than an already configured one on the local StoreFront server, a new IIS site is automatically created.
• DS_CreateStoreFrontStore -FriendlyName “MyStore” -HostBaseUrl “https://anotherurl.com” -FarmName “MyFarm” -FarmServers “Server1″,”Server2” -EnablePNAgent $False
  Creates a StoreFront deployment, a XenDesktop store, farm, and Receiver for Web site, but DOES NOT create and enable a PNAgent site. The communication with the Delivery Controllers uses the default port 80 and transport type HTTP.
  In case the HostBaseUrl is different than an already configured one on the local StoreFront server, a new IIS site is automatically created.

The complete PowerShell script at the end of this part includes the creation of one StoreFront deployment in line 1101.

One more thing, the function DS_CreateStoreFrontStore uses another function called DS_BindCertificateToIISPort. This function is responsible for binding a certificate to the HTTPS port and requires two variables: the host base URL or a domain name and the port number to bind the certificate to. The function automatically checks for a wildcard or Subject Alternative Name (SAN) certificate in case the host base URL does not match the subject name of any of the installed certificates.

Disable CEIP (optional)

The Customer Experience Improvement Program (CEIP) can be disabled in Citrix StoreFront. During installation, CEIP is enabled by default. The first upload of data occurs approximately seven days after you install StoreFront. You can change this default in a registry setting.

Disabling CEIP can be done in the registry by setting the registry item Enabled (DWORD) in the key HKLM\Software\Citrix\Telemetry\CEIP to 0.

Using PowerShell, the command to disable CEIP is as follows:

Reference: https://docs.citrix.com/en-us/storefront/current-release/install-standard.html

Please note that I am not stating that CEIP should be disabled! I am only showing you how to do it in case you want to.

The complete PowerShell script at the end of this part includes the disabling of CEIP including detailed logging and error handling in line 1107.

StoreFront deployment scenarios

In the following paragraphs, I outline a number of StoreFront deployment scenarios as well as a detailed description of how to create these using the complete PowerShell script below.

Scenario 1: create a single-site deployment with a single store and a single farm

The minimum deployment is to create one IIS site containing one store containing one farm. The authentication service, the Receiver for Web, and PNAgent service are also created.

In the complete PowerShell script you simply add the following line.

In the example above the PowerShell code calls the function DS_CreateStoreFrontStore.

Scenario 2: create a single-site deployment with multiple stores and one farm per store

In case you would like to create a single-site deployment, but with multiple stores, call the function DS_CreateStoreFrontStore as many times as you need stores, but each time with a different virtual path (= variable -StoreVirtualPath). The virtual path is the parameter that determines whether a new store is created or not.

The following PowerShell code creates one deployment containing three stores (and one farm per store). Add these lines to the complete PowerShell script.

Scenario 3: create a single-site deployment with one store and multiple farms

In case you would like to create a single-site deployment with one store, but with multiple farms, call the function DS_CreateStoreFrontStore as many times as you need a new farm, but each time with a different farm name (= variable -FarmName). The farm name is the parameter that determines whether a new farm is created or not. As you can see in the example, the virtual path to the store (= variable -StoreVirtualPath) remains the same. This ensures that no new store is created.

The following PowerShell code creates one deployment containing one store and three farms. Add these lines to the complete PowerShell script.

Let’s take a closer look at the PowerShell code above.

The function DS_CreateStoreFrontStore is called three times. Each time, the virtual path to the store is the same (/Citrix/MyStore). The first time the function is called, the store is created. The second and third time the function is called, the function realizes that the store already exists and proceeds with the next step. Since the farm name is different each time the function is called, the function creates a new farm in the existing store. A total of three farms are created within the same store.

Scenario 4: create a single-site deployment with two stores, two farms per store, and two Receiver for Web sites

In case you would like to create a single-site deployment with multiple stores and multiple farms, call the function DS_CreateStoreFrontStore as many times as you need a new store and a new farm. Each time you have to use a different combination of the variables -FarmName (the farm name) and -StoreVirtualPath (the virtual path to the store).

The following PowerShell code creates one deployment containing two stores and two farms per store. Add these lines to the complete PowerShell script.

Let’s take a closer look at the PowerShell code above.

In line 4, the function DS_CreateStoreFrontStore creates the first store called MyStore1 in the virtual path /Citrix/MyStore1 with the XenDesktop farm MyFarm1. Line 9 contains the same store details. The function DS_CreateStoreFrontStore will determine that the store already exists and will continue with the next step. However, the function will determine that the farm called Farm2 does not yet exist and will proceed to create this farm.
The same process is repeated in line 14 and 19. In line 14, the store called MyStore2 with farm Farm3 is created. In line 19, the farm Farm4 is added to the store MyStore2.

Scenario 5: create a multi-site deployment (two IIS sites) with one store per deployment and two farms for each store

In case you would like to create a multi-site deployment (two IIS sites in this example) with one store per deployment and two farms per store, you need to call the function DS_CreateStoreFrontStore a total of four times. Two different host base URLs are used to create the two deployments (= IIS sites). Also, two different store names (= variable -StoreVirtualPath) and four different farm names (= variable -FarmName) are used. The store name is the parameter that determines if a new store is created; the farm name is the parameter that determines whether a new farm is created or not.

The following PowerShell code creates two deployments containing one store per deployment with two farms per store. Add these lines to the complete PowerShell script.

Let’s take a closer look at the PowerShell code above.

The function DS_CreateStoreFrontStore is called four times. The first two times, the host base URL is the same, which means that the same IIS site is used. Also, the store name is the same, which means that the same store is used. However, two different farm names are used, which means that two farms are created within the one store.
The third and fourth time the function is executed, a different host base URL is used, which means that an additional deployment (= IIS site) is created. In both cases the store Store2 is used, which means that this second deployment contains one store only. Two different farm names are used, which results in two farms being created in Store2.

Complete script for configuring Citrix StoreFront

In case you use my installation template, this is what the complete script, including logging and error handling, looks like.

Please customize the variables $BaseLogDir and $PackageName in lines 1066 and 1067 to your requirements (or leave them as-is). Also, customize the code in lines 1088 to 1107 (e.g. the certificate file names in lines 1089 and 1095).

Execute the script as follows, for example:
powershell.exe -executionpolicy bypass -file C:\Temp\Citrix\StoreFront\Configure_CitrixStoreFront.ps1

Log files are created in the directory C:\Logs\Citrix_StoreFront_(configure), but you can change this to any directory you want (see lines 1066 and 1067).

Conclusion

This concludes this article on the Citrix StoreFront unattended installation. You can customize the scripts in this article in any way you see fit.

If you want to go one step further and create an SCCM package, please follow the step-by-step explanation in the article Deep dive creating SCCM packages for Citrix.

If you have any questions or recommendations please leave a comment below. Happy scripting!