Some MSI deployment to Vista machine failing
Once upon a Clean Vista machine that was deployed via WDS and placed in correct OU a simple Computer based software installation Group policy was applied. Some of the MSI's were successfully deploy - mostly commercial ones eg flashplayer, clickview player, plus one or two of my created MSI's.
All the MSI's created by myself were created with appdeploy's repackager on a clean Vista machine. (Wininstall LE no longer works on Vista)
We also live in the land of Server 2003 with only standard security group policies applying at the level of this OU.
The system Event log records:
"The assignment of application clickview library location from policy standard software failed. The error was : %%1603"
In reading around it would appear that the 1603 error is possibly related to privileges in launching the installer script at start up, as per post https://www.experts-exchange.com/questions/24299878/Error-1603-when-installing-Windows-XP-SP3-using-Group-Polciy.html
However Vista does not appear to have the InstallShield InstallDriver config options under DCOM config. From reading http://msdn.microsoft.com/en-us/magazine/cc163486.aspx#S6 I would suggest that the MSI's that failed all require changes to HKLM registry keys. Also there is some way to elevate the privilege of the MSI so that it doesn't require a token??
BTW - UAC is turned off on the machine and the MSI's in question will all install by manually starting them (without having to run as administrator).
I am somewhat at a loss for how to proceed. Suggestions welcome including, "Oh we do it this way, I thought everybody knew that..."
All the MSI's created by myself were created with appdeploy's repackager on a clean Vista machine. (Wininstall LE no longer works on Vista)
We also live in the land of Server 2003 with only standard security group policies applying at the level of this OU.
The system Event log records:
"The assignment of application clickview library location from policy standard software failed. The error was : %%1603"
In reading around it would appear that the 1603 error is possibly related to privileges in launching the installer script at start up, as per post https://www.experts-exchange.com/questions/24299878/Error-1603-when-installing-Windows-XP-SP3-using-Group-Polciy.html
However Vista does not appear to have the InstallShield InstallDriver config options under DCOM config. From reading http://msdn.microsoft.com/en-us/magazine/cc163486.aspx#S6 I would suggest that the MSI's that failed all require changes to HKLM registry keys. Also there is some way to elevate the privilege of the MSI so that it doesn't require a token??
BTW - UAC is turned off on the machine and the MSI's in question will all install by manually starting them (without having to run as administrator).
I am somewhat at a loss for how to proceed. Suggestions welcome including, "Oh we do it this way, I thought everybody knew that..."
ASKER
Thank you for your response. I have enabled voicewarmup in the registry.
I have also done multiple reboots to nil effect.
Attached is the log file with verbose logging.
I can see from the log you are quite correct about the privileges even though it is unsigned it is permitted to run at the 'unrestricted' authorization level.
Still reading through the log file, but nothing has jumped out to me yet.
I remembering reading something about the FilesInUse issue on the appdeploy website yesterday.
MSI59bc1.LOG
I have also done multiple reboots to nil effect.
Attached is the log file with verbose logging.
I can see from the log you are quite correct about the privileges even though it is unsigned it is permitted to run at the 'unrestricted' authorization level.
Still reading through the log file, but nothing has jumped out to me yet.
I remembering reading something about the FilesInUse issue on the appdeploy website yesterday.
MSI59bc1.LOG
ASKER
Okay, just finished reading the log file, it is a successful install for crosswordwizard.msi that I manually ran from the helpdesk account. There is no reference in there for the other 6 msi packages that are failing on boot.
I tested crosswordwizard on that machine to double check that the msi package was able to successfully run. Therefore probable that the log file doesn't contain anything useful except as an example of a successful install.
I tested crosswordwizard on that machine to double check that the msi package was able to successfully run. Therefore probable that the log file doesn't contain anything useful except as an example of a successful install.
When the package is assigned to the machine, the log file will be in machine's account %temp%, which is usually %windir%\temp
ASKER
Found the series of log files that are related to the failed installs, not in %temp% as most sites say because that refers to the users temp directory, but %windir%\temp as you say.
Text below
Text below
=== Verbose logging started: 6/01/2010 7:11:33 Build type: SHIP UNICODE 4.00.6001.00 Calling process: C:\Windows\system32\svchos
MSI (c) (68:C0) [07:11:33:034]: User policy value 'DisableRollback' is 0
MSI (c) (68:C0) [07:11:33:034]: Machine policy value 'DisableRollback' is 0
1: 2905 2: C:\Windows\system32\appmgm
MSI (c) (68:C0) [07:11:33:035]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Softwar
MSI (c) (68:C0) [07:11:33:035]: DoAdvertiseScript is returning: 1603
=== Verbose logging stopped: 6/01/2010 7:11:33 ===
All the files seems to be exactly the same including the CLSIDMSI (c) (68:C0) [07:11:33:034]: User policy value 'DisableRollback' is 0
MSI (c) (68:C0) [07:11:33:034]: Machine policy value 'DisableRollback' is 0
1: 2905 2: C:\Windows\system32\appmgm
MSI (c) (68:C0) [07:11:33:035]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Softwar
MSI (c) (68:C0) [07:11:33:035]: DoAdvertiseScript is returning: 1603
=== Verbose logging stopped: 6/01/2010 7:11:33 ===
ASKER
Problem solved, thank you for your assistance.
In summary:
It would appear that appdeploy repackager is not able to directly create an msi that is deployable through group policy. Even with the latest 1.2 beta - not 100% confirmed. For some reason it is not populating the tables adminExecuteSequence, AdminUISequence, AdvtUISequence and AdvtExecuteSequence. A quick use of orca to export those tables from the repacker.msi (or probably any working msi) and then again with the orca to import them into the failng msi's.
Then make sure in group policy you remove the software and re-add so that it pushes the modified files.
The rest of the msi is working great guns as long as you change the shortcut location and import the tables as above... well great guns for being free.
So thanks again for your assistance, very appreciated.
ref: http://www.appdeploy.com/messageboards/tm.asp?m=46766
In summary:
It would appear that appdeploy repackager is not able to directly create an msi that is deployable through group policy. Even with the latest 1.2 beta - not 100% confirmed. For some reason it is not populating the tables adminExecuteSequence, AdminUISequence, AdvtUISequence and AdvtExecuteSequence. A quick use of orca to export those tables from the repacker.msi (or probably any working msi) and then again with the orca to import them into the failng msi's.
Then make sure in group policy you remove the software and re-add so that it pushes the modified files.
The rest of the msi is working great guns as long as you change the shortcut location and import the tables as above... well great guns for being free.
So thanks again for your assistance, very appreciated.
ref: http://www.appdeploy.com/messageboards/tm.asp?m=46766
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hey vadimrapp1, thanks for following up with this.
What tool (free or otherwise) have you used in your experience is the best tool to use to repackage MSI's for group policy deployment?
What tool (free or otherwise) have you used in your experience is the best tool to use to repackage MSI's for group policy deployment?
ASKER
App deploy repackager is not the best of tools it would seem.
I'm using Wise. It's not free, far from that, especially that I'm using Package Studio. But it's very useful in company environment when you work not with one package but many - Package Studio maintains centralized database of all components, which allows practically full elimination of all conflicts. I'm repackaging most of the software that I deploy to the users, including Flash, Adobe Reader, and even Microsoft Access Runtime. Right now working on Internet Explorer 8-) It also allows "pilot" deployment, when it creates fake installation package that fully emulates the real installation, however does not install anything - you deploy it to all users, and it reports about the installation to the centralized server, then you see what happened where.
The biggest problem with GP deployment is absence of reporting the result. My article at http://www.vadimrapp.com/article5.htm describes a solution that I'm using.
The biggest problem with GP deployment is absence of reporting the result. My article at http://www.vadimrapp.com/article5.htm describes a solution that I'm using.
I would enable voicewarmup and looked in the log.
I think in Q_24299878.html the first assisted solution was only the sign of politeness - the accepted solution in the end has nothing in common with Installshield, and I don't think XP SP3 was made by Installshield.
As for elevating the privileges - assigned packages always run elevated, by definition. You will see it in the log once you enable it.