App Volumes + Imprivata OneSign Agent

[epa80]

Has anyone tried stacking the Imprivata OneSign Agent for SSO? We're being told to put it in the parent image along with VMware Tools/View Agent. For environmental changes, we'd love to stack it. Technically it's not supported, but that doesn't always mean it won't work. Would love to hear if anyone's given it a shot. We're going to try anyway.

[CA_Chris · Accepted solution]

Needs to be a part of the main parent image due to all the OS dependent calls...had to do the same for other products out there that do "App layering"...hopefully that'll change eventually.

[CFeeney]

The 2.x version of AppVolumes delivers "AppStacks" after the user is logged into the virtual desktop.  Because the Imprivata Agent needs to be part of the Windows logon / bootup process, delivering it "after the user is logged in" is not recommended for Application Layering.  Since the OneSign agent also integrates with the Horizon Agent, this would be another reason why delivering the Horizon Agent as an AppStack after the user logon occurs is not recommended.

So what you were told and the first reply are the correct answers. 

Regarding support, Imprivata and VMWare are working together to provide guidance for customers using AppVolumes as more customers have begun to ask about this.  More information will be coming but the general recommendation is as stated above and what you had already been told about putting the OneSign agent within the image.

[RyanChristopher]

We've successfully deployed the Imprivata Agent to our virtual desktops as a layer using Unidesk (www.unidesk.com). We actually have both the type1 and type2 agents in separate layers, along with the Imprivata Epic Connector in another separate layer (so in all 3 separate layers). It allows us to layer just one time and then apply to desktop pools as we see fit. For example, for FastUserSwitching workflow we can deploy the type2 agent to our ExamRoom desktop pool, but for other desktop pools deploy the type1 agent. We can also easily add the Imprivata Epic Connector to desktop pools with Hyperspace in them.

I'd definitely check out this solution, especially the forthcoming 4.x version with VMware support, if you are constantly updating your Gold/Master images and/or trying to have all of your applications individually layered. As an added benefit, OS updates are quite painless now (no more Patch Tuesday nightmares).

Here's a really good write up for what Unidesk can do vs. AppVolumes:

Comparing Unidesk and VMware App Volumes

This isn't to say that AppVolumes isn't a good choice if you're licensed for it and are using it for specific use cases--we've just found that Unidesk works better since it provides both in-guest/at logon (Elastic Layering) and out-of-band/pre-boot layers. Pretty much we can throw any apps/drivers/stacks at Unidesk and it will work.

[m1k3yr]

We will be testing Imprivata with App Volumes soon but our Production VDI was built with Unidesk and Imprivata is usually not a problem.  It does have a few oddities with RFID readers and needing to detect VMware Horizon View Agent during install but that's all been documented and once the layer was built, its built.  Nothing else needed to be done and it behaves like any layered app would.  We've built batch files which automated the Imprivata install setup so when a new Imprivata Hotfix comes out, we build a new layer, run the batch file install we wrote, and we're done.  Upgrading the 1800+ VDI clients is just a un-check here and a new check there.  Next maint cycle and they all come up with the hotfix version installed and the old version gone!

The trick could be that Imprivata (now this is older versions before 5.0 but I think it still holds true today) needs to see the VMware View Agent during install or else it doesn't install the little bits needed to pass creds though the different login screens correctly.  So if I understand App Volumes correctly, you need to make something where the Vmware Agent and the Imprivata can see each other during the Imprivata install.  There are several ways to do this in Unidesk but not 100% sure on App Volumes.  And since Imprivata makes changes to some Windows OS files, not sure how that would work exactly in App Volumes either.  We are testing the waters to see if anything has changed since we started VDI with Unidesk a few years ago.  Still just setting up the test environment for App Volumes.

Lastly, you may have to get with your VMware sales rep to get after Imprivata.  We had a small problem (just a registry key for the RFID readers) at the beginning and we could not figure it out.  Imprivata had a few old docs on the issue but still wasn't much help.  Our Vmware got with a higher VMware rep, who got with a higher Imprivata rep, who figured it out. 

FYI, we are running Vsphere 6.01?, View 6.02, Unidesk 2.9.4, Imprivata 5.1.207.48, 1800+ VDI machines, Teradici2 zero clients, RFIDeas readers.

Mike

[Ray_handels]

