End point 'Up To Date' notification period - customise?

Hello and welcome, Craig

To answer your question first: I believe the value is not configurable.

If you take a closer look you will notice, that the "Not since" field contains only "discrete" values - it tells you the time when the oldest update which the computer has not yet applied became available. Now one could argue that SEC should take the updating interval into account and therefore not report the computer as out of date before this interval has expired.

But that's not the intended purpose of this column. If you click Protection on the Dashboard you get a list of connected computers (the indicator is still - SEC4.5 - in error as it sometimes shows computers as connected which haven't reported back for months) which have not yet the latest package (or IDEs) applied. This is an important information if you want to assure that the client has the latest protection data (the number of IDEs is not the perfect indicator).     

To get the PCs which are "really" out of date just sort the Up to date column (selecting the respective computers and using Edit->Copy you can export the list as tab-delimited file for further processing).

Christian

Hi Christian,

Thanks for the quick and informative response.

I'm trying but I can not quite get my head around the concept you have described, everytime I think I have it figured out I realise I still don't really understand how it's supposed to be interpreted, as logic says:

 - I set an update interval of 2 hours

 - If SEC is reporting a computer as "Out Of Date" and the Up To Date column reads "not since X" which is outside of the 2 hours, then some other circumstance has stopped it updating such as the PC being off / network connection loss / fault within SEC during that update window, 

 - If SEC is reporting a computer as "Out Of Date" and the Up To Date column reads "not since X" which is inside of the 2 hours, this indicates to me that SEC wasn't able to update the PC within the update window, does this mean the window is too frequent and can't update that many PCs in that time frame and it just starts at the top again on the next update window therefore always missing these PCs?

I suppose I was assuming that all the PCs are being updated without issue on time and that SEC was getting ahead of itself, "jumping the gun" you could say on reporting PCs out of date. So basically, updating issues aside, if the client version doesn't match the latest then it will be listed in this column and as "Out Of Date" even though theoretically it was supposed to be updated an hour ago?

Thanks,

Craig

Hello Craig,

it's not SEC updating the clients but the client fetching updates from the CID. Thus if the client last looked for updates at, say, 09:37:23 a.m. it will do so again around 11:37:23. Assuming Sophos published an update, SUM downloaded it and deployed it to the CIDs on 10:02:13 SEC will update the client's status to Not since ... 10:02:13 after a while (I don't know the exact timings but it will definitely happen as soon as the client sends some message through RMS). 

 - If SEC is reporting a computer as "Out Of Date" and the Up To Date column reads "not since X" which is outside of the 2 hours, then some other circumstance has stopped it updating such as the PC being off / network connection loss / fault within SEC during that update window

Close, but unlikely fault within SEC (if a message is lost due to problems on the management server you will have noticed).

- If SEC is reporting a computer as "Out Of Date" and the Up To Date column reads "not since X" which is inside of the 2 hours, this indicates to me that SEC wasn't able to update the PC within the update window, does this mean the window is too frequent

Again, SEC doesn't notify the clients when an update is available but the clients check for updates using the specified interval. What you said would more or less apply if you use Update Computers Now. SEC will try to notify the clients, the messages are queued until they are either successfully sent to the client or discarded if the client can't be contacted over a longer period (because e.g. it is switched off).

Re-reading your initial post I think there's a misconception which I didn't notice at first. The update interval tell the client how often it should check for updates. A client will attempt to AutoUpdate shortly after boot and from then on every nnn minutes (we're using 10 minutes). So if Sophos issues an update a client should have it applied within half an hour (worst case - 10 minutes SUM interval, 10 minutes update interval on the client plus time for processing) or less than that (except for major updates where SUM needs more time for processing).

Christian

Hi,

There is a registry key the management service can read in to change the allowed latency.  I found it in:

http://www.sophos.com/sophos/docs/eng/secsrep_30_speng.pdf along time ago.

It's a DWORD called ‘‘‘‘UpToDateLatencyMins’’’’ in the registry entry

[HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\EE\Management Tools]

If it doesn't exist, 60 minutes it the latency, so you could create that and make it 120 minutes and see how that changes the values. It will offset the "Not since" times in SEC but if you know what that's fine.

If you were to create this key, you would need to restart the management service.  This should cause the dashboard to be more lenient.

I looked into the up to dateness field in SEC and found the following by looking at the database:

The "Packages" table in the database is the source of all the package information, any data going into it is put there by the stored procedure PackageAdd in the case of the information coming from an endpoint, from ComputerPackageAdd if it's from EM Library and SDDMPackageAdd if it's from SUM.  THese stored procedures creates new records in the packages table if the current package information supplied to the stored procedure at that time does not match the following:

1. ProductID
2. SAV Version
3. VirusDataVersion
4. IDEChecksum

of any package already in the table.

The package information in the table can have data from 3 sources:

1. EMLibrary
2. SUM
3. The endpoints

The way I've found to identify where the data has come from is as follows:

1. If the package information has come from EMLibrary the RolloutNumber column will be a number that isn't 99999999.
2. If the package information has come from SUM the RolloutNumber column will be 99999999.
3. If the package information has come from the client the RolloutNumber column will be null.

So if a client (as listed in the "computersanddeletedcomputers" table) is pointing to the packageid in the "Packages" table ("packageid" column in the "computersanddeletedcomputers" table maps to the "id" column in the "Packages" table)  which data has originated from the endpoint it will be shown in SEC as "Unknown" as the server side has no knowledge of this package from either EMLibrary or SUM at the point in time this package information was sent to the server by the client. 

The "Not since" time against a machine in SEC is the expiry time of the package the client is linked to.

I hope that helps explain why a machine might show up as Unknown as well.

Jak

Hi Christian,

Thanks for putting your explanation again in different words, it's really helped to clear up my questions on this matter. Again another misconception on my part, thinking SEC pushed the updates out to clients.

Thank you both for your very detailed informed responses, I now have a much deeper understanding of how SEC works together with the clients...as usual with complicated software, nothing is exactly how you initially think it should work.

Thank you again for all your help :smileyhappy:

Cheers,

Craig