Denied Groups Parameter?

[VIrtuallyJason]

I know that there is a PermittedGroups parameter (and, when enabled, all other groups are implicitely denied); I'm wondering if there is an inverted equivelent.  Here's my situation and why I want this:  I've ThinApped Office 2010 along with Project and Visio.  Every user in my organization gets the basic Office package and a select list of users will get access to Project and/or Visio.  Currently, there are no restrictions on the executables for the basic Office apps and I have PermitedGroups entries for both Visio and Project.  So far, so good.  My trouble comes from the Visio Viewer.  If a user is part of the Visio group, I do not want the Visio Viewer to register for them (mainly because I want to ensure that Visio grabs the file associations, rather than Viewer, if the user belongs to the Visio group).  Right now, I'm using PermittedGroups to control access and a super simple logon script that just registers all .exe files in my ThinApp Repository.  I'd *really* like to avoid putting logic into my login script so that it avoids certain applications, as I fear that will lead to maintenance issues when I hand this project off.

ThinReg goes through directories alphabetically, right?  I suppose that I could rename my Visio Viewer entry point as "aVisio Viewer" (so that the registration for Visio happens afterwards and takes over the file associations) but that's pretty hokey.  Does anyone have a better idea?  Thanks.

[Pankaj11]

Hi,

There is a /e option in ThinReg which basically is for exclusion of any directory or file from registration. e.g. /e XXXX, if a file or directory match XXXX, where XXXX is a filename or wildcard, this will not be registered.  You can specify multiple files/dirs by adding additional "/e" params to the command-line.

Would this option be of any help to you, as I understand you don't want the Visio viewer to be registered in case Visio is to be registered, but this option is like a blanket ban on the filename specified after /e.

Thanks.

[VIrtuallyJason]

Thanks for the input, but I don't think that the /e option will serve in this situation since, in order to employ it, I would have to start baking logic into my thinreg script.

As I think more on it, I could probably create the file associations manually in the master image and take them out of the Visio Viewer ThinApp.  Then, when Visio registers, it will take over those associations even if the Viewer were to register afterwards.

[Phil_Helmling]

Why not create a group for Visio Viewer and full Visio and setup PermittedGroups for both, then ensure you add users to one or the other. You could have a script that runs everynight that checks the groups and ensures no user is in both. I know not elegant, but will work for now. I'd also recommend you submit a feature request - https://www.vmware.com/support/policies/feature.html

Phil

[VIrtuallyJason]

Thanks for the suggestion - I've submitted the feature request.