As part of my involvement with the Ask the Architect program, I try to venture out into our various Citrix SDKs from time to time to gain an understanding on what we are capable of automating. The XenDesktop 4 PowerShell SDK is something I’ve had on my list for some time to tackle. After all, XenDesktop is a huge focus of the company, PowerShell is the new de facto standard for scripting languages, and the blending of them together can have a huge impact on simplifying administration in a big way.

When I first started to learn the XenDesktop SDK, I didn’t realize that there was actually quite a bit already written about the topic. Many of you may have seen Christian Gehring’s blog on the XenDekstop 2.1 PowerShell SDK. He provides a great summary and some sample scripts for getting started. Paul Wilson also has some recent blogs on creating PowerShell scripts for a Hyper-V/XenDesktop environment.

So why the need for a new blog series? I think there is still quite a bit we can discuss and explore with the XenDesktop SDK. How many of you are XenDesktop admins that have a need for automating various configurations within the environment but you don’t have a background in PowerShell to get started? Or how many of you have seen some sample scripts, but are not quite sure how to customize them to fit your own needs? I’m going to take a different approach with this blog series to not restate what has already been stated, but to provide topics that can benefit those both new to PowerShell and those that already have had some experience with the XenDesktop SDK. In particular, the goals I have for this blog series are as follows:

  • Demonstrate XenDesktop PowerShell scripts that can be executed on both the Desktop Delivery Controller (DDC) as well as any other domain member machine
  • Provide additional insights on what the scripts are doing so that any XenDesktop admin can learn how to create their own scripts or modify the supplied scripts to suit their own environments
  • Provide reference materials for the upcoming TechTalk that I will be delivering on August 24 on how to use the XenDesktop 4 PowerShell SDK. I will be co-hosting this TechTalk with Mike Bogobowicz and we will cover the essentials on the XenApp and XenDesktop PowerShell SDKs.

PowerShell Overview
In this day and age, most of us have heard about PowerShell. We may not have all used it directly before, but it’s something that we see pop up quite a bit on product installations. Both XenDesktop (all versions) and XenApp 6 use PowerShell as their SDK for automating configurations. Citrix Workflow Studio is heavily dependent on PowerShell for the core of how it executes workflows. Microsoft (who creates PowerShell) provides their own PowerShell commands for most (if not all) of their latest products. PowerShell is also pre-installed with Windows Server 2008 and Windows 7. A separate installer is available for earlier Windows operating systems such as Windows Server 2003 and Windows XP.

