KACE Product Support

Could you enable the Windows Installer Logging policy (verbose) on the client that should get the MSI deployed through AD and post the relevant "error" information.

Hi and thx for taking care of my issue. I've done more investigations yesterday.

First of all here what you're asking for :
=== Verbose logging started: 02/04/2009 08:35:19 Build type: SHIP UNICODE 3.01.4001.5512 Calling process: \??\C:\WINDOWS\system32\winlogon.exe ===
MSI (c) (5C:28) [08:35:19:453]: User policy value 'DisableRollback' is 0
MSI (c) (5C:28) [08:35:19:453]: Machine policy value 'DisableRollback' is 0
1: 2905 2: C:\WINDOWS\system32\appmgmt\MACHINE\{df17173a-81bd-44f8-b4ef-0dcda78fc8ee}.aas
MSI (c) (5C:28) [08:35:19:468]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (c) (5C:28) [08:35:19:468]: DoAdvertiseScript is returning: 1603
=== Verbose logging stopped: 02/04/2009 08:35:19 ===

My investigations pushed my looking at the .aas files that should be locally present for installation in the appmgmt folder. No file, so i've searched for them in my sysvol folder in AD and seen that they are all at 0Kb size. that mean, there is some trouble when the GPO is creating the deploy script for the MSI files made by appdeploy repackager. So i've had a look at the AD application event viewer and that one told me there is an error :
Source : Software Installation
Event ID : 107
Description : The software installation program was not able to read the MSI file \\XXX\xxx.msi. The following error occured : SQL query syntax invalid or unsupported.
So i've searched the web for that and seen somewhere something about the schema table or something like that. It seems there is the same issue with autocad and the guy who succeeded have simply added a table upgrade with nothing in and it goes. What i've done but with no success. However, i've gone through the msi with orca and run a validation and seen that there is many ICE03 errors telling i'm using an old database. And what i've seen also is that all packages that are not working (made with appdeploy tool) are based on the MSI schema 1.0 and others that are working are at the minimum of 2.0 (made with Wininstall LE).
By the way what i still do not understand is that my packages are working when running without GPO. So does it come from the release of W2K3S ? I'm really disapointed as all my packages are done and i do not want to rebuild them all !!! :-(

Has anyone an idea ?

From which location are you installing the MSI?

I'm installing from a LAN server from where i have full control access. Pretty sure it's not coming from security as i can install manually as a user !

Forget it, i've finally found what was going wrong. So for those who have the same issue as me packaging with appdeploy repackager and failed to deploy via GPO, here what you need to do !

