Use PowerShell to get the Citrix Configuration Log as well as Old and New Property Values

This is a quick tip to show you how to get the Citrix Configuration Log, plus all the old and new property values, and convert this all to JSON.

Here is a quick tip for you. I had a need to get the Citrix Configuration Log, so I dropped into PowerShell and ran Get-CtxConfigurationLogReport. That is all good and well, but you do not get all the old and new values of the changed properties. However, converting this output to JSON will do just what I want. Plus, converting to JSON is better for me anyway as I want to push this stuff over to Splunk to do some analytics. Here is what you need to do:

Step 1 – Create your UDL file to connect to the database

Add-Content C:\conflog.udl –Value $null; Start-Process C:\conflog.udl

This will prompt you for your SQL credentials. You can use Windows integrated security if you like, but I’m saving my creds for later use outside of my interactive PowerShell session later.

Citrix Config Log UDL


Step 2 – Get the things

# Load the Citrix Common Commands Snapin
Get-PSSnapin -Registered "Citrix.Common.Commands" | Add-PSSnapin

# Get the configuration log and convert to JSON
Get-CtxConfigurationLogReport -DataLinkPath C:\conflog.udl | ConvertTo-Json -Depth 10


Here is some sample output (notice the property old and new values)

    "EntryId":  "3_0_3",
    "Date":  "\/Date(1443804400000)\/",
    "Account":  "LAB\\administrator",
    "TaskType":  2,
    "ItemType":  0,
    "ItemName":  "Calc",
    "Description":  "Published application Calc was modified.",
    "Details":  [
                        "PropertyName":  "Application Description",
                        "OldValue":  "Calculator",
                        "NewValue":  "Calculator 123"
    "References":  [

Note, this requires PowerShell 3.0

Here is a Gist as well ->


Using PowerShell to Retrieve Citrix Monitor Data via OData

Starting with XenDesktop 7, Citrix stores the data the Desktop Director displays in a SQL database. Citrix opened up this data via a Monitor Service API that uses OData.  I’m not going to go deep into the details of the API as it is fairly well documented at the eDocs site.  The examples in the documentation show you how to access this data via web browser, Microsoft Excel, and LinqPad.  What I want to do in this article is show you how to use PowerShell with this API.

To start out, let’s take a look at the Citrix Monitor Service schema (click to enlarge):



Suppose we want to get all sessions as well as the all the connection/disconnections to the session.  The following URL will return the data we want in XML format.


The trick to get this working with PowerShell is to transform all this information into a nice hierarchical structure.  In the example code below, we use the Invoke-ODataTransform function to do this.

function Global:Invoke-ODataTransform ($records) {

    $propertyNames = ($records | Select -First 1) |
        Get-Member -MemberType Properties |
        Select -ExpandProperty name

    foreach($record in $records) {

        $h = @{}
        $h.ID = $record.ID
        $properties = $

        foreach($propertyName in $propertyNames) {
            $targetProperty = $properties.$propertyName
            if($targetProperty -is [System.Xml.XmlElement]) {
                $h.$propertyName = $targetProperty.'#text'
            } else {
                $h.$propertyName = $targetProperty


$connections = ""
$uri = "http://localhost/Citrix/Monitor/OData/v1/Data/Sessions?`$expand=Connections"
$connections = Invoke-ODataTransform(Invoke-RestMethod -Uri $uri -UseDefaultCredentials)

foreach($connection in $connections)
    $output = $connection | Get-Member -MemberType Properties | ForEach-Object {
        $key = $_.Name
        $value = $connection.$key
        '{0}="{1}"' -f $key,$value

    Write-Host $output

Citrix XenApp 6.0 to XenApp 6.5 PowerShell Upgrade Utility Under the Hood

Citrix recently released XenApp 6.5. However, there is not a way to do an in-place upgrade from XenApp 6.0 to XenApp 6.5. This means that the Citrix administrator will have to uninstall XenApp 6.0 components and install XenApp 6.5 components. Citrix released a PowerShell utility to help in this process, and in this post I break that utility down into a Visio flowchart to you can understand what is going on behind the scenes.

Ever since I was a kid, I liked taking things apart.  Citrix recently came out with a PowerShell tool to help administrators turn XenApp 6.0 servers into XenApp 6.5 servers because unfortunately (or fortunately depending on the way you look at it), there is no in-place upgrade option from XenApp 6.0 to XenApp 6.5.

This utility is a PowerShell script that performs the following:

  • Checks to see if XenApp 6.0 is installed or not, and if the XenApp 6.5 installer is available.
  • Prompts for a password to silently run the install process after reboot.
  • Uninstalls XenApp 6.0 components. By default these include the Online-Plugin, Management Consoles, and XenApp Application Delivery role. Other components are included in the script and can be enabled for automatic removal.
  • Installs XenApp 6.5 and, by default, joins the server to the farm as a worker.
  • Verifies the join is successful by checking to see if the IMA service is running.
I think this script is really cool so I had to take it apart to see just how the script was doing these things.  I made some notes in the form of a flowchart and have provided the flowchart here for your viewing pleasure.


– or-
Click the picture below for .gif image of the flowchart

You can download the tool from Citrix’s website ->

Export and Import Citrix XenApp 6 Published Applications Using PowerShell

Exporting and Importing published applications in Citrix XenApp used to be a tedious process. Now, thanks to XenApp PowerShell Cmdlets, this process is much easier and more flexible. No uber scripting skills needed.

Exporting and importing Citrix XenApp 6 published applications using PowerShell is super easy. In this article, I will show you how to export all or some of your XenApp 6 published applications into a XML file. Then, I will show you how to import those applications while overriding certain application properties like Worker Group and Server Names.

note Note: before you get started, be sure to check out this post on how to install the Citrix XenApp 6 PowerShell Cmdlets.


Exporting Citrix XenApp 6 Published Applications

The first thing we need to do is export some published applications from an existing XenApp 6 farm. In this example, I will only export applications in a certain folder instead of the entire application inventory.

Get-XAApplicationReport * | ?{$_.FolderPath.StartsWith("Applications/Testing")} | Export-Clixml c:\testingApps.xml



So, there are 3 parts to this export.

  1. Get-XAApplicationReport gets all properties of a published application. If you are familiar with MFCOM, the Get-XAApplicationReport command is similar to calling LoadData(1) on an application object.

    FYI – There is a command called Get-XAApplication, but that command doesn’t get all properties of a published application.

    Anyway, if you don’t use the Get-XAApplicationReport command, you won’t get all your application properties and you will be sad.

  2. ?{$_.FolderPath.StartsWith("Applications/Testing")} looks at each application object that Get-XAApplicationReport returns and filters out all applications whose folder path does not start with “Applications/Testing”.

    Note to Citrix – it would be nice to have some filtering built into the Get-XAApplicationReport command. You will notice in the example, that I have to get all the published applications in a farm and filter out what I do not want. That is a pretty expensive operation. It would be better to just get what I want from the get go.

  3. Export-Clixml saves it all to a XML file called testingApps.xml.


Importing Citrix XenApp 6 Published Applications

Now that you have the applications exported to a XML file, you can import those applications to another farm. Here is one way to do this:

Import-XmlCli c:\testingApps.xml | New-XAApplication -ServerNames [servers] -WorkerGroupNames $null

The cool thing about this is that you can override settings during an import. For instance, the original farm I exported from had published applications assigned to Worker Groups rather than Servers. In the destination farm, I want to publish the applications to Servers rather than Worker Groups. You can actually override a multitude of properties during the import process which will make your life easier.

note Note: if you do not create the folder structure beforehand, you will get the following error when you try to import:

New-XAApplication : Cannot find folder with path Applications/Testing (0x80160001)
At line:1 char:70
+ Import-Clixml C:\testingApps.xml | New-XAApplication <<<<
    + CategoryInfo : InvalidResult: (Applications/Testing:String) [New-XAApplication], CitrixException
    + FullyQualifiedErrorId : ComApp.GetFolderId,Citrix.XenApp.Commands.NewAppCmdlet

So, check out this article on migrating a folder structure.


Migrate Citrix XenApp 6 Folder Structure Using PowerShell

There are times when you need to migrate all or part of your Citrix XenApp 6 folder structure from one farm to another, or just back up a XenApp 6 folder structure. This post will show you how to accomplish this using PowerShell.

There are times when you want to migrate a folder structure from one Citrix XenApp 6 farm to another.  For instance, if you maintain separate test, quality assurance, and production farms and need to migrate folders and applications between the farms.  Fortunately, this is super easy in XenApp 6 using PowerShell.

note Note: before you get started, be sure to check out this post on how to install the Citrix XenApp 6 PowerShell Cmdlets.


Export Specified Folders

You can export your entire folder structure, or just certain parts of it.  In the example below, I will export only the “Testing” folder (see the screen shot below).

Here is how to export just the “Testing” folder and its subfolders using PowerShell to a XML file called “TestingFolders.xml”:

Get-XAFolder -FolderPath "Applications/Testing" -Recurse | Export-Clixml c:\TestingFolders.xml



Well, the cool thing about PowerShell is that it is pretty readable, so I don’t think this command needs a lot of explanation. However, let’s look at the resulting XML file.

  Applications/Testing/Microsoft Office

No rocket science there either. It is just a list of folders. You could easily hand craft one of these XML files to create a folder structure. What I am going to do here is modify the folder path so that the folders get created in the “Applications/QA” folder and then save the file as “QAfolders.xml”. Here is what the XML file looks like now:

  Applications/QA/Microsoft Office


Import Folders

Now that you have your XML file, it is relatively easy to import. Here is how to do it:

Import-Clixml c:\QAFolders.xml | New-XAFolder


Here are the results:


Next Steps

So all this folder structure stuff is fine, but wouldn’t it be nice to import some apps into those folders? Of course it would. Here is how to export and import XenApp 6 published applications using PowerShell.


How to Install the Citrix XenApp 6 PowerShell Cmdlets

PowerShell is the new API for Citrix XenApp starting with version 6. Whether you want to write interactive applications or work with your XenApp farm via command line, you first need to set up the XenApp 6 PowerShell SDK. This post will step you through setting up the Citrix XenApp 6 PowerShell SDK in your environment.

PowerShell is the new API for Citrix XenApp starting with version 6.  Whether you want to write interactive applications or work with your XenApp farm via command line, you first need to set up the XenApp 6 PowerShell SDK.  This post will step you through setting up the Citrix XenApp 6 PowerShell SDK in your environment.

Installing the Citrix XenApp 6 PowerShell cmdlets

Before we get started, you first need to download and install the Citrix XenApp PowerShell SDK (which includes the XenApp cmdlets). You can download the SDK here:

I recommend installing this on one of your XenApp 6 servers.  Technically, you can install this on a workstation and use remoting to remote all the commands to a XenApp 6 server, but it is very messy and doesn’t always work from my experience.  Anyway, during the setup of the SDK, you will be asked to set the PowerShell execution policy to AllSigned.  It is a good idea to leave this box checked to prevent malicious PowerShell scripts from ruining your day.

XA6 SDK Execution Policy

Adding the Snapins to your Runspace

After installation is complete, the assemblies will be loaded into the GAC (Global Assembly Cache).  Every time you want to use the Citrix XenApp cmdlets, you will need to add the snapins to your PowerShell runspace.  This can be done by launching PowerShell and using the Add-PSSnapin command as seen below:

Citrix PSSnapin

Adding the snapins will allow you to execute all the XenApp cmdlets.  Alternatively,  you can launch PowerShell from the Citrix/XenApp Server SDK folder in the  start menu as seen below.  This will launch a PowerShell runspace with all the Citrix snapins loaded and ready to go. 

XenApp PoSH

You are now ready to start PowerShelling your Citrix environment.

Bulk Update XenApp 6 Published Application Properties with PowerShell

There are times when you need to update a property on multiple XenApp published applications. If you only have a few applications to update, this can be done via the management console. However, if you have more than a few applications to update, then PowerShell is the way to go. In this post, I will show you how to use PowerShell to update published application properties on multiple applications at the same time.

Disclaimer: This article deals with Citrix XenApp 6 and above only. PowerShell cmdlets are available for XenApp 5.0 on Windows Server 2003 and 2008; however, the cmdlets are CTP (Community Technology Preview) and will likely never get “officially” released. The cmdlets in XenApp 5 are not always the same as the cmdlets in XenApp 6.

Have you ever had the need to update a lot of Citrix XenApp published application properties at the same time?  For instance, suppose you publish all your Citrix XenApp applications with sound disabled.  Then, somebody comes up to you and says “hey, we need to have all our applications support sound.  Thanks.”  If the only tool you had to use was the Citrix console, you will probably get carpal tunnel syndrome from all the mouse clicking you will need to do.  Luckily, the management console is not your only tool to solve this dilemma.  By using PowerShell and the Citrix XenApp 6 PowerShell cmdlets, this task is reduced to a single command.

Updating all Citrix XenApp 6 Published Applications with PowerShell

Note Note: if you haven’t already done so, you need to install the Citrix XenApp 6 PowerShell SDK to use the XenApp PowerShell cmdlets.  Refer to this post for more information.

The following command will set every published application in the farm to have an audio type of Basic:

Set-XAApplication * -AudioType Basic

To break this down some more:

  • Set-XAApplication will set a property on any application
  • The * is the search string to match.  If you wanted to match any application that started with test, you could use test*.
  • -AudioType is the property we are setting.  In this case, AudioType is an enumeration.  AudioType can be set to Unknown, None, or Basic

To see a list of all the properties that can be set on a XenApp published application, check out the help file that comes with the XenApp 6 PowerShell SDK, use Get-Member in PowerShell, or check out this page.

Updating Citrix XenApp 6 Published Applications in a Folder

If you only wanted to update some publised applications in a particular folder, you can first select all applications in a folder and then pass those application objects to the Set-XAApplication cmdlet like so:

Get-XAApplication –FolderPath Applications/Testing | Set-XAApplication –PassThru –AudioType Basic

Breaking it down:

  • Get-XAApplication gets a collection of XenApp applications
  • -FolderPath lets Get-XAApplication know that we just want to get applications in a particular folder
  • Applications/Testing is the folder that holds the applications we want.
  • We then pipe (using the pipe ‘|’ character) all these XenApp application objects into the Set-XAApplication cmdlet (the same cmdlet we used above)
  • This time, we use the –PassThru parameter to let Set-XAApplication cmdlet know that we are not going to search for some applications, but instead we are going to pass one or more XenApp application objects to it.
  • The rest of the parameters are the same as above

There you have it.  We have now set a property for all applications using one command, as well as set application properties using selection criteria.  Hope this helps you out with your XenApp environment.

Citrix XenApp 6 PowerShell SDK: Getting a List of Applications with C#

This post will show you how to use the Citrix XenApp 6 PowerShell SDK to obtain a list of applications from your XenApp 6 farm. We’ll look at how to do this with using the PowerShell Runspace and how to do this using the Citrix XenApp 6 wrapper assembly.

This post will show you how to use the Citrix XenApp 6 PowerShell SDK to obtain a list of applications from your XenApp 6 farm. We’ll look at how to do this with using the PowerShell Runspace and how to do this using the Citrix XenApp 6 wrapper assembly. The examples used in this post will be using an ASP.NET website, but the code can be reused in a Windows application, Console application, web service, etc.

Note Note: Be sure to read the getting started post for information about adding the correct references to your project.

Using the PowerShell Runspace

I added a Web Form to my project named RunSpaceFactory.aspx. Here is what it looks like:

using System.Management.Automation;
using System.Management.Automation.Runspaces;

namespace WebApplication1
    public partial class RunSpaceFactory : System.Web.UI.Page
        protected void Page_Load(object sender, EventArgs e)
            Runspace rs = RunspaceFactory.CreateRunspace();

            PowerShell ps = PowerShell.Create();
            ps.Runspace = rs;

            PSSnapInException ex;
            rs.RunspaceConfiguration.AddPSSnapIn("Citrix.XenApp.Commands", out ex);


            // You can add a search string like this:
            // ps.AddCommand("Get-XAApplication").AddParameter("BrowserName", "n*");

            foreach (PSObject app in ps.Invoke())


Lines 10 – 14 are standard PowerShell things you would do to work with PowerShell in any C# application.

Line 17 adds the Citrix PowerShell SnapIn to the Runspace so we can execute the Citrix commands.

Lines 19 – 28 lists all the applications in the XenApp 6 farm.

Note line 21 & 22. If line 22 was uncommented, this excerpt would list all the applications that start with the letter ‘n’ by adding a parameter to the Get-XAApplication command. You can use any matching pattern here like ‘%o*’ which would get all applications whose second letter is ‘o’.

Using the Citrix XenApp 6 Wrapper Assembly

When using the Citrix XenApp 6 wrapper assembly, you first need to add references to the appropriate DLLs to your project. The DLLs can be found in %ProgramFiles%\Citrix\XenApp Server SDK\bin


After adding the references, here is the code to accomplish the same task from above:

using System.Management.Automation;
using System.Management.Automation.Runspaces;

using Citrix.Management.Automation;
using Citrix.XenApp.Sdk;
using Citrix.XenApp.Commands;

namespace WebApplication1
    public partial class ListApplications : System.Web.UI.Page
        protected void Page_Load(object sender, EventArgs e)
            GetXAApplicationByName apps = new GetXAApplicationByName();
            apps.BrowserName = new string[] {"*"};

            foreach (PSObject _app in CitrixRunspaceFactory.DefaultRunspace.ExecuteCommand(apps))
                XAApplication app = (XAApplication)_app.BaseObject;


As you can see, there is quite a bit less code here.

Line 14 sets up all your Runspace stuff and adds the appropriate command.

Line 15 adds a parameter to the command. This is an interesting line because the BrowserName property expects an array of strings. I’m just passing one string here, but you could pass several to match. For example, string[] {“n*”, “%o*”} would find all apps that either started with the letter ‘n’ or the second letter was ‘o’.

We loop through the results in lines 18 – 24. Note that I cast the PSObject (generic PowerShell object) to a XAApplication object. This helps with the type safety and IntelliSense. To be fair, you can do the exact same thing in the PowerShell Runspace example above if you wanted.

The Results

Here is what the Citrix Delivery Services Console looks like concerning published applications:

Citrix Delivery Services Console Applications

Here is the output from both examples:


What’s Next?

The next examples will show you how to publish and application as well as how to manage sessions. You can also get a jump start by downloading the example code below:

Getting Started with the Citrix XenApp PowerShell SDK and C#

In XenApp 6, MFCOM is out and PowerShell is in. This post is the first in a series to help you understand how to develop appliations that utilize the Citrix XenApp 6 PowerShell SDK and Microsoft C#.

At BriForum 2010, Brandon Shell and I presented a session on how to make the transition from MFCOM to PowerShell.  At the end of the session, I presented several examples on how to use the XenApp PowerShell SDK in C#.  I wanted to share some of the details on those examples in a few blog posts.  This first blog post will detail what is needed to get started developing applications that leverage the Citrix XenApp 6 PowerShell SDK.

What you need

To get started, you need to set up a development environment.  You really only need two things:

Actually, there isn’t anything set in stone that says you *have* to use Visual Studio, but it will make your life a whole lot easier.  I recommend installing Visual Studio on a XenApp server because remoting in PowerShell is less than desirable for these examples.

Creating your first project

After you install Visual Studio and the Citrix XenApp 6 PowerShell SDK, you are ready to get started with your first project.  The examples I will be showing will be web projects.  So, launch Visual Studio and select  File > New > Project…

Visual Studio New Project


Add a Reference to System.Management.Automation

After you create your Project, you need to add a reference to System.Management.Automation.dll in order to do stuff with PowerShell in your project.  If you go looking for this DLL in the file system, you will find it at %ProgramFiles%\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0 <- DO NOT USE THIS FILE.  The version of System.Management.Automation you want is in the GAC.

Normally, if you want to add a reference to an assembly that lives in the GAC to your project, you can just right-click your project in Visual Studio, select Add Reference and browse for the name.  But, for some reason, this assembly isn’t like the others.  You actually have to close your project in Visual Studio and manually add a reference to System.Management.Automation by editing the .csproj file.  For example, if your project name was WebApplication1, you would need to edit WebApplication1.csproj (you can use Notepad to edit this file if you like since this file is just XML) and manually add:

<Reference Include=”System.Management.Automation” />


Once you manually add this reference to your project file, you will want to add a couple of using statement to your code files that will deal with PowerShell:

using System.Management.Automation;
using System.Management.Automation.Runspaces;


To Wrap or not to Wrap

There are basically two ways to use the Citrix XenApp 6 PoweShell SDK in a C# project:

  1. Use “traditional” PowerShell Runspace (uses common PowerShell Runspaces)
  2. Use the XenApp 6 wrapper assemply (wraps each command and paramter in a Class for safe typing)

There are pros and cons for both:

“Traditional” PowerShell Runspace pros:

  • Easy to convert existing PowerShell scripts to C#.
  • You can log all the PowerShell commands and save before running – kind or like Microsoft Exchange 2007 does.

“Traditional” PowerShell Runspace cons:

  • No type safety – meaning that commands and parameters are specified as strings – which means you can mess up by typing the wrong string making troubleshooting difficult.
  • No IntelliSense for XenApp commands/odjects in Visual Studio.

XenApp 6 Wrapper pros:

  • Type safety.  Every command and parameter is wrapped in a class so there is no chance of misspelling a string parameter or passing an incorrect parameter.
  • Enables IntelliSense in Visual Studio.

XenApp 6 Wrapper cons:

  • Does not translate well to PowerShell commands.  For instance, the PowerShell command to get an application is Get-XAApplication.  The wrapper assembly’s command is GetXAApplicationByName().

I like using the wrapper assembly personally, but in the end it is all the same.

What’s Next?

I’ll be writing a few more posts on concrete examples of using the XenApp 6 PowerShell SDK.  Stay tuned…

MFCOM to PowerShell: How to Make the Transition

MFCOM has been the de facto standard for programmatically interfacing with Citrix XenApp. Whether you wanted to write a simple script or develop an application that interfaced with XenApp, MFCOM was the answer. Now, Citrix is committed to building their management architecture on PowerShell–not just for XenApp, but for all Citrix products. That’s great news for standardization across platforms and aligning with Microsoft on using PowerShell for management architectures. Now, the question is how do you take what you know about MFCOM and translate that to PowerShell?

As you may of may not already know, Citrix has committed to building their management architecture (and SDK) on PowerShell – not just for XenApp, but for all Citrix products.

In XenApp 6.0, MFCOM is not available anymore. The underlying architecture has changed dramatically enough to make backward compatibility with MFCOM impossible. The replacement for MFCOM is PowerShell. MFCOM-based scripts need to be completely re-written in XenApp cmdlets. In most cases, the conversion should be simple and most MFCOM scripts can be replaced with one-liner PowerShell commands.

Source: Citrix XenApp 6 PowerShell SDK reference manual.

That’s great news for standardization across platforms and aligning with Microsoft on using PowerShell for management architectures.  But, that begs the question – what do you do about all those scripts and applications that leverage MFCOM going forward?  I’ll be presenting a session at BriForum 2010 with Brandon Shell about this very topic.  The session will cover:

  • General Object Orientation
  • Specific Citrix XenApp objects
  • Examples of how scripts and applications were done with MFCOM
  • Converting scripts and applications to use PowerShell
  • PowerShell remoting
  • Availability of PowerShell cmdlets on XenApp 5 and XenApp 6
  • C# applications leveraging the PowerShell command wrapper

BriForum takes place from June 15th to June 17th at the Hilton Chicago Hotel.  There is still time to register.