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!!!!!!!! ;)

AppV Application Slow to open

I've recently sequenced a Pathology application that we use in the NHS that uses a Terminal Emulator to retrieve bloods direct from the Lab.

I had managed to sequence it fine but the package was taking an age to load up and sometimes timing out completely.

After looking at the SFTLOG (C:\ProgramData\Microsoft\Application Virtualization Client) I noticed an error: 4636126-0B01FD04-0000041E

As per AppV error format:

App-V Error 04-0000041E

Event:
Starting/Running the application
Error Message / Symptoms:
It took to long until the application was ready for interaction with the users.
The application shuts down after about 5 minutes
Potential Causes:
The application is a Java or DOS like application. App-V can not determine that the application is ready for User Input, because the app does not use default Windows Classes.
Potential Solutions:
In the OSD file, SUBSYSTEM VALUE has to be changed from "windows" to "console" (case sensitive).
If it is an 16-bit application, also the VM VALUE should be set from "Win32" to "Win16"
References:
Microsoft Knowledgebase Article: http://support.microsoft.com/kb/931112. This articles lists a set of potential causes, however the most common reason (SUBSYSTEM "windows") is not listed there.

Thanks to Falko at  Kirx.org for the above.

Once I'd made these changes I updated the package and viola, Bob's your aunties live-in lover!