RG067 – Inside Workspace Manager 2014 SR2

By Max Ranzau


Note this article is not current as April 2014 saw the release of Service release 3. I have not had time to take that one under proper review, so for info on SR3 go have a look at the RES blog here. The article below is on the previous release, but keep in mind since the Service Release updates to Workspace Manager are cumulative, the information below is still valid, if not the latest and greatest:

res-wm2014-00From the Nuts&Bolts Dept. November 2014 saw the release of Workspace Manager 2014 Service Release 2. You may have read the initial post over at RES, but as always here at RESguru.com we like to kick the tires and take it for a spin around the block. There’s several items in this release that are important to know about and I’m going to highlight some and give you my view on them. You can of course dust through the full release notes here as well. Let’s roll up the sleeves and get started:

Update considerations:

First of all, when rolling out the SR2 update, keep in mind that if you occasionally are using the Force Cache update on the agents view, you want to get all agents spun up to SR2 as quickly as possible. RES has changed some of the security underneath the hood, so a SR2 console can’t force-cache-update an SR1 agent, and vice-versa. You may recall the TCP/1942 port, which needs to be open on the WM agent. This port hasn’t changed, but the comms on it has. The schematic below explains it pretty well:



Finally! Batch Buildingblock processing:

Long awaited is the ability to export and manage buildingblocks. Many customers I’ve trained and worked with over the years had a hard time understanding why it was only possible to batch import buildingblocks with the current pre-FR2 /add parameter, but it wasn’t possible run a regular backup/export. Well, lo and behold we now have the following new commandline options for the WM console binary, pwrtech.exe:

  • /del – delete configuration items currently inside the WM datastore. You can use both a buildingblock, thereby mass-deleting items, or just deleting one item by specifying it’s GUID (this can be found by exporting a buildingblock and looking for the <guid> tag.)
  • /export – the droid we’ve been looking for. This allows you to export any one object by specifying a guid. It can also export all configuration objects of one or more given type keywords separated by commas.
  • /addresource – Allows you to upload any file as a custom resource to the WM datastore. With a /path parameter you can specify where in the custom resource folder structure the resource will be placed, or you can just leave it in the root. Using a /guid parameter you can overwrite an existing resource
  • /exportresource – Does pretty much the opposite. Either a /path inside the custom resource structure or a /guid to what you want to export can be optionally specified
  • /delresource – Deletes a custom resource. Again either /path or /guid can be specified.

A couple of random neuron-misfires here:

  • This makes me wish RES would put in a GUID field in the console (which can be copied from, thank you very much) on each and every last item, thus it would be quick to reference it as the alternative is to sit and munch through buildingblock XML. Besides, we already have the GUID visible on managed applications, so why not make it consistent
  • Also, these new commandlines gives food for thought. One could quite easily imagine future customers subscribing to new WM content made available from someone (like RCS), running a BuildingBlock IT store, powered by Automation Manager downloading buildingblocks and importing them… Now there’s an idea! :)

For now, go look at page 16 of the release notes for the exact commandline syntax until we get the WM Commandline Reference updated accordingly with the new stuff. Also be sure to check the type reference on page 18.


Automatic agent cleanup

agentcleanupAnother item that is handled better in SR2 is the list of WM agents. It stands to reason that in non-persistent VDI environment, you would end up with a boatload of inactive agents as your hypervisor is generating new computernames, depending on your agent identification method. Prior to SR2 you would have to clean these out yourself on a regular basis. This is no longer necessary as the Settings tab for the agents now has a setting for automatic agent removal. Besides having it turned off, you can choose between 45, 60, 90 and 120 days where you haven’t heard from an agent and it’ll automagically be removed.

Loads of new registry settings

regedit-supericonThe new Workspace Manager SR2 includes about 9 new behinds-the-scenes registry treaks. There are several settings relating to the WM Relay servers. to configure custom certificates to secure the communications between agents and as well as handling log cleanup and connection timeout. You can check out the tweaks in the updated WM Registry Guide available here.


New filehash based whitelisting.

filehash1Whfilehash2en authorizing files in Workspace Manager security, you can now add SHA-1 filehashes to the authorization. In the past the Appsense guys were moaning on about how that was a big differentiator to their advantage, so there – another FUDbomb defused. Besides, their filehash was afaik MD5 based, which generally is considered inferior to SHA-1, due to a lower bitlength and fewer rotations. Stones and glasshouses, lads. Note that the SHA-1 filehashes can either be imported via the Authorized Files node, or on the new log screen. I’m guessing there might be a new new logtype in the database as a result, so perhaps we soon might see an update of Patrik G’s DB Cleanup Tool. One important thing to mention is that you can also batch import the SHA-1 filehashes with a command line, like this: Pwrtech.exe /importhashes=<file> /createifnotexists.


XenApp 7.x Publishing

ctxreceiverWhat’s there to say; it just works. While some of us were banging around with the SR1 update pack for a while which had a few snafu’s, they to have been ironed out nicely in the SR2 release. One weird thing I’ve come across a couple of times is that for no apparent reason, you may get the WM ‘The application cannot be started”-popup on the XA box, however it seems that a de-publish/republish via QuickEdit resolves that and the problem doesn’t come back. One thing to note, it looks like Citrix brought back Session Lingering in XA 7.6, so while Workspace Manager SR2 offers a surrogate solution via a reghack, it looks like it’s only relevant up to XA 7.5


The above is a small sample of all the improvements that SR2 offers, which I found interesting at this point. There’s plenty more. Again, I cannot emphasize this too mch: When there is a new major release or update to any of the RES products, always take the time to read the release notes. There are loads of goodies in there!


No Comments

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

You must be logged in to post a comment.