Silent uninstall of password protected TrendMicro antivirus

Ever tried to silently uninstall the TrendMicro AntiVirus client when it’s password protected? You probably could not find a suitable, free and total solution for your situation. It happened to me a while ago and I would like to share my experiences. I know it’s possible to manage the installed clients through the TrendMicro server management console, but at the company where I implemented this solution they chose not to because of the limited bandwidth to certain company locations.

 Environment description:

  • Windows 2008 R2
  • Window 7
  • SCCM 2007 R2
  • RES Workspace Manager 2011 SR2
  • App-V 4.6 SP1
  • TrendMicro v10.5+

The challenge:

Before installing the new version of the TrendMicro AV client the old client needs to be uninstalled. When I tried uninstalling the client with “msiexec.exe /x{guid} /qn /norestart” I noticed that the the uninstallation failed. At that point I discovered that the uninstallation required a password. The uninstall will be a part of a SCCM 2007 “Task Sequence” which  will contain multiple software updates and contains one reboot at the end.

Requirements:

  • Workarround for the Password protection
  • No Reboot until planned reboot
  • Silent Uninstall

Solution:

Searching the internet for a solution I didn’t find any working method to bypass the password protection and/or silently uninstalling the AV client. It seemed that the only solution was to manage the clients through the TrendMicro AV Management Console. Like mentioned earlier this was not an option. I needed to look for another solution. After some searching I came across the AUTOPCC.ini file on the TrendMicro management Server: AUTOPCC.ini located in:

“X:\Program Files (x86)\Trend Micro\OfficeScan\PCCSRV\Autopcc.cfg”

Here I found the values -991334* (no password) and -0442* (silent uninstall).
I discovered that these parameters worked in combination with “ntrmv.exe” which is located in the following location on the client side:

“C:\program Files\Trend Micro\OfficeScan Client\”

(*) I’ve recently changed these parameters for security reasons, if your not able to find these parameters on the location I mentioned. You are probably not authorized to uninstall the TrendMicro AV

By using these parameters in combination with “ntrmv.exe” the uninstall ignores the password protection and uninstalls the TrendMicro client silently without rebooting.

I created a script for the uninstall. In this script I prevented that the installation of the new client would start before the uninstall of the old client is completed. To achieve this I added a check in the script. It will check if the “ntrmv.exe” process is still running, if so it will keep on checking untill the process has stopped. Than the script will finish.  Underneath the code of the vbs script I created.

Underneath a version which will check if it’s a x86 or x64 installation;

After the uninstall I checked if there was anything left behind. As well as the installation folder as the TrendMicro registry-tree were completly deleted during the uninstall.

If you’ve got any comments or questions please post them below if not I hope this information was useful for you.

Windows 7 and error "Could not connect to the System Event Notification Service"

At the moment I work at a company with about 8000 to 9000 workstations. A couple of users called in an issue that they had trouble logging in into Windows 7. Once in a while they got the following error message during the logon process.

“Windows could not connect to the Event Notification Service service. Please consult your System Administrator”

 

Only one or more reboot(s) seemed to bypass the error. This was not an acceptable situation and I was asked to look into this problem.

Environment description:

  • Windows 2008 R2
  • Window 7
  • SCCM 2007 R2
  • RES Workspace Manager 2011
  • App-V 4.6 SP1

Underneath a screenshot of the error message:

System-Event-Notification-Service

After checking the event viewer I noticed that not only the “System Event Notification Service” was failing but also several other services failed to start. Underneath a list of services that are involved.

  • Certificate Propagation
  • Extensible Authentication Protocol
  • Group Policy Client
  • IKE and AuthIP IPsec Keying Modules
  • IP Helper
  • Server
  • Multimedia Class Scheduler
  • User Profile Service
  • Task Scheduler
  • System Event Notification Service
  • Shell Hardware Detection
  • Themes
  • Windows Management Instrumentation

With the knowledge that not only the “System Event Notification Service” service was failing to start I searched the web for a solution. I found several articles but they didn’t solve my problem. Than I stumbled onto the following Hotfix:

http://support.microsoft.com/kb/2590550/en-us?fr=1

This hotfix solved my problem. But in the meanwhile several users were still experiencing this problem. Due a backlog on the change management side, it would take a while to get this hotfix in production. I decided to look for a workaround for the customers who were experiencing this problem more frequently.  It seemed, like described in the article, that the “Microsoft Virtualization client” had something to do with it. I quote:

Cause: This issue occurs when a new drive is added to the system while background services are still starting.  The most common example of this is with Microsoft Application Virtualization Client.  When this service starts, it creates a virtual drive.  When this drive is created during system startup, the Server service may crash the shared service host process.  This process contains other services which are important for completing user logins.  When these services fail at startup, a blue or black background image is displayed instead of the user’s desktop.

When trying to find a workaround I found that delaying the startup of the “Microsoft Virtualization Client” service seemed to work. This should give the other services time to start-up. It’s a quick and dirty method but it did solve the problem for the users who were experiencing this problem on a frequent base. We decided to use it as a temporally workaround until the hotfix was applied.

The hotfix is also applicable for Windows Server 2008 R2 in case you are experiencing the same issues on a server.

Greetings,

SCCM 2007 R2 Error unregistering notification query CcmExec

Not to long ago we had some issues (re)deploying Windows 7 (including the baseline) on our client systems.  One out of three systems failed during (re)deployment.  At first we thought it was because the systems were not removed correctly from SCCM before redeployment. Further investigation told us that the deployment also failed on new systems and systems which were correctly removed from SCCM before redeployment.

Environment description:

  • Windows 2008 R2
  • Window 7
  • SCCM 2007 R2
  • RES Workspace Manager 2011
  • App-V 4.6 SP1

Description:

CcmExec.log logged the following:

“Error unregistering notification query CcmExec“ occurs after a restart initiated by the installation of the App-V client. It seems that CcmExec (SMS Agent Host  service) is having trouble to start. After a while it times out and the (re)deployment fails. The restart which is needed after the installation of the App-V client is the first restart initiated by an application after the windows installation. It could be possible that this error also occurs after other installations where a reboot is needed. Unfortunately we haven’t run tests on this, we only have one installation which needs a reboot during this phase.

Solution:

By delaying the auto startup of the CcmExec service we solved the (re)deployment issues in this case. The CcmExec service will start after all other services who are configured as “Automatic” startup. Normally this is used to shorten the boot time but in this case it also helps us preventing (re)deployment failures. Right before the installation of the App-V client we added a “Run command line” to the task sequence as follows.

Type: Run Command Line
Name:  Delay startup CCMexec service
Description: Delay CCMexec (SMS Host Agent) service
Command line:

Before the last action of our task sequence will take place, in our case a last reboot to complete the deployment, we added the following “Run Command Line”.

Type: Run Command Line
Name:  Automatic startup CCMexec service
Description: Sets CCMexec (SMS Host Agent) service on automatic start without delay
Command line:

This was our solution for the (re)deployment problem we encountered and hopefully it will help some of you who experience the same problems. If you have any comment or questions you can post them down below in the comment section.

Greetings,

Marco Nuijens