This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Patch Policy Settings - scheduling

It appears that the only place to schedule patch policies are:

1. Configuration > Security (which does everything)
2. Individual workstations (which does just that PC)

Am I missing something?  I would think it should be possible to have a group of workstations assigned to one schedule and another group to another schedule.

Parents
  • 0  

    The native options are:

    1) Configuration > Security to set them at the zone level for all devices.

    2) The setting tab on any folder in the device hierarchy to set the setting for the devices in that folder

    3) The individual device

    If you need more control you could set the schedule to Manual and then use a bundle that you can set schedules on that just runs 'zac pap' to apply patches.

  • 0 in reply to   

    This has been a little frustrating so far.  I had set the policy for a 3 AM install.  And I created a WOL bundle to wake up the PCs at 2:40 AM.  I set these to occur every day over the weekend hoping to get up to date.  Came in this morning to find just over 25% were patched.  And many of those were ones I had done manually during testing.

    I just set the policy to manual.  Modified the WOL bundle to run "zac pap" and set it to run every day of the week.  Also created a separate bundle that just runs "zac pap" and asked users to manually run it.  Hopefully between the two I can get everything caught up.

    Setting it during the day doesn't work because it causes too much grief for users trying to get work done.  I tried testing "patch during shutdown" but I could not get all patches to reliably install.  WOL should be working because I checked with wireshark and the packets do appear.

    Patching is important and yet no one has a reliable method to make it happen.  I blame Microsoft ultimately because it is their OS.  MicroFocus has come up with some great tools that ease issues caused by Microsoft.  I had hoped ZPM would be the same.  Maybe I just need to work through it some more.  I will see what happens over the next day or two with the WOL patching and manual patching.

  • 0 in reply to 

    We do patches via a bundle and have used the info in this post /collaboration/zenworks/zpm/f/patchmanagement/222276/microsoft-servicing-stack-updates-and-patch-policies  (Craig's reply) to get the servicing stacks to install first.  The method using the tracking key works well.

    In my layout I have our devices in folders by department(Mechanical Design, Project Management, etc.).  I then can schedule the bundle as I see fit by department.

    For the bundle I added a user prompt action at the beginning

    "Critical System Patches are Being Installed in the Background....... Make Sure You Shut Down Your Machine Tonight to Complete the Install Process."

    I have reboot as the last action and have a requirement for HKEY_CURRENT_USER\Volatile Environment\LOGONSERVER value not existing to control automatic reboot.  This allows me to schedule it whenever and not force a reboot if a user is logged in at the time but get the reboot if I am using it after a WOL in a night run scenario.

    Jim

  • 0 in reply to 

      This sounds good, but I'm trying to sort out scheduling...  It seems like there would be times that the bundle would run, prompt the user to shutdown/reboot later, and then run "zac pap" and nothing would happen because their pc was already up to date.  How are you scheduling this bundle and how do you prevent the prompt if there is nothing to be patched?

  • 0 in reply to 

    A key to our success was having a reboot bundle prior to conducting patch management activities.  Even if you enable automatic reboot through patch management based on patch requirements, it may not always do it.   So you will have patches that require reboot from the last patch event and you cannot proceed with new patch installation until the machine has rebooted.

Reply
  • 0 in reply to 

    A key to our success was having a reboot bundle prior to conducting patch management activities.  Even if you enable automatic reboot through patch management based on patch requirements, it may not always do it.   So you will have patches that require reboot from the last patch event and you cannot proceed with new patch installation until the machine has rebooted.

Children
No Data