AD GPO MSI Install using a runas for UID
I have been working on a MSI for the past week. I finally have it finished and workign correctly in manual install mode - i.e. I click install and allow the process to run. This particular package is wrapper for a series of 19 seperate installers that are provided an answer file by a vendors product. This install sequence uses a sort of runas command to perform the install with elevated rights on the machines as our domain users cannot install software. Here is what is supposed to happen:
Device starts and attaches to AD. The GPO sees that the MSI is not installed and beings the routine.
The MSI places the installs for all 19 sub-apps in a series of folders.
After the files are all placed, I begin the "real" install with call to the vendor supplied batch file.
I get an error in the logs that states the app install failed to create the registry for the logged on user which in this case is called mydomain\dmadmin. I'm assuming that because this account is not as elevated as the system account, it cannot perform the installs without a uer being logged on. Has anyone ever had to modify the GPO to make a system user out of a domain user? My thought was to use something like "Act as part of the operating system" to try to eleveate this account high enough to perform the installs.
Jimm
Device starts and attaches to AD. The GPO sees that the MSI is not installed and beings the routine.
The MSI places the installs for all 19 sub-apps in a series of folders.
After the files are all placed, I begin the "real" install with call to the vendor supplied batch file.
I get an error in the logs that states the app install failed to create the registry for the logged on user which in this case is called mydomain\dmadmin. I'm assuming that because this account is not as elevated as the system account, it cannot perform the installs without a uer being logged on. Has anyone ever had to modify the GPO to make a system user out of a domain user? My thought was to use something like "Act as part of the operating system" to try to eleveate this account high enough to perform the installs.
Jimm
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
anonymous_9363
15 years ago
GPO deployments install using the local System account already...if they didn't, my current client would be in a bit of a pickle!
Running MSIs from within another MSI is a no-no. Since only one client MSIExec process can run at a time, you'll be stuck with calling the batch file from a CA in the ExecuteImmediate sequence, after InstallFinalize. That CA will run in User context. If you try and have it run in ExecuteDeferred, before InstallFinalize, you'll get the error message that another installation is already running.
The best route for you is simply to add all the MSIs to the GPO "package". Add them in the order you want them to be installed, if order is important. If the batch file is passing parameters to the MSIExec calls, add those via properties in a transform.
Running MSIs from within another MSI is a no-no. Since only one client MSIExec process can run at a time, you'll be stuck with calling the batch file from a CA in the ExecuteImmediate sequence, after InstallFinalize. That CA will run in User context. If you try and have it run in ExecuteDeferred, before InstallFinalize, you'll get the error message that another installation is already running.
The best route for you is simply to add all the MSIs to the GPO "package". Add them in the order you want them to be installed, if order is important. If the batch file is passing parameters to the MSIExec calls, add those via properties in a transform.
Posted by:
JimmPanik
15 years ago
VBScab, you're exactly right as usuall. I have the package setup exactly as you stated but the install is still failing. What I think is happening is that this. The installs start as the SYSTEM user account like normal. Then, the install.bat takes over and tries to use it's internal runas to install each seperate "component" of the app. For some reason, it cannot logon this user and the install fails. I believe this to be true because of a few things I see:
1. When the install works correctly, I see a profile created called DMAdmin. This is not happening from the GPO.
2. The logs make references to access denied while trying to write to the registry for user DMAdmin. If there is no profile, there is no registry.
As an experiment, I moved things around slightly and entered the batch file into the ALLUSERS\Startup folder. I then set the registry to perform an autologon with a user I created in VBS. After the install completed, I used REG in a different batch file to remove the user and the autologon entries. This works but sure is not how I want to deliver this package. Is there an alternative?
Jimm
1. When the install works correctly, I see a profile created called DMAdmin. This is not happening from the GPO.
2. The logs make references to access denied while trying to write to the registry for user DMAdmin. If there is no profile, there is no registry.
As an experiment, I moved things around slightly and entered the batch file into the ALLUSERS\Startup folder. I then set the registry to perform an autologon with a user I created in VBS. After the install completed, I used REG in a different batch file to remove the user and the autologon entries. This works but sure is not how I want to deliver this package. Is there an alternative?
Jimm
Posted by:
anonymous_9363
15 years ago
Is there an alternative?Ummm...follow what it says in the last paragraph of my response? Forget the batch file and just add all the MSIs - in order - to your package. It's a no-brainer.
Posted by:
JimmPanik
15 years ago
I've tried this approach as well and had the same results. The user DMAdmin cannot access the registry is the logged error message.
Not sure if it matters or not, the individual app installs are all Install Shield EXEs not MSIs. I'm cannot consider placing all of these into one massive captured package as some installs are actually MSIs such as the pre-req installs that I mention later. The things that worries me is that there are a lot of add-ins for office 07 in there and the original installers are somehow settings everything for the office trust center and security. This is a little over my head.
One thing that might add more clarity - the "batch" file simply calls the master EXE file with an INI file specified as a parameter. This master EXE is somehow fed the data as to which of the 19 indivudal installers execute and with which properties etc. The answer file is binary so I cannot read it.
To handle the per user registry entries, the install places a batch file in ALLUSERS\Startup that uses a series of RED ADD calls. I know how to repair these from reading previous posts of yours.
On top of all of this, the master EXE also installs .NET Framework 2.0 even if it is already there, MS C+ Redist. and something called Office 2007 Primary Interop Assemblies.
My next thought is that I can maybe repack each of these apps individually. That will at least show me how they work. After I finish one package, is there a way to merge it with another package?
For example - package A is done. Package B is finished also. Is there a way to import everything from package B into A for one larger file? This is already sounding like a bad idea.
Not sure if it matters or not, the individual app installs are all Install Shield EXEs not MSIs. I'm cannot consider placing all of these into one massive captured package as some installs are actually MSIs such as the pre-req installs that I mention later. The things that worries me is that there are a lot of add-ins for office 07 in there and the original installers are somehow settings everything for the office trust center and security. This is a little over my head.
One thing that might add more clarity - the "batch" file simply calls the master EXE file with an INI file specified as a parameter. This master EXE is somehow fed the data as to which of the 19 indivudal installers execute and with which properties etc. The answer file is binary so I cannot read it.
To handle the per user registry entries, the install places a batch file in ALLUSERS\Startup that uses a series of RED ADD calls. I know how to repair these from reading previous posts of yours.
On top of all of this, the master EXE also installs .NET Framework 2.0 even if it is already there, MS C+ Redist. and something called Office 2007 Primary Interop Assemblies.
My next thought is that I can maybe repack each of these apps individually. That will at least show me how they work. After I finish one package, is there a way to merge it with another package?
For example - package A is done. Package B is finished also. Is there a way to import everything from package B into A for one larger file? This is already sounding like a bad idea.
Posted by:
anonymous_9363
15 years ago
My apologies: I mis-read your post and assumed all 19 were MSIs.
No matter - as you say, just capture them. Remember that it's *very* likely that the InstallShield EXEs will ultimately extract and execute an MSI: watch your %TEMP% folder for new MSIs. Note, however, that some vendors are now extracting their temporary MSIs to folders beneath [%APPDATA].
Merging MSIs is indeed a bad idea. One disadvantage should immediately come to mind - how will you update, say, Package B?
No matter - as you say, just capture them. Remember that it's *very* likely that the InstallShield EXEs will ultimately extract and execute an MSI: watch your %TEMP% folder for new MSIs. Note, however, that some vendors are now extracting their temporary MSIs to folders beneath [%APPDATA].
Merging MSIs is indeed a bad idea. One disadvantage should immediately come to mind - how will you update, say, Package B?
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.