WEM 4.3 Upgrade Available

63426576

Intro

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.

Documentation

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]

Deprecated

Item Announced in Alternative

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

4.3

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

4.2

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

4.2

Removed

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,
Alain

Advertisements

PowerShell: Get XenApp Load and Create Report (Again)

load2.jpg

Intro

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.

Changes

  • 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.

load1

The Script

Get the script from Github

PowerShell: Cleanup Reboot script

cleanup-reboot

Intro

If your environment leverages Provisioning Services and is fairly large, you may run into issues with servers coming up but not allowing any users to login. The fix we implemented is to reboot those servers after it’s clear that they will not allow users to login (usually sometime mid-morning when most of our users have logged in). This was  a manual process and I wanted to find a way to automate this until we could change our reboot schedules or find a resolution. In this post we’ll explore using a script to catch these unresponsive servers.

Scenario

Your reboot script ran last night and you find that the next day there are a handful of servers that report to the farm, but do not have any users attached. You’ve checked the obvious problems/issues and the event log isn’t any help. The only solution seems to be another reboot. Once the system comes up, users are able to connect.

In order to automate the reboots, we have to determine the criteria that identifies a server as having a problem and not just an idle server.

  1. It is mid-morning and most of our users are logged in and using Citrix. The server has no users connected even though the load evaluators and login behavior should allow users to connect.
  2. The server is marked as ‘Online’ when using the PowerShell Cmdlet get-xaserver.
  3. The server is a not in our excluded list (more on this below)
  4. The server has a high load even though it is hosting no users.

I got one two words for you…Worker Groups

You will have to edit the $WORKERGROUPS variable to list the Citrix Worker Groups (WG) you wish to check for zero-user servers. The list can be separated by commas. Optionally you can also edit $EXCLUDESERVERS to have the script ignore servers you do not want checked for zero-users.

The script will iterate though the servers in each WG. This is done with 2 nested foreach loops.

The script confirms the Worker Group is valid and then iterates through the servers in the WG. It checks that the server is considered Online and not a member of the $EXCLUDESERVERS list. It then confirms the server has no users connected and then checks to see if the load is greater than or equal to 3500. In our farm, this was a common characteristic for these zero-user servers. You may need to change this to better reflect your environment. I setup a scheduled task to run this script every day around 10Am and it has automated an administrative task freeing me up to write blogs about PowerShell.

NOTE that this script does not actually reboot the server. We have another script that runs all day looking for servers that are set to ProhibitNewLogOnsUntilRestart. This secondary script checks that no users are logged into a server set to ProhibitNewLogOnsUntilRestart and then reboots it. You could edit the script above to add this.

What about reporting?

If you wish to receive an email report of which servers were set to ProhibitNewLogOnsUntilRestart uncomment the above lines in the script. You will have to provide an SMTP server and a single or list of email addresses. Here’s an example of the email report:cleanup-reboot

The Script

You can download the script from Github.

Thanks for reading,
Alain