reboot failure ?

[mray]

Computer had BP run on it 2 weeks ago (6/15) and then again today. It is unknown if the machine was restarted in that time, but it seems unlikely. The job cycle run on the computer was:

Reboot (force always)

Wait 10 Minutes

Wait for host to be detected online

Download and install updates + reboot if required

The log shows a reboot initiated, but it seems the host never did as the subsequent error indicates that BP was already/still running:

Wed-20:58:25> Job Queue: Execution complete

Wed-20:58:25> Windows Update: Error 1623. HRESULT -2147024891: Access to the path '\COMPUTERC$Program FilesBatchPatchBatchPatchRemoteAgent.exe' is denied. This can occur when BatchPatch is already executing a Windows Update process on the target host.  Please make sure the previous BatchPatch Windows Update process is complete before executing a new one.   You can re-attach to an existing BatchPatch Windows Update process using 'Actions > Windows Updates > Reattach orphan'

Wed-20:58:25> Windows Update: Attempting to initiate Windows Update (Action: Download and install updates: 'SoftwareOnly'  ¦  Server selection: Default / Managed) ...

Wed-20:58:25> Windows Update: Establishing connection...

Wed-20:58:25> Windows Update: Initializing...

Wed-20:58:25> Job Queue: Initiating 'Download and install updates + reboot if required'

Wed-20:58:25> COMPUTER is online and responding to WMI requests

Wed-20:57:21> Job Queue: Initiating 'Wait for host to be detected online'

Wed-20:47:21> Waiting 10 minutes...

Wed-20:47:21> Job Queue: Initiating 'Wait 10 minutes'

Wed-20:47:21> Reboot/Shutdown: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

Wed-20:47:16> COMPUTER ONLINE

Wed-20:47:12> COMPUTER OFFLINE

Wed-20:46:59> Reboot/Shutdown: Attempting to initiate reboot (force)...

Wed-20:46:59> Job Queue: Initiating 'Reboot (force always)'

Wed-20:46:01> Windows Update: Update/Reboot Cycle: Queued...

Wed-20:27:40> CPU Info: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz | Sockets: 1 | Cores: 4 | Logical Processors: 4

Wed-20:27:27> CPU Info: Attempting to retrieve CPU info...

Wed-16:04:54> Remote Command: Exit Code: 0 (SUCCESS)

Wed-16:04:28> Remote Command: Executing  \COMPUTER -h  -s cmd.exe /C MSG * "This computer will be rebooted tonight for Windows Updates. Please close all open programs before 8PM"

Wed-16:04:28> Remote Command: Establishing connection...

Wed-10:39:41> CPU Info: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz | Sockets: 1 | Cores: 4 | Logical Processors: 4

Wed-10:39:35> CPU Info: Attempting to retrieve CPU info...

This morning I manually rebooted the machine and then a subsequent BP instance ran successfully.

Why did the reboot action fail? Why did it log the RPC server unavailable error?

[doug]

Hard to tell exactly what happened here. You can normally use ‘Get last boot time’ in BatchPatch to quickly see the last start time of the computer, which would answer the question of whether or not it was actually rebooted. But since you already rebooted it again, you would need to look in the event log to confirm whether or not it was rebooted by BP on Wed night. To me it looks like it *was* rebooted, based on the following two events.

Wed-20:47:16> COMPUTER ONLINE

Wed-20:47:12> COMPUTER OFFLINE

In this case you used ‘Reboot (force always).’ However, the ‘force’ method does not guarantee that the computer will return a ‘success’ message to indicate that it accepted and is processing the reboot command, which is why the ‘RPC server is unavailable’ or other error/failure messages can occur in that case, even when the machine is actually rebooted successfully. Generally speaking, I would recommend always using ‘force, if required’ which will always first try a normal reboot. It will only use ‘force’ if the normal reboot cannot be initiated. There is nothing wrong with using the ‘force always’ option, but since it doesn’t guarantee a return value, it can add confusion in the cases where it doesn’t return ‘success’ but still reboots successfully. This is not a BP issue. It’s how Microsoft designed the ‘force’ method.

The one piece of the puzzle that does not make sense is the Error 1623. This should be investigated independently because it normally should only occur if there is a pre-existing Windows Update process running on the computer. From your log there does not appear to be a previous attempt to initiate Windows Update, so it’s unclear to me why you would receive this error, unless you had already initiated Windows Update from a different BP grid. Considering that you already rebooted the machine and find that it is working properly/normally, there is nothing else really to do. We won’t be able to determine why that error occurred anymore.

-Doug

[Author]

Posts