Symantec's SEPM system did not handle the rollover to 2010 gracefully. Any defs later than 12/21/2009 are marked as out of date. http://www.symantec.com/connect/forums/official-status-sepm-definitions-stay-31-12-2009-last-updated...
So they are locking the definition date at December 31, 2009 and incrementing the revision number. If you (like us) are using the host checker to make sure defs are current, this will mess you up. Especially since v6.4 doesn't allow you to specify how many days old the defs are allowed to be, just how many revisions out of date. I wonder how long it will be until we're locked out of our own system.
We're having the same issue. We could disable the hostchecker, but that'd be highly inadvisable. Figure out any other work arounds?
If you update the virus defs manually, it will put in the new date. The update is here:
While that may put in the correct date, if it's a SEPM managed system it will show as out of date there and end users may get the "Your defs are out of date" warning depending on where you have that set.
They still don'thave a fix yet so we shut off the def date check.
"Access with possibly old defs" or "No access for anyone" - Which is worse?
Does anyone know what "updates out of date" really means in 6.4? I sure wish Juniper had just left it at "days out of date".
The definition version on client is checked against the definition history available in the XML file configured on the SA under EndPoint Security > Host Checker > Virus signature version monitoring.
This XML file maintains a history of upto last 10 updates. So if you have configured on the SA a policy for 'Virus Definition files should not be older than 8 Updates.' then Host Checker will find the client definition version and see if its older than the 8th update. If it is then the policy fails.
While Symantec fixes this issue another workaround is to stop the Auto-Update of the virus signature list on the SA admin UI under Endpoint Security > Host Checker > Virus signature version monitoring and configure the policy to older than 10 updates. This workaround is slightly better than completely disabling the check.
Note: Eventually even the 10th update in the definition history XML will be newer than 31st Dec 2009 and then the only workaround will be to use a previously saved copy of the XML which still contains in its definition history the definition from 31st Dec 2009.
Please note that due to unforeseen circumstances we had to modify the KB. There were some issues related to the custom XML and had to be removed.