So I now I want to summarize what we learned about software deployment and group policy in this module.
So ASI or group policy software installation provides a really basic software deployment software distribution
feature that allows you to install MSA packages on a per computer or per user basis.
So again, you're limited to those MSA packages and there are obviously a few flexibilities that you
have within that per computer and for user deployment around publishing or assigning.
But by and large, it's a pretty limited capability.
So you can publish per user where you can assign per user in per computer.
And in either case, the user must log on or reboot to get that new package installed.
Now when you're deploying packages, you should definitely use a DFC share if possible.
This avoids the issue that I mentioned where servers that you've got packages on get retired and the
sort of link between the client that's installed that application and the original share package is
lost and you can no longer upgrade or manage those packages through group policy.
So DFC kind of abstracts the physical server from that deployment path and allows you to trade out servers
as needed underneath the DFC share.
And the client is none the wiser in terms of knowing which server it's getting its package from.
So I talked about lifecycle management of packages using ACI and I mentioned that and even showed that
you can patch and upgrade applications, but you definitely want to use an administration install of
the MSI file as long as it's supported because that allows you to do that.
Patching that I showed.
Without that administrative install, you can't really patch a deployment.
So it's important that if you deploy an MSI file, use that slash option on my MSI exact to essentially
get that administrative install out to your share package.
And then finally avoid those scenarios where the user can remove a package or try to manage an application
that's been deployed by group policy themselves.
What ends up happening and it's really easy to get into this situation and really hard to get out of
it is once a package gets orphaned.
In other words, either the user has removed it, but group policy still thinks it's there.
Or, in the case of the share going away or the server going away, the client is no longer able to
be managed through that relationship.
There really are no tools in group policy software installation to fix that scenario.
So you really have to keep that relationship between client and server clean and let group policy do
all of the lifecycle management.
If you don't let group policy do that lifecycle management, then you end up in these kind of orphaned
scenarios where you can no longer manage that package.
So that kind of concludes what I wanted to talk about with software deployment.
In the next module, I'm going to talk a little bit about user and settings and data management and
how group policy can help with that.