Tag Archives: Workspace Manager

VMware Horizon Mirage RES Workspace Manager Integration

Probably one of the best acquisitions in end point computing (in recent times) was VMware’s crafty swipe for Wanova.

In my opinion VMware Horizon Mirage (formally Wanova Mirage) is the best next generation Windows deployment and management platform in the market today.

To learn more see: https://www.vmware.com/products/desktop_virtualization/mirage/overview.html

And for some more in depth info of their layering coolness see:

RES Workspace Manager
So we’re currently at the end of our pilot phase with Mirage and are now in that “anxious” Business Case phase. Like with any project you must set out clear success criteria. For us one of the key check boxes was compatibility with the RES product suite.

So the good news is that if you have integrated Workspace Manager with VMware View or Citrix XenDesktop before, it’s pretty much the same process.

Configure Workspace Manager to ‘Identify Agents By’ ‘Computer domain name and NetBIOS name’.


Simply install Workspace Manager on your Mirage reference machine as you would with your parent/golden VDI image and that’s it. Publish the base layer to your Mirage end-points and off you go.

Hardly worth blogging about I know but sometimes with something “new” people like a little validation.

Next up, VMware Horizon Mirage RES Automation Manager Integration! – Not hard either…

Using RES Workspace and Automation Manager with App-V 5.0

At the time of writing this RES Workspace Manager and Automation Manager do not currently support App-V 5.0 and PowerShell 3.

This article is the work around… We are using RES WM and AM to publish and manager App-V 5 packages. I’m guessing there are other/better ways of doing this 😉

First of all using Automation Manager I created a new module called “App-V 5 Publisher”.  Within this a “Command” task (note, PowerShell 3.0 is not supported at this time).The script field has the following,

“”c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe” “add-appvclientpackage -Path ‘$[AppPath]‘| Publish-AppvClientPackage -global | Mount-AppvClientPackage””

The ‘file extension of Script’ is the default ‘cmd’.

Note: I use a parameter called AppPath to which we pass a variable from Workspace Manager.

Under the Settings tab, I execute the command using the windows command interpreter and I specify a domain based service account with local admin access.

Note:  You need to ‘Load user profile’.

That’s all that’s required in Automation Manager.

Before the Workspace manager configuration I recommend you publish the app to your “test” machine which also has the WM management console… Un publish/remove when after the following steps.

In Workspace Manager, under Composition and Applications, create a new package (using the wizard if you prefer) and for the application path, browse/type the location of the published application (%programdata%\appv\etc\etc…

Configure the application as you would any other managed app. Note you can still use Process Interception, Zero Profiles, etc…

Under the Configuration options add a new Automation Task.

Now select the module you created in Automation Manager (above). You will be prompted to enter a parameter value for the module. Enter the path to your app-v package (Package.appv) on your content/network share.

Select ‘Skip if application executable was found’, ‘wait for task to finish before continuing’ and ‘Run before other actions’.

Click OK and ta-da, test away…

This is far from perfect but it works (for me anyway). My only recommendation at the moment would be not to publish packages with start menu/desktop shortcuts and use Workspace Manager for this. As the package is being published globally, other users of that workstation will be able to access the package (unless you implement other lockdown, etc).

It’s a start anyway!