Endpoint Protection Log locations

Posted: March 4, 2014 in Configuration Manager, Information, System Center, Windows Update
Tags: , , , ,

Another “reminder where stuff is” post. This time for the Endpoint Protection logs. These should be the same for pretty much any version as far as I know, but I’m looking specifically at System Centre Endpoint Protection (SCEP) included as part of Config Manager 2012.

Log locations:

  • %allusersprofile%\Microsoft\Microsoft Antimalware\Support—Log files specific for the antimalware service
  • %allusersprofile%\Microsoft\Microsoft Security Client\Support—Log files specific for the SCEP client software
  • %windir%\WindowsUpdate.log—Windows Update log files, which include information about definition updates
  • %windir%\CCM\Logs\EndpointProtectionagent.log – Shows Endpoint version and policies applied
  • %windir%\temp\MpCmdRun.log – Activity when performing scans and signature updates
  • %windir%\temp\MpSigStub.log – Update progress for signature and Engine updates

References:

http://technet.microsoft.com/en-us/library/gg477022.aspx

Advertisements
Comments
  1. Mikw says:

    thanks for the details.
    you just got a typo in the name of the file McCmdRun.log – it should be MpCmdRun.log instead

  2. Mark says:

    I’ve been looking forever for these logs, thank you.

  3. Darren says:

    thanks Legend. You rock!

  4. Paul C says:

    I have also found (on SCCM 2012R2) that the msmpeng process is hooking into the IIS log files, default location c:\inetpub\logs\LogFiles\W3SVC1\u_ex[yymmdd].log – even if you switch off IIS logging. I’m still trying to work out how to move this since it fills the C: drive over time.

    • Scott says:

      That’s not an issue I’ve seen it encountered before. As far as I am aware there is no “hook” or connection into IIS at all. Changing the location of the IIS log files has never been an issue for me, but perhaps you can try adding the log path as an exclusion?

      • Paul C says:

        I did resolve it, and the answer was pretty simple.
        Although I had disabled of IIS logging, EP was using the IIS log file location setting. To change it I had to re-enable logging logging, change the IIS log file path to a different drive, then disable it. As soon as I made the change EP picked it up and started logging to the new location.

        • Scott says:

          I still think they’re is something else going on. EP has no connection to IIS or its logs. Do you have done other product or extension installed? I can’t see any similar thing happening in any of my servers that I’ve looked at.

        • Paul C says:

          We have a very vanilla SCCM install – we haven’t even added the Servicing Extension or MDT

        • Scott says:

          I don’t know what the Servicing Extension is you refer to, but MDT wouldn’t have any bearing on this either. I’m also running a “very vanilla” ConfigMgr environment, although of several thousand servers, but I haven’t seen a similar issue to what you describe so I don’t think I can’t relate to what your issue is.

  5. KumarG says:

    For every custom scan using MpCmdRun.exe -Scan -ScanType 3 -File
    sometimes log file is updated and sometimes not. How to get specific log details for every scan.

    • Scott says:

      I don’t have an answer for that. If the log file isn’t updated then that may be a bug you could report to Microsoft.

      • KumarG says:

        Thanks,
        Apart from %windir%\temp\MpCmdRun.log and “C:\ProgramData\Microsoft\Microsoft Antimalware\Support\MPLog-11222015-143957.log”, is there any other log files which is being updated when MpCmdRun.exe is executed.

  6. Phil W says:

    Just to add for anyone that comes cross this, with Endpoint Protection in SCCM logs on the client for scheduled definition updates actually run as the NetworkService account C:\Windows\Temp\MPCMDRUN.log and MPSIGSTUB.log don’t show much or anything. You need to check C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\ for MPCMDRUN.log and MPSIGSTUB.log

    • Scott says:

      Thanks for that tip, I’ll definately check it out. I get regular issues with some clients refusing to update defs, and the SCEP logs are a total pain to follow to work out what the problem might be.

      • Phil W says:

        It certainly doesn’t seem to be straight forward.

        My policy is currently set to only use MMPC as a definition source. MPCMDRUN in C:\Windows\Temp\ shows signature update being run at the interval set in the policy but no results are output whether an update occurs or not.
        MPCMDRUN in the NetworkService folder I mentioned above also updates at the set interval but regularly says no updates required and doesn’t seem to search the HTTP path for the update, even when new definitions are available from MMPC.
        Several cycles of this later it may eventually download new definitions.
        No errors seem to be occuring, it’s just like the definition update process isn’t bothering to actually check for updates on some cycles.
        Sometimes MPCMDRUN will show it searching the HTTP path for MMPC and downloads and installs updates but then finishes with “Update completed succesfully . no updates needed (hr:0x00000001)” which just makes things even less clear has it updated or not?

        Microsoft could really do with making these logs a lot more readable, as well as only having them in one place! It’s also massively over complicated to have 5 possible choices of definition update source in my opinion.

        • Scott says:

          And updating through ConfigMgr is slightly different again as there are interactions seen in logs in the CCM folder. It really doesn’t seem like SCEP was ever properly integrated into ConfigMgr at all and still has a lot left over from its very early FEP days.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s