Automating Citrix XenDesktop has been taken to the next level since XenApp 6.0. For those of us still remembering the “good old days” struggling to automate settings with MFCOM, the arrival of PowerShell has been highly appreciated. Basically all installations and configurations can now be managed using PowerShell. To be able to automate your environment you need to understand the PowerShell fundamentals.

It is also important to understand certain fundamentals in order to work with the other PowerShell related articles on Dennisspan.com. In most, if not all, PowerShell related posts I refer to this article for further clarification. This keeps me from repeating the same information.

For a nice and neat summary of what PowerShell is and how to use I strongly recommend to read the article PowerShell Cheat Sheet by CompariTech.

Table of contents File locations Snap-ins and modules Security Help

File locations

The directories which store PowerShell modules are defined in the environment variable PSModulePath on the local server:

The Windows PowerShell module files are located in the following directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules

The Citrix PowerShell files are located in multiple directories.

PowerShell file location	XenApp	XenDesktop (7.x)
C:\Program Files\Citrix\PowerShell Modules	XenApp 6.5
C:\Program Files\Citrix\XenDesktopPoshSdk\Module\Citrix.XenDesktop.Admin.V1		Delivery Controller, StoreFront
C:\Program Files\Citrix\Telemetry Service		Delivery Controller, StoreFront
C:\Program Files\Citrix\Receiver StoreFront\PowerShellSDK\Modules		StoreFront

When modules are stored in a directory defined in the PSModulePath variable they can be loaded without specifying the directory. For example:

PowerShell will automatically check these directories when searching for a module.

When adding your own or third-party PowerShell extensions to your system it is best to copy them to a directory which is defined in the PSModulePath variable. It is also possible to create your own directory for these PowerShell modules and then add this path to the aforementioned variable.

Please be aware that this path has nothing to do with snap-ins. As explained in the upcoming paragraph, snap-ins are DLL files which need to be installed. The directories containing these DLLs are not listed in the PSModulePath variable.

The following paragraph deals with snap-ins and modules.

Snap-ins and modules

PowerShell items such as providers and cmdlets are installed by using modules or snap-ins. Modules and snap-ins are not the same thing.
Modules are packages containing PowerShell items which can be imported in your Powershell session. The command for this is:

Snap-ins are dynamic link libraries (*.dll files) which first need to be installed on your local system before you can use them in your PowerShell session. Snap-ins are added with the following command:

To see all available modules on your system type the following command:

Note: in order to see available modules these modules have to be stored in a directory which is defined in the environment variable PSModulePath (see the previous paragraph).

To get the list of all available (= installed) snap-ins type the following command:

When starting PowerShell (powershell.exe) the internal Windows modules and snap-ins are loaded automatically.
Third-party modules and snap-ins, such as the ones from Citrix, are not, even though the directories containing modules are registered and all snap-ins are installed. Citrix modules and snap-ins have to be loaded “manually” every time PowerShell starts using the aforementioned commands.

For example, one of the first command in a Citrix related PowerShell script is:

After you have loaded your modules and you have added your snap-ins you can use the following command to see all available cmdlets.

The above PowerShell command returns ALL available cmdlets in your current PowerShell session and not just the once from Citrix.

Since Citrix PowerShell modules start with the name “Citrix” (except for the XenServer module which is called XenServerPSModule) it is possible to filter the output of the get-command to only show Citrix specfic cmdlets:

The following command also includes the XenServer module in your output:

To further customize the output, add the select-object statement. For example, if you are only interested in the name of the cmdlet and the module that contains it use the following PowerShell command:

In case you would like to import your own modules (*.PSM1 files) or modules from a third-party vendor, use the following command:

In case the file is stored in a location which is not included in the variable PSModulePath use the following command:

Security

Executing PowerShell scripts (*.ps1 files) often results in an error due to the default security restrictions. In this case execute a PowerShell script as follows:

• Open a command window (Start Menu \ Run \ “cmd.exe”);
• Execute the script as follows: powershell.exe -executionpolicy unrestricted -file C:\example.ps1

See the following Microsoft article for other security options:
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-powershell-1.0/ee176961(v=technet.10)?redirectedfrom=MSDN

Help

To see more information about a cmdlet use the build-in help function, which is get-help:

To get detailed information type the following:

To view the available examples enter:

I hope this article was helpful to you! Happy scripting!