Category Archives: Documentation

WEM 4.3 Upgrade Available



As is often the case, Citrix incremented almost all the versions of their products during the Citrix Synergy conference. Included with the new release of XenApp/XenDesktop 7.14 was WEM version 4.3. You can now download the new version here (requires Platinum licenses and login to I’ve provided the release notes below.

What’s new

Site management

In previous releases, site settings were stored on the agent side and it was possible to change them from the agent GPO. Workspace Environment Management 4.3 introduces a different approach to site management which improves product security. Sites are now assigned to machines (or Security Groups or OUs) by the infrastructure service (broker) using a new Machines page in the administration console. A new Registrations tab under Administration>Agents in the administration console indicates machines which are bound incorrectly to multiple sites, so that you can take the appropriate action to remove the duplicate binding. A new Registrations tab on the Agents page shows agent registration information.

From this release, Workspace Environment Management “sites” are referred to as “configuration sets” in the user interface and documentation.

Agent localization improvements

The session agent user interface is now localized for the following languages: German, Spanish, French, Italian, Japanese, Korean, Dutch, Russian, Traditional and Simplified Chinese.

User interface improvements

Various text labels and messages in the installation wizards, administration console, and GPO templates have been rationalised and made mutually consistent to improve the user experience. For example, fields used to enter the same parameters in different installation wizards now use the same labels. Current and changed terminology is describe in a new glossary.


Workspace Environment Management 4.3 documentation is updated to reflect current product behaviour. Various minor improvements have also been made, including the following improvements designed to assist users:

  • a number of installation field descriptions have been revised to better explain their purpose
  • the documentation uses new standardized terminology visible in the installation wizards, GPO templates, and in the administration console. For example, the term “broker” is replaced by “infrastructure service”.
  • a glossary has been added to explain the new terminology seen in the installation wizards, the administration console, and the documentation. Changed terms are also indicated.
  • the technical overview diagram is updated
  • a new port information table has been added to summarize port usage

Fixed issues

The following issues have been fixed since Version 4.3:

  • When the Workspace Environment Management session agent is running in command line mode, User Statistics data is not reported to the WEM infrastructure services. [WEM-41]
  • The Workspace Environment Management session agent interface does not render correctly when a computer display is extended to external displays connected via a dock. This problem, which occurs when extending to multiple displays with different screen resolution settings, results in a portion of the right-hand side of the display not rendering completely. This prevents users seeing the home button or being able to change other native Workspace Environment Management settings. [WEM-90]
  • The Workspace Environment Management session agent causes the mouse to stop working on virtual machines which have the System Center Configuration Manager (SCCM) client installed with Power Management enabled. [WEM-115]
  • When you are using the Transformer feature, the session agent generates an unhandled exception if Wi-Fi is turned off using “ms-settings:network-wifi.” [WEM-133]
  • The Workspace Environment Management session agent causes the mouse to stop working on virtual machines after an interruption to network access is restored. [WEM-159]

Known issues

This release contains the following issues:

  • On Windows Server 2012 R2, if Adobe Acrobat Reader is installed it prevents Workspace Environment Management associating files of type .PDF with other PDF reader applications. Users are forced to manually select the PDF reader application to use each time they open a PDF. [#WEM-33]


Item Announced in Alternative

Support for assigning and binding existing (pre-version 4.3) agents to sites via GPO.


Upgrade agents to Workspace Environment Management 4.3.

The Administration Console will not be supported on the following platforms after the next LTSR:

Windows XP SP3 32-bit and 64-bit
Windows Vista SP1 32-bit and 64-bit
Windows 8.x 32-bit and 64-bit
Windows Server 2003 32-bit and 64-bit
Windows Server 2003 R2 32-bit and 64-bit Windows Server 2008
Windows Server 2008 R2


Workspace Environment Management will not be supported on the following software after the next LTSR:

Microsoft .NET Framework 4.0
Microsoft .NET Framework 4.5.0
Microsoft .NET Framework 4.5.1



The following platforms, Citrix products, and features are either removed in Workspace Environment Management 4.3 or are no longer supported in Workspace Environment Management 4.3.

Item Replacement

Support for assigning and binding version 4.3 agents to sites via GPO.

Assign and bind version 4.3 agents to sites via administration console.

Thanks for reading,

Runbooks or How to Make Documentation As Painful As Possible



I’ve begun the process of creating a Runbook from scratch to document a XenDesktop/XenApp environment that is completely new to me. Runbooks are useful…right? I certainly hope so, as I’m committing a lot of time to creating an exhaustive document. Having all your infrastructure and operations detailed in one place is probably best for knowledge transfer or training.  Unfortunately, it’s also great for outsourcing.

/rant on
In my prior job, the company decided that it did not want to be in the “IT business” anymore. So, as many companies are doing these days they fired “let go” the IT staff and brought in a third-party to manage operations, infrastructure, development, what have you. When this morale-destroying decision was made, my staff were directed (by me) to work with the outsourcing company to regurgitate all their accumulated knowledge. If you’ve been spared this exercise, you are fortunate. What follows is depressing and frustrating. Imparting detailed technical knowledge is difficult, especially when you’re having to document operations and infrastructure that were never documented before. Combine that with the fact that you are obsolescing yourself during this process, and you’ve got to wonder why you should come to work at all.

After many, many meetings, all this information was put into runbooks. When I reviewed them, everything was very high-level and only did a good job of describing our environment. Very little was detailed on the operations side. If you have knowledgeable staff and workers who are familiar with your technology, then I suppose this is sufficient.
/rant off

In my case, I don’t have an operations group to rely on. So, I want to document not only infrastructure in detail, but also operations. This will assist in training, but I also want to use this Runbook to improve this environment with automation. None exists at this stage and it is a barrier to scaling out the environment to support more users. So where do we start?

Define Infrastructure

First, take a 30,000 foot view of your environment. What are the major components? You’ve got a network, server infrastructure and possibly storage. Maybe start with an outline view

  1. Network
  2. Hypervisor
  3. Storage

This can be further refined (for example):

  1. Access Layer
  2. Servers
    1. Infrastructure
    2. XenApp
    3. XenDesktop
  3. Applications
  4. Users
  5. …and so on

Yeah, outlines are nice, but how do you get started?

I’m not going to sugar-coat it, this is the toughest thing to put together especially if you don’t have anything yet. The best way to get started is to keep expanding your outline with more and more detail. You can note procedures for changes, user management, application testing and so on. I’ve previously done a blog post on documenting Citrix Policies using PowerShell and MS Word. I would also highly recommend using Carl Webster’s documentation scripts. This can fill in a lot of detail for you. Carl has the following scripts available:

  • Active Directory
  • DHCP (DHCP must from from Windows Server 2012)
  • NetScaler
  • PVS (5.6 – 7.1)
  • XenApp 5 for Windows Server 2003
  • XenApp 5 for Windows Server 2008
  • XenApp 6
  • XenApp 6.5
  • XenDesktop 4

The scripts are available here: Where to Get Copies of the Various Documentation Scripts

Carl is developing other documentation scripts (XenDesktop 5 for one), so keep checking his web site for updates.

The Long Haul

I’m still actively working on my runbook (123 pages, with attachments almost 200) and have benefited from information I had from the previous environment administrators and earlier jobs, but I have my document always open and I’m making additions and edits to it daily.

So What About You?

I hope this post has inspired you to work on a run book or at least encourage documenting more of your environment and procedures. Please leave any tips, ideas, or questions in the comments. I’d like to know what you do to document and I’d like to know if you don’t document.


Powershell: Installed Software Versions


When you take over an existing environment, there are always surprises that keep one up at night. One of the most important applications that I deliver with my cloud environment was developed in-house. It was never designed to run in a multi-user environment and each installation is specific to a single user. This is a mess to say the least, but one of the largest issues is how to maintain, update, and easily deploy to new users. This post will begin with determining how many versions of this software are installed.

First the Good News…

I love starting with the good news. All the installs are on one XenApp server. This will allow us to iterate though some number of directories and query all the EXE’s for their version without making RPC’s or some other method of file query.

Now the Bad News…

Each install generates 3 (sort-of) random sub-directories, so there is no fixed pattern to where the main EXE resides. I say sort-of because at least they follow a pattern that we can rely on. RegEx to the rescue! The rest of the bad news is that all versions of the software under the latest will not automatically update. Thus I need this script to know how big a problem I have and which users I need to contact to update their software.


I can add more fields to the CSV by doing an AD user lookup and getting an email address and/or phone number as I will have to contact these users to upgrade their software. This will require either Microsoft or Quest Active Directory PowerShell modules.

The Script

Creates a list of users and their installed Software Version.
Creates a list of users and their installed Software Version.

It is recommended that this script be run as an admin.
.PARAMETER UserDirectory
Defaults to %HOMEDRIVE%\Users
Used to iterate through the Users directory and look for Software installs
.PARAMETER Outputfolder
Defaults to current folder location.
Enter a path to output the file.
PS C:\PSScript > .\check-Softwareversion.ps1
Will use all default values.
$env:homedrive = C:

Output file will be in the current directory.
None.  You cannot pipe objects to this script.
No objects are output from this script.  This script creates a CVS document.
NAME: check-Softwareversion.ps1
CHANGE LOG - Version - When - What - Who
1.00 - 06/04/2014 - Inititail script - Alain Assaf
AUTHOR: Alain Assaf
LASTEDIT: June 4, 2014
<a href=""></a>
<a href=""></a>
<a href=""></a>
<a href=""></a>
<a href=""></a>

[parameter(Position = 0, Mandatory=$False )]

[parameter(Position = 1, Mandatory=$False )]

$Appdata = "AppData\Local\apps\2.0"
$verInfo = New-Object System.Collections.ArrayList
$datetime = get-date -format "MM-dd-yyyy_HH-mm"
$Software = "somesoftware.exe"

#Get user list from $UserDirectory
$UserFolders = Get-ChildItem $UserDirectory

foreach ($UserDir in $UserFolders) {
$User = $UserDir.Name
$UserAppdata = "$UserDirectory\$User\$AppData"
if (test-path $UserAppdata) {
$subdir1 = Get-ChildItem $UserAppdata | where {$ -match '\S{8}.\S{3}'}
$TempDir = "$UserAppdata\$subdir1"
$subdir2 = Get-ChildItem $TempDir | where {$ -match '\S{8}.\S{3}'}
$TempDir2 = "$TempDir\$subdir2"
$subdir3 = Get-ChildItem $TempDir2 | where {$ -like 'other..dir*'}
$SoftwareDir = "$TempDir2\$subdir3"
$SoftwareApp = Get-ChildItem $Softwaredir | where {$_.Name -eq $Software}
$SoftwareVersion = ($SoftwareApp.VersionInfo).FileVersion
$SoftwareFileName = ($SoftwareApp.VersionInfo).FileName
$verInfo += New-Object psObject -Property @{'User'=$user;'SoftwareDir'=$SoftwareDir;'SoftwareFilename'=$SoftwareFileName;'SoftwareVersion'=$SoftwareVersion}

#Write report to CSV file
$LogFileName = $Software + "_VersionInfo" + $datetime + ".csv"
$LogFile = $Outputfolder + $LogFilename
$verInfo | Export-Csv -Path $LogFile