Tons of Failure Audits by Microsoft.Exchange.Monitoring.exe

Status
Not open for further replies.
M

MGLDK

Hi,

We have an Exchange 2010 installation consisting of four servers. Two CAS/HUB servers and two MBX servers.

In the Security Logs of the CAS/HUB servers, I see many Failure Audits caused by Microsoft.Exchange.Monitoring.exe. The events look like this:

An account failed to log on.

Subject:
Security ID: SYSTEM
Account Name: <SERVER>$
Account Domain: <DOMAIN>
Logon ID: 0x3e7

Logon Type: 3

Account For Which Logon Failed:
Security ID: NULL SID
Account Name:
Account Domain:

Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc0000064

Process Information:
Caller Process ID: 0xc68
Caller Process Name: C:\Program Files\Microsoft\Exchange Server\V14\Bin\Microsoft.Exchange.Monitoring.exe

Network Information:
Workstation Name: <SERVER>
Source Network Address: -
Source Port: -

Detailed Authentication Information:
Logon Process: C
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

The Exchange servers are being monitored by SCOM 2007 R2.

Why am I seeing all these failures and what could be wrong?

Thanks in advance!

/Michael
 
B

busbar

can you make sure that you have configured the SCOM action account to use specific account not local system, also make sure that action account has the correct username and password and not locked outRegards, Mahmoud Magdy Watch Arabic Level 300 Videos about Exchange 2010 here: http://vimeo.com/user3271816 Read pretty advanced Exchange stuff I and other MVPs post here: http://www.enowconsulting.com/ese/blog.asp Or follow my blog: http://busbar.blogspot.com or our corp blog: http://ingazat.wordpress.com and if you Liked my post please mark it as helpful and accept it as an asnwer
 
M

MGLDK

Hi,

Thank you for replying.

I don't have access to the SCOM environment as I am an external consultant hired for the Exchange-implementation.

I just need to be 'sure', that SCOM could be causing these events before I 'blame' the SCOM-guys for the errors.

/Michael
 
B

busbar

M

MGLDK

I don't see any related errors in the OpsMgr log.

I deployed Exchange and " everything" looked fine when I left it (about 2 months ago). Unfortunately, the Security log only goes back to the 18th of may because of all the events so I can't be 100% sure, that it started with the install of OpsMgr (april 28).

/Michael
 
B

busbar

M

MGLDK

Yes, it does run as Local System.

I will talk to the SCOM guys to make them have a look.

Thanks.
 
Status
Not open for further replies.
Top