Pending restart

system · June 1, 2007, 9:18pm

(imported topic written by SystemAdmin)

Hi all,

I’m trying to get a better understanding of why clients that have been successfully updated still show “pending restart.” I’ve seen the articles regarding the two types of registry entries checked, and the case where the action expires before the client pc restarts, and one discussion post about “the console operator who deployed the actions was continually losing and regaining management rights over some of the systems.”

I have two questions I’m hoping someone can answer.

a) If an action is open for an extended period, say, a month, is it possible for the status to change day to day for individual pcs during that time if other things (additional big fix actions or other apps) are writing things to the PendingFileRename reg key, causing whatever status happens to be present when the action expires to stick? Or, once a client is restarted, if necessary, and is recorded as “fixed” in the database, does the status stay “fixed” for that action through to the action expiration?

b) What method(s) exactly does Big Fix use to restart PCs? Is it something as simple as shutdown.exe? And, is there any way a pc can be misconfigured so a restart can be prevented from occuring?

Thanks very much for your help

system · June 5, 2007, 9:27pm

(imported comment written by SystemAdmin)

Hi jrupr,

a) Yes, it is possible for the action status to change from Fixed to another state. The final state of an action is determined by evaluating the appropriate relevance expressions and if the computer state changes it could cause the actions status to go from Fixed to Failed. Image a patch is uninstalled, you would see the action status that applied that patch go from Fixed to Failed. The ‘Pending Restart’ state wouldn’t be seen again though, this action status state is only calculated once per run of the action. An action that runs more than once might see multiple Pending Restart states but a single run of an action could only see that state once. Basically, the Pending Restart is an intermediary state between running the action and the final state, the final state can change but there is no going back to a previous state unless the action is re-run.

(I hope this is all correct, its based off of my experiments and experience).

b) For Windows, we make a call to ExitWindowsEx:

http://msdn2.microsoft.com/en-us/library/aa376868.aspx

It is possible that a computer could be mis configured such that this API call fails. There are also polite calls and non-polite shutdown calls that are made to ExitWindowsEx and if you are only using Polite shutdown requests its possible the shutdown is being blocked because of that.

We use the Force flag if:

There is no count down specified with the shutdown/restart
We have already attempted a restart without the force flag
The _BESClient_ActionManager_SkipVoluntaryOnForceShutdown option is set to 1.

system · June 5, 2007, 9:29pm

(imported comment written by SystemAdmin)

Also, here are some reasons that the action status would get stuck at ‘Pending Restart’

The action expired or was stopped.
The action was issued by someone whose management rights have been revoked from the computer and it is no longer managed by them.
The computer hasn’t reported in since being restarted.

system · June 6, 2007, 12:08am

(imported comment written by SystemAdmin)

Tyler,

Thank you very much for your reply.

I can understand how the status could change if the computer state changes relating to an action

and a new evaluation is done. When is the new evaluation done? Only once at the end of the update

on the computer? Does the action continue to do periodic checks of relevant machines that it’s

already patched until the action expires? Or is the change detected by the periodic running of

the fixlet that the action addresses? How is it that machines that had a “pending restart” status

for an action and are restarted still show “pending restart”? Is this where the case of entries

in PendingFileRenameOperations (possibly entered by another action or some process unrelated to

big fix) can cause confusion? If the “pending restart” status can only be applied once how does it

sometimes continue to appear after a restart…especially if the state can change, but never back

to “pending restart”? Does that mean there can occasionally be a failure to update action status

in the database after a restart?

How quickly does the status change get written to the database? Is the database updated right after

the evaluation or cached until the client does its regular properties update with the server?

If the status change is detected by the fixlet, will the fixlet change the status recorded for the

action or just put the computer back into the list of relevant machines?

It seems as though the “pending restart” status is purely informational – it doesn’t indicate any

problem, it’s just saying the computer is in the transitional state, and it can be assumed the

update was successful. In other words, someone verifying the success of an action on a couple

thousand computers doesn’t need to spend time investigating computers that show “pending restart”

at action expiration?

Sorry if I sound dense, I’m new to big fix. I really appreciate your help. I haven’t been able to

find specifics about this in any documentation. If you know where I can find it please let me know.

I just need to make sure updates have been completed. As far as I can tell, the best way to verify

this is to see that the computer is no longer in the fixlet applicable computers list and that a

restart has been recorded in the computer properties sometime after the time an action completed on

an individual computer.

Thanks again for your help

system · June 6, 2007, 10:25pm

(imported comment written by SystemAdmin)

Lot’s of questions! I’ll try to answer them.

The BES Client is basically in a loop evaluating all the properties, Fixlets and actions. So, it will re-evaluate the action frequently, every few minutes for most deployments. Actions will disappear from the BES Client once they expire or are stopped and the BES Client will no longer evaluate them. I believe that actions in the ‘Pending Restart’ state get marked as needing to be re-evaluated after the next restart and then the BES Client will determine a final state for the action after the next restart.

The BES Client reports new action status message immediately after a state change is determined and the database is updated very shortly afterwards, the whole cycle takes a few minutes but I doubt there is a database problem here. You could send the BES Client a ‘force refresh’ by right-clicking on it in the BES Console and see if that helps.

Actions are completely independent from Fixlets at the BES Client level. Your BES Console pulls data from Fixlets to create actions so they end up with lots of copies of the same relevance code but the BES Client does handle actions independently of the source Fixlet. The Fixlet state tends to more accurate then the action state because actions can be in one of about 20 different states while Fixlets are boolean and don’t have expiration problems. Its also possible there is a bug that is causing the action state not to update after a restart, the BES Client is supposed to re-evaluate the action after the restart and update the status. I think there are some bugs in 5.1 and a few in 6.0 that will cause the BES Client not to re-evaluate actions correctly after restarts, it misses the fact that it needs to re-evaluate them for the final state after the restart.

Its possible that the PendingFileRenameOperations registry key isn’t getting cleared on restarts and that is causing the status to stay at pending restart. You might check the registry on a few computers and see if that appears to be the case.

system · June 27, 2007, 10:04pm

(imported comment written by SystemAdmin)

Hi, Tyler,

I apologize for letting this thread drop.

Just wanted to say thanks again for help…