RE: [ActiveDir] Using GPO to install an MSI package

[Jeff Salisbury]

There should be one more requirement:       4.  The vendor promptly tests all service packs and security updates, publishes the results of their testing plus any end user feedback on their web site, and aggressively pursues correction of any incompatibilities discovered by themselves or their customers.   These vendors should have a designation such as "Microsoft Security Partner", which folks involved in purchasing solutions could point out as a key requirement in any future solutions.   Jeff From: Crawford, Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 15, 2005 1:29 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Using GPO to install an MSI package Envision my utopia – all apps, in order to get a “Designed for XP” logo need to meet some requirements: Come with an MSI installer or have one that’s easily extractable from an EXE. Come with an .ADM file for configuring options Run under a non-privileged user account.   How nice would that be?  Think about it, you spent several hours preparing your package, and tracking down the required permissions.  Multiply that by all the admins that would like to run in a secure environment and multiply that by all the apps that need special perms to run.  Add to that all the time spent making MSI’s of legacy installs.  Then you’ll get some idea of the YEARS of man hours wasted trying to make things manageable in a secure enterprise environment.  Compare this to the comparatively miniscule amount of additional time needed to build things right.   It would take relatively no time for developers to issue their installs as MSI’s in addition to EXEs.  It might take a bit of time to create an ADM file, but still relatively little since they have intimate knowledge of the app and where it reads settings from.  The biggest issue would be redesigning their apps to work as non-privileged users, but even that could be mitigated if they would at least publish a list of special perms needed or at the very least, every file and registry entry that’s part of their app so that we could give full control to Users over those objects.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason B Sent: Tuesday, February 15, 2005 3:00 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Using GPO to install an MSI package   I really appreciate everyone's input on my situation.   I did get it to work, in short, because of everyone's help here.  Thanks!    Here's what I did:   I contacted Intuit (maker of Quickbooks) and wasted 55 minutes on hold and another 10 minutes on hold after a rep answered the call only to find out absolutely nothing other than what a waste it is to have a "support" contract with Intuit.  Apparently the employees in product development are too busy improperly coding new programs to talk to those who actually [try to] use their stuff.   I determined that I needed to find out if the program explicitly looks for the user to be a local PU or Admin, since, if it did, as someone pointed out, we'd be SOL.  I created a test OU, created a test GPO and applied it to that OU.  I created a test group and a test user and put him in the group, and added the user (and test machine) to that OU.  I then gave the test group full permissions to the C:\ drive (FS) and \\classes_root \\machine \\user (registry) and logged in as the test user on the test box to see if it could run under the non-PU and non-Admin context.  It worked.  Now that that was known, it was time to filter down.  I removed the permissions for C:\ (FS), \\machine and \\user and tried again - it still worked, so now I have to figure out which keys were being written to in classes_root, so I ran regmon and after an hour of trying to decipher what it used and what it didn't, and making a long list in the test GPO permissions, I got it to work.  I think it took longer to enter the registry keys in the GPO than it did to find out what was needed as far as permissions go (sigh).  Did I mention how much I hate Intuit products?   ----- Original Message ----- From: Jason B To: ActiveDir@mail.activedir.org Sent: Tuesday, February 15, 2005 8:44 AM Subject: [ActiveDir] Using GPO to install an MSI package   Okay, our environment is that all our clients are running Windows XP SP2, and our servers are Windows 2003.  The situation is that our Accounting department uses Quickbooks, and about 70 of our employees need to use an application that comes with Quickbooks called "QB Timer".  It's free for use for our employees and it integrates with Quickbooks without requiring a Quickbooks install on each machine.  Now, the quandry:  according to Intuit/Quickbooks, the program requires at least Power User permissions to install and run.  Neither I, nor our CIO are willing to give local Power User permissions for these users, as that opens things up to too many potential problems, but our CFO and COO are REQUIRING the use of this application, or a similar one that integrates with Quickbooks.  Now, the QBTimer is free, which is good, so that's the *preferred* app to use.  It comes as an exe with a few other files, so I used WinInstall LE 2003 on a clean XP SP2 machine to package it into an MSI file.  That worked well, and I can install it/assign it through GPO - even if the user doesn't have local Power User privs.  However, true to form with Intuit products, it won't run if the logged on user doesn't have local admin or PU privs.  If I grant PU privs to the user, it runs fine.  I feel like I am --> <-- this close to getting this done, but I ran out of ideas to get this to work.  I tried looking at the reg file that was made when I ran WinInstall and gave the users full rights to the specific areas in the registry to see if that did anything; which it didn't.   Does anyone else have any siggestions, or am I stuck with Intuit's "users must have >= Power User privs" to run that app?   ANY help or suggestions are GREATLY appreciated!   --Jason Confidential This e-mail and any files transmitted with it are the property of Belkin Corporation and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed.  If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited.