Too Many Folders To Successfully Migrate To Exchange Online

Posted on 1 CommentPosted in activesync, android, email, exchange, exchange online, Exchange Server, iPad, iPhone

Exchange Online has a limit of 10,000 folders within a mailbox. If you try and migrate a mailbox with more than this number of folders then it will fail – and that would be expected. But what happens if you have a mailbox with less than this number of folders and it still fails for this same reason? This is the problem, with resolution, I outline below.

I was moving some mailboxes to Exchange Online when I came across the following error in the migration batch results:

Data migrated: 18.18 MB ‎(19,060,890 bytes)‎
Migration rate: 0 B ‎(0 bytes)‎
Error: MigrationMRSPermanentException: Error: Could not create folder 2288. –> MapiExceptionFolderHierarchyChildrenCountQuotaExceeded: Unable to create folder. ‎(hr=0x80004005, ec=1253)‎ Diagnostic context: Lid: 55847 EMSMDBPOOL.EcPoolSessionDoRpc called [length=204] Lid: 43559 EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=468][latency=1] Lid: 52176 ClientVersion: 15.20.1730.17 Lid: 50032 ServerVersion: 15.20.1730.6019 Lid: 35180 Lid: 23226 — ROP Parse Start — Lid: 27962 ROP: ropCreateFolder [28] Lid: 17082 ROP Error: 0x4E5 Lid: 25953 Lid: 21921 StoreEc: 0x4E5 Lid: 27962 ROP: ropExtendedError [250] Lid: 1494 —- Remote Context Beg —- Lid: 38698 Lid: 29818 dwParam: 0x0 Msg: f28f1e21-62aa-4999-977f-ce310efea309-61f0997f-74d5-4421-9050-64f8272e5ac2[9]-28A06 Lid: 29920 dwParam: 0xB Lid: 29828 qdwParam: 0x2711 Lid: 29832 qdwParam: 0x2710 Lid: 45884 StoreEc: 0x4E5 Lid: 29876 StoreEc: 0x4E5 Lid: 30344 StoreEc: 0x4E5 Lid: 54080 StoreEc: 0x4E5 Lid: 56384 StoreEc: 0x4E5 Lid: 38201 StoreEc: 0x4E5 Lid: 35904 Lid: 45434 Guid: f12f3e45-67aa-89012-345f-ce678efea901 Lid: 10786 dwParam: 0x0 Msg: 15.20.1730.017:VI1PR0502MB2975:145a3769-3902-4e6b-9fe4-6db564e4eb92 Lid: 1750 —- Remote Context End —- Lid: 31418 — ROP Parse Done — Lid: 22417 Lid: 30609 StoreEc: 0x4E5 Lid: 29073 Lid: 20369 StoreEc: 0x4E5 Lid: 64464 Lid: 64624 StoreEc: 0x4E5

In the above I have highlighted some of the errors I was seeing – with the “could not create folder” message, the first indicator is that I have too many folders to migrate or I have a corrupt mailbox. Running Get-MoveRequestStatistics and including a full report (with -IncludeReport) shows in part the below. This was run to get more info on the move request. This was run from Exchange Online:

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​26/03/2019 17:10:09 [VI1PR0502MB3855] ‘MigrationService (on behalf of ‘’)’ created move request.
26/03/2019 17:10:15 [DB8PR05MB6025] The Microsoft Exchange Mailbox Replication service ‘’ (15.20.1730.17 ServerCaps:01FFFFFF, ProxyCaps:07FFFFC7FD6DFDBF5FFFFFCB07EFFF, MailboxCaps:, legacyCaps:01FFFFFF) is examining the request.
26/03/2019 17:10:15 [DB8PR05MB6025] Content from the Shard mailbox (Mailbox Guid: f12f3e45-67aa-89012-345f-ce678efea901, Database: cc980daf-4402-4645-b26c-2a83760b161c) will be merged into the target mailbox.
26/03/2019 17:10:15 [DB8PR05MB6025] Connected to target mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’, database ‘EURPR05DG090-db014’, Mailbox server ‘’ Version 15.20 (Build 1730.0).
26/03/2019 17:10:20 [DB8PR05MB6025] Connected to source mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’, database ‘DB’, Mailbox server ‘’ Version 15.0 (Build 847.0), proxy server ‘’ 15.0.847.40 ServerCaps:, ProxyCaps:, MailboxCaps:, legacyCaps:1FFFCB07FFFF.
26/03/2019 17:10:21 [DB8PR05MB6025] Request processing started.
26/03/2019 17:10:21 [DB8PR05MB6025] Source mailbox information:
Regular Items: 8443, 905.4 MB (949,422,345 bytes)
Regular Deleted Items: 1149, 189.9 MB (199,115,692 bytes)
FAI Items: 4651, 11.72 MB (12,285,701 bytes)
FAI Deleted Items: 9, 19.26 KB (19,721 bytes)
26/03/2019 17:10:21 [DB8PR05MB6025] Cleared sync state for request 2c065e32-3bd5-4524-9aac-03880fa8e961 due to ‘CleanupOrphanedMailbox’.
26/03/2019 17:10:21 [DB8PR05MB6025] Mailbox signature will not be preserved for mailbox ‘\f12f3e45-67aa-89012-345f-ce678efea901 (Primary)’. Outlook clients will need to restart to access the moved mailbox.
26/03/2019 17:11:20 [DB8PR05MB6025] Stage: CreatingFolderHierarchy. Percent complete: 10.
26/03/2019 17:12:38 [DB8PR05MB6025] Initializing folder hierarchy from mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’: 29048 folders total.
26/03/2019 17:21:21 [DB8PR05MB6025] Folder creation progress: 1102 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 17:31:22 [DB8PR05MB6025] Folder creation progress: 2730 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 17:41:22 [DB8PR05MB6025] Folder creation progress: 4535 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 17:51:23 [DB8PR05MB6025] Folder creation progress: 6257 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 18:01:23 [DB8PR05MB6025] Folder creation progress: 7919 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 18:11:23 [DB8PR05MB6025] Folder creation progress: 9570 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 18:14:15 [DB8PR05MB6025] Fatal error StoragePermanentException has occurred

The move request logs show an increasing folder count, and when this exceeds 10,000 a storage error occurs.

So the next thing to do is to check what I have on-premises. I have generally two options to try and fix a mailbox I am moving to Exchange Online. One is to move the mailbox elsewhere on-premises (on the basis that I discard errors on-premises and then move a cleaner mailbox to the cloud) or run repairs on the mailbox. Note that running repairs on-premises is part of the move to the cloud anyway as Exchange Server does this as part of the move.

But this revealed nothing! The move request logs on-premises showed the same – there was over 10,000 folders (indeed some of my mailboxes had over 20,000 folders) and this was enumerated in the move request logs. A New-MailboxRepairRequest did nothing either. But interestingly, Get-MailboxFolderStatistics | Measure showed only 200 folders! Each of my failing mailboxes had between 150 and 263 folders – nothing like the +10,000 that the move request was finding!

So I opened the mailbox in Outlook having granted myself permissions to it – again nothing.

So I opened MFCMapi and had a look at the folders. Now MFCMapi shows everything in the mailbox, and not just items under the “top of the information store” folder. I went about expanding each subfolder I could find and I came across a subfolder that everytime i expanded it, MFCMapi would hang. I would close and restart MFCMapi and the same thing!


I had found my suspect folder – its a iPhone device that had created the +10,000 folders. Now that I had a good candidate for my issue, the fix was easy. I listed the active-sync devices using Get-MobileDevice -Mailbox “Richard Redmond” | FL Identity and then removed the suspect device using Remove-ActiveSyncDevice “ Redmond/ExchangeActiveSyncDevices/iPhone§A9BCDE7FG57HIJ81KL1M08NOPQ” -Confirm:$false where the device identity was returned in the Get-MobileDevice cmdlet run just before.

This Remove-ActiveSyncDevice (or Remove-MobileDevice) cleans up this mailbox and deletes the partnership with the device.

Once this was done, I moved the mailbox again and it was ~200 folders and moved to Exchange Online without further issue.

Where I tested the move to Exchange Server rather than Exchange Online, I found that looking in the move request report (I had prestaged the move and then removed the corrupt mobile device), the move report showed information like the following and all I had done was removed one mobile device from the mailbox!

26/03/2019 17:41:22 [servername] Folder hierarchy changes reported in source ‘Primary (a8c13a2f-535b-d996-908e-ff84b1484a7)’: 200 changed folders, 24080 deleted folders.

From the users perspective, if the phone is an active device and is syncing email, then removing the phone causes it to create a new partnership. If the server allows any device then this is seamless to the user. If the server requires authorization to add a new device, then the user will be told this and service desk/admin will need to approve the device again. So if Allow/Block/Quarantine (ABQ) is not enabled on the server, one wonders if deleting all active sync partnerships before migrating any mailbox is an idea worth considering – there could be mailboxes I have moved that are <10,000 folders but not far from that number and therefore storing up issues for the future!

Continuing Adventures in AD FS Claims Rules

Posted on 7 CommentsPosted in 2013, activesync, ADFS, ADFS 3.0, exchange online, https, Office 365, Outlook, OWA for Devices, Web Application Proxy

Updated 20th April 2017

There is an excellent article at which discusses the use of Claims Rules in AD FS to limit some of the functionality of Office 365 to specific network locations, such as being only allowed to use Outlook when on the company LAN or VPN or to selected groups of users. That article’s four examples are excellent, but can be supplemented with the following scenarios:

  • OWA for Devices (i.e. OWA for the iPhone and OWA for Android), also known as Mobile OWA
  • Outlook Mobile Apps
  • Using Outlook on a VPN, but needing to set up the profile when also on the VPN
  • Outlook restrictions when using MAPI over HTTP
  • Legacy Auth and Modern Auth Considerations

OWA for Devices and AD FS Claims Rules

OWA for Devices is an app available from the Apple or Android store and provides mobile and offline access to your email, adding to the features available with ActiveSync. Though OWA for Devices is OWA, it also uses AutoDiscover to configure the app. Therefore if you have an AD FS claim rule in place the blocks AutoDiscover you will find that OWA for Devices just keeps prompting for authentication and never completes, though if you click Advanced and enter the server name by hand ( then it works.

Using OWA for iPhone/iPad diagnostics (described on Steve Goodman’s blog at you might find the following entries in your mowa.log file:

[NetworkDispatcher exchangeURLConnectionFailed:withError:] , “Request failed”, “Error Domain=NSURLErrorDomain Code=-1012 “The operation couldn’t be completed. (NSURLErrorDomain error -1012.)” UserInfo=0x17dd2ca0 {NSErrorFailingURLKey=, NSErrorFailingURLStringKey=}”

And following the failure to reach successfully you might see the following:

[NetworkDispatcher exchangeURLConnectionFailed:withError:] , “Request failed”, “Error Domain=ExchangeURLConnectionError Code=2 “Timeout timer expired” UserInfo=0x17dc6eb0 {NSLocalizedDescription=Timeout timer expired}”

and the following:

[PAL] PalRequestManager.OnError(): ExchangeURLConnectionError2: Timeout timer expired

[autodiscover] Autodiscover search failed. Error: ExchangeURLConnectionError2: Timeout timer expired

[actions] Action (_o.$Yd 27) encountered an error during its execution: Error: Timeout timer expired

[autodiscover] TimerCallback_PeriodicCallback_HandleFailedAutodiscoverSearch took too long (XXXms) to complete

The reason is that the first set of AutoDiscover lookups work, as they are connecting to the on-premises endpoint and authentication for this endpoint does not go through AD FS. When you reach the end of the AutoDiscover redirect process you need to authenticate to Office 365, and that calls AD FS – and that might be impacted by AD FS claims rules.

The problem with OWA for Devices and claims rules can come about by the use of the AD FS Claims Rules Policy Builder wizard at This tool can be adjusted quite easily for AD FS 2012 R2 (change line 218 to read “If (($OSVersion.Major –eq 6) –and ($OSVersion.Minor –ge 2))” (look for AD FS servers that are –ge [greater or equal to 2] rather than just 2). The AD FS Claims Rules Policy Builder has a setting called “Block only external Outlook clients” – and this blocks Outlook, Exchange Web Services, OAB and AutoDiscover from being used apart from on a network range that you provide. The problem is that you might want to block Outlook externally, but allow OWA for Devices to work.

To solve this problem make sure you do not block AutoDiscover in the claims rules. In the “Block only external Outlook clients” option, its the 2nd claim rule that needs to be deleted, so you end up with just the following:


With AutoDiscover allowed from all locations, but EWS and RPC blocked in Outlook, you still block Outlook apart from on your LAN, but you do not block OWA for Devices. Use to test Outlook Autodiscover after making this change and you should find that the following error is not present when AutoDiscover gets to the stage.

The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL for user

The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.

An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN).HTTP Response Headers:

If you changed an existing claims rule you either need to restart the AD FS service or wait a few hours for it to take effect.

OWA Apps and AD FS Claims Rules

The above section covers why MOWA (Mobile OWA) needs AutoDiscover to work. The same is true for any client application such as ActiveSync or Outlook for iOS / Outlook for Android / Windows Mail etc that needs to run AutoDiscover to determine your mailbox settings. Therefore, as in the above section ensure you are not blocking AutoDiscover from external networks unless apps on mobile devices are also only allowed to work on your WiFi.

Outlook with AD FS Claims Rules and VPN’s

As mentioned above, Outlook can be limited to working on a given set of IP ranges. If you block AutoDiscover from working apart from on these ranges (as was the issue causing OWA for Devices to fail above) then you can have issues with VPN connections.

Imagine the following scenario: Web traffic goes direct from the client, but Outlook traffic to Office 365 goes via the LAN. A split tunnel VPN scenario.

In this example, if AutoDiscover and initial profile configuration has never run you have a claims rule that allows Outlook to work on the VPN (as the public IP’s for your LAN/WAN are listed in the claims rules as valid source addresses), but AutoDiscover fails due to the same rules (as the web traffic is coming from the client and not the LAN). Therefore AutoDiscover fails and Outlook is never provisioned, so it appears as if Outlook is being blocked by the claim rules even though you are on the correct network for those claim rules.

Outlook with MAPI over HTTP

Updated April 20th 2017

A new connection protocol was released with Exchange Server 2013 SP1 called MAPI/HTTP and has been available in Exchange Online for a time before the release of it on-premises. After this protocol was released, support was made available for it from a range of client versions and currently it works with Outlook 2010 and later (as long as you are on the supported versions and not Outlook 2010 SP1 for example). There is no support for MAPI/HTTP on Outlook 2007 which is why this client will stop working with Office 365 in October 2017 (as Microsoft turn off RPC/HTTP at that time).

With this new protocol in place for Outlook 2010, it is important to ensure that the AD FS claim rule for x-ms-client-application with a value of Microsoft.Exchange.RPC is updated to include Microsoft.Exchange.Mapi and Microsoft.Exchange.Nspi. And come October 2017 when RPC/HTTP is turned off in Exchange Online, claim rules could be updated to remove Microsoft.Exchange.RPC from their checks.

Therefore if you are an Exchange Online user with claims rules for AD FS you need to add the following rules. These would have the same IP ranges as your Microsoft.Exchange.RPC rule and would be identical to this rule in every way, just the x-ms-client-application string needs to look for the following (one rule for each):

  • Microsoft.Exchange.Mapi
  • Microsoft.Exchange.Nspi

The Microsoft.Exchange.Mapi rule can be named “Outlook MAPI/HTTP” and the Nspi rule can be named “Outlook MAPI Address Book”. You need to keep the Exchange Web Services and Exchange Address Book rules in place, but once all users are migrated to MAPI/HTTP you can remove the Microsoft.Exchange.RPC rule.

Note that Exchange Online caches your AD FS credential’s for 24 hours for connections from a single IP address, so if you successfully connect to Exchange Online (say because you have not got the Microsoft.Exchange.Mapi block in place) then you will not connect back to AD FS for 24 hours and so not be affected by new rules that are added after you connect. If you want to test if your new Microsoft.Exchange.Mapi block rules work then you need to connect to Exchange Online via a different IP address, so a trip to the nearest coffee shop in the quest for network lockdown on your companies expense is called for!

Also it is possible to create a single rule rather than the multiple rules listed above. A single rule would contain the claim rule clause similar to the below:

exists([Type == "", Value =~ "Microsoft.Exchange.WebServices|Microsoft.Exchange.RPC|Microsoft.Exchange.Mapi|Microsoft.Exchange.Nspi"])

Note that this is different from what the Rule Builder wizard creates, as that creates a string comparison value, which is compared to the result with ==, but when more than one possible string is stored in the value the comparison operator needs to be =~ which is string compared to RegEx, as the | sign makes the value in the claim rule a RegEx expression.

Legacy Clients and Outlook 2016

Outlook 2016 supports modern authentication out of the box (unlike Outlook 2013 which required client side registry keys and certain hotfixes). But you still need to enable Modern Authentication on your tenant in Exchange Online.

To check if Modern Auth is enabled run Get-OrganizationConfig | FL *OAuth2* from a remote PowerShell session connected to Exchange Online. The value of OAuth2ClientProfileEnabled will be $True if Modern Authentication is enabled. If it is not enabled then Outlook 2016 will use Legacy authentication protocols and so will be blocked by the claim rules discussed here. If you enable Modern Auth though, Outlook 2010 is impacted by Claim Rules and Outlook 2013 June 2015 update + reg keys and Outlook 2016 and later are not impacted by the claim rules above (see below for these). Outlook with Modern Auth is restricted with the use of Conditional Access in Azure AD Premium. If you do not turn on Modern Auth you can use the legacy auth claim rule restrictions until the point where Microsoft enable Modern Auth for you – therefore it is best that if you are doing this then make your changes at your schedule and enable Modern Auth now, EMS to block Outlook 2016 and claim rules to block Outlook 2010 until the point where Microsoft removes support for that product.

Therefore a single claims rule for blocking legacy auth would look like the following:

exists([Type == ""])
 && exists([Type == "", Value =~ "Microsoft.Exchange.WebServices|Microsoft.Exchange.RPC|Microsoft.Exchange.Mapi|Microsoft.Exchange.Nspi"])
 && NOT exists([Type == "", Value =~ "\b51\.141\.11\.170\b"])
 && exists([Type == "", Value == "/adfs/services/trust/2005/usernamemixed"])
 => issue(Type = "", Value = "true");

Note that in the above, though this comes from ADFS on Windows Server 2012 R2, we are still recommending the use of x-ms-proxy and x-ms-forwarded-client-ip. That is because the insidecorporatenetwork claim cannot be used for legacy authentication, as all auth request originate from Exchange Online (active auth) which is never on-premises! This claim rule is added to the Office 365 Relying Party Trust Issuance Authorization Rules after the default Permit Access to All Users rule that the Convert-MSOLDomainToFederated cmdlet or AADConnect configures. The claim rule permits access to all, then denies access if an legacy authentication session happens for Outlook protocols where the forwarded IP address is not the public IP for your LAN

Use Claim Rules to Block Modern Auth Clients

So the final scenario here, newly added to this old post in April 2017, requires issuing deny’s to claims when insidecorporatenetwork is false for the protocols/user agents that you want to block. For example the following will block all modern auth requests from outside the network from all applications apart from ActiveSync and AutoDiscover (as AutoDiscover is used by ActiveSync to set up the mobile device initially):

exists([Type == "", Value == "false"])
 && NOT exists([Type == "", Value =~ "Microsoft.Exchange.ActiveSync|Microsoft.Exchange.Autodiscover"])
 && exists([Type == "", Value == "/adfs/ls/"])
 => issue(Type = "", Value = "true");

Enabling ActiveSync on a Sony P1i with a GoDaddy Certificate

Posted on Leave a commentPosted in 2003, 2007, activesync, exchange, mobile phones, pki

GoDaddy issued certificates are not trusted by the Sony P1i phone and so if you are using a GoDaddy issued digital certificate for ActiveSync on one of these phones you will be prompted to accept the certificate at each sync. As this kills the purpose of push email sync you will want to stop the prompt.

You do this by installing the GoDaddy trusted root certificate. On any Windows computer that works when connecting to a website protected with your GoDaddy certificate run mmc.exe and add the Certificates snap-in, selecting the local user option. Browse to Trusted Root Certification Authorities and click on the Certificates node. Find and right-click the Go Daddy Class 2 Certification Authority and choose All Tasks > Export. Export the certificate as a DER encoded binary X.509 (.CER) file to a folder on that computer.

Email that file to the owner of the Sony P1i and sync the phone to download their email (confirming the prompt that we want to remove). Open the email and download the attachment. Once the attachment is downloaded (which might involve syncing again and confirming the certificate prompt) open the attachment. The phone will install the certificate into its certificate store. No more prompts!