Restart needed for updates to take effect - Not clearing

Hello,

For one of these computers, on each update check, the ALC log (SAV client, "View updating log") of AutoUpdate still shows a restart is required?

Everything else past that is just moving along the message to the management server, i.e. messages in the RMS agent log:

I believe at the end of the update AutoUpdate creates the key:

HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Sophos\AutoUpdate\UpdateStatus\VolatileFlags

and sets the RebootRequired name value under this key to either 0 | 1.

The key: "VolatileFlags" is created as a volatile key, i.e.. it is only held in memory, the idea being that these types of keys are always lost on a restart and therefore a pretty reliable way to know if a computer has been restarted.  One way to check if a key is volatile, is to try and create a sub key under them,  If it's volatile it will error.

So, if you restated and the key has gone, alupdate.exe, on it's next check should attempt to read the key, fail and the next update status should send back a 0 state.

Have you tried creating a regular key:

HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Sophos\AutoUpdate\UpdateStatus\VolatileFlags

Create a DWORD under it called RebootRequired and set it to 0.

Then force an update.  What message is sent up, if it's 0, this should clear the alert in the console.  You can then delete the VolatileFlags key.

It might be woth running Process Monitor (http://live.sysinternals.com/Procmon.exe) filtered on the process name alupdate.exe and on registry keys, looking for access to the key  HKLM\SOFTWARE\Wow6432Node\Sophos\AutoUpdate\UpdateStatus\VolatileFlags\RebootRequired 

Can you see it read the 1 or 0, etc..

Hope it helps.

Regards,

Jak

Thank you Jax,

The ALC log is still showing that an update needs to take place. I have created the VolatileFlag key and set it to 0. Then after running the update, there was no change in the Enterprise Console. I ran the process monitor and was unable to see the alupdate.exe when trying to update remotely but saw the process if I ran the update from the client. Could this be a connection issue between the client and management server? I tried another computer that is not showing the "Restart needed for updates to take effect" and it worked just fine. In both cases, I was unable to see the registry key on the problem client.

I have also noitced that the computer in question is updating less frequently than the other servers in the same group (gaps of a day or two).

Im not sure if this is helpful at all, but I ran a query against the error table on the database and see that the error's source is ALC with the number 109. I will be trying to some additional fixings (suggestions always welcome :smileyhappy:) but if there is no progress, I may just try to give a reinstall another go.

Thanks again.

Hi,

Re: this comment:

"was unable to see the alupdate.exe when trying to update remotely but saw the process if I ran the update from the client."

When you select "Update now" from SEC, there can be a delay in the client taking action depending on configuration/setup.

Essentially, when you perform an action on the client, update now, scan now, send a policy, etc, it relies on the management server connecting to the client on 8194 to notify it that there is a message waiting. This notify  triggers the client to check in immediately for outstanding messages.  In addition to the notification methos, the clients are also polling the server for messages every 15 mins +- 50%.  This is really as a fall back if the server cannot connect to the client on 8194, I.e. a firewall is blocking incoming connections, NAT connections, etc.. Clearly if this is happening there is a delay in downstream messaging.

So if the server isn't too busy processing messages and the server can connect to the client on 8194, I would expect the message to take around 2-3 seconds for the client to take action.  If the server cannot notify the client of the outstanding message it could take up to, worst case: 15+7.5=22.5 mins for the action to take place.

To trace the downstream message, you can check the message router log on the server and client (\programdata\sophos\remote management system\3\router\logs\) for a EM-SetConfiguration or EM-DoAction.

Regards,

Jak