Hello and welcome to Part three of the Patch Management lesson. We're still talking about update Manager. One of the things you can do is select an object in your inventory when you're in the update manager and check its compliance.
And what this does is it lets you see if the object is compliant with bass lines or with previously installed patches
or even with future installed patches. If you're doing this with a virtual machine, you do need to be in the PM's in templates view.
Otherwise, you select the object in the inventory as normal and go the update manager tap.
Uh, when we scan a *** checked in the inventory, we get different results.
One of things we can see is compliance with our baselines are baseline groups.
We can also see when the last game was completed, whether there are non complying, compliant or unknown objects like the EMS appliances, your hosts, so little list, all those different things you want to have to comply in V EMS, one non compliant host and three unknown status for your virtual appliances.
It could be a mix and match situation.
So what's the scanning is done. We can think about remediation. This is actually installing the patches,
So whether it's ah, VM, we could remediate templates. Which is kind of interesting concept to remember. A template is of'em that can't be powered on,
but we can re mediate it as far as the virtual hardware goes.
We can also immediate virtual appliances. Our hosts
and this could be done manually or immediately, or it could be scheduled.
So this gives you the flexibility to schedule it during a normal downtime window, so you don't have to wait around for that moment during the day when this is possible to do this work.
If your host is getting patched,
sometimes it requires going into maintenance mode. Not all updates require this, but most of them do.
When the When you're deciding to put the host of maintenance bone, you need to make some decisions about what to do with the PM's. We can power down the PM's or we can suspend them. Same thing would apply to virtual appliances
if you have a DRS cluster, however,
the DRS distributed Resource scheduler algorithms should detect that you want to go into maintenance mode and start migrating the V EMS to other hosts in that cluster.
We can also specify the number of re tries to go into maintenance mode. Maybe you wantto set that to two or three. Maybe the 1st 1 doesn't work
it times out because the VM they're still being moved somewhere else.
So you can set that for two or three re tries. And that way you can try to get a higher chance of going into maintenance. But without having a manually intervene,
you could also specify the time delay between re tries.
So if I want to do three re tries,
I might want to wait at least five minutes, maybe 10 minutes or longer between re tries. So I don't waste all three in a row while I'm still waiting for some VM to be moved to another host. So a little bit of trial and error, a little bit of testing here will help a lot.
think about some of the restrictions. If you do have a beer s cluster, we need to temporarily disable distributed power management H a a ad mission control and fault tolerance features.
And when you look at the configuration screen, these are all just check boxes that you can easily select.
This makes it easier for the host
to get into maintenance mode, which means that your updates will then happen and everything will be great.
Two more things to think about is
getting notified about Patch recalls.
So this is basically update Manager will contact the M, where in some interval that you that you designed you, did you designate or you pick the default
and it'll look for Patch recalls, patch fixes and other alerts.
It could find something that
has been recalled that you need to deal with. It will generate a notification update Manager will.
It will let you know if the patch has been recalled.
It'll actually delete the patch buying there is from your depository so that they're not there, meaning you can't use them again. That just keeps things easier to deal with.
And that way your repositories doesn't continue to grow in overtime with stuff in it that you no longer need or can't even use.
And then, lastly, it does not install patches from your *** I hosts. So if you get a notification that a patch needs to be rolled back
you need to do that manually
or schedule it, but it's not something that can be done
automatically from update manager.
If you have a deal. Arrest, cluster some other things to think about
host needs to go into maintenance mode, this is managed by update manager, so it's some automation there.
Then, as I mentioned earlier, DRS. Will migrate to be EMS to the other hosts in the cluster
so that the one going into maintenance spoken, therefore be worked on. Then you would bring that host back up,
bring the next host on the cluster down. Now the V EMS. Move around again, remediate that host and do it and so on until you're all of your hosts Remediated.
This not only makes it
a little bit safer because you're only doing one host at a time, but you can maintain up time as well. So that's that's an important thing to think about.
Once the host gets patched, it will then exit maintenance mode, come back up into full boot mode,
and then D D arrest will migrate. The VM is back,
So if you had some affinity rules or anti affinity rules, the U. S. Would evaluate that once the the host goes back out of maintenance mode and then it will readjust where the PM's go based on those rules.
we talked about what compliance view means. This is checking if that object and in for inventory is complying with your bass lines or baseline groups.
Then you know that what can be remediated the EMS templates, virtual appliances or hosts immediately or scheduled.
We know we have some some considerations for going into maintenance mode. Basically, it involves moving the VM somewhere else. And if you're in a dlrs cluster that's handled for you automatically,
you can get notified when you have recalled patches.
And then you decide what to do with those, depending on whether it's a host or or of'em that that's patched.
And then, as far as the cluster goes, we know that dear Rest will manage a lot of these details for us moving the VM somewhere else, moving them back all according to the D RS rules that you set up when you configure the cluster.
All right, that concludes a lesson. Thank you,
lad. 22 is your next task
in this lab, you'll be configuring and installing. Update Manager will see what's involved with that.
You also install the plug in for the V's fear clients that you can integrate that functionality into the client.
You modify your cluster settings to accommodate using some of the features for the lab that we're gonna d'oh.
Then you configure up the manager, created baseline, attach it to your host and scan for updates.
Once the scan is done, then the patches will be staged as we talked about here
and the host will be remediated.