Exchange 2013: Receive connector authentication error

I recently had an issue with an application relaying e-mail via an Exchange 2013 Client Access Server. The error i was getting on the logs was:
“The account ‘Domain\AccountName’ provided valid credentials, but it does not have submit permissions on SMTP Receive connector ‘Receive Connector Name’; failing authentication”
The application was configured to authenticate with a valid username and password, on the front-end transport service of the Client Access server, which was listening on port 25.
So why was this happening? The answer is simple, the receive connector used was not allowing authenticated relay of emails.
The Client Access Server in question had several receive connectors, and how do we know which one is that specific server/application using? Well it will use the more specific receive connector, meaning that if your application server IP is and that IP is specified on the “RemoteIPRanges” attribute of the receive connector, than that is the receive connector being used, and it’s there that you need to look and see what authentication options is the receive connector advertising.
To check the Remote IP Ranges of a receive connector you can use the Exchange Admin Centre, and go to the Scoping tab on the receive connector properties.
If the IP address of your application server is not specified on any receive connector, chances are it will use the default receive connector to try and relay (or any other that accepts all IP ranges), or if your default receive connector is not allowing relay from any IP (it shouldn’t so if it is you should change it) the relay would be denied and you’re looking at a different error than the one i am blogging about today.
But back to the authentication problem. I checked which receive connector was being used, and went to check the authentication options. I verified that “Exchange Users” and not selected. Problem found! Selected Exchange users, tried again, and job done! See below my receive connector security options, for guidance:
In my case this was good enough to sort the issue. Allowing authenticated users to submit on that specific receive connector. But if you want to allow just a specific user, or make sure that a specific user can submit on a specific receive connector, you can also run the following Exchange Management Shell cmdlet:
Get-ReceiveConnector “<ConnectorName>” | Add-ADPermission -User “UserName” -ExtendedRights ms-Exch-SMTP-Submit
For more information on the cmdlet above go to:
I hope the above was helpful! As always, any questions or queries let me know.

Lync Server 2013 Cookbook – Available this January

Recently i was invited to write a chapter for a Microsoft Lync 2013 Cookbook. My contribution to the book was around the integration between Microsoft Lync and Microsoft Exchange. It was an amazing experience to participate as a co-author on this book, and the final result was excellent. The book is amazing and highly recommended both for consultants or administrators that work with Microsoft Lync and Microsoft Exchange on a daily basis. You can find it here:

It was a pleasure to work with the highly skilled Lync experts Fabrizio Volpe, Alessio Giombini, Lasse Nordvik Wedø and all the technical reviewers. It’s an experience that hopefully i will repeat soon.


Exchange 2010 DAG – Error when adding database copies [Event MSExchangeRepl ID:2059]

Recently i was adding new Exchange 2010 SP3 servers into an existing Database Availability Group, and adding database copies on those servers, to all the existing databases.

To add the database copy i ran the cmdlet:

Add-MailboxDatabaseCopy -Identity <DatabaseName> -MailboxServer <NewDagMember> -ActivationPreference 2

The copy was added and started seeding, but when it finished, it immediately went into a failed state, as shown below:


I went to the NewDagMember and the log file directory was empty, meaning that no log was seeded during the process of adding the copy. Then i went to the event viewer of the NewDagMember and found two relevant events.

Event ID 2059 – MSExchangeRepl: The required log file <file number> for <Database\Server> is missing on the active copy. If you removed the log file, please replace it. If the log file is lost, the database copy will need to be reseeded using Update-MailboxDatabaseCopy.


Event ID 117 – ExchangeStoreDB: At <Date Time> the copy of <Database Name> on this server experienced an error that requires it to be reseeded. For more details about this failure, consult the event log on the server for other storage and ExchangeStoreDB events. The passive copy has been suspended.




So in summary event ID 117 was telling me that the local copy experienced an error and had to be reseeded and event ID 2059 was telling me the cause of that error. A log was missing on the source.

