Author Archives: Daniel Bolton

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!

The Power of a Service Store

At work we have traditionally opted for a push “everything” to everyone and everywhere model with the desktop. This in my view is a legacy concept and can pigeonhole users in to a single “class” of user type.

For us (IT) it’s becoming increasingly challenging to manage the diverse range of users we have. From the task worker to mobile power user we can no longer “dictate” what people use to work/study.

One of the most exciting projects I think I’ve led in my time here is the introduction of the KUSS (Kingston University Service Store). With the KUSS we will (have already started to) change users into service consumers and empower our staff and students to control their workspace. This is achieved by providing a personal service catalogue, where services can be subscribed to and where the service will follow the user.

To give an example of how a small and simple service can dramatically improve the user experience, as well as save time and not have IT involved with the process…

One of our service store workflows has reduced one support task from an average 1 to 3 days response time down to 30 seconds!

Our academics often require the ability to have local administrator access on their managed workstations. The traditional process for this has been to,

  • Log a call with the service desk
  • Wait for the call to be escalated to the local support team
  • Wait for local support team to either remotely add the user to the local administrators group or visit the machine in person.

Now with the KUSS we are providing users with a self-service facility to grant local administration access on their local workstation without the service desk or IT being involved. In addition to this a job is automatically opened and resolved for the user on our helpdesk system (for audit purposes).

This is one of many “small” services that can have a big impact.

Of course a service store is much more than simple administration tasks… Application access, app delivery, drive mappings, printer access, storage and VM provisioning – Anything that can be automated/scripted can be turned into a service for users to “consume” and make life easier for IT – or at least allow us to focus on innovation rather than spending our time being reactive.

For those that are interested… We’re using RES Service Orchestration for the KUSS. I can’t think of a better product that brings self-service delivery and workspace management together.

The best way to empower a user is to give them nothing…

Dan.

KU vWorkspace Multi Session Initiator – Beta

I’m pleased to be able to announce the public beta of my new vWorkspace session initialization tool for the purpose of load/stress testing vWorkspace deployments.

I say “my new” but Adam Wilden (works with me) brought a lot to the table too.

I’ve dedicate a page (with details and screenshots) HERE

Enjoy!

 

 

RES, vWorkspace and WinTPC – A Winning Combo

I bet there is not many (if any) people doing all three at the same time but I am and am pretty sure we will use this as our re-purposing strategy…

Check out this video of our RES Workspace Manager, Quest vWorkspace and Microsoft WinTPC repurposing blockbuster here:

This was actually filmed some time back using the first public beta of WinTPC… the login process is roughly 5 seconds faster now and the black screen “delay” on logout no longer happens.

It’s obvious to me but just to explain the process of whats going on….

Firstly, we have deployed WinTPC through our normal delivery methods, bound it to AD, Installed the vWorkspace Connector and installed RES Workspace Manager which, adds it’s self into a WinTPC workspace container.

The video shows the following steps,

User logging into WinTPC.

RES Workspace Manager composes the users desktop which, auto launches a full screen vWorkspace session at login.

RES Workspace Manager composes the user desktop on the remote session. The user can now work…

Once finished with the remote session, the user logs out (instant logoff enabled in Workspace Manager)

Workspace Manager automatically logs the user off the physical workstation.

Job done!

Wait… What happens if a user needs to access another remote desktop/session?

Well RES have you covered here… Actually there are many waits you could splice this but my favourite (this week anyway) is to assign a different workspace container (with the other remote session allocated to it) to the same device and have the user choose at login…

Wait (again)…. What happens if they need to access multiple desktop sessions at the same time?

Well… RES (and only RES in this situation) have you covered again too… VDX styleeee.

I will document the steps to configure this setup in the near future….Honest 😉

Goody bye.

How to Integrate RES VDX and Quest vWorkspace

For those who don’t know what RES Software’s Virtual Desktop Extender (VDX) is, check it out: RES VDX

VDX effectively allows users to view locally running/installed apps on top of their full screen virtual desktop/RDSh session. It’s a little more than that but I’m not doing a sales pitch today (not feeling creepy enough).

VDX as it currently stands, supports Citrix ICA/HDX, Standard RDP (including RemoteFX) and I think PCoIP (not sure). With a little bit of tweaking it will work with the current (7.2 MR1 at the time of writing this) version of vWorkspace.

Actually VDX worked with vWorkspace since before it was called VDX and before vWorkspace was called vWorkspace, http://support.ressoftware.com/Modules/KnowledgeBase/knowledgebaseTreeView.aspx?id=1760

However as solutions evolve compatibility issues arise from time to time… With the help of the splendid chaps from both Quest and RES, I have been able to get VDX working with vWorkspace and this is how…

Create the following path:

HKLM\Software\Provision Networks\Terminal Services Client\AddIns\VDX

————————–

Create:

String (REG_SZ)
Value Name – ‘Name’

String (REG_SZ)
Value Data – ‘C:\Program Files\RES Software\VDX Plugin\VDXRDPPlugin_x86.dll’

Without the ”…

Note: As the vWorkspace connector for Windows is only 32bit, you still need to set the same dll (as above) on x64 systems however the Provision Networks key is located in, HKLM\Software\Wow6432Node\ – I guess once Quest release a x64 connector then you will need to switch to the x64 VDX DLL.

Also… In the original RES KB, HKLM\Software\Provision Networks\Terminal Server Client was used… This now needs to be, HKLM\Software\Provision Networks\Terminal Services Client. This is where I went wrong!

I have tried this on both X32 (Win XP/7) and X64 clients (Win7) using RDP/EOP and RDP with RemoteFX and EOP connecting to a RDSh session. I assume it will work for RemoteFX/EOP on a VDI box but I’ve not had chance to test.

I guess the next step is to get Quest and RES’s products aware of each other to automate this process!

My Next RES/vWorkspace compatibility post will include RES Workspace Manager working with vWorkspace for VDI and RDSh.