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! =)
Best Answer
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.