Tag Archives: XenApp

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 Citrix.com). 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,

PowerShell: Get XenApp Load and Create Report (Again)



Nostalgia is ruling movies and TV these days. Mystery Science Theater 3000 has returned from the dead to Netflix. I’m still getting through he first episode, so I’m still withholding judgement. In the spirit of going back to the well and rehashing old ideas, I’ve revisited my XenApp Load/Report script again.


  • I’ve moved the code to my Github account
  • I’ve removed the Logon Status column and replaced it with the server’s worker group
  • I’ve sorted the report by the Worker Group
  • I fixed the formatting to display all the columns even if the first server was down. Before, if the first server queried by the script was down, then only the servername and status would show for all servers.

The Report

The report can be generated and sent to your browser of choice (the script defaults to Internet Explorer). In addition, you can set the SMTP information in the script have have it emailed.


The Script

Get the script from Github

PowerShell: Cleanup XenApp Users



One of the signs of a successful IT team is to have clearly defined environments for development, testing, and production. To actually put this into practice however, requires enough head count and enough resources (real and virtual) to maintain it. Many Citrix shops don’t have these luxuries. In this post, we will look at a script I wrote to help cleanup the users/groups assigned to Published Applications in a XenApp 6.5 farm that was used for development, testing, and production.

Hey, we need to test an app…

This phrase is met with trepidation by many Citrix Admins. Your co-worker has just sent an email with scant details and many assurances that this application test is just a POC and won’t have many users or require many resources. So you (being awesome) get the application installed and working and the POC starts.

First, you add one or two users, then more and more, then a group that holds most of the department that wanted to test this application to being with. Within a month, you’re told the POC was wildly successful and they already purchased the software. Now you have an application with a “Configured Users” section that is out of control

Yes, this is a real production application

So, if you have a number of applications like this how can you clean things up or at least get some feedback on what should change?

Putting It Together

Loops and loops

We save all the active applications to a variable and just keep the application name and assigned accounts. Then we start looping through the accounts for each application. If the account matches the regular expression (see the $accountpattern variable in the full script below) for user accounts, then it is added to the $isUser variable. Otherwise, we add the AD Group to the $isGroup variable (skipping the “Citrix Admins” group as it is already added to every application).

Act on the information

Keep in mind that we are still in the second account foreach loop. Review the $isUser and $isGroup variables. If a user is a member of one of the groups already assigned to the application, make a note in a text file to remove the user from the application. If a user is not a member of any groups, then recommend that a new AD group be created for this application and add those users to it. Otherwise, if there are no groups associated with the application, recommend that one get created. You can step through the if..else logic with some test applications and add actual active directory actions to further automate the script.

At the end you will end up with a text file (two if you use the $addADGroupList switch variable). The xaappfixes_datetimestamp.txt file has a list of users to remove from groups and suggested AD (Active Directory) groups that should be created. The xaappgroups_datetimestamp.txt just lists suggested AD groups that you could run through a AD script or hand over to your AD team.

Here is an example of the xaappfixes file


Here is an example of the xaappgroups file


The Script

You can get the script from GitHub

Thanks for reading,
Alain Assaf