To better understand why was that log missing i went to investigate the source, and found out that:

  • the database on the source never had other copies up until i added that one
  • the database on the source mounted and functional with no problems being reported from the users
  • the database was being backed up with full and incremental backups. The last backup on the database was an incremental one
  • the database on the source had thousands of log files waiting to be truncated by the next full backup

At this point i was sure on how to resolve this: I needed to truncate all those database logs. The incremental and probably also the full backups were not truncating the logs as expected and some logs were missing, so if i was able to truncate them asap it was problem solved for me.

So how do you truncate the logs on the database? You have several options:

  • A full backup (if the backup software is well configured and 100% compatible with Exchange 2010)
  • Circular logging
  • the eseutil tool to identify and remove unnecessary logs

Before telling you what option i made i would like to recommend that you read this fine article:

So what i did was, i got a small maintenance window and enabled circular logging on the databases. If you choose to do that be aware that: You need to dismount the database twice (hence the maintenance window), the database cannot have any copies when you enable the circular logging and you need to monitor the logs folder of that database as circular logging might take some time to truncate the logs.

To use the same procedure i did, do the following steps:

  1. make sure you remove the existing copy (the one that is failed and suspended) of the database, from the new DAG server
  2. Enable circular logging on the database
  3. dismount the database
  4. mount the database
  5. wait for circular logging to truncate all the logs
  6. Disable circular logging on the database
  7. dismount and mount the database for the change to apply

Please see the following for instructions on how to enable circular logging on Exchange 2010:

Once i did the procedure described above, i re-ran the Add-MailboxDatabaseCopy cmdlet and my problem was solved.

Hope that was helpful. Enjoy

Exchange HCW Error – Exchange OAuth authentication couldn’t find any accepted domains

Recently I’ve bumped into a strange issue, when setting up an Exchange Hybrid Scenario on a customer. The customer has a pure Exchange 2013 on premises, with no legacy versions of Exchange, and when you run the Exchange Hybrid configuration wizard it will try and configure OAuth authentication between the Exchange On Premises and Exchange Online. The problem I had was, when trying to configure the OAuth authentication I was getting the following error:

“Exchange OAuth authentication couldn’t find any accepted domains in your on premises organization. Verify that you’ve configured at least one on-premises accepted domain.”.


So what was the actual real impact of the error above? The answer is: Free/busy information between Exchange online users and Exchange on-premises users, on both directions, was not working? Why? Well i am going to try and keep the explanation simple and focus more on the solution. Free/busy was broken because it relies on IntraOrganizationConnectors, and the IntraOrganizationConnectors rely on OAuth authentication.

The first thing that i did was to check if my accepted domains on-premises were ok. I ran on the on-premises Exchange Management Shell:

get-accepteddomain |fl

the output showed all my on premises domains, as expected, and the * domains created by the Hybrid Wizard. So all good here.

The next step was to check the IntraorganizationConnectors. I ran both on the on-premises and online Exchange Management Shell:

get-intraorganizationconnector |fl

(More Info:

The main purpose here was to make sure that the IntraOrganizationConnector was there and enabled. I verified that i had both connectors, one on-premises and one online. Then i disabled the connector to force the Free/Busy information to be handled by the OrganizationRelationship. I ran on both Exchange Shells:

Set-IntraOrganizationConnector <Connector Name> -Enabled $false

(More Info:

You need to wait up to one hour to test the Free/busy from an online to an on-premises user. From one on-premises to one online should be almost instant, depending of course on Active Directory replication.

So did disabling the IntraOrganizationConnectors fixed the Free/Busy issue? For me it did, which means that i had the issue identified.

When i ran the Hybrid Configuration Wizard, the OAuth authentication was only partially configured, and therefore the IntraorgConnectors were not working. Disabling them or removing them sorted the issue, but that is not the ideal solution, as the goal is to use them correctly.

And what was the solution? To manually configure the OAuth authentication between my Exchange on-premises and Exchange Online. To do that follow all the steps from the link below, and you should get your problem sorted, as i got mine. Any questions or comments let me know.

I hope that the post above was helpful!