Sophos Enterprise Console shows wrong Update-Details

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

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