Restart Endpoint in Automation Plans

Usage and Config Server Automation
1

We use automation plans to pre-fetch our patches to our servers and then automatically start running whatever patches we are running for each cycle. We typically create a If Pending Restart then go ahead and restart endpoint. While this seems to work well it’s the subsequent restart endpoints after patching that don’t always reboot. Is there a better way to force restarts? We are using BF 9.5.5.193

thanks,

Dan

2

Bueller, Bueller? Bueller, Bueller?

3

Hi Dan,

So can you give a summary of the individual steps in the plan? (at what point do the restart(s) take place in the overall flow)

And what are you using to perform the restarts? A custom fixlet? One of the SA restart fixlets, etc.?

Regards,
Paul

4

I replied to your email with a few screenshots so not sure those will show up or not…Is there a better sure fire way to issue restart commands? Should we use the Post action in the baseline ?

5

just got back the NDR from the post I did via email:

Paul,

Here is a screen shot of our 1 of our Automation Plans, the “Restart Endpoint and Don’t Wait ICW” is a customized “Restart Endpoint” Fixlet from BigFix. We added the AND (pending restart).

image.png894×617 22.3 KB

image.png914×593 22.2 KB

BUT we have also used the original Fixlet for restart as well:

Thanks Dan

6

Hi Dan,

Okay, thanks for that. So it looks like the flow is:

  1. Restart any computers in a pending restart state
  2. Apply current set of patches
  3. Restart all targeted computers

And from your previous post, the one that’s causing trouble is (3).

Do you know if there’s any correlation between the endpoints causing the issue in (3) and the ones that were actually restarted by (1)? For example, is the issue to do with ones that were restarted by (1) and then re-restarted in (3)? Or are computers randomly causing the issue in (3)?

In terms of the restart fixlets that come with the SA site:

  • (#160) “Restart Endpoint on Pending Restart and Wait for Restart to Complete”:
    I think this could be used as step (1) here.
    Any computer that is targeted by this and is not in a pending restart state will just return a Not Relevant result and nothing shall be done on that target for this step.

  • (#94) “Restart Endpoint”:
    Looks like this is currently being used as as step (3) here.
    Essentially just issues the restart command.

  • (#126) “Restart Endpoint and Wait for Restart to Complete”:
    This issues the restart command as well, but also includes a directive to override default plan engine behavior. The “Pending Restart” setting of the plan (see the “Settings” tab of the plan definition) is overridden by this fixlet, and the engine will always wait for the step to complete, regardless of that setting for the plan.

Regards,
Paul.

7

Hmm so our custom Restart Fixlet is stopping our actions? BUT then again we’ve had systems not restart using the #94 on the 2nd reboot process after patches are applied…

8

Hi Dan,

Well no, a restart won’t stop the action itself. It will just indicate to the BigFix client running on the targeted computers that those computers need to be restarted.

There might perhaps be some kind of network issue between the server and the clients that may cause them to be restarted after a prolonged delay or indeed not at all. For example some clients can become unresponsive or “non-reporting” when such a network issue occurs, meaning that the client is not reporting back to the server at regular intervals and so it is not aware that there is any work for it to do (under normal conditions, clients essentially “download” the action from the server and process it. So if it can’t contact the server, it cannot perform the action).

One option might be to automatically exclude non-reporting endpoints from the list of targets - there is a checkbox that can be checked on the “Settings” tab on the plan definition to achieve this. Please see the Excluding non-reporting endpoints page for more details on how to use this feature.

If that doesn’t help though, there’s a reasonable chance that you may need to engage IBM BigFix support directly to troubleshoot exactly what the issue might be if some of your clients are not processing actions correctly, Depending on what the cause is, it can be tricky to get to the bottom of it so it’s not really practical to try to do that via a forum post. From the Server Automation point of view though, it’s main job is to orchestrate and coordinate the work on the endpoints, however if an endpoint is not properly processing the work it has been given, then that goes a little bit outside our domain and into the domain of the BigFix client itself.

Regards,
Paul.