6

I have an internal application that uses the Windows Installer. Each update to this application is a "major upgrade" (different product code, same upgrade code) and it calls RemoveExistingProducts. (In effect, this means that any time a new build is created, you can install it by just clicking on the MSI file, since it will uninstall the old version and then install the new version.)

It's currently deployed via a machine configuration in group policy. Any linked GPO will install the software at next boot, and this works great.

I also have a continuous integration server (TeamCity) that builds and runs tests for this software each time we commit something to source control and "pin it" for deployment. I can even copy the freshly-built MSI file to the network share in preparation for deployment.

Unfortunately, I don't see a way to actually tell the GPO to re-deploy the newly updated MSI file programmatically as part of my integration process.

If I just overwite the existing MSI file and don't touch the GPO, then the change is not noticed by machines that have the older MSI installed, and newer machines freak out when they can't find the MSI file with the product code in the script generated by the Group Policy Management Editor. Fine, makes sense.

The same behavior seems to happen if I just overwrite the existing MSI file and click "Redeploy application" in GPME. Again, we seem to be unhappy that we are trying to redeploy with an MSI file whose package code does not match the one in the script generated by the GPME. Fine, makes sense.

What does work is right-clicking the installation package in GPME, hitting "Immediately Remove," and then adding the installation package right back--that creates a new *.aas script and the old package is removed and the new package installed at next boot. Is there some way to do this via a batch script that I can add to my integration server's build process?

Thanks!

Follow-up update

After reviewing Evan's remarks, I ended up just writing a small batch script that runs at Startup. I also wrote a small utility called msicheck that determines whether or not a given MSI package is installed. This met my needs well enough, and is a far cry better than wading through pages of an LDAP specification! =)

Nicholas Piasecki
  • 282
  • 3
  • 10

1 Answers1

5

I've had the desire to do something similiar and have done some reserach on the topic in the past.

There's no exposed API that I've been able to find to do what the Group Policy Editor is doing to create those application advertisment script (.aas) files and the corresponding records in AD. The PowerShell Group Policy API lets you configure registry-based settings, but not settings for other Group Policy Extensions.

There is now a reference to the Group Policy Software Installation Protocol Extension (thanks EU anti-trust settlement!) and I suppose you could try and roll engine to perform assignments yourself. The LDAP transactions necessary to perform the addition of the package and the format of the .aas files are in there. It looks a bit daunting (though fun)...

Frankly, your attention to detail re: deployment testing is to be commended. I wish you were writing software that my Customers use. The fact that you're using Windows Installer alone puts you ahead of the pack. That you know about Group Policy software deployment and are actually testing it makes me giddy! I wish some measurable fraction of developers cared as much as it's clear that you do.

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • Ugh, I was afraid of that. I'll have to see if I can cobble together some solution when I have a chance and will update this post if I can come up with something. Right now, my thinking is that it'll be a batch or PS script that runs at boot and invokes the appropriate msiexec commands--a poor man's software deployment. I'd lose patching and transforms and other nonsense, but I'm not using that anyway; for an internal app, far easier to blow it away and reinstall without worry. Thanks for the insight! – Nicholas Piasecki Nov 05 '09 at 13:28
  • Yep, looks like a startup batch script was the way to go. I updated the post with more information about my workaround. Thanks for the help. – Nicholas Piasecki Nov 07 '09 at 17:42
  • It's sad to say it, but that startup script method is the officially Microsoft-sanctioned way of installing Office 2007 from group policy. For reasons that I'd love somebody to tell me, the MSI for O2K7 was made to be incompatible with software installation policy. Just one more illogical Microsoft action. – Evan Anderson Nov 07 '09 at 21:58