First of all, in order to see if it's really the same issue as me, use wininstall LE. open your MSI, open the advanced tab in the general one ! Go to sequence > publication > execution. If you have nothing there, it's normal you can not deploy. There is also nothing under administration > execution. I do not know why when packaging with appdeploy, these tables are not populated.
In a second time, use ORCA in order to export the two following tables (i'm exporting 4 templates : AdminExecuteSequence, AdminUISequence, AdvtExecuteSequence, AdvtUISequence. The 2 ExecuteSequence should by sufficient) of a package that you are able to deploy (for exemple, create a basic package with wininstall LE). The ORCA tool will create 2 .idt files that you'll store where you wish. After that step, open the appdeploy package you're unable to deploy via GPO and import the 2 tables you've just exported ! And let's try now to redeploy your MSI ! Hopefully, That should work !

Personnaly i prefer doing that that way as i've many less issues creating Basic MSIs using appdeploy repackager tool. When using a full wininstall LE packaging, i've troubles with multiple users as each time a user logs in, the install tries to reach the original MSI stored in the LAN server. I let you imagine if you wish to login as a local user or disconnected from the LAN !

BRGDS every one ...

Forget it, i've finally found what was going wrong. So for those who have the same issue as me packaging with appdeploy repackager and failed to deploy via GPO, here what you need to do !

First of all, in order to see if it's really the same issue as me, use wininstall LE. open your MSI, open the advanced tab in the general one ! Go to sequence > publication > execution. If you have nothing there, it's normal you can not deploy. There is also nothing under administration > execution. I do not know why when packaging with appdeploy, these tables are not populated.
In a second time, use ORCA in order to export the two following tables (i'm exporting 4 templates : AdminExecuteSequence, AdminUISequence, AdvtExecuteSequence, AdvtUISequence. The 2 ExecuteSequence should by sufficient) of a package that you are able to deploy (for exemple, create a basic package with wininstall LE). The ORCA tool will create 2 .idt files that you'll store where you wish. After that step, open the appdeploy package you're unable to deploy via GPO and import the 2 tables you've just exported ! And let's try now to redeploy your MSI ! Hopefully, That should work !

Personnaly i prefer doing that that way as i've many less issues creating Basic MSIs using appdeploy repackager tool. When using a full wininstall LE packaging, i've troubles with multiple users as each time a user logs in, the install tries to reach the original MSI stored in the LAN server. I let you imagine if you wish to login as a local user or disconnected from the LAN !

BRGDS every one ...

If the AdvtExecuteSequence & AdvtUISequence tables isn't included in the package then it should also be impossible to import them, during so you will be prompted by an error during the "import" phase in the GPO.
The AdminExecuteSequence & AdminUISequence tables shouldn't be an requirement as they are only used during an admin install which will never happen when deploying through AD/GPO.

For the first point, i'm not prompted by any error. The difference i see, is that the .ass file created is much bigger than 0Kb.
For the second point, if i do not act like that, i can simply not deploy the freshly created packages.
If you have any cleaner proposition, i'm ready to take it ;-)

Sorry so slow here, but we are looking into this-- the more data like this shared the easier it will be for us to nail it down. Thanks!!!

No pb ... however, thx a lot for all is done down there !

Bob, I should probably provide some input here since I just experienced the same issue. This is the first time I've tried the Repackager since my first experience where it wouldn't create the .cab file. Anyway, I downloaded the latest 1.2 version and created a very simple package for some educational software that included a few files and registry entries and a shortcut. It installed fine manually but failed with a 1603 error (DoAdvertiseScript) when I tried to deploy it via GP. I enabled verbose Policy logging and found the following error:

[font="Courier New"]Windows Installer cannot advertise application (snip) from script (snip), error 1603...

After opening the package in InstEd, I found that the package created with Repackager did not have the AdvtExecuteSequence table. I tried the solution presented by dov08 above (using the AdvtExecuteSequence table exported from Repackager12.msi), and it now works when deployed through GP. I don't know enough about Windows Installer database internals to understand fully why it wants to process an advertisement (the package is set to install per-machine), but it's clearly looking for that table.

Just another data point. I will say that this tool is perfect for the work I'm doing this summer. I had to create 8 nearly identical packages with the only difference being a couple of the files and registry entries, and being able to create one template (recipe) and reusing it for each package has saved considerable time.

Excellent feedback, and thanks for the positive comments!

This issue is indeed still outstanding but we are tracking the problem-- with this additional clarification I'm sure we should be able to get this fixed soon.

Thanks!

I'm happy to report that this issue has been addressed in the latest (beta 2) release - http://itninja.com/question/faulttree-103060

Thanks for the effort on this bug fix, but (at least for me) it appears that the issue still remains.

Using the v1.2 Beta 2 of the AppDeploy Repackager, I still cannot deploy using GPO. As before, the MSI works perfectly if executed manually.

Specifically, here is what I did. I created an MSI that simply creates a text document on the c:\. When deployed using a Group Policy, the error I get out of the Event Log is...
"The assignment of application Test 2 from policy MSI - Test failed. The error was : %%1603."

This is the exact same issue I have been experiencing using v1.2 Beta 1.

I've uploaded the XML file, as well as the generated MSI, to: http://www.brandonaguilar.com/msiissue

Hopefully you guys can nab this bug. I find the AppDeploy Repackager to be an awesome tool. I sincerly appreciate its simplicity. Unfortunatly it is not very useful to me in its current state, as I do all my application deployment over GPO.

Thank you very much for your support. I'm sure you've got lots of people waiting on the edge on their seat for this issue to be resolved.
-= Brandon.

I am seeing this issue as well where the assignment file doesn't get populated and policy installs of the packages fail. At first I thought it was because the platform and language codes weren't getting set, but after manually adding them to the package with InstEd It! and seeing the same symptoms I am back at the drawing board. I don't mind doing some digging to figure out why this isn't working exactly, but I am not really sure how to hook diagnostics in to the system account as the machine is booting and trying to apply policy.

Thanks guys, it worked for us in our internal tests but we will revisit this and give it a closer look.

I am having the same problem that the tables meantioned above are empty. I need use wininstall le to get the tables then import them into the snapshot that repackager.

My clean/app machine is a d510 with xpsp3 and drivers.

There should be a fix for this soon. I've seen that though the tables are now in the installer, they are empty, which still causes some failures.

Try the latest beta; the tables ought to be populated making GPO installations work.