SEC Constantly Showing 50%+ of My Computers "Out-of-Date"!

HI,

Do they individually show as "Unknown" or "not since [date time]"?

Regards,

Jak

They all show "Not since... (today's date & less than 2 hours ago!)"

The updating policy has the computers set to check for updates every 30 minutes and the console is set to not show a computer out of date unless it hasn't checked in for more than 24 hours.

Hi,

I have a few questions...

How many SUMs do you have?

Do they have the same subscription single subscription or multiple?

Is it always the same clients that show as out of date for a while?  If you order the out of date computers by the primary update location, do all the clients update from a CID maintained by the same SUM?

Are you able to describe your SUM and CID and subscription configuration?

Regards,

Jak

Hey Jak,

   I have 1 SUM that handles ~1800 endpoints.  I have several subscriptions on there (1 operational (v10.0.3) and 2 test (v10.0.5 & .6).  Its not the same clients showing OOD, I've not been able to detect any pattern so far as a matter of fact.  All the clients are looking to the same CID maintained by the only SUM I have.  I appreciate your help.

Additional question:  What is the max recommended endpoints per SUM?

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