I pinged development about it as killing McpService.exe seems to just start back up because its governed by the McAfee Management Service (MMS).
I found that its possible to query the MMS for service status and start services but not stop them:
"C:\Program Files\Common Files\McAfee\SystemCore\mmsinfo.exe" -enum
"C:\Program Files\Common Files\McAfee\SystemCore\mmsinfo.exe" -query mfemcp
"C:\Program Files\Common Files\McAfee\SystemCore\mmsinfo.exe" -start mfemcp
"C:\Program Files\Common Files\McAfee\SystemCore\mmsinfo.exe" -stop mfemcp <--- command doesnt exist
Outside of that, you could drop a MCP policy on the machine which includes a non-existent proxy, but that seems less than ideal.
I'll let you know what I hear back.
thanks for the input. Hmmm, this is really a problem.
Szenario: A C-Level employee is not connected to the companies network, The location has another timezone. Now, if there is a problem with any kind of software which is not capable to connect through a proxy or there is a problem with the proxy ruleset we have no change to disable MCP. A short example: Teamviewer does not connect if MCP only is installed. Teamviewer must be configured using a proxy, otherwise it does not use HTTP(S).
With the previous version the employee was able to stop the service and enables it afterwards again.
For me there is one important PER.
Understood, I figured as much about your scenario. In your case, Access protection is disabled (otherwise stopping the service wouldnt work), right?
As far as ENS integration, MCP 2.3 was the first step in getting the two to work with each other. Thank you for the PER idea.
Maybe you can try something like this in the MCP configuration:
- You redirect only if outside the corporate network
- You test the "corporate connection" via something that is always true
So basically MCP is never enabled.
You create the policy on the ePO server, export the client OPG file, put it in C:\ProgramData\McAfee\MCP\Policy\Temp, and it will be automatically loaded on the client.
thanks for the input. So, i know how to manage MCP.
BUT, this does not solve the problem if MCP redirects the traffic to a proxy and there is a wrong Ruleset which blocks necessary HTTP(S) traffic.
With non ESP integrated MCP installations there is a serive available which can be stopped. With ESP integration there is no service available any more.
In a case like described above no one can help the user.
Well, I guess I must have understood wrong then, as in your scenario I would have sent the OPG file via email and the folder location in which the user has to put it to disable MCP.
If your users only have webmails and a proxy rule blocking the access, then you can send it to another computer and use a USB key to put the OPG file on the folder.
What would not work?
I totally agree, but I do know that my users will not be able to wait for the release
I just posted a workaround in case a user is indeed stuck and need a release.
Download the new ePolicy Orchestrator (ePO) Support Center Extension which simplifies ePO management and provides support resources directly in the console. Learn more about ePO Support Center