Since upgrading my console to 5.1 (v 5.1.0.1839), I have a LOT of computers constantly showing "out-of-date". I can manually update them and most of them will get the latest updates, but this is high maintenance and should not be required. I've looked through the logs on both the server and a few clients, but didn't see anything that indicated the problem. Has anyone else experienced this? Thanks in advance!
Jason
Hi,
As you have a few subscriptions, how long does it take SUM to update them all for example following an IDE update? There is a LogViewer.exe in the SUM program directory which should help you to ascertain this without having to look through the logs.
There is no limits to endpoint per SUM but you might however see timing issues if the SUM is creating multiple CIDs as SUM updates CIDs one at a time and SUM only sends back a status message once it has finished updating. It is this status message is used by the management service to calculate the up-to-date-ness of the clients.
So as each subscription is essentially a CID (these are the Sxxx directories in the SophosUpdate share) and each of those can maintain multiple software packages, so SUM, especially on a heavily loaded computer may take a while to update them all. The clients updating from the CID first updated however get their updates and report in a version yet to be reported by SUM. I suppose as the clients start to update from the first CIDs they start to slow down the server and make the operation take even longer.
So that being said, anything you can do to speed up SUM updating all the shares the better. For 1800 machines, I would probably have:
SEC + SUM on one server, a local SQL instance should be fine for that number as long as the server isn’’’’t performing other roles. Subscribe it to all the same subscriptions and have it create the local shares. This SUM would be authoritative: http://www.sophos.com/en-us/support/knowledgebase/57638.aspx, meaning the SUM status should be sent in quickly.
On another file server, install a SUM, have it maintain all the same subscriptions. The clients would update from CIDS this server creates.
This would remove the load off the main SEC server to help with message processing, SQL, the management service and console responsiveness. SUM should now be able to update the CIDs quicker as it should have more resource to do so without all the clients hammering it. If you don't have a file server to dedicate to this but have a network filer for example, you could try pushing CIDs to that.
http://www.sophos.com/en-us/support/knowledgebase/1462/7800/1700/112127.aspx is also worth a read.
Most of the above however really applies to an "unknown" up to date state due to the client getting ahead of the server, the not since time if a client is actually updating would be more to do with the client status message being delayed behind the server status message.
E.g. SUM updates and sends in a status message. This new package is added to the Packages table of the database. The client may update interms of updating but if the status message from the client is delayed getting back to the server and into the database, then that would result in not since. In this scenario, you would want to trace the status message from a client following an update to see how long it takes to get into the database.
Do do so, Following an update, check on the client the Sophos Agent logs (\programdata\sophos\remote management system\3\Agent\Logs\) for the text:
"I SAV state observer received a status:"
This is where the agent has detected a change to SAV, I.e. a new update. Then Check the Sophos Router logs (\programdata\sophos\remote management system\3\Router\Logs\). You should see in the Router log a message of type "EM-GetStatus-Reply" being created around the same time, 20 seconds later ish.
Then on the server Router logs, you should be able to find an entry at this time for that message from the client. The next entry to check would be the msgn logs (\programdata\sophos\sophos endpoint management\log\ (maybe in a version directory, use the timestamps to check which file is being written to)) on the server to see if the message was received by the Sophos management service.
I hope it helps or gives you a few ideas.
Regards,
Jak
Hi,
As you have a few subscriptions, how long does it take SUM to update them all for example following an IDE update? There is a LogViewer.exe in the SUM program directory which should help you to ascertain this without having to look through the logs.
There is no limits to endpoint per SUM but you might however see timing issues if the SUM is creating multiple CIDs as SUM updates CIDs one at a time and SUM only sends back a status message once it has finished updating. It is this status message is used by the management service to calculate the up-to-date-ness of the clients.
So as each subscription is essentially a CID (these are the Sxxx directories in the SophosUpdate share) and each of those can maintain multiple software packages, so SUM, especially on a heavily loaded computer may take a while to update them all. The clients updating from the CID first updated however get their updates and report in a version yet to be reported by SUM. I suppose as the clients start to update from the first CIDs they start to slow down the server and make the operation take even longer.
So that being said, anything you can do to speed up SUM updating all the shares the better. For 1800 machines, I would probably have:
SEC + SUM on one server, a local SQL instance should be fine for that number as long as the server isn’’’’t performing other roles. Subscribe it to all the same subscriptions and have it create the local shares. This SUM would be authoritative: http://www.sophos.com/en-us/support/knowledgebase/57638.aspx, meaning the SUM status should be sent in quickly.
On another file server, install a SUM, have it maintain all the same subscriptions. The clients would update from CIDS this server creates.
This would remove the load off the main SEC server to help with message processing, SQL, the management service and console responsiveness. SUM should now be able to update the CIDs quicker as it should have more resource to do so without all the clients hammering it. If you don't have a file server to dedicate to this but have a network filer for example, you could try pushing CIDs to that.
http://www.sophos.com/en-us/support/knowledgebase/1462/7800/1700/112127.aspx is also worth a read.
Most of the above however really applies to an "unknown" up to date state due to the client getting ahead of the server, the not since time if a client is actually updating would be more to do with the client status message being delayed behind the server status message.
E.g. SUM updates and sends in a status message. This new package is added to the Packages table of the database. The client may update interms of updating but if the status message from the client is delayed getting back to the server and into the database, then that would result in not since. In this scenario, you would want to trace the status message from a client following an update to see how long it takes to get into the database.
Do do so, Following an update, check on the client the Sophos Agent logs (\programdata\sophos\remote management system\3\Agent\Logs\) for the text:
"I SAV state observer received a status:"
This is where the agent has detected a change to SAV, I.e. a new update. Then Check the Sophos Router logs (\programdata\sophos\remote management system\3\Router\Logs\). You should see in the Router log a message of type "EM-GetStatus-Reply" being created around the same time, 20 seconds later ish.
Then on the server Router logs, you should be able to find an entry at this time for that message from the client. The next entry to check would be the msgn logs (\programdata\sophos\sophos endpoint management\log\ (maybe in a version directory, use the timestamps to check which file is being written to)) on the server to see if the message was received by the Sophos management service.
I hope it helps or gives you a few ideas.
Regards,
Jak
