Video Screencast Help

Possible to have computers update when they first turn on if they missed patch window

Created: 12 Jul 2013 • Updated: 11 Sep 2013 | 6 comments
This issue has been solved. See solution.

Hello All,

     I'm a newbie working along getting our Alitiris 7.1 system going.  I'm now working on the patch management piece.  I approved the latest microsoft bulletins to deploy to all our desktops.  Currently I have the updates to run at 3am and then reboot the system at 5am.  After that I only received 31% complaince.  It appears a lot of systems were either turned off or noon our network at that time.  When a system that missed the window powers on in the morning is it possible to run the updates then?  If so how can I set that up?  Thanks

Operating Systems:

Comments 6 CommentsJump to latest comment

Thomas B.'s picture

Hi Oscar,

I am also new here, but maybe I can help you.

We are also using the patch management function in Altiris 7.1. for ~250 desktops.When we started Patch Management Delivery with Altiris one year ago, we launched updates over weekend (time schedule), including several reboots provided by a second policy.

If you set a time schedule with start/end (e.g.19. july until 21. july), updates will only be deployed in this period. I have made the same experience, that compliance was first at low level. Sometimes, a reboot of client PC´s seemed to be necessary to receive a more exactly compliance report. Another point is, that Altiris Agent will recognize Updates/Bulletins instantly, but it won´t launch them immediately. Hence, we had to run our Patch Management for another three weekends to get a high patch level. 

With regards,

Thomas.

 

michael cole's picture

Hi Oscarc619,

I would check two things;

1) The reboot task went ahead in the cases of non compliance. Typically companies will manage the deployment of the Patch Policy as one item and the change control of the reboot policy as another. These end up running seperately, but I've often see cases where another reboot was needed before compliance was shown.This can be down to several reasons, often if you have multiple patches going out.

2) The reporting is accurate: You have a number of source of information for compliance, some of them lag behind what is out there in your environment. I found it's worth taking one client and checking through his logs to see the truth of what happened. Once you follow the logs the reasons usually become apparent.

Michael Cole

Remote Product Specialist

Business Critical Services

SOLUTION
michael cole's picture

I forgot to mention, your policy schedule will decide when patches are installed, I dont think that is a worry, but it's the reboot that actually does something and always the most important part. Patching in a window is all well and good, at least it satisfies the curious, but it actually does very little until the reboot which is both the invasive and vital patr of patching.

Seperate the two concepts with your companies support if possible. I believe a corporate reboot policy is one of the most useful things you can implement as an Admin since many security patches are not active until that reboot has occurred but it fixes many other issues incidentally like shoddy applications with memory leaks.

Michael Cole

Remote Product Specialist

Business Critical Services

oscarc619's picture

Thanks so much for all the help and suggestions.  After a few days I'm seeing some better numbers.  Getting a grasp of the power of all the options has been challenging but getting a better understanding each day.  Thanks again for all the help.

HighTower's picture

I would do this by creating an SWD policy or a Task to call the AeXPatchUtil.exe process to trigger the patching event.

Native Patch policies don't work the same as SWD policies in that they only run when they're assigned to.  AeXPatchUtil.exe will trigger the patching event when it's called.

HighTower's picture

Oscar, can you mark this thread as solved or did you need additional info?