Trend OfficeScan 10 causing Hash Mismatch Errors in SCCM 2007

For the last 2 years of my SCCM Career I've been blighted with issues concerning the above.  I've added exceptions to our Trend server, calls have been logged but I can never seem to get this sorted.

I find that if Trend is running the execmgr.log will sometimes show Hash Mismatch errors.  If I manually disable Trend (or better still remove it!!) - it works fine.

I've started adding a quick command to my Task Sequences and package deployments to temporarily disable OfficeScan while the deployment takes place and it works a charm!!

Simply add the following command lines before and after via Task Sequence or simply create a package with a batch file containing the following.

Before:

net stop tmlisten
net stop ntrtscan

After:

net start tmlisten
net start ntrtscan

Obviously this works manually too if you should ever need to disable Trend remotely...  Even if it has a password!!!!!!!! ;)

SCCM Collections not updating - eggtimer displays

I've had a problem with the old girl recently - our SCCM 2007 environment had been chugging along nicely until a few weeks ago.

We have approx. 500 collections with update schedules running pretty evenly throughout the day.  As I'm sure you will agree the annoyance of the the old Update Collection Membership and then refresh the console is a blight on our day - but when that little red eggtimer WILL NOT DISAPPEAR it sends my SCCM OCD twitching and I just cannot carry on with my day until I've sorted it...

 

I've done a fair bit of Googling and not really found that many comprehensive solutions to this other than those that point to the Microsoft KB982400.  I was checking the Colleval.log and kept seeing Checking collection: 0x18, EvaluationCRCChanged=FALSE, ScheduleCRCChanged=FALSE, AwaitingRefresh=TRUE - which is fine, yes it's awaiting a refresh - SO REFRESH ALREADY!!!!

The D:\PROGRAM FILES\MICROSOFT CONFIGURATION MANAGER\inboxes\COLLEVAL.box seemed fine and the BADRELP and RETRY folders were empty - so what was causing this???

Finally I spotted a few references to AV related issues (which I suspected were responsible for another issue I have with slow PXE boots).  Sure enough, when I killed off all the Trend related services from Windows Task Manager and did another update and refresh of the collection - IT WORKED!!

Trend Services Running on the SCCM Server

I've since added an exception to Trend File scanning for the PROGRAM FILES\MICROSOFT CONFIGURATION MANAGER\inboxes folder and I've noticed a considerable improvement - I'll post back after a week or so to let you know how it's going.

Hope this helps someone else...

DocN

***UPDATE***

It seems the actual problem here was down to the sheer volume of collections running updates.  There was a cumulative effect of the schedules and come 1pm the collection action list was backed up with about 3 hours of updates pending.

I've gone through and removed all update schedules from our collections (yes - it was a lengthy monotonous task) and all is well.