Hi,

i need assistance in trying to resolve an ID 1035 event on a fresh install of Exchange 2013 CU7

Inbound authentication failed with error LogonDenied for Receive connector Default SERVERNAME. The authentication mechanism is Login. The source IP address of the client who tried to authenticate to Microsoft Exchange is [127.0.0.1].

This event is logged every 15 minutes, and appeared the first time after setting up the send connector and external addresses / virtual directories. There are currently no clients connecting to the server.

I'Ve spend hours in digging through Technet and other ressources. This seem to be a very common issue, unfortunately no solution could fix it with me. Some of te suggestions were: Add anonymous access to connector (did not work), too much receive connectors, delete some (huh? Without loosing functionality), mixed up ports in hub transport when client access role and post office role is installed on the same server (which is, but there seem to be any faults with the ports. Also no additional revceive connectors were installed, just the default ones).

Best hint ever was "Just ignore it, thats the price you've to pay when using unfinished software". However, I want my log to be clean. So I would appreciate any help in getting rid of this warning.

Best regards
Holger

Edit: I forgot to mention that, after the same configuration step, lots of health sets became unhealthy. Meanwhile I've found HealthMailbox[...]@domain.com producing Kerberos Error 0x6 KDC_ERR_C_PRINCIPAL_UNKNOWN. Maybe this is all related.

• Edited by Holger Keil Tuesday, February 03, 2015 10:48 AM

Anybody? This warnings are really getting annoying. It turns out that this seems to be really some authorization issue. I guess, the reason for that ID 1035 warning is this kerberos error message.

A Kerberos Error Message was received:
On logon session: HealthMailbox3864a7ff935943dc8ef2336910f9215a@contoso.com
Client time:
Server time: 12:9:55.0000 2/9/2015 Z
Error Code: 0x6 KDC_ERR_C_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: CONTOSOLAN.LOC
Server Name: krbtgt/CONTOSOLAN.LOC
Target Name: krbtgt/CONTOSOLAN.LOC@CONTOSOLAN.LOC
Error Text:
File: e
Line: d3f
Error Data is in record data.

And yes, this seems to be also the reason for all the unhealthy probes. In the ProbeResults event log, I find tons of this and similar stuff:

Probe result (Name=AutodiscoverSelfTestProbe/MSExchangeAutoDiscoverAppPool)
Error System.ApplicationException: monitoring mailbox HealthMailbox7d8ffd6c56a24158828ccd34fcbcc54b@contoso.com logon failed, SecurityStatus=LogonDenied [...]

All those other "unhealthy" probes appear in a similar way in the ProbeResults log. Either "Logon failed" or "Logon denied" or"(401) Unauthorized".

So for some reason, the health system is not allowed to probe it's own server. But why? And how could I resolve this?

It would be really nice if some of you experts have any helpful hint for me.

Best regards
Holger

• Edited by Holger Keil Tuesday, February 10, 2015 3:34 PM typo

PUSH!

This all happened after a clean install of Exch2013CU7 on W2012R2 following strictly the M$ post installation tasks. You can|t be telling me that I|m the only one having these problems...!

Looking at what you have posted I see some indication that your domain may be .loc and your health mailboxes may be created with .com addresses. I ran into some issues with something similar where my users have a .org email address and the domain is .local. The result was that my email address policy caused all of the service mailboxes to be created with .org addresses. It appeared to me that some of mine worked that way and some did not. You can see some discussion in my thread about it https://social.technet.microsoft.com/Forums/office/en-US/2de87b3f-52e4-4c1c-8f18-421f948d41c3/seemingly-successful-install-of-exchange-2013-sp1-turns-into-many-errors-in-event-logs-after-upgrade?forum=exchangesvrdeploy#bf6dcc99-9cd8-4f72-9cd5-2c17389e2a3f

You can recreate the system mailboxes easily enough just make sure you have the correct email address policy applied to the container (or as default) when they are created.  I would start with just the health mailboxes since that seems to be what you are having issues with.  http://byronwright.blogspot.com/2013/07/exchange-2013-corrupted-health-mailboxes.html

Other system mailboxes need a little more work to recreate but these instructions for Exchange 2010 work in Exchange 2013 http://social.technet.microsoft.com/wiki/contents/articles/6874.how-to-recreate-system-mailbox-federatedemail-discoverysearchmailbox-in-exchange-2010.aspx

