Exchange 2013

Assign an SSL Certificate to Services in Exchange Server 2013

Switching Exchange 2013 over to a public accessible address requires a valid FQDN and a valid SSL Certificate. After installing the certificate on the server we need to find our way to the Exchange Administration Center. Once here do the following:

  • Select Servers, then Certificates
  • Choose the valid Certificate you plan to use and Click edit (double click seems to work also)
  • Select the services to be used by the Certificate – SMTP, IMAP, POP, IIS
  • After making your selection click Save

You will get a warning about the existence of the previous certificate, click Yes.

Now you should be able to test your Outlook Web App by going to the https:// address of your site

Exchange 2013 – Unable to access ECP

After a successful install of Exchange 2013 came time to move services from Exchange 2010 over to the new server. I was able to do all of this via the new management interface under ECP without issue.

After a lengthily testing all seemed to be working when I noticed I was no longer able to access the ECP. What I noticed was I was not entering the Exchange Admin Center at all and was being redirected out to the Outlook Web App.

Questioning the idea was there any other way to access this, I found none. I searched far and wide with no results. The question I kept asking myself; Where was your mistake?

I decided that this may have been caused by bindings and that I should keep my external URL different than that of my Internal one. And that took me to loading up the Exchange Management Shell.

I used the following commands to configure the ECP virtual directory back to what it was originally for the Internal Interface:

Get-EcpVirtualDirectory -Server EX1 | Set-EcpVirtualdirectory -InternalUrl “https://ex1.jermsmit.local/ecp”

At this point you are notified that you must match the OWA’s InternalURL to that of the ECP’s, so I ran the following:

Get-OwaVirtualDirectory -Server EX1 | Set-OwaVirtualdirectory -InternalUrl “https://ex1.jermsmit.local/owa”

I then rebooted the Exchange 2013 server and when I returned I could access the Admin Center without issue, both internally and on the external side.

Exchange Server 2013 RTM Cumulative Update 2

Have you recently installed Exchange 2013, to later need to install CU1 to support down level servers such as Exchange 2010. Guess what?

Cumulative Update 2 (RTM) for Exchange Server 2013 has been released to the wild. In this update we expect to have resolutions to issues that were found in Exchange Server 2013 CU1 since the software was released.  Hmmm, DNS issues, and various of other bugs perhaps?

I will be downloading from here: to introduce to my Exchange 2013 Server.

For more info check out the following TechNet Blog Post:


Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.”

In my previous post I was banging my head over an Exchange 2013 issue. I was able to finally resolve it. And it took some steps to do so…

451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.”

After an Exchange 2013 Install I found myself having issues with sending emails between two Exchange Servers; 2010 and 2013. The messages on both server seem to be stuck in the mail Queue.

Full message reads: 451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.” Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.

This issue existed because the Exchange servers could not authenticate with one another. This type of authentication is required for Exchange to route email internally. The respective servers use the X-EXPS command to authenticate. This error will happen when servers don’t have this method of authentication enabled.

In my case this wasn’t true, however there was another issue preventing the X-EXPS command from being passed and that was our Cisco security appliance/router. In fact the Extended SMTP verbs X-ANONYMOUSTLS, X-EXPS, and GSSAPI must be able to pass. I will get to this a bit later…

In my adventure to troubleshoot this issue the following was done (thank you Microsoft for providing details. While useful did not directly solve the overall issue. These steps are below


Step 1 – Enable Exchange Authentication on Receive Connectors

For Microsoft Exchange Server 2013 remote servers:

  1. Go to the following website to access the Exchange Administration Center (EAC):


  1. Sign in to the ECA by using the administrator account.
  2. Click mail flow.
  3. Click receive connectors.
  4. In the Select server box, select the remote Exchange server that the email message should be sent to.Note To determine the correct Exchange server, review the send protocol logs from the server that the email message is stuck in.
  5. Select the receive connector and then click Edit.Note Typically, the receive connector is the Default server_name receive connector for the remote Exchange server
  6. Click security, under Authentication, make sure that Exchange Server Authentication check box is selected.

For Microsoft Exchange Server 2007 or 2010 remote servers:

  1. Start Exchange Management Console.
  2. Expand Server Configuration and then click Hub Transport.
  3. Click the Receive Connectors tab.
  4. Locate the remote Exchange server receive connector that the e-mail message is trying to be sent to.
  5. Right-click the receive connector and then click Properties.
  6. On the Authentication tab, make sure that the Exchange Server authentication check box is selected.

For Microsoft Exchange Server 2003 remotes servers:

  1. Start Exchange System Management.
  2. Expand the Servers container.
  3. Under the problematic remote Exchange server, locate to the Protocols container.
  4. Expand the Protocols container, right-click SMTP.
  5. Right-click Default SMTP Virtual Server and then click Properties.
  6. Click the Access tab and then click Authentication.
  7. Make sure that the Integrated Windows Authentication check box is selected.

As I mentioned above this did not resolve my issue as this was already enabled, so I went onto the next step in troubleshooting the problem.


Step 2 – Event ID 12014 (MSExchangeTransport)

I had (for some time) many errors in my Application Event Log referencing the ID of 12014, where the TLS Certificate for SMTP was no longer valid. Event message below.

Log Name:      Application
Source:        MSExchangeTransport
Date:          7/3/2013 4:30:06 PM
Event ID:      12014
Task Category: TransportService
Level:         Error
Keywords:      Classic
User:          N/A


Microsoft Exchange could not find a certificate that contains the domain name in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector To Internet with a FQDN parameter of If the connector’s FQDN is not specified, the computer’s FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

To correct this issue I needed to log open the Exchange Power Shell on my Exchange 2010 server and enter the following: New-ExchangeCertificate -DomainName -services SMTP” followed by a restart of the Transport Services (I did this on both).

I tested out my change and now the event error message is gone however I am still unable to send email between the Exchange Servers.


Step 3 – Back to the basics

I later logged into each Exchange Host (2010/2013) and used telnet to connect to the respective hosts SMTP address. I got a response: 220**************************************************** but this was not the proper response for an Exchange SMTP.

Then it was apparent that a firewall was blocking the communication between one Exchange host and the other. In my case it was a Cisco ASA which has a mailguard feature turned by.  The Auth and Auth login commands (Extended Simple Mail Transfer Protocol [ESMTP] commands) are stripped by the firewall

So the logical thing was to turn it off. This was done by entering the following command:
no fixup protocol smtp 25

Once this command was issued I restarted the transport services on each host and to use an old coined phrase “You Got Mail” I was back in business.


Info Resources:


not so foreign Exchange 2013

I have been banging my head over issues with the new Exchange 2013. Install seems to go well but doesn’t seems to want to coexist with Exchange 2010. Moments aware from calling in a product support case I find Cumulative update 1 for Exchange Server 2013 (KB2816900):

It seems I now need to wait about an hour for this update to complete before I know if this fixes the issue*

* issue I am having is email routing between Exchange 2010 and Exchange 2013

More on this here