[Citrix XenDesktop / SCCM]: 7.13 Components unattended install command lines in SCCM
Not so much an issue but a “how-to”. To make the process of deploying XenDesktop a little more consistent across Dev/Prod automation seems like the obvious answer.
The below shows the commands used to deploy each component using the binaries found on the XenDesktop ISO.
|Delivery Controller||“x64\XenDesktop Setup\XenDesktopServerSetup.exe” /components CONTROLLER /quiet /noreboot /configure_firewall /nosql|
|Storefront||“x64\XenDesktop Setup\XenDesktopServerSetup.exe” /components STOREFRONT /quiet /noreboot /configure_firewall|
|License Server||“x64\XenDesktop Setup\XenDesktopServerSetup.exe” /components LICENSESERVER /quiet /noreboot /configure_firewall|
|Desktop Director||“x64\XenDesktop Setup\XenDesktopServerSetup.exe” /components DESKTOPDIRECTOR /quiet /noreboot /configure_firewall|
|Desktop Studio||“x64\XenDesktop Setup\XenDesktopServerSetup.exe” /components DESKTOPSTUDIO /quiet /noreboot /configure_firewall|
Kees Baggerman has a great article on what the various switches do in some detail.
Alternatively you can used the help switch by typing one of the following:
XenDesktopServerSetup.exe /? XenDesktopServerSetup.exe /HELP XenDesktopServerSetup.exe /H
|Note: If you copy paste the command lines from Kees’s article into SCCM the quotation marks (“ “) are the incorrect type. Simply remove and replace them and the command line will now work correctly.|
This article won’t be covering how to create and deploy applications/packages in SCCM but rather focusing on the specific caveats for deploying XenDesktop.
SCCM Application vs. Package
In this article an SCCM Package (Legacy Application if you are using a really early version of 2012) is used, this is because deploying applications within a Task Sequence (a series of steps to achieve a task, akin to scripting but in the native SCCM format) is still intermittently unreliable.
The preferred method wherever possible would be to use an SCCM Application. For example if the desire was simply to deploy binaries and use a different method to configure the server (e.g. Desired State Configuration or DSC), an SCCM Application should be used. This is because applications offer better control in SCCM, for example it is possible to set reasonably complex rules to validate the environment and compliance rules can be applied to maintain that state.
In simple terms an SCCM package is simply running a command whereas an Application keeps a program installed and compliant on a system.
While it is tempting to import only the “XenDesktop Setup” folder into SCCM, this unfortunately will result in a failed install.
The installation requires files from the following folders based on a /nosql install:
|\Citrix XenDesktop 7.13\ProductVersion.txt
\Citrix XenDesktop 7.13\x64
\Citrix XenDesktop 7.13\Support\DirectorWMIProvider
\Citrix XenDesktop 7.13\Support\DotNet452
\Citrix XenDesktop 7.13\Support\Installer4.5
\Citrix XenDesktop 7.13\Support\SharedManagementObjects
\Citrix XenDesktop 7.13\Support\SQLLocalDB2014
\Citrix XenDesktop 7.13\Support\VcRedist_2008_SP1
\Citrix XenDesktop 7.13\Support\VcRedist_2010_SP1
\Citrix XenDesktop 7.13\Support\VcRedist_2013_RTM
\Citrix XenDesktop 7.13\Support\VcRedist_2015
|Note:Note: This may not be an exhaustive list but did work in my Lab. Original package is 2.32 GB, the stripped down version is 897 MB. Please test, test and test again before removing vendor files from install media|
There is nothing particularly special about this package other than defining the software can be installed “Whether or not a user is logged on” and it is “Run with administrative rights”
As above all the standard options are fine, the only exception is that the software is not run from a Distribution Point. This seems to cause the integrity check to fail so select the option to “Download content from the distribution point and run locally
The installation logs for XenDesktop components can be found here:
If there are issues with the deployment and there is nothing obvious in the SCCM logs this would be a good place to start to troubleshoot.
MSI install logs are also located here in a sub folder MSI Log Files.