Piszki Lab | EN

My case study in the clouds…

Deep Security: Removing orphaned Agent

| 3 Comments

Motto: When Agent loses contact with the Base, it should be eliminated Smile

In view of recent updates of the Trend Micro Deep Security, I had to carry out mass action raising agents to the new version. During this operation, the amazement I found that one of the virtual machines operating in a strange mode of suspension. Lost the protection afforded by DSVA and Agent “hangs” with the message “Activation delayed” (infinity). Migrating to another host did not gave, as to reinstall VMware Tools. Very disturbing is the fact that the state did not generate any alerts!

agent3

Of course uninstalling activated Agent is not such a simple thing. Software asset records defends itself against manipulation (removal or modification of this application is prohibited by its security settings), you can not just turn off the service, “Trend Micro Deep Security Agent”. If, however, we can safely restart the machine it is best to move the service to “disabled” and reboot.

agent1

Otherwise, we need to kill the following three processes:

coreServicesShell.exe

coreFrameworkHost.exe

ds_agent.exe

When we have excluded Agent processes, should  in the Windows registry, in the key:

HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro\Deep Security Agent

Set the parameter “Self Protect” from one to zero.

agent4

At this point we can safely uninstall the Agent. Before you execute the steps, you should make sure that the machine operates vShield Driver. Just (as far as Windows) to run msinfo32.exe:

agent10

At this point we can install a new version of the agent.

In the case described by me, even comb the Internet and Trend Micro web support, I failed to make the DSM saw again the said machine (her condition was fixed for him). Fail over to each activation new installed agent. Ultimately, the matter reported to technical support. Support for Trend Micro have generally boast demonstrated considerable commitment to the issue. Ultimately, the matter could be resolved, as always, in a little accident. The problem probably lay in the DSM, we patched system, and then reboot the server. After the restart, DSM finally refreshed ourselves about the failed machine and the whole moved forward.

As you can see, the methods straight from Windows 95 still work, reboot is good for all Smile

At end, I give a link. It is the most complete study on the safety on VMware what I got. Quite different than the normal documentation or blog posts, this is a thesis, so the full scientific methodology. Really worth reading.

Source

Rate this article:
[Total: 2 Average: 4.5]

Author: Piotr Pisz

Computer always, since I got a Commodore 64 at the end of primary school, through his beloved Amiga and Linux infinite number of consoles, until today, fully virtual day. Since 2001, Unix/Linux Systems Administrator, for seven years a faithful companion and protector of Solaris system, until his sad end. In the year 2011 came in the depths of virtualization, then smoothly ascended into the clouds and continues there today. Professionally working as Systems Architect in the Polish Security Printing Works.

3 Comments

Leave a Reply

Required fields are marked *.


.

Enjoyed the post? Support Piszki Lab | EN, click on the AD! :-)

.