Software Deployment

There seems to be something accessing the source. Log the installation and see where it fails.
If unsure post the relevant log related to this.

I have a similar problem at my work place. Pretty much all of our packages are uncompressed MSIs, meaning that the file and folder structure for the MSI sits alongside the MSI on our server (as opposed to compressed all-in-one MSIs). And while I'm not sure of all the factors that went into this decision, I figure it's part and parcel of failed uninstalls we experience when for the server's copy of the package (MSI and support files) is deleted before it's been removed from all workstations (from experience we no longer aggressively clean our server of old packages for this very reason). When a computer installs a GPO pushed MSI, Installer makes an exact cached copy of the MSI (renamed randomly for some reason I don't get) in the c:\windows\installer directory, but I don't believe it makes cached copies of the support files. So when the uninstall eventually happens and the server copy of the package is no longer available, it fails. I've always figured this is due to maybe that the support files need to be read for the uninstall to happen. That's just theory (I'm kinda new to packaging and deployment).

So I figure the problem PeterL is having is likely due to the MSI on the CD being uncompressed (pretty normal practice for most vendors I think) and therefore the uninstall fails due Installer's inability to read the support files. Could be talking out me arse though.

I figure the solution is to copy the CD locally and install from there, or if this is an option, make a network administrative install of the CD (MSI and all related support files, CABs, DLLs, etc...) and deploy from there.

Hi fosteky,

It doesn't matter if the files are external uncompressed, CABs external or CABs internal the cached msi locally on the client will be an copy of the msi without the files/cabinet(s).

The cached copy of the MSI (renamed randomly for some reason I don't get) in the c:\windows\installer directory.
The random name is required otherwise other installations would overwrite the cached msi and therefore be unavailable during repair & uninstall.

It's not required for the uninstall to have access to the msi and files stored on the server, but this will happen if there are custom actions accessing the SOURCE.

Thanks for the information, this will enable me to more effectively troubleshoot failed uninstalls.

So maybe the MSI on PeterL's CD has a custom action that calls SOURCE.

Or a component has the msidbComponentAttributesSourceOnly attribute bit (Component can only be run from source).