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."

So I ran a validation in Orca and came up with 2 ICE38 errors and 2 ICE 64 errors. The 64 I can fix, but the 38 has me stumped.



Basically what I'm trying to do is toss the shortcuts that Installshield capture and create my own. They are links to a network drive, so i'm droping them in with the rest of the files rather than in the shortcut table. I think my problem is centered around that.

Orca's telling me that the components related to those files must use a registry key under HKCU.

Can anyone help me out here?

EDIT: Oh yeah, the vendor install was an IScript [:@]
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Community Chosen Answer

1
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.
Answered 04/04/2005 by: bheers
Second Degree Blue Belt

Please log in to comment
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

2
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.
Answered 04/04/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
(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.
Answered 04/04/2005 by: Bladerun
Green Belt

Please log in to comment
0
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.
Answered 04/04/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
At the risk of sounding like a complete packaging newbie, how can I change it? I'm stuck with adminstudio & orca at the moment.
Answered 04/04/2005 by: Bladerun
Green Belt

Please log in to comment
0
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.
Answered 04/04/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
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.
Answered 04/04/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
For changing the INSTALLDIR
General Information -> product Properties -> INSTALLDIR
or you can use direct editor -> directory Table.
Answered 04/04/2005 by: bheers
Second Degree Blue Belt

Please log in to comment
0
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.
Answered 04/04/2005 by: Bladerun
Green Belt

Please log in to comment
0
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
Answered 04/04/2005 by: bheers
Second Degree Blue Belt

Please log in to comment
0
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).
Answered 04/04/2005 by: Bladerun
Green Belt

Please log in to comment
0
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
Answered 04/05/2005 by: MSIMaker
Second Degree Black Belt

Please log in to comment
0
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?
Answered 04/05/2005 by: Bladerun
Green Belt

Please log in to comment
0
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]
Answered 04/05/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
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?
Answered 04/05/2005 by: Bladerun
Green Belt

Please log in to comment
0
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
Answered 04/05/2005 by: nmi
Orange Belt

Please log in to comment
0
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.
Answered 04/05/2005 by: brenthunter2005
Fifth Degree Brown Belt

Please log in to comment
0
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.
Answered 04/05/2005 by: Bladerun
Green Belt

Please log in to comment
2
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.
Answered 04/05/2005 by: brenthunter2005
Fifth Degree Brown Belt

Please log in to comment
0
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.
Answered 04/05/2005 by: Bladerun
Green Belt

Please log in to comment
0
Rate our posts? [;)]
Answered 04/06/2005 by: brenthunter2005
Fifth Degree Brown Belt

Please log in to comment
0
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]
Answered 04/06/2005 by: Bladerun
Green Belt

Please log in to comment
0
Ya Velkomme![8D]
Answered 04/06/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
Cheers Cheers! [:)]
Answered 04/06/2005 by: brenthunter2005
Fifth Degree Brown Belt

Please log in to comment
0
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.
Answered 02/28/2008 by: inr32
Senior Yellow Belt

Please log in to comment
0
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! :)
Answered 01/21/2009 by: VBScab
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity