Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 1 subscriber
  • Views 4829 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Craig_IT

Hi Everyone,

New to the forums in search of some support that I haven't had any luck finding via the knowledge base.

Basically my endpoints are set to update every 120 minutes (every 2 hours / 12 times a day) as a lot of our workstations are turned on / used at different times through the day, so this hopefully captures as many as we can.

My problem is that even though they are getting updated every two hours, I will always have between 40 and 100+ endpoints listed as "Not since...." in the up to date column and it hasn't even been 2 hours from the date and time they list.  For example, they will say "Not since 14/09/10 10:15:13 AM" and the actual time is 11:30am on the same day.  This causes the "Out Of Date Computers" statistic on the EC dashboard to be grossly inaccurate and is no good for reporting or any kind of real troubleshooting / diagnosis of PCs truly out of date by more than a day / week / etc.

Is there a way to customise the period for the EC to determine what is out of date and what is not, a configuration setting somewhere or a file you can modify some parameters for?

Thanks,

Craig

PS...this is Sophos Enterprise Console 4 for anyone wondering....thanks.

:5015


This thread was automatically locked due to age.
Parents
  • 0

    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

    :5078
Reply
  • 0

    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

    :5078
Children
No Data
Unfiltered HTML