DatabaseCopyAutoActivationPolicy Setting Breaks Client Access in Exchange 2013 CU2


This issue comes fresh from a Microsoft Crit-Sit case I was just on for one of our customers.

Issue:

All client access was broken (specifically OWA) on a standalone Multi-Role Exchange 2013 CU2 Server. User’s would receive “The website cannot display the page” after authenticating to OWA. This started after the customer installed CU2.

Also, if you look in the HTTPProxy logs (C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Owa) you would see the following error:

“ServerLocatorError,POST,,,,, The database with ID 5105a9bc-cfcd-4842-baaf-451561550e08 couldn’t be found. —> Microsoft.Exchange.Data.ApplicationLogic.Cafe.MailboxServerLocatorException: The database with ID 5105a9bc-cfcd-4842-baaf-451561550e08 couldn’t be found

Full Error:
Capture

 

Resolution:

After a night’s worth of troubleshooting we escalated to Tier 3 in Microsoft Support & our resolution came from a setting I would not at all have expected. Before installing CU2 the customer had read a blog stating some maintenance steps he should perform on his Exchange Server beforehand. One of them was running “Set-MailboxServer -Identity EXServerName -DatabaseCopyAutoActivationPolicy Blocked”. This customer did not have a DAG so this command was not needed but nonetheless this command should have absolutely no ill effect on the ability of CAS to proxy requests to the mailbox server components. All this command should do is tell the DAG that no mailbox database copies can be automatically activated on this server. It would take an admin action to override this & activate the database. But again, no DAG so it should not matter.

However in this case it was causing CAS to break as it could not find the mailbox database. I was able to replicate this issue in my own lab by setting my DatabaseCopyAutoActivationPolicy to Blocked on my two Exchange 2013 CU2 Mailbox Servers (also not in a DAG so the setting “should” not matter). After making the change & restarting some services I was greeted with the very same errors when trying to login to OWA. I also received the very same “ServerLocatorError” “The database with ID <GUID> couldn’t be found”.

So the resolution in this case is to just run “Set-MailboxServer -Identity EXServerName -DatabaseCopyAutoActivationPolicy Unrestricted

I was told Microsoft Support would escalate this internally but I am currently unsure if this affects only CU2 or all Exchange 2013 builds as my lab is only 2013 CU2. I’m also unsure if this only affects multi-role servers or only servers not in a DAG but I hope to test & report the findings.

Update: I’ve been told by others that this setting has this same impact on CU1 systems.

Update#2: We tried asking MS Support to classify this as a bug so it would be fixed (also so our support bill would be compensated as is the case with all bugs). However, they would not agree to classify this as a bug. The answer from Support was “the fact that is was not easy to find is simply due to the complexity/functionality of our product”. We were told that if we wanted to push harder to classify it as a bug then we would first have to write-up a business impact statement & then it could be tested/researched internally. However, if the Product Team did not deem it a bug then we would be charged for the hours spent testing. I’m pretty disappointed in this response.

Update#3 I’ve tested & this still affects CU3 systems.

Update#4 I’ve tested & this still affects SP1 systems.

9 thoughts on “DatabaseCopyAutoActivationPolicy Setting Breaks Client Access in Exchange 2013 CU2

  1. Pingback: DatabaseCopyAutoActivationPolicy Setting Breaks Client Access in Exchange 2013 CU2 | Troubleshooting Exchange | JC's Blog-O-Gibberish

  2. Many thanks, this helped solve a problem for me. After setting up a DAG and setting the activation policy to blocked the ECP and OWA website stopped working. Changing this setting back and restarting the server fixed the issue. I can confirm this issue still exists in CU5

  3. Pingback: Troubleshooting Issues with Client Access Servers | A bit of Exchange & Office 365

  4. This is still an issue with CU5.
    I had to change the setting to Blocked because our databases kept failing over for random reasons. And every time it fails over users that access shared mailboxes would lose access to them.

    I changed it to IntrasiteOnly and fixed both issues.

  5. This is also a problem with CU6. Many hours on the phone with premier support to discover this one.

    Set-MailboxServer on Technet now reads the following……
    Blocked Databases can’t be automatically activated on the specified Mailbox server. In Exchange 2013 prior to Cumulative Update 7 (CU7), this setting stops server locator requests to the specified server, which prevents all client access to manually activated databases on the server if all DAG members are configured with a value of Blocked.

  6. Hi Andrew, just wondering if you tested the affects of disabling activation at the database level in your lab seeing as disabling at the server level had such a detrimental effect? Set-MailboxDatabaseCopyStatus DBName\EXServerName ActivationSuspended True

    • I haven’t tested with recent CU’s but disabling auto activation at the database level should not have the effects mentioned in this article.

  7. this is also an issue in exchange 2016 CU3.
    migrating a client from 2010 ro 2016 and proxy from 2016 to 2010 was broken, spent hours on the phone to MS support and got no where fast 😦
    stumbled upon this blog, checked the setting and it was blocked, once changed to unrestricted everything worked as expected.
    a big thanks from me

  8. Just stumbled across this article today after having issues for a week with failing CAS operations. Not sure how Blocked got set but changed to Unrestricted and all our CAS operations started working again. Jeesh. Anyway a big thanks for this article.

Leave a comment