Post-Action Restart problem

Usage and Config Platform
1

BES client 9.5.4 on Win 7 Enterprise, I’m having repeated issues with post-action restarts having very long delays. I’m watching the BES Client logs on 8 workstations now, all are reporting along the lines of

At 15:05:48 -0500 -
   IBM BigFix Restart (Force count:25) from ActionID 934924
At 15:07:19 -0500 -
   IBM BigFix Restart (Force count:26) from ActionID 934924
At 15:08:50 -0500 -
   IBM BigFix Restart (Force count:27) from ActionID 934924
At 15:09:21 -0500 -
   Report posted successfully
At 15:10:21 -0500 -
   IBM BigFix Restart (Force count:28) from ActionID 934924
At 15:11:52 -0500 -
   IBM BigFix Restart (Force count:29) from ActionID 934924
At 15:13:23 -0500 -
   IBM BigFix Restart (Force count:30) from ActionID 934924
At 15:14:19 -0500 -
   Report posted successfully
At 15:14:54 -0500 -
   IBM BigFix Restart (Force count:31) from ActionID 934924

I’ve seen this get as high as Force count:40. It looks like eventually they might restart on their own, but are there any suggestions as to where I should look to explain this delay?

These workstations do not have any logged-on users at the moment.

(edit: typo - max force count is 40 not 50)

2

Interesting observation - on at least the 6 clients I’ve checked, they all got to exactly Force Count:40 before rebooting.

So is there something the client does differently after 40 retries? And if so, can I bring that retry count down?

1 Like
3

This might be because I’m also trying to trigger a reboot in the Action Script itself, in addition to the Post-Action Restart.

I’m trying to work-around the condition where the BES Post-Action Restart doesn’t take effect (usually due to logged-on but disconnected RDP sessions, or Windows Core installations). So I thought I’d let the BES Post-Action Restart handle “really logged-on cases” with a nice reboot timer, but also use the hammer of shutdown.exe in case BESClient gets confused. So my actionscript includes

runhidden shutdown.exe /R /T 86400 /C "BigFix is initiating a restart of the system in 24 hours to complete patching"

What I suspect is happening is that because there’s already a restart in progress (based on shutdown.exe), that BESClient cannot trigger the restart itself.

1 Like
4

That could be what is happening. If the post action is using a similar mechanism to do it, but this is definitely odd.

5

I believe this has happening because the UI could not be presented to warn of the reboot countdown, due to logged-on but disconnected RDP sessions.

I’m testing now with the _BESClient_ActionManager_UIMissingHoldMode setting with value none, and so far it looks good.

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Configuration%20Settings

1 Like
6

I think it might work better if in the end of the actionscript you just put:

restart 3600

or something like that. I think it might be more forceful than using the post action thingy and instead of using runhidden shutdown.exe /R

It will still present the BigFix UI if it can, but then it will just reboot.

The doc above says “The delayed restart is a forced restart. It will not prompt the user to save changes to documents. The machine will restart without further prompting.” but I haven’t found that to be the case. When I have used it I still got a BigFix UI telling me it was going to reboot with an option to snooze the notification for a short time until the timeout.

I’m not sure what would happen if you tried to use both.

I’m pretty sure that: IBM BigFix Restart (Force count:31) means that bigfix attempted to force a reboot 31 times and failed, which it seems like you have come to a similar conclusion.

CC: @AlanM @joseg

7

Yes never use the OS command or your action will also “fail” as it will not complete if the restart occurs before the action actually closes off.

8

Understood. I was using the OS command because the built-in ‘restart’ command was failing to reboot the machine in some cases - which I believe is due to the disconnected Remote Desktop user and resolved via _BESClient_ActionManager_UIMissingHoldMode

1 Like
9

Did you raise a PMR for that case? It would be good for us to be able to handle the disconnected users better.

10

No, I didn’t PMR this one. I think setting the UI Action Hold value is a good solution for me.