[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Some MSI deployment to Vista machine failing

Posted on 2010-01-04
10
Medium Priority
?
1,020 Views
Last Modified: 2013-11-14
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 http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/XP/Q_24299878.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..."
0
Comment
Question by:stmarysit
  • 6
  • 4
10 Comments
 
LVL 40

Expert Comment

by:Vadim Rapp
ID: 26184875
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.
0
 

Author Comment

by:stmarysit
ID: 26186081
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
0
 

Author Comment

by:stmarysit
ID: 26186133
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.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
LVL 40

Expert Comment

by:Vadim Rapp
ID: 26186339
When the package is assigned to the machine, the log file will be in machine's account %temp%, which is usually %windir%\temp
0
 

Author Comment

by:stmarysit
ID: 26186406
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
0
 

Author Comment

by:stmarysit
ID: 26187325
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
0
 
LVL 40

Accepted Solution

by:
Vadim Rapp earned 2000 total points
ID: 26187686
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.
0
 

Author Comment

by:stmarysit
ID: 26196761
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?
0
 

Author Closing Comment

by:stmarysit
ID: 31673854
App deploy repackager is not the best of tools it would seem.
0
 
LVL 40

Expert Comment

by:Vadim Rapp
ID: 26197038
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.
0

Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

One of the frequent problems with the installations is when some file or registry entry is not removed from the system upon un-installation of the product. Clean removal is always highly desirable. One major reason for that is badly authored inst…
One of the most frequently asked questions on EE in the "Windows Installer" zone is how to eliminate self-triggered installation of some product.  The problem occurs when, suddenly, whenever a certain application is launched, or even when a folder i…
The Task Scheduler is a powerful tool that is built into Windows. It allows you to schedule tasks (actions) on a recurring basis, such as hourly, daily, weekly, monthly, at log on, at startup, on idle, etc. This video Micro Tutorial is a brief intro…
Despite its rising prevalence in the business world, "the cloud" is still misunderstood. Some companies still believe common misconceptions about lack of security in cloud solutions and many misuses of cloud storage options still occur every day. …
Suggested Courses
Course of the Month18 days, 14 hours left to enroll

834 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question