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

However Vista does not appear to have the InstallShield InstallDriver config options under DCOM config. From reading 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..."
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Vadim RappCommented:
I think 1603 is "A system restart may be required because the file being updated is also currently in use. Users may be given the opportunity to avoid some system restarts by using the FilesInUse Dialog or the MsiRMFilesInUse Dialog. For more information, see System Reboots and Logging of Reboot Requests." - maybe it wants to reboot but it's somehow prohibited, so it fails.

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.
stmarysitAuthor Commented:
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.
stmarysitAuthor Commented:
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.
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

Vadim RappCommented:
When the package is assigned to the machine, the log file will be in machine's account %temp%, which is usually %windir%\temp
stmarysitAuthor Commented:
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
=== Verbose logging started: 6/01/2010  7:11:33  Build type: SHIP UNICODE 4.00.6001.00  Calling process: C:\Windows\system32\svchost.exe ===
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\appmgmt\MACHINE\{6c2dda91-ad6c-4d18-8299-b3329781c268}.aas
MSI (c) (68:C0) [07:11:33:035]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
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 CLSID
stmarysitAuthor Commented:
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.
Vadim RappCommented:
I became curious and reproduced all this - downloaded this tool, created trivial installation, and yes, saw the same result and the same resolution. But I also looked around the installation that the tool has created, and ran validation. From what I saw, I can definitely recommend everybody to avoid Appdeploy Repackager by all means. One telling example: the execute sequence contains action ISPreventDowngrade, obviously stolen from Installshield; however, of course, the custom dll for this action is not present, so the action would never be able to run; luckily, it will be always skipped because it has condition ISFOUNDNEWERPRODUCTVERSION, also stolen from Installshield, which will be never filled, so these two thefts mutually kill each other. The package is stuffed with things like this. Whoever has created this tool, it looks, took some installation created by Installshield, and "modeled" some arbitrary selected pieces of it. I'm pretty sure that the packages created by this tool will be much closer to being a recipe for trouble than for success.

Experts Exchange Solution brought to you by ConnectWise

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
stmarysitAuthor Commented:
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?
stmarysitAuthor Commented:
App deploy repackager is not the best of tools it would seem.
Vadim RappCommented:
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 describes a solution that I'm using.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.