Scripting Question

EXPERT needed for MSI-GPO-AD problem!!!

11/17/2004 3569 views

We are experiencing the following interesting problem regarding MSI’s and Active Directory deployment. We want to deploy applications using active directory. It is a Windows 2000 Server AD environment with Windows XP clients. A group is created for every application and users that need the application are added to this group. A GPO is created for every application and rights are set for the application group. Applications are assigned in the user configuration of the GPO, if necessary applications can be installed at logon (XP clients!) e.g. if they have no shortcuts. So far so good!

Now we have two vendor based (InstallShield) applications (SUN Java RunTime 1.4.2_05 and VMware Workstation 4.5.2) that we want to deploy to the users. Doing this using the install at logon feature fails.
What appears to be the problem is that the vendor placed custom actions after InstallFinalize. These custom actions need elevated rights. During login the part run after InstallInitialize and before InstallFinalize is executed with the AD elevated rights. The rest is executed with the rights of the user that’s logging in. If this user has administrative privileges all goes fine. But (almost) all users are restricted users, so this is a problem.

I have tried to move the custom actions to run deferred in system context or to change the position of InstallFinalize but this only leads to a corrupt installation. Using a GPO that gives users elevated rights for executing MSI files does not help either (of course) because this still does not execute the custom actions after InstallFinalize with elevated rights. Searching on the web does not give an answer either.

We do not apply GPO's to machines (hey I didn't create the AD environment!). So I have come to the point that the only solution is to repackage the vendor MSI. This is something I dislike because of the other problems that can occur and the lack of support of the vendor!

Can anyone help me on this interesting problem!

Best Regards Mu.
0 Comments   [ + ] Show comments


Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

All Answers

Maybe you should consider deploying applications that install device drivers and applications which should be part of a standard system image to machines. I realize that you are trying to work within an environment that has been layed out for you, but we all come to a point where we need to compromise a little to get things done, otherwise you will be in the position of having to tell your boss that you cannot use an application in your environment because it is not "compatible" with the current structure. Sometimes there is a "right way" of doing things and it usually ends up being the "only" way to get it done.
Answered 11/17/2004 by: cdupuis
Third Degree Green Belt

I think cdupuis is right......you might be stuck with repackaging or doing workstation based installs for those apps.
Answered 11/19/2004 by: MSIMaker
2nd Degree Black Belt

I don't think you can manage without using Computer packages in fact it is almost the only thing I use, in my environment.

The custom actions run in user mode (Client process) or as a service (computer package) but only when applied as a computer package will you get the elevated privileges.

Sweede [;)]
Answered 11/26/2004 by: Sweede
Second Degree Green Belt

No gaurentees here, but something you can look into is to look to the windows 2000 resource kit. Microsoft has a utility called they mimic'ed from UNIX called "su" which would allow you to switch to a different user for a specific NTVDM session. I've never done it, but you may spend some time calling that command in a custom action to do the steps you need to do that require administrative rights. It could save you a lot of footwork.
Answered 11/30/2004 by: Toupeiro
Senior Yellow Belt

This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