GPO Deployment issues - Fatal Error
Hello,
I've been going through these message boards trying to find an answer to my problem, and I haven't found it, so I figured I'd ask it here.
Here's the scenario: We have 120 users with homogenous XP Pro workstations on a Windows Server 2003 domain. WE are currently deploying applications via Group Policy, though we plan to use SMS in the future. Some apps are assigned, and they install with no problem, but we want our users to be able to pick and choose among certain other apps. Even within the OU certain users need some apps but not others, and sub-OUs will not help us in this case. (Eventually, when we deploy SMS, we can use collections to assign apps because users can be in more than one collection.) Anyway, we create different GPOs for each app. We have the users pretty locked down rights-wise, but we still have "Install with elevated privileges" set to "Enabled" for both the user and computer configuration on the default domain and on each application GPO. However, some apps install and some die with a "Fatal error during installation" when you try to run them from the Add New Programs portion of the Add/Remove Programs control panel applet. This is very frustrating for us, and something tells me that even SMS would not be able to correct it. I know some of the apps try to write to the system folder, but shouldn't the elevated privileges take care of that? Is there something we are missing with the order of the GPOs? I even tried creating a Test OU with nothing but the default domain policy and one application policy, and the installation still bombed. Has anyone ever run into this problem? Or is this a known MS bug?
Thanks in advance,
JR Jones
I've been going through these message boards trying to find an answer to my problem, and I haven't found it, so I figured I'd ask it here.
Here's the scenario: We have 120 users with homogenous XP Pro workstations on a Windows Server 2003 domain. WE are currently deploying applications via Group Policy, though we plan to use SMS in the future. Some apps are assigned, and they install with no problem, but we want our users to be able to pick and choose among certain other apps. Even within the OU certain users need some apps but not others, and sub-OUs will not help us in this case. (Eventually, when we deploy SMS, we can use collections to assign apps because users can be in more than one collection.) Anyway, we create different GPOs for each app. We have the users pretty locked down rights-wise, but we still have "Install with elevated privileges" set to "Enabled" for both the user and computer configuration on the default domain and on each application GPO. However, some apps install and some die with a "Fatal error during installation" when you try to run them from the Add New Programs portion of the Add/Remove Programs control panel applet. This is very frustrating for us, and something tells me that even SMS would not be able to correct it. I know some of the apps try to write to the system folder, but shouldn't the elevated privileges take care of that? Is there something we are missing with the order of the GPOs? I even tried creating a Test OU with nothing but the default domain policy and one application policy, and the installation still bombed. Has anyone ever run into this problem? Or is this a known MS bug?
Thanks in advance,
JR Jones
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
Jaradel
19 years ago
Just wanted to add some more info about my problem:
I have one MSI (a custom keyboard made with Microsoft's Keyboard Layout Creator) that fails the installation when trying to install from Add/Remove Programs. If the user just goes directly to the MSI itself and tries to install, it says "Installation incomplete." I have another MSI that I made with InstallShield for RealPlayer that also fails when trying to install from Add/Remove Programs, but runs fine with no errors when the user runs the MSI from the network share. What gives? The only thing I can think of is that the installer wants to write something to a protected part of the filesystem or the registry when you try to install from Add/Remove Programs, that it DOESN'T try to do when you install directly from the network share. That explains RealPlayer, but still doesn't explain the custom keyboard. I must also mention that the custom keyboard installs fine for administrators, so it's not the MSI file that the Keyboard Layout Creator creates. Oh, and there is virtually no support for the Keyboard Layout Creator on Microsoft's site, I checked.
Any thoughts?
Thanks,
JR Jones
I have one MSI (a custom keyboard made with Microsoft's Keyboard Layout Creator) that fails the installation when trying to install from Add/Remove Programs. If the user just goes directly to the MSI itself and tries to install, it says "Installation incomplete." I have another MSI that I made with InstallShield for RealPlayer that also fails when trying to install from Add/Remove Programs, but runs fine with no errors when the user runs the MSI from the network share. What gives? The only thing I can think of is that the installer wants to write something to a protected part of the filesystem or the registry when you try to install from Add/Remove Programs, that it DOESN'T try to do when you install directly from the network share. That explains RealPlayer, but still doesn't explain the custom keyboard. I must also mention that the custom keyboard installs fine for administrators, so it's not the MSI file that the Keyboard Layout Creator creates. Oh, and there is virtually no support for the Keyboard Layout Creator on Microsoft's site, I checked.
Any thoughts?
Thanks,
JR Jones
Posted by:
brenthunter2005
19 years ago
Check the Application Event Log for any errors.
You could also use Filemon/Regmon to check if its a permissions problem.
If the above two fail, then enable MSI logging via Group Policy setting, and then check the installation log for problems.
[8D] Keep cool. [8D]
You could also use Filemon/Regmon to check if its a permissions problem.
If the above two fail, then enable MSI logging via Group Policy setting, and then check the installation log for problems.
[8D] Keep cool. [8D]
Posted by:
Jaradel
19 years ago
Thanks for the reply, I appreciate it. I did run an install with verbose logging, but aside from the Error 1603, did not see why it is failing - then again, that log is full of stuff that I can't decipher. I also looked at the Application Event Log, but it just tells me that the installation failed, nothing specific. I will try Filemon/Regmon next.
Posted by:
fairfranco
18 years ago
hi,
I've been searching the web desperately trying to get an answer to this same problem.
my problem is with a Microsoft Office 2003 installation MSI which works without problem manually but when published via gpo has the fatal error.
we have another internal developer made MSI which also works manually but doesn't work through policy.
i've also tried assigning but to no avail.
permissions are granted on all relevant directory's and neither MSI work when run by an administrator.
elevated privilliges are set to enabled in policy.
if you've got an answer to your problem jardel please let me know!
I've been searching the web desperately trying to get an answer to this same problem.
my problem is with a Microsoft Office 2003 installation MSI which works without problem manually but when published via gpo has the fatal error.
we have another internal developer made MSI which also works manually but doesn't work through policy.
i've also tried assigning but to no avail.
permissions are granted on all relevant directory's and neither MSI work when run by an administrator.
elevated privilliges are set to enabled in policy.
if you've got an answer to your problem jardel please let me know!
Posted by:
oofemioo
18 years ago
If you are deploying to computer accounts, do ensure that the computer accounts
have permissions/rights to those folders.
have permissions/rights to those folders.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.