1

This is my first attempt at creating a Group Policy to install a software product for computers on our domain. When I attempt to add a package I receive the following error:

Add operation failed. Unable to extract deployment information from the package. Run validation on the package to ensure that the package is correct.

Here are the steps I have taken to get to this point:

  1. Within Active Directory, right-click on the Domain and choose Properties
  2. Click on the New button to create a New Group Policy Object
  3. Named the object
  4. Selected the new Group Policy Object and clicked on the Edit button
  5. On the Group Policy Editor dialog, under Computer | Software Settings | Software Installation node, right-click and choose the New Package command.
  6. The path to the MSI file is a valid UNC path (the share where the MSI file resides has been shared to users within our Domain - full control).
  7. Click "Open" to select the MSI file
  8. Under the Deploy Software dialog, select "Assigned" and click OK
  9. After a few moments (10 - 15 seconds) the error message described above is displayed

Troubleshooting Steps I've tried to Date:

  1. Made sure that the software is not installed on the server already
  2. Used the MSI file to install the software on another machine to make sure the MSI works.
  3. Verified that the Windows Volume on the server has adequate free disk space (100+GB).
2
  • I take it at the command line your passing the unattended and silent commands?
    – Tubs
    Jul 30, 2009 at 11:57
  • Yes - I think. I used the /qn command Jul 30, 2009 at 15:18

2 Answers 2

1

That's bad mojo, then. That's nothing that you're doing w/ your procedure, but rather something wrong with the MSI. Did you build the MSI yourself or is it 3rd party? If it's third party, does the manufacturer indicate the MSI works in this type of deployment scenario?

I can't tell you which specific validations you should run because I don't know exactly what Windows is doing when it "extracts" the "deployment information" out of the MSI. I know that I've seen this with a couple of fairly poorly made MSIs from third parties. I belive that I ended up giving up on them, extracting the contents myself, and re-packaging them into MSIs w/ WiX.

(This is one of those places in Windows where I'd love to have some visibility into the source code...)

3
  • Microsoft could have done MSI's so much better if they had forced some things, such as admin installs and un-attended installs as must support options Jul 30, 2009 at 12:19
  • @SpaceManSpiff: Total agreement. Sysadmins need to be up in arms and very vocal and outraged with software "manufacturers" who don't use Windows Installer properly. EXE-based setups, poorly made MSI's, etc, are not acceptable. Especially when the tools to make good MSI packages are out there and free. (I can't tell you how many times I've wanted to say to a software manufacturer "Look-- pay for a plane ticket to fly me out there to meet your "setup people" and I'll build an MSI package for you for free just so I can have it for my Customers...) Jul 30, 2009 at 12:34
  • The MSI is one we built ourselves using a third party tool to create the MSI (AdvancedInstaller). Jul 30, 2009 at 14:32
1

Some .msi packages arent designed for unattended installation. Which might explain why it installed ok when you ran it manually. I've seen this a couple of times when extracting the .msi from an .exe. As Evan said, you are doing everything you should to make this work.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .