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
End of Article
Register