For the record, I have no idea how and if Imprivata works or doesn't work and haven't tested it

But i do wanted to reply to the Unidesk topic though as we tested both applications.

Unidesk has a totally different way of building up the machine than Appvolumes has. What Unidesk does is build a machine per user based on a specific subset of applications, patches and a golden image. If something changes the machine that is assigned to you is being recreated with the specific applications and patches installed in the machine. The positive thing about Unidesk is that it builds up the machine pre-logon and thus enhances login times quite considerably. Also, applications that need to be there during logon (like Imprivata is i guess?) will work in a Unidesk application layer.

The biggest downside to Unidesk is (maybe it changed but this was the reason we didn't went with it) that it creates a machine per user. Also, if you want your users to be able to log in rather quickly all of those machines need to be started up and ready for the user.

Appvolumes builds up the machine during login. So when logging in it checks to see which applications you have assigned and then adds these applications during logon. The writable volume is the only VMDK that is being attached pre-logon. So you could try and install applications into this.

The biggest downside is that logon takes longer because the machine is being build up during logon. The biggest positive about Appvolumes is that a machine is never assigned or attached to 1 named user. Let's say you have 20000 users but only need 1000 desktops for this userbase to be available at any given time. Using Appvolumes I only need 1000 pooled floating desktops which are created within a split second (if storage is good enough to deliver the IOPS) were is using Unidesk you would need 20000 desktops available. Just do the math .

What could be a solution (but you would need VMWare itself to elaborate on this one, maybe Jason can) is to attach the appstack pre-logon. You can assign appstacks to a machine. Only downside is you can't use both user and computer assignments due to restrictions with the writable volume (this one must always be the first disk being attached at least until now). It once was the idea to do both and i really hope it is on the roadmap. It would heavily increase logon times for users and would fix issues with applications like these that need to be there pre logon.

[epa80]

Thanks for the replies, everyone. Figured it was be a longshot. Was hoping for a miracle, simply because we're having to support multiple parent images for the different prod/test environments for Imprivata, where as app stacking would have been a fine alternative. Is what it is. Hopefully it will be a solid possibility sooner than later.

Thanks again.

[epa80]

We did try that Ray, assigning the stack to the machine. Indeed, pre-login, we saw the VMDK was mounted on the VM. That being said, we still didn't have any luck. Upon logging in, Imprivata just wasn't behaving how we expected.

[epa80]

Ray,

Would their be harm in putting the View agent on our provisioning machine, then doing a cature of the OneSign agent on that machine? I know the rule of thumb is no View Agent on the capture machine, but, trying to see if we can trick the OneSign agent into believing the View agent is there upon capture. Could this possibly work?

1. Boot up provisioning machine.
2. Install View Agent.
3. Reboot.
4. Start Provisioning.
5. Install OneSign.
6. Complete Provisioning.

[akjrabe21]

With most layering technologies this isn't possible outside of the Gold image, however I have been using Unidesk for application layer and with this technology I have been successfully layering Imprivata separately outside of the Gold Image.

I saw a couple posts below stating that it has to go in the Gold Image for all "app layering": technologies, and just wanted to add that this is not the case I have seen when using Unidesk. 

Hope that helps let me know if you have any questions!

[akjrabe21]

Hey Chris,

Not sure if there are any other layering technologies that support this, but I have been using Unidesk successfully for application layering with Imprivata and all other applications outside of the parent image for the last 2 years.  If someone knows of another technology feel to add it here, but essentially Unidesks layering architecture starts below the OS so it is able to make those calls to the OS. 

[akjrabe21]

Hey Ray,

Thanks for the reply, I just wanted to add that we started migrating to the new Unidesk 4.x platform that resolves the issues you mentioned so you kind of get the best of both worlds.  Good catch on the old platform though, that used to be a limitation caused by the added flexibility.

[Ray_handels]

Hey epa,

It could be worth a try but i'm not quite sure how that will work out with other appstacks. The problem is that if it indeed grips into the View Agent some parts of the view agent might end up in the Appstack. I'm not 100% sure if all VMware settings and files are excluded from the appstack. I don't know what is being altered by this applications. It might well be that it is altering things that are not recorded into the appstack.

To be honest I thought that adding the appstack pre-logon would do the trick. At least the succes rate of that seems to be higher than adding the agent into the packaging machine, but that's just my 2 cents.