Sophos Enterprise Console shows wrong Update-Details

Hello Robby,

first thing to check is the Last message time to the right in the Computer Details tab. 351 was the number before noon (UTC) on Tuesday 2nd so the last message time should be before that (but not more than a few hours). As the number on the clients is correct and half of the clients do report it looks like a communication (RMS) problem.

Obvious question - have the clients something in common (other than the incorrect number)? Do you use message relays?

Christian

Thanks for your help, but i finally fixed the issue...we had a strange issue with our SQL-Cluster, wich caused this failure.

I apprechiate for that.

Seems the SQL-Cluster wasn't the origin of the problem.

Since the Update to 10.0.9 there are round about 350 machines that report beeing not up to date. But when i look on the client, everything is fine.

Another issue in this case...if there is an IDE-Update, the machines where shown as up-to-date for i think 2 hours, after that, they fall back to there old state.

There are no Message-Relays and if restartet the Management-Server and also the clients a few times.

Thanks for your help.

Just an update:

I think the pcs have nothing in common. The OS is XP, Win 7, Server 2003, Server 2008.

Another strange thing...the "Last received message"-time is also up-to-date.

HI,

The most important factor in the ability for SEC to determine if a client is up to date is that SEC receives from SUM the package information the client reports in so it can make a match and decide if that combination has not expired.

Ideally the package info should make it to the database from the authoritative SUM (http://www.sophos.com/en-us/support/knowledgebase/57638.aspx) before the client updates and typically this is the case, especially if you have one SUM and one CID.

Typically: SUM updates, writes the latest .ide for example to the CID, SUM completes the update (deploys to all CIDs maintained) and then sends in a status message, part of which is the package information for this update.  Shortly after the client checks the CID, sees the new .ide, pulls it down, and then sends in the status message which essentially reports the same package combination information as the SUM did before.  As the package hasn't expired, the client is shown as up to date.

The problems start if, the clients status message arrives in the database before that of the authoritative SUM.  As the clients status does not match a package.  This will leave the client showing 'unknown' for up to date, until the SUMs message arrives.

Clients may also show as out of date, if they update from a CID behind a SUM that takes a long time to distribute all its update locations.  E.g the authoritative SUM on the SEC server updates every 10 minutes.  There is a down-stream SUM that updates from this parent SUM every hour, the clients check on the CID from that downstream SUM every 1hour.  In this scenario, the latest package data gets to the database pretty quickly, say 5 mins after the .ide is released.  If the downstream SUMs checks the parent SUM for updates just before the new update, it then might have to wait another 59 minutes to check and pull the update.  If that SUM is maintaining a large number of subscriptions/CIDs then it might take another 20 minutes to update them all.  Likewise the client might have checked the CID, just before the .ide was written, so has to wait, worse case another 59 minutes.

So in this sort of scenario, you can see how the client might take a few hours to get the update that the parent had within a couple of minutes after release from Sophos.

So to answer the up to date ness you need to consider:

1. How many SUMs?

2. Which is the authoritative SUM and what schedule/package information that has, how long does it take to update and distribute updates to the CIDs it maintains (the status message is only sent right at the end of an update)?

3. How many CIDs do the SUMs generate?

4. How many subscriptions do they have?

5. The update frequency of the clients?

6. Do the clients show as "not since x" or "unknown" for their up-to-dateness?

Here are a number of posts that might prove helpful:

• /search?q= 5078
• /search?q= 28885
• /search?q= 7485

Regards,

Jak

Okay this are the answers:

1. Only one SUM wich delivers the update to 5 locations where the clients could get them.

2. ---

3. Just one CID

4. One subscription

5. Clients update frequency is 10 minutes

6. The clients show "not since 19.10.2012"

I've also tried an Update from Enterprise Console 5.0 to 5.1...no changes.

Hello Gorek,

not since 19.10.2012 suggests they are affected by the Shh/Updater-B False positives.

Christian

No, this problem is already solved in our company. So, any other suggestions?

Hello Gorek,

just asked. So the clients do report regularly (Last message time is recent)? I might miss something but IMO "normally" either they report and then it should be with the correct data - in which case they have not updated - or they don't communicate with the console.

Hmmm ... for those not since - they do have a recent Last message time? And what is the VDL version and number of IDEs in SEC? Wonder if the Last message time is increasing when they report up to date and then fall back.

Christian

Hello Christian,

the clients report reguaryly. The "last message"-time is recent. VDL-Version is 4.82G. The number of IDEs is 278.