Q: I have several software packages that were deployed using Group Policy Software Installation. I want to retire the server that houses the packages I’ve deployed, but if I move the packages, this will trigger a reinstallation of all the applications that have already been deployed. Is there any way to get around this?
A: This is a common problem with no easy solution, but I’m asked about it so often, it deserves an explanation. The first thing I’ll say is that I always recommend that when you use the Software Installation feature in Group Policy, that you deploy your packages from a DFS or DFS Replication (DFSR) share. Doing so gives you the flexibility of moving the physical package from server to server without requiring a change to the package’s logical path. That being said, if you’re in this situation, there’s little you can do out-of-the-box to repoint an alreadydeployed package to a new location. There are several reasons why this is difficult. The first is that the package path location is embedded both within the Active Directory (AD) portion of the package definition within a given Group Policy Object (GPO), as well as within a package advertisement (.aas) file in the SYSVOL portion of the GPO. You can’t simply modify the .aas file because it’s a binary file that’s generated when you deploy the package. The problem gets even more difficult if you’ve deployed transforms as part of your installation because transforms are cached by the client during installation and are never recached as part of a redeployment. Finally, the client keeps information about the path to the package in its registry, and changes to that path will “orphan” the application for future modifications, upgrades, or patches. So make sure you deploy your packages from a DFS or DFSR share and avoid the problem.
—Darren Mar-Elia
