I have been tracking down two related problems in our event log which have been appearing with some regularity over the last few weeks:

• Error 12014 on MSExchangeTransport
• Warning 12015 on MSExchangeTransport

As they have been referring largely to our test Microsoft Office SharePoint (MOSS) environment I haven’t been too worried about them but it was time to try and get them resolved.

The first problem is Error Event ID 12014 which says “Microsoft Exchange couldn’t find a certificate that contains the domain name host.domain.com  in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector HOST with a FQDN parameter of host.domain.com.“

This could be quite a major problem if it wasn’t referring to our test environment and there is quite a bit more text in the actual event telling me that I should really make an effort to locate this certificate and enable it upon the Exchange Server.

The error often seems to be accompanied with a Warning Event ID 12015 which states “An internal transport certificate expired.” – it is probably the combination of the two problems that has caught my eye.

This second event is pointing to a problem between our Exchange Server 2007 and our MOSS test environment. Bizarrely, whilst typing out the information for this post I noticed the domain name was slightly misspelled – I hadn’t noticed this before, so a simple creation of a new internal certificate and a removal of the offending one seems to be the solution to fix the problem – however a new problem appeared in the event log as Warning Event ID 12023 saying “Microsoft Exchange could not load the certificate with thumbprint of XXX from the personal store on the local computer. This certificate was configured for authentication with other Exchange servers”.

My first step was to analyse the send and receive connectors to try and identify the source of the problem. To do this I ran the commands from the Exchange command shell:

• get-receiveconnector |fl name,fqdn
• get-sendconnector | fl name,fqdn

Sure enough, the send connector showed the problem as a misspelled domain name – I could then track down it down further in Exchange, Hub Transport, Send Connectors the MOSS connector and  enough the FQDN was specified incorrectly – as expected. After correcting this I created a new self-signed certificate using the Exchange console command

• New-ExchangeCertificate –DomainName “host.domain.com”, “host”, –services “SMTP”

This was checked with Get-ExchangeCertificate which showed it associated with the SMTP transport. Shortly after I was treated to a new Informational Event ID 16002 stating “The new transport server configuration has been read and components have been notified.”

The trouble is when you start really looking through the event logs you start noticing other little problem that need addressing – not all of these are clearly indicated as Warning and Error events – sometimes they can be lurking as Information events.

For more information about adding and importing certificates see http://technet.microsoft.com/en-us/library/aa998840.aspx.