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.


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


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.

How to Launch Vapplauncher with Parameters using powershell

Hello everybody,

At the moment I am working in an environment where App-V is integrated in SCCM 2007. To launch an App-V application the “Vapplauncher” is used. This week I have been asked to package an application with the following requirements.



The application must be able to start from a Scheduled Task and External Application.

  • The application must start with different parameters.
  • The parameters can change every month and this should be done by the “Super user” (Which has no access to App-V / SCCM)

Starting the App-V application from a schedule or external application is just pasting the Vapplauncher command line into it. However, the Vapplauncher doesn’t accept any parameters. This is why you have to create a extra OSD with the parameters in it. This means that the “Super user” has to change this OSD each month and deploy it through SCCM. Of course this was not an option because of the rights.

The challenge:

  • Start the application with the parameters through: C:\WINDOWS\system32\CCM\VAppLauncher.exe /launch “MyApp”
  • The user must be able to change the parameters each month without having to change the OSD or having special rights.


  • Create a networkshare where the user has enough rights to change/write files
  • Place a *.txt file in the share containing the parameters
  • Create a PowerShell script (or more if needed) in the share which can do the following:
  1. Get the content of the *.txt file
  2. Start the application with the parameters found in the *.txt file which is edited by the user
  • Create an OSD to start the PowerShell script
  • Give the user the command line to start the OSD so it can be used in a schedule or External application

Components of the solution:

Networkshare: G:\MyApp\Test\
*.txt file for user: G:\MyApp\Test\MyApp_parameters.txt
PowerShell script: G:\Myapp\test\Script\Start_Myapp.ps1
App-V package: With at least one OSD that starts the application with the powershell script

The powershell script:

These are the basics of the script. Of course you should adept it to your needs with logging and checking on existing files etc. But now you will have a start.

This is the starting line you should use in the OSD:

The command line to start the application is:

Thank you for reading. I hope it will be useful for you. If you have any comments or questions you can use the comments underneath or the PM system to ask questions.


Joey Steenstra

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


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.


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.


Marco Nuijens