Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 1 subscriber
  • Views 16265 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Restart needed for updates to take effect - Not clearing

Tyler_EFI322

Hello all,

I am fairly new to working with Sophos but sometimes we get a machine that will keep the "Restart needed for updates to take effect {0x0000006d]". Typically, I am able to resolve it by following the knowledgebase support page below. However, I have rebooted the machine several times, reinstalled the software, and followed the steps outlined in the links with no luck.

http://www.sophos.com/en-us/support/knowledgebase/31540.aspx
/search?q= 6865

The client computer has been able to contact the Enterprise console after all reboots. I have noticed that the registry value, HKLM\Software\Wow6432Node\Sophos\AutoUpdate\UpdateStatus\VolatileFlags, does not appear for this machine as well. I have tried to import the key from another client and it did not have an effect.

Does anyone have any ideas on how to resolve this issue?

Thanks

:51326


This thread was automatically locked due to age.
Parents
  • 0

    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

    :51390
Reply
  • 0

    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

    :51390
Children
No Data