Software Deployment

Ah, AMBest... my old employer...

They're using ISScript? Hmmm, Upgrades! [:)]

If history is my guide, they're probably doing something creative. They were quite fond of that way back when I was there. Resolving ICE38's involves a tedious process of getting all aspects of a component on one side of the User/Machine fence. What is the exact text of your ICE38? (There are 5 possibilities) Here's a link that might help get to the root of it: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/ice38.asp

Usually, the problem is that the component has several files/keys in it that straddle the user/machine line. It's normally fixed by breaking it up into two components, one with all user, one with all machine, and keypaths set as appropriate for whichever side of the fence it's on.

You may also find that the component has files for the User Profile but there are not registry keys in HKCU to act as the key component. In that case, just create a dummy registry key in HKCU that does nothing but be the key for the component.

When you are trying to add this MSI to your GPO, I assume you are doing it on the actual DC (not remote TS).

If so, check the Application Event Log. This can sometimes show you whats wrong with this MSI.

try adding the lnk files as components, and create a advertised shortcut to those lnk files. when you add them as compoents verify that it reads .lnk. drag and drop the lnk files to INSTALLDIR and make them as key paths.

(bheers) I took your advice & dropped the lnk files then created shortcuts to them. I set one of the lnk files to be a key path.

No luck. Still works manually. Still get the error when I try to import it.


Note- I did drop them in program files rather than INSTALLDIR b/c INSTALLDIR points to a network drive. Is that a problem?

(Viking) My ICE38 text is as follows:

ICE38-ERROR-Component AllOtherFiles1 installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file.

Yup. That's the problem. Self heal data on many workstations for a single network resource? That's not good, so MSI doesn't like it. Switch INSTALLDIR to someplace local.

At the risk of sounding like a complete packaging newbie, how can I change it? I'm stuck with adminstudio & orca at the moment.

Component AllOtherFiles1 installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file.

For this one, just give it what it wants. Create a new registry key somewhere in HKCU that makes sense, like SOFTWARE\[Appname]\AllOtherFiles1 = 1 (or whatever, it doesn't matter as long as it's in HKCU). Add that registry key to the AllOtherFiles1 component and set it as they KeyPath.

It just has a bunch of files for the user profile, but needs KeyPath to a registry key in HKCU to define it as a User component.

INSTALLDIR is defined in the Directory table, but it should be easier to change in AdminStudio. Probably a field called Installation Directiory or something similar.

For changing the INSTALLDIR
General Information -> product Properties -> INSTALLDIR
or you can use direct editor -> directory Table.

Excellent input guys, but I'm still having no luck.

Using the Viking's method I created dummy HKCU keys for each component that I was getting ICE38 errors for.

I used bheer's method to reset INSTALLDIR to program files.

STILL runs fine manually, STILL gettting error when I try to create a package in policy.

I ran another validation in Orca, I now get no errors just warnings (ICE17, 33, 48, 49, 57)

Further ideas?

I'm taking off for the day, but I'll check back tomorrow at 8 EST. Thanks again for all the help guys, I've learned a boatload from this.

Add operation failed. Unable to extract deployment information from the package

did you try this one

http://support.microsoft.com/kb/324886
or
http://support.microsoft.com/default.aspx?scid=kb;en-us;304746&Product=winxp

Yeah, I saw that first one when I was googling. The application is not installed on the machine that's trying to create the package in GP.

That second one is new to me, I'll check it tomorrow morning (I'm in EST, its 7 pm here).

Make sure Adminstudio hasnt stuck in one of its custom actions to force you to run a setup.exe first. This will also cause the error your getting in Active Directory

Well, I checked & there's no UI in the summary info so thats not it. (bheers)

There are also no custom actions in the msi at all.

I'm wondering if it has something to do with this:

ICE57 WARNING - Created 02/11/1999. Last Modified 01/17/2000.
Component 'AllOtherFiles1' has both per-user and per-machine data with an HKCU Registry KeyPath.


Either way, any further ideas?

Well, to resolve that ICE57 Warning you should create another component and put the per-machine data in it. Name it something like AllOtherFiles2 and move all files not in the user profile into it. Since it's per-machine data, you don't need to make up a reg key. Just make the most essential/prominent file the key for the new component.

...I don't think that will solve your SMS issue though. If those KB articles don't help ya, I'm stumped. We don't use SMS here so I'm a bit out of practice but I'll keep an eye on this thread just in case I actually have something to contribute. [:D]

Yeah I tried that & still no change. [:@]

Thanks for the input.

(BTW...We're using GPO deployment)



On the flip side, does anyone know where I can find more info regarding what exactly happens in the background when you create a package through the Group Policay manager?

ORIGINAL: Bladerun

I created an msi package for the AMBest software. Running the msi manually works fine. When I try to create a package in group policy for it I get the "Add operation failed. Unable to extract deployment information from the package. Run validation on the package to ensure that the package is correct."



This may be totally unrelated to your issue, but I had problems before when trying to use GPO's for deploying MSI's.

The fix in my case was to add an Uninstall table (using Orca) then try it again. The Uninstall table wasn't being created (in this case by WinINSTALL) and can be left blank.

HTH

nmi

Also ensure that the REBOOT property isn't defined in the Property table, as this can stop a MSI from being entered into a GPO.

Negative on both. The RebootYesNo property was set to 'Yes' so I left the field blank and tried that, then removed the entire property completely, still no luck.

I added a blank uninstall table, but to no avail.

I did discover that I'm using AdminStudio 6 Standard, and the feature to convert IS msi's to standard msi's is a feature of professional. I'm d/ling professional eval right now, I'll try and repackage it using that & see how it goes.

THANK YOU.

Didn't even think about the Application event log. When I checked that out, I discovered this piece of junk:

Product: 2005 BestESP Serv -- Error 1327.Invalid Drive: S:\

I searched the tables and and found that DIRPROPERTY1 in the Properties table was still pointed to S: - the network drive that INSTALLDIR was originally pointed to. I dropped the row since INSTALLDIR is now pointed locally, and GPO accepted the msi without issue.


Thanks again viking, bheers, and brent. Couldn't have hammered this one out without you.

Rate our posts? [;)]

Yeah how does that work? i've seen people talk about rating, but I'm not sure what its about.


EDIT: heh, ok, I guess its pretty self explanatory. Done[:D]

Ya Velkomme![8D]

Cheers Cheers! [:)]

WOW! This is an OOOOOOOOOOOOLLLD topic.. but wanted to add something.

I was trying to create an msi package to be deployed via GPO.. the only thing this package does is to create a shortcut to a file in a network location.
Rather than install an lnk file and then create a shortcut to it, I wanted to install a shortcut by itslef (no files are installed).

I did this by creating a property called "SERVDRV" and setting it to my network location, V:\. Then I created a dummy entry with the same name in the directory table so that I could have something to point to for the working directory in the shortcut that I created.

So, I created a non-advertised shortcut, the shortcut points to [SERVDRV]prog.exe
This shortcut has a working directory specified as [SERVDRV]
SERVDRV is in the property table and is set to my network location, in this case V:\

Well, it installed no problem by itself, but when I tried to create a package in GPO, I got the same error as the OP, that is how I found this thread.

So I went back to my MSI, set the property to C:\, and then created a new set directory custom action that sets it back to V:\ right after install initialize.

Thanks for the tip.

Please delete this post and post again with a new 'Subject' line and try to avoid hijacking old threads, particularly ones which seem to have no relation to the subject of your question! :)