For my environment since my server was not in production I simply reinstalled exchange from scratch after fixing my email address policy issues so that all of my system mailboxes were created with .local accounts.

Looking at what you have posted I see some indication that your domain may be .loc and your health mailboxes may be created with .com addresses. I ran into some issues with something similar where my users have a .org email address and the domain is .local. The result was that my email address policy caused all of the service mailboxes to be created with .org addresses. It appeared to me that some of mine worked that way and some did not. You can see some discussion in my thread about it https://social.technet.microsoft.com/Forums/office/en-US/2de87b3f-52e4-4c1c-8f18-421f948d41c3/seemingly-successful-install-of-exchange-2013-sp1-turns-into-many-errors-in-event-logs-after-upgrade?forum=exchangesvrdeploy#bf6dcc99-9cd8-4f72-9cd5-2c17389e2a3f

You can recreate the system mailboxes easily enough just make sure you have the correct email address policy applied to the container (or as default) when they are created.  I would start with just the health mailboxes since that seems to be what you are having issues with.  http://byronwright.blogspot.com/2013/07/exchange-2013-corrupted-health-mailboxes.html

Other system mailboxes need a little more work to recreate but these instructions for Exchange 2010 work in Exchange 2013 http://social.technet.microsoft.com/wiki/contents/articles/6874.how-to-recreate-system-mailbox-federatedemail-discoverysearchmailbox-in-exchange-2010.aspx

For my environment since my server was not in production I simply reinstalled exchange from scratch after fixing my email address policy issues so that all of my system mailboxes were created with .local accounts.

• Marked as answer by Holger Keil 10 hours 57 minutes ago

Looking at what you have posted I see some indication that your domain may be .loc and your health mailboxes may be created with .com addresses. I ran into some issues with something similar where my users have a .org email address and the domain is .local. The result was that my email address policy caused all of the service mailboxes to be created with .org addresses. It appeared to me that some of mine worked that way and some did not. You can see some discussion in my thread about it https://social.technet.microsoft.com/Forums/office/en-US/2de87b3f-52e4-4c1c-8f18-421f948d41c3/seemingly-successful-install-of-exchange-2013-sp1-turns-into-many-errors-in-event-logs-after-upgrade?forum=exchangesvrdeploy#bf6dcc99-9cd8-4f72-9cd5-2c17389e2a3f

You can recreate the system mailboxes easily enough just make sure you have the correct email address policy applied to the container (or as default) when they are created.  I would start with just the health mailboxes since that seems to be what you are having issues with.  http://byronwright.blogspot.com/2013/07/exchange-2013-corrupted-health-mailboxes.html

Other system mailboxes need a little more work to recreate but these instructions for Exchange 2010 work in Exchange 2013 http://social.technet.microsoft.com/wiki/contents/articles/6874.how-to-recreate-system-mailbox-federatedemail-discoverysearchmailbox-in-exchange-2010.aspx

For my environment since my server was not in production I simply reinstalled exchange from scratch after fixing my email address policy issues so that all of my system mailboxes were created with .local accounts.

• Marked as answer by Holger Keil Sunday, February 22, 2015 12:54 AM

Hey MnM Show,

thanks for taking time. Exactly this was the problem. I'd just changed the policy back to .loc temporarily, deleted the health mailboxes and restarted the integration service and - tadaaa, problem gone.

I'm wondering how this could happen. I bet it's not unusual that a mail server has to deal with both, internal and external domains. The server is installed in the internal domain, while the external domain can only become set during post installation tasks - where all the trouble started (as mentioned in my op). It looks like -at least- some of the health mailboxes will become (re-)created or changed, when the external domain is set. This might be the explaination why those belonge to the .com domain while the server resides in the loc. domain.

However problem solved and once again, many thanks to you.

May I ask you another question? Since you use CU7 as well, do you also have some unresolvable events? As I'd understood, you're already stuck with those three (remaining) performance counters. What about "The setting SupportedIPMTypes in the Web.Config file was missing. Using default value of System.Collections.Generic,List`1[System.String]." or periodic "ProcessKillBit. Failed to read killbit list file because of exception System.IO.IOException: The process cannot access the file 'C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\owa\prem\15.0.995.29\ext\killbit\killbit.xml' because it is being used by another process." There are several more where I can only find questions without or with no working answers...

Best regards,
Holger