Just wanted to get some feedback, we are currently looking at application virtualization. From what I understand it's a stand alone .exe file that lives on the machine. If I where to virtualize office (and I'm a smart end user) I dont see anything that's going to keep me from being able to e-mail myself the .exe files to my home address and then I'll have a full version of office at home. Is there anything to prevent this?
It does not have to live on the machine and you can run the virtualized app from a share. From a protection standpoint, you can:
Control it via Active Directory. You can specify which users/ groups can run the app. Page 125 of the manual. Search for PermittedGroups.
Vbscript you can check for specific data (registry, files, etc...) that only your machines have.
I think they Thinstall are working on a license management system. Not really sure where this is at considering the VMware aquisition.
Hope this helps.
Yeah, I will look into it some more. If I use the permitted groups through AD, do you know how hit works in the machine is offline? Like does it query your DC everytime the app runs to make sure you are in the group, and if it where a remote user not on the network would it not run?
I'm trying to build a proof of concept with starting out by putting this on our machines at our 2 call centers. Right now I'm just having some problems with Avaya Interaction Center and the iSeries access for windows emulator, but I think I'm on the right path, just need to do more tweaking.
One Thing I did messing around was made a Vbscript which would ping the core. If the core was not on the network then the a message box would pop up denying access to the application. Like Zman said you could search or files on a machine.. You could put a text file in the windows folder called "12345" then have a vbscript check to see if it exists. I
Yeah, not a bad idea. I think it would be cool if you could set it up for a grace period. So like when the machine is online and you ran the app, it would authorize itself with the core, then if you took the machine offline the app would continue to run for X days until you had to check it back in. That way even if someone did steal the .exe and put it on their home machine, it would time bomb in a few days.
It uses cached credentials. When you build the app you must be online and have access to the DC, after words it uses cached credentials. Just a personal note, take it for what is worth...we looked at everything out there - (Tarpon, Softgrid, SVS, appstream, Thinstall, etc...) Thinstall for our needs beat everything (even before the LANDesk partnership). See below for some caveats.
You can control access to application using Active Directory Groups. At build-time Thinstall will convert D Group names into SID values. A SID is small binary value that unique identifies an object, similar o a GUID. SIDs are not unique for a few special groups like Administrator. Because SID values are tored in packages for later validation, this means a few different things:
1. You must be connected to your AD domain during build and the Groups you specified must exists. Thinstall will lookup the SID value during build.
2. If you delete a group and recreate it, the SID may change so you will need to rebuild the package in order to authenticate against the "new" group.
3. When users go offline, they can authenticate using cached credentials. Assuming a user can log nto their laptop, Thinstall AD authentication will still work. You can control the period of time cached redentials are valid using Group Policy.
4. Cached credentials may not refresh on clients until the next AD refresh cycle. You can force a group policy on a client using the command "gpupdate". Sometimes the user may need to log-off efore AD credentials are recached.
5. Special groups like Administrators and Everyone have the same SID on every Active Directory domain and Workgroup. Other groups you create will have a domain-specific SID, meaning a user annot create their own local group with the same name to bypass authentication.
VBScripts can be very effective also. I would think about mobile usage (laptops) when desginging such a solution and the app usage patterns (e.g., do you want to be able to run the app from a laptop in a OOB environment?) If so I would make the VB checks more machine centric. We currently brand our machines with certain reg keys.
Plus what is cool about it is the SLM hooks!!!!!!
once you're calling vbscript, you've got a pretty rich set of choices. I wonder if it'll work to call a windows form? Anyone want to make the user win a game of blackjack before letting them use the app? http://www.freevbcode.com/ShowCode.asp?ID=6607