Okay.
Now I want to get into how you can use group policy software deployment to manage a software lifecycle.
What I mean by lifecycle is sort of that birth updating and death of a package as it's deployed to a
client.
So some of the things you can do within the CI lifecycle capabilities are patching of existing packages.
Upgrades of existing packages.
So I could go from Adobe Reader 11 to Adobe Reader 12 or Office 2007 to 2010.
Actually office is a really bad example because as of about Office 2007, Microsoft actually broke the
ability to use group policy software installation to deploy office.
So you aren't going to really be able to do that to deploy Microsoft Office using group policy software
installation for a variety of reasons, not the least of which is that it's no longer packaged as an
MSI file.
So there's a lot of challenges around using it with group policy.
But in any case, you can do patching upgrades and redeployment of an existing application.
So if for whatever reason, you need to redeploy and I'll talk about where that comes into play for
some of this lifecycle stuff, you can do that.
And then the removal of the package.
If you no longer need the package installed or you want to remove it from certain systems, then that
option that I showed you earlier about having a GPO remove the package when the scope of the GPO is
no longer targeting that user or computer.
So all of these things are possible with group policy, software, installation to a certain degree.
Each of those operations, of course, is done against the entire deployed base.
As I kind of alluded to earlier, in the limitations around group policy software installation, there's
no such thing as being able to phase in patches.
If you've deployed a package in a GPO to 100 computers, then when you update that package, when you
patch that package, the phasing in is really governed by how quickly the computer is rebooted or the
user logs in.
And that's really the only governing factor you have, the only sort of limiter.
There's no way to say, I only wanted to go to these ten systems.
So once the package is deployed, you're kind of stuck with whatever target base you've deployed it
to.
Now you can certainly target the same application to smaller subsets of machines or users and then use
that as your sort of deployment strategy going forward.
But you have to consciously do that by using, you know, features that I've talked about before, such
as security group filtering or WMI filtering to target those applications to particular user or computer
populations.
So again, all of these lifecycle options, if you want to call them that, require that foreground
refresh to take effect.
So you either need to reboot the computer to get the new upgrade or the new patch, or you need to reload
gone.
And all of those things need to happen.
So let's spend a little bit of time talking about how we redeploy or remove a package.
So once the package is out there, all you need to do is right click on package and choose all tasks.
And you'll notice that you can do three different things for a published application in this example.
You can actually change its deployment mode from publish to assign.
You can remove it.
And then when you remove the package, then the behavior at the client is governed by how the checkbox
was set.
That uninstall when package falls out of scope checkbox how that set when you deployed the package.
So if that set to you know basically checked then when you click remove, then the software package
will be removed from that target system when the next foreground refresh happens.
Now the redeploy feature is really just it's not actually going out and forcing all clients to redeploy
the application at that moment.
It's setting a flag on the package in Active Directory that at the next refresh the client sees and
says, Oh, I need to rerun the installation for this package.
And so we'll use that redeploy in a demo in a short bit to show you how you can essentially patch that
Adobe Acrobat reader package that I just had deployed.