Essentially, PowerShell can be thought of as an object-oriented scripting language. Let’s break that statement down really quick.

  • First – it’s a scripting language. Like other scripting languages before it (e.g. VBScript), you can create a custom script file that contains a series of PowerShell commands and the commands are executed from the top to the bottom much like how a book page or movie script is read. The key thing about scripting languages and what differentiates them from the core .NET languages (C#, VB.NET, etc.) is that they are not pre-compiled before they are executed. With a standard Windows program, you compile your source code into a binary file (EXE or DLL) first before you execute it. Compiled code can run faster than a non-compiled program since the instructions have already been translated into code that the OS can understand better. To summarize, PowerShell scripts are executed completely at run time, from the top to the bottom, much like how our older VBScripts run.
  • Second – it’s an objected oriented language. As you will soon see in this blog series, many of the XenDesktop PowerShell commands (called cmdlets) will retrieve a configuration from XenDesktop and return it to you as an object. You can define your own variables to store this object within memory. Once you have the object stored inside a variable, you are free to view the properties of the object or call its methods. You can also use this object as a parameter into another PowerShell cmdlet. Being able to natively use and manipulate objects as part of a PowerShell script really simplifies the complexity and length of the script. This concept will be repeated over and over again in all of the scripts that we discuss in this blog series.

Getting Started with the XenDesktop 4 PowerShell SDK
So we know a little bit more about PowerShell, how do we get started with the XenDesktop 4 PowerShell SDK? The cool thing about this SDK is that you can execute XenDesktop PowerShell scripts from any domain member machine, not just the Desktop Delivery Controller (DDC). As long as your machine resides on the same domain as the DDC and the DDC is reachable, the scripts will run just fine. In fact, all of the scripts that I will share as part of this blog series were built and executed on a generic Windows Server 2003 domain member that had no other XenDesktop components on it other than the PowerShell SDK.

1. Determine which machine you want to run your scripts from. For me, the real choice was to either run on the DDC or run on another domain member machine. I chose a general domain member since I know that any script I produce there will also run on the DDC just fine. FYI – I’m finding that many of the XenDesktop scripts that have already been posted to the web will only run on the DDC in their current form. Just keep that in mind as you review the scripts.

2. Install the prereqs for the SDK (PowerShell 1.0 and the .NET Framework 3.5). The .NET Framework 3.5 can be found on the XenDesktop installation media. Powershell 1.0 can be found as a free download from the web here.

3. Insert the XenDesktop 4 installation media (ISO or CD) and select to install the Desktop Delivery Controller SDK. It’s a very simple install, just click Next through a few dialogs.

4. Launch PowerShell. There’s a couple ways you can open the PowerShell prompt to start writing your own XenDesktop scripts:

  • Open the Desktop Delivery Controller SDK Shell from the Start window. – from the Start Window, if you navigate to All Programs –> Citrix –> Desktop Delivery Controller SDK –> Citrix Desktop Delivery Controller SDK Shell, a special PowerShell window will open that already contains the XenDesktop PowerShell snap-in pre-loaded. You can start using the XenDesktop cmdlets right away within this window.
  • Open a generic PowerShell window and add the XenDesktop PowerShell snap-in manually. – I don’t know exactly why, but this is the route I always choose. Maybe it’s the feeling I have more control over my entire session. With this option, open a generic PowerShell window by navigating to All Programs –> Windows PowerShell 1.0 –> Windows PowerShell. At the PowerShell prompt, type the following command to load the XenDesktop PowerShell snap-in.
Add-PSSnapin <span class="code-quote">"XdCommands"</span>

No matter which of these options you choose, PowerShell needs to be allowed to execute scripts in order for the Add-PSSnapin “XdCommands” command to execute correctly. If you perform either of the above options and see some error messages, it mostly likely means that PowerShell has its execution policy set to Restricted. To get the current PowerShell execution policy, type the following command:


If the above command returns Restricted, we need to relax the policy to something like RemoteSigned. Type the following command:

Set-ExecutionPolicy <span class="code-quote">"RemoteSigned"</span>

5. View the available XenDesktop cmdlets within PowerShell. At the PowerShell prompt, type the following command:

Get-Command -PSSnapin <span class="code-quote">"XdCommands"</span>

6. View the help on a specific XenDesktop cmdlet. For example, to get the details of the Get-XdFarm cmdlet, type one of the commands below. Notice that you can include an extra switch called -full to provide even more detail about the cmdlet. I would definitely recommend doing that when you start out. The pound symbol # just represents a comment. Statements with a leading # are ignored.

#Provide basic data about the cmdlet
Get-Help Get-XdFarm

#Provide comprehensive data about the cmdlet, including full parameter descriptions and sample scripts
Get-Help Get-XdFarm -Full

In the next blog, we’ll take this to the next level and actually start to use the cmdlets to retrieve back information from the XenDesktop farm. Stay tuned!

Available Resources
I mentioned in the sections above about some existing resources on the XenDesktop PowerShell SDK. Whenever you get started with a new SDK, it’s always good to know what is already out there for you to leverage. If I missed any resources, feel free to post a comment and I’ll be sure to update my list…

Upcoming TechTalk
I will be leading a TechTalk with Mike Bogobowicz on Essentials for using Windows PowerShell with XenApp and XenDesktop on Tuesday, August 24 from 2pm to 3pm EST. If you interesting in learning more about these SDKs first hand and want to see the demos in action, you can sign up here. We hope to see you there!

Blogs in this series
I have a lot of blogs planned for this series, and my hope is to complete all of them prior to the TechTalk. Stay tuned for more blogs in this series coming very soon!

Ed York – Senior Architect – Worldwide Technical Readiness
Ask-the-Architect Site:
Follow Me on twitter: