Error: DatabaseGuidNotFound


  • Hi. We have 2  Server 2012 R2 +Exchange 2013 sp1 servers  which work in DAG. These servers as are CAS servers and database server.

    Periodically we observe errors of HTTP 500 at connection through OWA or ActiveSync.
    Having started the test on one of servers received such error:

    Test-ActiveSyncConnectivity -URL https://e2013a.domain.local/Microsoft-Server-ActiveSync MailboxCredential (get-credential domain\username) | fl

    RunspaceId                  : 3565257a-41f0-4cde-9f6d-5fc1c4c829dd

    LocalSite                   : Kiev

    SecureAccess                : True

    VirtualDirectoryName        :

    Url                         :

    UrlType                     : Unknown

    Port                        : 0

    ConnectionType              : Plaintext

    ClientAccessServerShortName : e2013a

    LocalSiteShortName          : Kiev

    ClientAccessServer          : e2013a.domain.local

    Scenario                    : Options

    ScenarioDescription         : Issue an HTTP OPTIONS command to retrieve the Exchange ActiveSync protocol version.

    PerformanceCounterName      : DirectPush Latency

    Result                      : Failure

    Error                       : [System.Net.WebException]: The remote server returned an error: (500) Internal Server Err


                                  HTTP response headers:

                                  request-id: 9db50b60-ccb4-4b86-8aa9-1c9516dcaa8c

                                  X-CasErrorCode: DatabaseGuidNotFound

                                  X-FailureContext: FrontEnd;500;RGF0YWJhc2VHdWlkTm90Rm91bmQ=;VGhlIGRhdGFiYXNlIHdpdGggSUQgY



                                  X-FEServer: E2013A

                                  Content-Length: 0

                                  Cache-Control: private

                                  Date: Tue, 11 Mar 2014 12:10:47 GMT

                                  Server: Microsoft-IIS/8.5

                                  X-AspNet-Version: 4.0.30319

                                  X-Powered-By: ASP.NET

    • Edited by Mandri Tuesday, March 11, 2014 12:38 PM
    Tuesday, March 11, 2014 12:31 PM

