Thursday, 20 February 2014

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.


net stop tmlisten
net stop ntrtscan


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

Tuesday, 4 February 2014

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

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"
Microsoft Knowledgebase Article: This articles lists a set of potential causes, however the most common reason (SUBSYSTEM "windows") is not listed there.

Thanks to Falko at for the above.

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