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

[Jensen, Ken]

Title: Message

We had a similar problem here. Ours was an application that was designed for W98 and our move to W2K3 and XP workstations killed the app. Half the problem with some of those apps that require admin rights, has to do with the install location or the default permissions assigned by the OS when the app installs. On this particular problem, I was able to alter the permissions on the installed directory and the (2) .ini files(loaded in C:\Windows, go figure) with permissions for authenticated users. This limited the possible damage to only the one directory and did not require changing the user or group permissions at all. You can run a script at login, attached to the user group through a GPO,  that will alter the file permissions on a directory or file, so no need to visit or remote to every user desktop. An OnErrorContinue loop will be needed for those systems that might not have the file or directory. This will help keep the users from calling the help desk about an error box on their screen when they boot up :)   My current project involved both the requirement of admin rights and the installation needed to start itself as a service. WinInstall did not pick up the service starts when the MSI was created. I ended up with the files all extracted but no client loaded. The user clicking the client install file did nothing of course as we were back to the admin rights problem. I tried a number of approaches to solve the issue and ended up pretty frustrated. I tried embedding the runas command, vb scripting options to start a process and LoadW angles. I finally ended up, probably where I should have started, at JoeTools(not a shameless plug). Sure enough, Joe has a solution to the admin rights issue with CPAU. Things were looking up. Went to GDG software and picked up a very dynamic packet builder as well. Created the enclosure file with CPAU then packed the client exe and the CPAU enclosure into an executable. Copied the files to the software distrib website and pointed my users at it. It downloads the files to the user My Docs directory(%mydocdir% in the packet builder.) and then executes a command(my CPAU enclosure) after the files successfully extract. The packet builder then deletes the extracted files after a successful execution of CPAU leaving no leftovers to accumulate.   This also opens up a number of other options for software distribution and patching issues that I can see down the road.   Regards,   Ken Jensen Technology Support Specialist III Enterprise Desktop Integration/Automation Capistrano Unified School District (949)234-5525 -----Original Message----- From: Ruston, Neil [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 15, 2005 8:13 AM To: 'ActiveDir@mail.activedir.org' Subject: RE: [ActiveDir] Using GPO to install an MSI package I would speak with Intuit and ask if the app checks whether the user has 'power user' privs or whether the user simply needs rights in certain areas of the file system and/or registry.   Depending on the answer given, determines the approach you then take.   The former => user needs to be granted power user privs The latter => users need certain privs in the reg and/or file system   Only Intuit can really give you this info, altho a file/reg trace at app launch time will go some way to helping :)   hth, neil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason B Sent: 15 February 2005 15:44 To: ActiveDir@mail.activedir.org 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 ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ============================================================================== CAPISTRANO UNIFIED SCHOOL DISTRICT DISCLAIMER: This communication and any documents, files, or previous e-mail messages attached to it constitute an electronic communication within the scope of the Electronic Communication Privacy Act, 18 USCA 2510. This communication may contain non-public, confidential, or legally privileged information intended for the sole use of the designated recipient(s). The unlawful interception, use or disclosure of such information is strictly prohibited under 18 USCA 2511 and any applicable laws.