All replies

  • Dealing with the same issue but only for some users - others are fine

    please let me know if you have any luck

    Tuesday, March 25, 2014 4:10 AM
  • Are the errors occurring for the same user account or on all accounts? Does the problem come and go?

    If it is the same account every time it would be worth checking their AD permissions:

    Tuesday, March 25, 2014 4:28 AM
  • Please ensure that Active Directory replication is healthy among all Domain Controllers

    Look at get-ADServerSettings in powershell to see what Domain Controller Exchange servers are pointing to.

    Check health of Global Catalog servers to ensure there are no lingering objects

    Create new database, add it to DAG and move problematic mailbox to new database. Failover database to another node to ensure mailbox login works from all DAG members.

    - Sarvesh Goel - Enterprise Messaging Administrator

    Tuesday, March 25, 2014 4:51 AM
  • Single consolidated Exchange 2013 server. Migrated from 2007. Problems started after demoting and uninstalling 2007 - was working for all users for a day until some users stopped working. 

    Have tried all the permissions including restoring permissions to default on the user object.

    Some users are getting 500 internal errors when connecting to activesync (using
    Below articles are very similar to what we are experiencing but none of the fixes seem to help us.

    Applied security at the domain level instead of the users level

    Replicated AD and restarted the Exchange server.
    Removed and Re-created IIS ActiveSync Virtual Directories and restarted server

    Successfully tested some of the failed accounts on ActiveSync after Virtual Directories were recreated (Could also just have been the server restart resulting in positive tests)

    Thought all was well, waited 15 minutes and ActiveSync was once again broken for those users

    I had done this earlier to the ECP Virtual Directory since I was also experiencing 500 errors there

    I also re-ran the setup /p setup /ps and setup /pd again (after uninstalling 2007) just for good measures

    Back to square 1 - 

    Tuesday, March 25, 2014 2:48 PM
  • Jens,

    If you are getting the 500 errors just with active sync it's probably related to AD permissions.  Can you check to see if one of the affected users have Inheritance Enabled on it?  If it's not enabled then the most likely cause is that this account had it removed do to being a member of a group that has AdminSdholder protection applied to it.  If this is the case, you may want to take a look at the guide below to see what users/groups have the adminsdholder applied to it.

    I saw this same issue with users after doing a migration from Exchange 2007 to Exchange 2013.

    Tuesday, March 25, 2014 3:05 PM
  • Try creating a new database and move mailbox to new database to see if that works. Also check the AD replication and Global Catalog related errors.

    - Sarvesh Goel - Enterprise Messaging Administrator

    Tuesday, March 25, 2014 3:09 PM
  • I moved a users to a brand new database and it didn't help

    Tuesday, March 25, 2014 3:25 PM
  • It helped me.

    I added the key <add key="aspnet:UseLegacyRequestUrlGeneration" value="true" /> to the <appSettings> in the web.config located in the frontend\httpproxy\owa\web.config file.

    See http

    Friday, March 28, 2014 4:04 PM
  • I am having the same problem since today. A couple of days ago i moved the mailbox to another datastore in Exchange 2013. After that move the activesync was still working. Very weird problem because other mailboxes on Exchange 2013 are working fine with activesync.


    An HTTP 500 response was returned from Unknown.

    Headers received:

    request-id: 33fbae38-aa67-420c-9f80-d974bec73078

    X-CasErrorCode: DatabaseGuidNotFound

    I have solved my problem by migrating the failed users back to Exchange 2010 and then again back to Exchange 2013. 
    • Edited by MaartenMJ Tuesday, April 1, 2014 6:30 PM
    Friday, March 28, 2014 7:39 PM
  • Have you tried disconnecting and reconnecting affected mailbox, does it help ?
    • Proposed as answer by twagh Tuesday, April 1, 2014 2:55 PM
    Tuesday, April 1, 2014 2:54 PM
  • I am experiencing this exact issue as well, also migrated from Exchange 2007.

    Both CAS and Mailbox roles are on a single server.  After decommissioning our Exchange 2007 server, Activesync doesn't work for several users.  RCA shows the same HTTP 500 "DatabaseGuidNotFound" message.  I've confirmed Exchange has the permissions necessary on the user account, I've deleted all ActiveSync devices, and have disconnected and reconnected the user's mailbox.  Nothing so far has worked.  I'm hoping for a solution soon. 

    Tuesday, April 1, 2014 5:52 PM
  • exactly the same here - 2007 to Ex2013 SP1 migration.  About 300 users, all fine on activesync except for a handful and getting this both with connectivity tool and internal test-activesyncconnectivity's killing me! spent 2 days already on this damn issue

    An HTTP 500 response was returned from Unknown.
    Headers received:
    Connection: Keep-Alive
    request-id: 2384f476-aa86-4b67-8408-4782b46ff36c
    X-CasErrorCode: DatabaseGuidNotFound

    Wednesday, April 2, 2014 1:54 AM
  • I have the exact same issue. A handful of users cannot get e-mail on their phones. ( Includes iPad, iPhone, and Android) Active-Sync error for these users

    An HTTP 500 response was returned from Unknown.
    Headers received:
    request-id: a0c6710d-1240-459c-a356-30dd4db5c4f1
    X-CasErrorCode: DatabaseGuidNotFound
    X-FEServer: Exchange2013-Server
    Content-Length: 0
    Cache-Control: private
    Date: Wed, 02 Apr 2014 13:45:11 GMT
    Server: Microsoft-IIS/7.5
    X-AspNet-Version: 4.0.30319
    X-Powered-By: ASP.NET

    A little background in my environment just to see if you have something similiar.

    - Migrated from Exchange 2007 to 2013

    - 2013 Exchange is running SP1 which is installed on Server 2008 R2 Standard SP1 with all updates

    - Exchange 2007 was successfully uninstalled

    - On Exchange 2013 I have a wildcard certificate

    - Only about 15 of 300 users are affected

    - Inheritable Permissions is checked on all the users. (Also restored the default permissions)

    - Everything else works for these 15 users except Active Sync. (RPC, OWA, Outlook all good)

    - If I run iisreset on the exchange 2013 server those users start to work for a short period of time

    - Exchange 2013 Event logs don't show any errors related to any of this

    -  Also tried disconnecting and reconnecting the mailboxes with no luck

    Wednesday, April 2, 2014 3:16 PM
  • I have exactly the same problem.

    We had two Exchange 2013 SP1 servers, because we wanted to upgrade also OS to Windows Server 2012 R2.

    So we moved all mailboxes to other server and then back to the new one.

    Now we have only one Exchange Server (Mailbox and CAS role).

    When user gets error 500, we can see in httpproxy log, that Proxy (Exchange) wants to access database that is not present anymore (it was removed with the old server).

    Somewhere should be that wrong data of wrong database GUID for problematic user/mailbox. Is it in Exchange server or in Active Directory? Where?

    • Edited by si124 Wednesday, April 2, 2014 8:14 PM
    Wednesday, April 2, 2014 8:11 PM
  • OK! I think I have found the answer! So far its been about 30 minutes and my users are still connected with Active Sync. This is what I did to resolve the problem. 

    1. In the Advanced Security Settings of the User that is having problems, check to make sure there are no Unknown SID Security Entries. If there are then delete them. I had to delete two Unknown SIDs from the root level of my AD.
    2. Also while in the Advanced Security settings make sure that Include Inheritable Permissions is checked.
    3. Then Synchronize all domain controllers using "repadmin /syncall /e"
    4. Open ADSIEdit in the Default Naming Context
    5. Browse through the directory and locate the user object having problems
    6. Select the CN=ExchangeActiveSyncDevices container located under the troublesome user and delete it.activesync5
    7. The next time a device attempts an ActiveSync connection, the folder will be automatically recreated and the correct permissions applied
    8. Then Synchronize all Domain Controller Again "repadmin /syncall /e"
    9. Log into the Exchange 2013 Server and run "iisreset"
    10. Try your Active Sync Device again

    Also as a good measure I reset the Active Sync Virtual Directory on my exchange 2013 server just to make sure . Hope this helps the rest of you. I'll update the post if it breaks again. 

    • Proposed as answer by JustinPickett Wednesday, April 2, 2014 9:16 PM
    Wednesday, April 2, 2014 9:16 PM
  • tried that -does not work here.  Going on the incorrect GUID approach , I have just checked with adsiedit the Exchange databases and cannot find any reference to the old DBS.  This problem started after I moved users to the new DB on EX2013 and CLEANLY removed the old 2007 databases.  Come on MS - are you guys going to look at this????????????????
    Wednesday, April 2, 2014 9:37 PM
  • Hey Justin - is it still working?  I have had it up/down with that approach several times, but it eventually fails.  As a test i am only using the connectivity analyzer tool on the web.

    Wednesday, April 2, 2014 9:46 PM
  • ok - this is from the httpproxy log for eas

    HttpProxyException=Microsoft.Exchange.HttpProxy.HttpProxyException: The database with ID b1119dd3-ce3c-43c1-8831-3ceb67d62adc couldn't be found. ---> 

    WHERE IS THIS IN AD????????

    Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<BeginCalculateTargetBackEnd>b__30()    --- End of inner exception stack trace ---;
    2014-04-02T21:01:07.148Z,cacb2265-69da-4943-a5c7-bad36deeb773,15,0,847,30,,Eas,,/Microsoft-Server-ActiveSync/default.eas,,Basic,True,SYDROCK\debra.dawson,,Sid~S-1-5-21-1092122867-994803523-1629300891-14340,Apple-iPad3C6/1102.651,,SHFA-EX-HO2,500,,DatabaseGuidNotFound,OPTIONS,,,,,WindowsIdentity,,,,0,,,,0,,,0,,0,,0,0,15.6,0,,,,,,,,2,1,,3,,3,3,,,CorrelationID=<empty>;BeginRequest=2014-04-02T21:01:07.132Z;ProxyState-Run=None;ProxyState-Complete=CalculateBackEnd;I32:ADS.C[shfa-ad-ho2]=1;F:ADS.AL[shfa-ad-ho2]=1.161,HttpProxyException=Microsoft.Exchange.HttpProxy.HttpProxyException: The database with ID b1119dd3-ce3c-43c1-8831-3ceb67d62adc couldn't be found. ---> Microsoft.Exchange.Data.Storage.DatabaseNotFoundException: The database with ID b1119dd3-ce3c-43c1-8831-3ceb67d62adc couldn't be found.    

    Wednesday, April 2, 2014 10:44 PM
  • I confirmed that 6 users are still working properly. I am waiting to hear back from 4 users to confirm one way or the other. And the other 5 have stopped working again. SMH... Going to try a few more things and update later.
    Thursday, April 3, 2014 1:27 PM
  • Just a quick update. My client re-applied this article from MS to all the affected accounts and replicated AD. They are saying that the accounts are working again. However I did that already the other day and it didn't make a difference. While they were doing this on their own I was in the background still searching on Exchange. I found additional unresolved security descriptors in exchange by running this in EMS - Get-ADPermission "mailbox database" | where {$_.user -like "s-*"} | fl ... I went into ADSI edit and removed them at the highest level and replicated AD again. I also found that the Content Index state of my Exchange 2013 database was in a failed and suspended state. I followed this link to resolve that. Then reset IIS on exchange again after the index was rebuilt and showing healthy. So far everything is connected but I'm not confident it is going to stay that way. 
    Thursday, April 3, 2014 4:48 PM
  • @Campbed - That could be the RunspaceID, ExchangeGUID, etc.. Have you tried running this in EMS to see if it matches anything

    Get-Mailbox username |fl

    Also, everything is still working in my environment. Perhaps you can reboot the Exchange server since you made all the changes I did and mine is working now?

    Also remove your device partnerships with this tool

    Friday, April 4, 2014 3:13 PM
  • This issue seems to be intermittent, I removed the unknown SID's from a user account as Justin said and that account started working and I no longer got the DatabaseGUIDNotFound issue, but it appears there is more going on then just this issue since SP1, If anyone is looking into updating to SP1 I would wait.
    Friday, April 4, 2014 7:37 PM
  • Dear All,

    I had opened a case with MS on this issue a week or two ago.

    I just got a call back from the tech support group and they (MS) has classified this as a bug in SP1

    DO NOT use SP1 if you plan to migrate mailboxes (that was the MS recommendation)

    I would completely hold off with any mailbox migrations until MS have released a fix


    Wednesday, April 9, 2014 7:17 PM
  • I am in the same boat, I have been working with Microsoft for about a week as well and they have stated this as an SP1 bug as well. 

    I have (4) servers in my environment

    • CAS1
    • CAS2
    • MBX1
    • CAS/MBX2

    When users try to connect to CAS1/CAS2 into CAS/MBX2 they get an error DatabaseGUIDNotFound, however I created a DNS record to bypass the CAS1 server and go straight to the CAS/MBX2 server where all our mailboxes are hosted. After doing this users are able to connect to OWA and ActiveSync without issues.

    I do not know if this helps, but it looks like when users go through the CAS server to the MBX server they point to the wrong DatabaseGUID number. This issue may be noted by an HTTP500 error in IE or a blank screen in Chrome with the end address /auth.owa.

    So far there is no permanent solution besides bypassing the frontend cas server, but this is not permanent but a workaround to the issue. Has anyone tried installing Exchange 2013 and Exchange 2013 SP1 together and migrate users back to Exchange 2013?

    Still waiting on a solution from Microsoft on this issue.

    Wednesday, April 9, 2014 7:24 PM
  • FYI - I am no longer having this problem after the earlier solution I posted. I also ran the below commands to recreate the health mailboxes just in case.

    Your health mailboxes might be jacked up from the migration. Try this

    1. On the Exchange Server, run Exchange Powershell with admin rights
    2. Remove the existing HealthMailboxes (there are typically two - one for your mail store and one for Public Folders, should this be enabled) When I ran the first command I had only two Health Mailboxes showing. Then I ran the second command to remove the health mailboxes.

    Get-Mailbox -monitor

    Get-Mailbox -monitor | remove-mailbox
    3. Run "setup.exe /preparead" (setup.exe is stored in Program Files\Microsoft\Exchange Server\V15\bin"
    4. Restart the "Microsoft Exchange Health Manager" service

    5. Wait a couple of minutes (Be Patient as sometimes it take a few minutes to recreate the mailboxes) then run the below commad. After the mailboxes were recreated, I went from having 2 to 4

    Get-Mailbox -monitor

    The HealthMailboxes are then re-created in the right place, and the error messages are no longer generated.

    Wednesday, April 9, 2014 10:07 PM
  • I get an INSUFF_ACCESS_RIGHTS error trying to remove the HealthMailboxes.

    *ran EMS as admin
    *ran EMS as a domain admin user
    *also tried the domain administrator user
    *also tried with non domain-admin exchange administrator

    Active Directory operation failed on XXXX. This error is not retriable. Additional information: Access is
    Active directory response: 00000005: SecErr: DSID-031524FF, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
        + CategoryInfo          : NotSpecified: (:) [Remove-Mailbox], ADOperationException
        + FullyQualifiedErrorId : [Server=XXXX,RequestId=b373c93b-86de-4987-b365-d803df7c70b6,TimeStamp=4/10/2014 6:
       55:34 AM] [FailureCategory=Cmdlet-ADOperationException] EB1E1428,Microsoft.Exchange.Management.RecipientTasks.Remo
        + PSComputerName        : XXXX

    Thursday, April 10, 2014 7:36 AM
  • Ensure that yourself and the Parent OU in Active Directory users and Computers has Inherit Permissions enabled.

    1.Open Active Directory Users and Computers.

    2.Click View , and then click Advanced Features .

    Note To make the Security tab available at both the user level and the organizational unit level, you must enable the Advanced Features option in Active Directory Users and Computers. This option is available under the View menu.

    3.Open the properties for both the user level and the organizational unit level that the users are located in, and then locate the Security tab.

    4.Click Advanced .

    5.Make sure that the following check box is selected:

    Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here.

    6.Force Active Directory replication.

    Thursday, April 10, 2014 2:45 PM
  • We opened a case, this was confirmed as a bug for us, too.  We're recycling the ActiveSync App pool every 5 minutes as a work-around until the issue is addressed, hopefully in the next rollup.
    Thursday, April 10, 2014 3:03 PM
  • We opened a case, this was confirmed as a bug for us, too.  We're recycling the ActiveSync App pool every 5 minutes as a work-around until the issue is addressed, hopefully in the next rollup.

    Have you tried removing Unknown SID entries from a User to test? I did this for one of our users and it fixed the ActiveSync issues, also I have seen that if you bypass your CAS server and go straight to the MBX/CAS server if it is a multirole this fixes the issues.

    The issue itself appears to be the CAS server having the wrong DatabsseGUID for a user and sending the user to a database that no longer exsists or the GUID has changed.

    Try what JustinPickett recommended above and remove Unknown SIDS from a user and test.

    Thursday, April 10, 2014 3:05 PM
  • Update (4/11/2014):

    The KB article is now live at:

    Users cannot access mailboxes in OWA or EAS when mailbox database is removed


    Hello Everyone,
    Just wanted to let everyone know here that this is a known issue with Exchange 2013 SP1 and we are investigating it for a possible fix. We are also working to publish a KB article on this issue with detailed info on symptoms, cause and possible workarounds. I will update this post when the KB article is live. At this time, I would say the best and easiest way to avoid running into this issue is to not delete your old (source) databases from where you are moving mailboxes to their new destination databases. Hope this helps.

    Sr. Program Manager, Product Quality, Exchange Client Access Server

    Thursday, April 10, 2014 3:09 PM
  • Ensure that yourself and the Parent OU in Active Directory users and Computers has Inherit Permissions enabled.

    if I had a nickle for every site that suggested this "fix"... it does nothing for me and there's an automated process that undoes the change every hour or so.
    Thursday, April 10, 2014 3:13 PM
  • Yes it seems to be the catch all for any issues with permissions, did not know you attempted this fix already.
    Thursday, April 10, 2014 4:06 PM
  • My view of the topic is at It's a bug, but all software has bugs... it's just a pity that this one affects mailbox moves. But there's an easy workaround - just cherish those old databases for a little while longer.

    - Tony

    Friday, April 11, 2014 9:09 PM
  • In my case it had nothing to do with permissions, SIDs, inheritance etc. but exactly with what is described in Tony's article above (respectively KB2958434). It occured after migration from Exchange 2007 to 2013. The problem arised after deleting the old (empty) Exchange 2007 mailbox databases a few days after all mailboxes have been moved over to Exchange 2013.

    If you're in the situation that you already ran into this problem and your old databases are already gone - for example because you already decommissioned your old Exchange servers and databases - the following can be done to fix the error:

    - Make sure you have the problem descibed above by running the Test-ActiveSyncConnectivity cmdlet as described in KB2958434

    - Clear all cookies on your "defective" Active Sync device (i.e. Windows Phone: Clear history in Internet Explorer)

    - Recycle the MSExchangeSyncAppPool on your Exchange 2013 CAS servers (can be found in IIS Manager - Application Pools). In some cases it may be necessary to recycle the MSExchangeAutodiscoverAppPool as well. This will remove cached cookies from CAS servers. Important: Do this before your Active Sync device tries to automatically resync again.

    - Try to sync your Active Sync device - should work.

    - Observing the latest logfile in C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Eas can be helpful.

    - The Microsoft Remote Connectivity Analyzer at can help to find which service is exactly affected by the "DatabaseGuidNotFound" problem respectively which AppPools need to be restarted.


    • Edited by Martin Atteneder Tuesday, April 15, 2014 5:55 PM
    • Proposed as answer by Wall09 Thursday, April 17, 2014 1:41 PM
    Tuesday, April 15, 2014 4:56 PM
  • Had this exact issue as I was performing a 2007 to 2013 upgrade for another company yesterday.

    Martin Atteneder's suggestion of recycling the MSExchangeSyncAppPool is providing resolution.  Be aware that after recycling, additional users may encounter the issue.  You have to recycle the MSExchangeSyncAppPool everytime additional/new users are affected. 

    Not a pretty fix, but a fix non the less.  Hopefully this will be fixed soon in future Exchange 2013 service packs.


    Thursday, April 17, 2014 1:45 PM
  • OK guys - as MS are pretty slack on this one we have found a better work around for this (well it works for us anyway).  Oh, and MS, if you are there - a lot of companies cannot just leave the old DB there are after a move as the TIER 1 disk is expensive and often used on the new server in a leap frog approach to migration (as has worked with every other version of Exchange).  Telling us after the fact, to leave the old DBs in place is pretty useless.

    Our solution is......

    1.  get a device that cannot connect and connective to EAS with an account that WORKS.  You don't have to connect all the way through, just so the account has been verified.

    2. Then go back and edit the account details for a failed account.  The account now connects.

    3.  Any other device that had the failed account on it now will also work.

    go figure...


    Thursday, April 24, 2014 10:33 AM
  • oh - and to add.  Did not have to recycle, delete anything etc etc 
    Thursday, April 24, 2014 10:34 AM
  • recycling msexchangesyncapppool worked for us (so far). way to go Microsoft - another doozy.

    we moved all mailboxes from a win2012 ex2013sp1 server to win2012r2 ex2013sp1 server and deleted the old DBs.

    Tuesday, May 6, 2014 3:09 PM
  • Was a hot fix ever release by MS to fix this issue? – this is a bug

    I actually opened a case with Microsoft case no 114032511294659, and they admitted it was a bug (even got a refund)

    I currently have two other projects on hold due to this issue – we are already on SP1 and cannot migrate mailboxes from legacy environment until we have a hot fix!

    Just got a response back from support and here goes:

       -   "We do not have a fix yet for this issue and we would have a fix in CU6 for exchange 2013. At this point we do not know the roll out date for CU6. For the time being I would suggest if you are migrating to exchange 2013 from an older version of exchange please do not decommission the old exchange server or do not delete the databases on the old server."

    But wait a minute... - CU5 is not even released (however there are already references for it on TechNet...) so this could take a while...


    Wednesday, May 7, 2014 5:47 PM
  • I believe they call SP1 CU5 sometimes.
    Wednesday, May 7, 2014 6:37 PM
  • I have a few other names for SP1...........
    Friday, May 16, 2014 12:09 AM
  • CU5 has just been released, it doesn't look like a fix for this issue is included.
    Wednesday, May 28, 2014 7:15 PM
  • CU5 has just been released, it doesn't look like a fix for this issue is included.

    Due to the fact that the regression error was not listed in the fix list, or that SP1 CU5 has been applied and has not fixed the issue? 
    Thursday, May 29, 2014 11:51 PM
  • CU5 has just been released, it doesn't look like a fix for this issue is included.

    Due to the fact that the regression error was not listed in the fix list, or that SP1 CU5 has been applied and has not fixed the issue? 
    I have not installed CU5 on any of our affected servers, but the fix is not listed.
    Friday, May 30, 2014 2:01 AM
  • My hope is that much like some other errors, they simply are listed in the fix list.  But I suppose I will find out one way or another, as I plan to apply CU5 tomorrow night.
    Friday, May 30, 2014 5:00 AM
  • Look at my previous post with an excerpt from Microsoft Support stating that this will be fixed in CU6.
    Friday, May 30, 2014 5:04 PM
  • Well, I hope no one else has to go as far as I had to in order to finally get it working, but in case someone else still is having problems that are in the same class as mine, here goes...

    My issue wasn't the typical AD user-object permission inheritance thing, and I also checked but even after deleting cookies and restarting IIS, the issue returned. I was also not affected by - we were getting HTTP 500 errors before the new partnership could be created.

    I tried disconnecting (disable-mailbox) the mailbox and reconnecting it but that also did not help. My own user account also couldn't access EAC after removing the legacy 2010 database, so I started using that as a representative of the overall problem. I disconnected my mailbox and left it disconnected. Still broken. Then I cleared all the remaining msexch* attributes from my account in ADSIEdit, plus the protocolsettings value. Still broken, so I looked again in ADSIEdit and saw that the MSExchWhenMailboxCreated value didn't really clear out; all it lets you do is set it to another value, not erase it. So I set it to today's date, and after running repadmin /syncall and clearing my browser cache, I could log into EAC with my account again.

    Next, I tried re-connecting my mailbox, but when I did so, it broke my EAC access again (HTTP 500 error ). I checked in ADSIEdit and it had set the MSExchWhenMailboxCreated attribute on my account back to the real creation date of the mailbox, which was back in 2011. Must've read it from the mailbox that got reconnected. I'm not sure why this would matter but when I disconnected my mailbox again, cleared out all the values again (and set the MSExchWhenMailboxCreated to today's date), and then mailbox-enabled my account with a brand-new mailbox instead of re-connecting the old one, it did not break.

    With all this in mind, I took an approach similar to a dial-tone recovery with one of my broken ActiveSync users in the field, and it seems to be working so far, although it is really ugly. I tried everything else in here without any luck so this is what it came down to:


    disable-mailbox $mailbox
    Update-StoreMailboxState -Identity $mailbox.ExchangeGuid -Database $mailbox.Database
    repadmin /syncall <name of a dc>

    Open ADSIedit and Delete the subfolder CN=ExchangeActiveSyncDevices from the affected user's object. Then clear the values of all Exchange attributes in the user's object, plus the "protocolsettings" attribute. The MSExchWhenMailboxCreated attribute cannot be cleared; instead, set it to today's date (There might be some particular date it needs to be later than - I tried yesterday's date too, and that was fine, but if I left this value alone back in the 2011 timeframe, this fix did not work).

    repadmin /syncall <name of a dc>


    enable-mailbox $mailbox.SamAccountName -alias $mailbox.alias -Database $mailbox.Database -PrimarySmtpAddress $mailbox.PrimarySmtpAddress
    set-mailbox $mailbox.DistinguishedName -EmailAddressPolicyEnabled $false -EmailAddresses $mailbox.emailaddresses
    set-mailbox $mailbox.DistinguishedName -EmailAddressPolicyEnabled $mailbox.EmailAddressPolicyEnabled
    New-MailboxRestoreRequest -SourceDatabase $mailbox.database -SourceStoreMailbox $mailbox.ExchangeGuid -AllowLegacyDNMismatch -TargetMailbox $mailbox.DistinguishedName


    I think I pretty much tried everything short of this without success. Hopefully it's helpful to someone else out there.

    Hmm, not sure why I didn't think of this until reading it, but I wonder if it would work to just set the MSExchWhenMailboxCreated attribute to today's date and leave everything else alone. I'll try that if anyone else reports the problem. We just killed the old db over the past weekend so I may not have heard from everyone affected yet.
    Friday, May 30, 2014 9:42 PM
  • CU5 does appear to help mitigate this issue.  The expiration value is lower.  Applying it fixed my admin account's ecp access and I had previously been unable to get it working using the cookie/apppool recycling method...
    Friday, May 30, 2014 10:58 PM
  • Look at my previous post with an excerpt from Microsoft Support stating that this will be fixed in CU6.

    I was aware of your previous post referencing CU6.  I was also familiar with the list of items stated as fixed in CU5.  If a Technical support staff responds in a case and references a CU that beyond the next one to be released, and we know that not all fixes are noted in a fix list, it is still a valid question to see, in this case, if CU5 addressed the issue. 

    With that said, I applied CU5 last night, and it fixed the issue for my environment. 

    Saturday, May 31, 2014 2:52 PM
  • CU5 does appear to help mitigate this issue.  The expiration value is lower.  Applying it fixed my admin account's ecp access and I had previously been unable to get it working using the cookie/apppool recycling method...

    It fixed my environment as well.
    Saturday, May 31, 2014 2:53 PM
  • Hi guys!

    Anybody have news about the solution about this issue? We have it, too ;-(

    We try all things in this post... we have Exchange 2013 SP1+CU4, Is really the solution install the patch CU5?.

    News about CU6 release date?

    Thanks in advance.

    Tuesday, August 26, 2014 7:33 AM
  • CU5 greatly reduces the lifetime of the cached objects that cause this issue, so it's unlikely to happen.

    Unfortunately if you already find yourself in this situation, simply applying CU5 is not going to fix the existing problem. See the answers posted here regarding cycling the app pool - that's the only way we could get temporary relief.

    Tuesday, August 26, 2014 8:08 AM
  • Thanks for the reply!

    Recycling the pool effective solve temporally the problem, the solution is configure a periodic pool recycling? (30 minutes)

    What is the impact for the users when the pool is recycled? (15% users with the problem, 85% works fine).

    Tuesday, August 26, 2014 10:23 AM
  • FYI: E2013 CU6 was released earlier today ...

    Released: Cumulative Update 6 for Exchange Server 2013

    Sr. Program Manager, Product Quality, Exchange Client Access Server

    Tuesday, August 26, 2014 6:08 PM
  • In my case I tried a number of different solutions recommended with no success.

    I first tried moving the user mailbox to another database to clear up any corruption, but still had the same issue (move was successful though).

    I tried this: ( to recycle the app pools and cleared the cookies on the device but again did not fix the problem.

    I fixed the inherited rights issue (my user did have it not inheriting rights) but that did not fix the problem.

    I tried deleting the "CN=ExchangeActiveSyncDevices" container under the user ID in ADSI which also did not work.

    I tried resetting the activesync virtual directory but this also did not fix the problem.

    Whenever I tried to setup an account on the iPhone it would always come up with "could not verify server identity" and activesync test from would fail the activesync portion with the DatabaseGUIDNotFound.

    I was however able to get my EAS clients setup.  When the initial login fails and it asks for additional information (Server name, Domain, user name, etc.) I was able to get it to work by putting in the new format for the server name and that seems to fix my problem.

    The format for server name looks like  I was able to find this by looking on the outlook client on a desktop for the user in question.  Granted this is a total workaround but I hop it helps someone.

    UPDATE: and apparently that fix was only good for about 3 hours... back to broken again.  This has to be one of the buggiest implementations of Exchange ever.

    UPDATE 2: Cumulative Update 8 (KB3030080) fixed the issue for me.  Previously I was on SP1 which apparently was my issue.

    • Edited by BrettDioson Friday, June 19, 2015 12:17 PM Resolved
    Monday, June 15, 2015 7:43 PM
  • Thanks JustinPickett , That fixed the issue for me.
    Monday, April 3, 2017 2:53 AM