Tag Archives: Quest

Goodbye Old Friend – Hello New World

Without sounding big headed I genuinely thought we had and in “some” areas still have one of the most modern desktop environments going (at a solutions level anyway). While I’m full of opinions I’ll always engage 100% with what’s around the corner even if sometimes past loyalties have to be moved to one side for the greater good.

But what was good for yesteryear is not always appropriate to move us forward.

Hello New World
It is with great pleasure to announce that we have entered into a 3 year deal with VMware for an Enterprise License Agreement for our entire datacentre and EUC stack – Horizon Mirage and View. This is part of a clear step forward for us as we rationalise/standardise our strategic partners moving forward and meet the growing demands of our Business and users.

On a personal level, this (the Mirage element) is something I’ve been working hard on for a long time and is finally coming to fruition – I’m looking forward to the next few months!

In addition to this we are drastically scaling back our VDI architecture (Losing our claim on the largest RemoteFX environment) to a deployment for 1000 CCU sessions using IBM, Teradici and Atlantis Ilio (Did I mention how cool Ilio is?). Why are we scaling back our remote desktop offering? What was wrong with it? Why we’re moving forward with traditional desktops? – These questions will be answered at Briforum UK (shameless plug).

BFLondon2014SPKR

BTW – View has come a long way since I last reviewed it… Looking forward to seeing how the elements of desktone and View are merged together in the future.

The ELA and new VDI environment are just a few of the many activities and projects under way that I will no doubt talk about in the future.

So that leads me too…

Goodbye Old Friend
As I’ve already said sometimes old loyalties have to be moved to one side and through all the excitement and great things we’re embarking on there is inevitably going to be a victim (or two).

My old friend in this case is Dell vWorkspace (formally Quest).

It’s no secret that I’ve always been the biggest vWorkspace fan boy, arguing why it’s a valid competitor to Citrx/VMware and promoting it at all sorts of events. I don’t think this will change. I truly think from a management/IT perspective it’s the best remote desktop solution going.

However… It no longer fulfils our Business and User requirements moving forward. There are some other “reasons” why we’re moving away too but I don’t think now is the time to share these – That would require a bar to be present 🙂

It’s been one hell of a time vWorkspace. I wish the remaining vWorkspace team (not many left now) all the best for the future

So why did I blog this? I know we’re observed by vendors and organisations as to what we do in this space. I felt I had to state that vWorkspace isn’t being retired because it’s a bad product. It’s just no longer has a place here and we’re moving on to bigger and better things.

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.