Exchange (Anglais)

Announcing availability of 250,000 public folder Exchange 2010 hierarchy migrations to Exchange Online

Exchange Team Blog -

Last September, we announced a beta program to validate onboarding of public folder data from Exchange 2010 on-premises to Exchange Online with large public folder hierarchies (100K – 250K public folders).

We are glad to announce that Exchange Online now officially supports public folder hierarchies of up to 250K public folders in the cloud – more than double the previously supported limit of 100K public folders!

In line with our efforts to help larger customers onboard to Exchange Online, we would like to additionally announce support for the migration of public folders from on-premises Exchange 2010 to Exchange Online, for customers with folder hierarchies up to 250K.
What does all this mean?

  • All existing customers using Exchange Online who would have been constrained by the limit of 100K public folders, can now expand their Exchange Online public folder hierarchy up to 250K folders.
  • Any on-premises customers running Exchange 2010 with up to 250K public folders, who would like to onboard to Exchange Online, can now do so.

Note: At this point in time, Exchange 2013/2016 customers with over 100K folders can still only migrate up to 100K public folders to Exchange Online. However, once they have migrated to Exchange Online, they can expand their hierarchy up to 250K public folders. We are working to resolve this limitation for our Exchange 2013/2016 customers in the future.

Keep checking this blog for further updates on the subject.

Public folder team

Modern public folders logging and when to use it

Exchange Team Blog -

Hello again! In our last article, we discussed recommendations for deployment of public folders and public folder mailboxes. In this post, we will be discussing methods and tips for monitoring connections being made to the Public Folder mailboxes with the help of different log types available in Exchange Server 2013 and Exchange Server 2016. This article mainly focuses on logging related to public folder mailbox activity and provides information on how to analyze these logs to get the information on the usage of public folders. Let’s get to it!

How do I log and report on different public folder connections?

As we discussed in previous post, the ability to estimate the number of connections being made to public folder mailboxes is very helpful as deployment guidance for public folders partially revolves around connection counts. As of today, currently available logging methods will not reveal individual names of public folders clients are connecting to but will contain information about public folder mailboxes being accessed by clients.

Depending on what information you are looking to gather there are several flavors of logging you can consider.

  • Autodiscover logs – use these to learn which public folder mailboxes Outlook clients get sent to during the Autodiscover process.
  • Outlook Web App logs – use these to learn which default public folder mailboxes Outlook Web App clients get sent to during connection process. As stated in our first article, the default public folder mailboxes could be either the ones which are provided randomly to the requesting OWA client or could be a hard coded default public folder mailbox assigned to a specific user’s mailbox.
  • RPC Client Access logs & MAPI Client Access on Microsoft Exchange 2013 Mailbox Servers – use these to find out which public folder mailboxes on a specific mailbox server the users are connecting using RPC/HTTP and MAPI/HTTP protocols. These logs can be used with Microsoft Exchange 2013.
  • MAPI/HTTP logs in Microsoft Exchange 2016 Servers – learn which public folder mailboxes your MAPI/HTTP clients are connecting to. These logs should only be used with Microsoft Exchange 2016.

Let’s get started! In the upcoming section, we are going to make extensive use of Log Parser Studio (LPS) tool which will be used to parse the logs to help get the required data. It is a great tool and if you are not aware of it, I would recommend you to first visit the following links and get yourself familiarized with it first:

Autodiscover logs: Which public folder mailboxes are Outlook clients connecting to? Why do Autodiscover logs need to be investigated?

The Autodiscover service is responsible for informing Outlook clients where and how to connect to a public folder mailbox. This may be so Outlook can display the public folder hierarchy tree, or to make a public logon connection to access content within a public folder mailbox.

Thus, the Autodiscover logs can be useful to administrators in determining which public folder mailboxes are being returned by the Autodiscover service. This information can be very helpful in large multi-site environments when trying to identify possible improvements in public folder mailbox or public folder locations.

To understand this better let’s consider a common scenario that an administrator might face in the environment. An administrator may need to determine which public folder mailboxes are being returned to the end users when they connect from different sites using Outlook. This can be a challenging task if there are many sites and users resulting in a huge data set. Rather than try to analyze the data manually there needs to be an automated way which can get the desired outcome.

This is where the Log Parser Studio (LPS) queries can be used to parse the Autodiscover logs on mailbox servers to get us the required data for further investigation and actions.

Where are Autodiscover logs located?

Autodiscover logs should be investigated on Mailbox servers and can be found in the following default path for Microsoft Exchange 2013/2016:

  • C:\Program Files\Microsoft\Exchange Server\V15\Logging\Autodiscover

(The location may change if the installation path is different from the default.)

Autodiscover Method 1, server-side.

At this point it is assumed Log Parser Studio has been installed.

1. Open the Log Parser Studio by double clicking the LPS.exe application file as shown in the below image which will launch the LPS.

2. Once the LPS launches, at the top of the left corner, select File and then click on New Query which will open new tab for query

3. Copy the sample query mentioned in the example below to the query section and set the Log Type to EELXLOG

/* New Query */
SELECT Count(*) As Hits,
EXTRACT_PREFIX(EXTRACT_SUFFIX(GenericInfo, 0, 'Caller='), 0, ';') as User-Name,
EXTRACT_PREFIX(EXTRACT_SUFFIX(GenericInfo, 0, 'ResolveMethod='), 0, ';') as Method,
EXTRACT_PREFIX(EXTRACT_SUFFIX(GenericInfo, 0, 'ExchangePrincipal='), 0, ';') as PF-MBX,
EXTRACT_PREFIX(EXTRACT_SUFFIX(GenericInfo, 0, 'epSite='), 0, ';') as Site-Name
WHERE Method LIKE '%FoundBySMTP%'
GROUP BY User-name, Method, PF-MBX, Site-Name
/* End Query */

4. Lock the query to avoid any modifications by clicking on the Lock icon once as shown below

5. Click on the Log file manager button available at the top panel window of LPS to add required logs as shown in the below image.

6. Specify the log location of the required log files and select one file in the folder where the logs reside and click Open and hit OK

7. In this example, I have accessed and selected logs from a specific mailbox server by specifying the UNC path of the server and log location. It is possible to add multiple folders of same log type from different servers and parse all of them at same time.

8. The only thing left is to execute the query and to do so just click the execute query button. in the LPS panel. The output will be similar format to the one shown

Note: This LPS query will provide a report that includes information on what users are connecting to what public folder mailboxes along with the Active Directory site the mailbox resides in:

Why might this type of report be useful?

The output of this data may help an administrator determine if a significant number of users in a geographic location would benefit from a public folder mailbox to be located closer to them. Depending on the results administrator can make decision to deploy additional Hierarchy Only Secondary Public Folder Mailbox (HOSPFM) in those geographic sites and then set the DefaultPublicFolderMailbox property on the mailboxes so that they contact the PF Mailbox (HOSPFM) in their own site for fetching the public folder hierarchy information and in turn the user experience while accessing public folders will be better!

One more point to be noted is that only Microsoft Exchange 2016 Autodiscover logs will show the Site Name. This logging feature functionality is not present in Microsoft Exchange 2013 and will require additional manual work to figure out the site location of the mailbox.

Note: The example query will return additional Autodiscover log entries for non-public folder mailbox queries. If you have standardized naming convention for your public folder mailboxes you could enhance the query to only return results where the ExchangePrincipal value contains a portion of your naming convention.

Autodiscover Method 2, client-side.

You can also use the Test E-mail AutoConfiguration tool from within the Outlook client to perform a single user test. This will provide you with which public folder mailbox is being returned to a single end user by Autodiscover service for hierarchy connections.

To start the Test E-mail AutoConfiguration tool, follow these steps:

  1. Start Outlook.
  2. Hold down the Ctrl key, right-click the Outlook icon in the notification area, and then click Test Email AutoConfiguration.
  3. Verify that the correct email address is in the E-mail Address box. You do not need to provide a password if you are running a test for the currently logged in user. If you are testing a different user account than the one currently logged into the machine, then you will need to provide both the email address and password for that account.
  4. In the Test Email AutoConfiguration window, click to clear the Use Guessmart check box and the Secure Guessmart Authentication check box.
  5. Click to select the Use Autodiscover check box, and then click Test.

Below is the excerpt from the XML File gathered from Test E-mail AutoConfiguration:

As you can see above the user will be using the public folder mailbox to make a hierarchy connection.

Please note this is only an example; if you follow our guidance you will not have any users making connections to your primary public folder mailbox for hierarchy or content.

Outlook Web App logging: which default public folder mailboxes do Outlook Web App clients get sent to?

When users log into Outlook on the Web (OWA) in an environment with public folders, the public folder mailbox used for hierarchy information could be a static default public folder mailbox (if one has been set manually on the mailbox), or a random public folder mailbox. It should be noted Autodiscover is not utilized when accessing public folders using OWA. Instead, OWA uses its own function to return a default public folder mailbox to the requesting user. As such, you will not find OWA users in the previously mentioned Autodiscover logs.

Location of OWA logs

All logging data for Outlook on the Web (OWA) including public folder access will be in the following folder on Exchange 203 Client Access Servers or Exchange 2016 Mailbox Server:

  • C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Owa

Here is an example of a Log Parser Studio query to fetch data from OWA logs:

/* New Query */
SELECT COUNT(*) as hits,
AnchorMailbox AS PF-MBX,AuthenticatedUser,ProtocolAction,TargetServer,HttpStatus,BackEndStatus,Method,ProxyAction
GROUP BY PF-MBX,AuthenticatedUser,ProtocolAction,TargetServer,HttpStatus,BackEndStatus,Method,ProxyAction

Log type is set to EELXLOG

Fields used in Query Field Description AnchorMailbox The default public folder mailbox being returned to the user AuthenticatedUser Users accessing the PF mailbox ProtocolAction Action being taken by the user while accessing public folder such as GetFolder, Getitem, Createitem, Finditem TargetServer Provides information on which Exchange Server the query is being redirected to fetch the public folder mailbox HttpStatus & BackEndStatus Provides information on connection status for the public folder mailbox connection

Output is as follows:

In the output below the AnchorMailbox value is the public folder mailbox the end user is accessing for their hierarchy connection.

In the above sample result, the user “Administrator” is logged into OWA and is accessing public folder mailbox HOSPFM-001 which is returned as default public folder mailbox. We know Administrator is using this public folder mailbox for a hierarchy connection as OWA logging currently does not capture information for public folder content access.

In Log Parser Studio, you can save this query and execute it in batches to get concurrent logging. You can also add entire folder instead of individual logs which will make it easier to parse existing and newly written logs. The number of hits returned and being logged against specific public folder mailbox by the user will reveal the public folder mailboxes which are most often being used for fetching hierarchy information.

How can this logging be useful?

Since OWA does not use Autodiscover to fetch a default public folder mailbox, it may make sense to identify the public folder mailboxes being returned to users when they use OWA. Like our earlier example for Outlook, it may identify cases were OWA is using public folder mailboxes that are a less optimal performance choice. Keep in mind that for OWA a better performing hierarchy mailbox is one closer to the Exchange mailbox server where OWA is being rendered rather than one closer to where the user’s Outlook client sits. Depending on your Exchange deployment and where OWA is served this may mean making choices about your public folder mailbox deployment based on what client is more often used in your environment to provide that client more optimal experience.

As mentioned in my earlier post the recommendation for users in geographically disperse sites is to deploy additional Hierarchy Only Secondary Public Folder Mailbox (HOSPFM) and set the DefaultPublicFolderMailbox property on the user mailboxes in those sites to ensure a public folder mailbox within the Site is being used by the respective users for hierarchy.

RPC Client Access logs & MAPI Client Access logs on Mailbox Servers (Microsoft Exchange 2013)

While AutoDiscover logs can provide information about public folder mailboxes Outlook is learning about and may potentially connect to, the RPC Client Access (RPC/HTTP) & MAPI Client Access (MAPI/HTTP) logs will provide information about actual public folder mailbox connections established by users.

Both log types in this case can be combined in LPS in single query and parsed to get some useful information on Public folder mailboxes being accessed.

Default location of logs:

  • MAPI Client Access: C:\Program Files\Microsoft\Exchange Server\V15\Logging\MAPI Client Access
  • RPC Client Access: C:\Program Files\Microsoft\Exchange Server\V15\Logging\RPC Client Access
Which public folder mailboxes on a specific server are users connecting to?

Consider the scenario consisting of a multi-site environment where the administrator is given a task to determine which users are connecting to public folder mailboxes on a specific server. Let’s say E15-CLASS-MB1 is the Mailbox server hosting the public folder mailboxes and the administrator needs to find who is making connections to them. Depending on the results decisions can be made whether or not it makes sense to move certain public folder mailboxes closer to a certain user location based on who actually uses that public folder mailbox. Below are the steps to be followed:

1. Open the LPS on the machine. Copy and paste the query below in the New Query Window in LPS as per the instructions mentioned earlier in the post.

/* Public Folder Mailboxes Hits */
SELECT Count(*) as Hits,
operation as Operation,
user-email as [SMTP Address],
EXTRACT_PREFIX(EXTRACT_SUFFIX(operation-specific, 0, 'Logon:'), 0, ';') as MailBox-LegacyExchangeDN,
EXTRACT_PREFIX(EXTRACT_SUFFIX(operation-specific, 0, 'on '), 0, ';') as Server
WHERE operation-specific LIKE '%Logon: Public%' AND Server LIKE '%E15-CLASS-MB1%'
GROUP BY Operation, Mailbox-LegacyExchangeDN, Server, [SMTP Address]

Fields used in query:

Field Description Operation Used to extract the logons for public folder mailboxes SMTP Address Email address of the users accessing the public folder mailbox Mailbox LegacyExchangeDN Public folder mailboxes in form of LegacyExchangeDN Server Connection requests coming to the server

2. Set the Log File type to EELLOG. Add the required folders to parse from respective mailbox servers and start the query by clicking Query button in LPS Panel.

3. The above sample query exports the results in CSV format. If there is no specific location specified in the query to export the report the default export directory will be used.

4. Once the query has finished executing, it will export the output to a CSV file, which can be further formatted as table.

5. To do so Open the CSV file. By default, the CSV file will not have any formatting and will show the output in similar format.

6. Select all the cells which contains the data and then select Insert tab and click on Table which will open a new pop-up window to Create Table. Click on OK button

7. A new table will be created in structured format to help sort the data and filter it.

8. The filtering can be used to sort the data by available fields such as SMTP Address, Mailbox-LegacyExchangeDN

If the LegacyExchangeDN output is trimmed and you cannot figure out the full public folder mailbox name, then you can copy the LegacyExchangeDN value of the public folder mailbox in Exchange PowerShell and use it to find the name of relevant mailbox as shown below:

You now have information regarding public folder mailboxes being actively used by users on the server. Not only which ones, but also the frequency. This can be utilized by the administrator to make public folder deployment decisions.

MAPI/HTTP Logs (Exchange 2016 Only)

In Microsoft Exchange 2016 there is one additional folder created specially to log MAPI/HTTP protocol traffic. Recent updates to Exchange 2016 have removed MAPI/HTTP traffic from the MAPI Client Access log. If not all of your Outlook for Windows clients are connecting to Exchange 2016 via MAPI/HTTP you may need to analyze both logs to get a full picture of your public folder mailbox connections until such time that all Outlook for Windows clients are using MAPI/HTTP. All MAPI/HTTP logging is now logged in to the MapiHttp folder.

The logs reside in the following default path:

  • C:\Program Files\Microsoft\Exchange Server\V15\Logging\MapiHttp\Mailbox

Exchange Server 2016 uses slightly different field names for MAPI/HTTP logging, and a query used previously with Exchange Server 2013 for parsing the MAPI/HTTP traffic in the older MAPI Client access logs will no longer work with Exchange Server 2016.

Which public folder mailboxes are your MAPI/HTTP clients connecting to?

MAPI/HTTP logs can be investigated for connections established to public folder mailboxes over the MAPI/HTTP protocol in Exchange Server 2016 using the below query in Log Parser.

Ensure the Log Type is set to EELXLOG

/* New Query */
SELECT Count(*) as Hits,MailboxId AS PF-Mailbox, MDBGuid AS Database, ActAsUserEmail AS SMTP-Address, SourceCafeServer FROM '[LOGFILEPATH]'
WHERE OperationSpecific LIKE '%PublicLogon%'
GROUP BY PF-Mailbox,Database,SMTP-Address, SourceCafeServer

Fields used in this query: Field Description Operation-Specific Used to extract the logons for public folder mailboxes SMTP Address Email address of the users accessing the public folder mailbox PF-mailbox Mailbox Guid of PF mailbox SourceCafeServer Connection request coming to the server Database Shows which specific mailbox database which host public folder mailboxes is being connected to

Once the query is executed it will gather the information and will populate the results in the below format which can be exported to CSV and output can be gathered in batches by running the query in batches to fetch more data.

Sample output:

In Exchange 2016 MAPI/HTTP logs, the name of the public folder mailbox is not revealed but, the log does capture the mailbox GUID of the public folder mailbox which can be used in PowerShell command to fetch the actual public folder mailbox name.

Note: If there are any users hosted in Exchange 2016 who still use the RPC/HTTP protocol, the RPC/HTTPS query previously shown can be used to fetch the data for these specific users.

How this data can be useful to administrators?

The administrators can run this report repeatedly in batches and gather the data in CSV file. The data can be collated for the results from different batches and investigated for public folder mailboxes being accessed frequently by the users. From there administrators should be able to find if there are any public folder mailboxes being used heavily by the users and then make decision to move any specific public folder mailboxes or maybe even specific public folders closer to users in specific location.

There are so many log types. When should I use what?

It is true there are many different logs in Exchange Sever showing similar information. Depending on what protocol your users use you may make decisions on the log type to parse. Autodiscover logs will give a combined view of what public folder mailboxes users are at least trying to access once. If you have content-only public folder mailboxes in your environment that are excluded from serving hierarchy and not directly assigned to users as their default, you may be able to determine if some are never accessed and may contain content worthy of purging. If you need a more granular view of the world, and the ability to generate some sort of heat map you may choose to go with more protocol specific logs. These logs will provide data on each time the client creates a new connection to a public folder mailbox and allow you to determine more than just if the client learned about it through Autodiscover but if it is being used far more heavily by many users over time. The options are varied and up to you to choose based on your need.


In this post, I have discussed and provided information on different types of public folder logging and how this logging can be useful to administrators to identity heavily used public folder mailboxes, which in turn can be used to do planning and deployment of public folders in the environment. In upcoming posts, we will discuss topics related to public folder management and quota related information

I would like to thank Brian Day, Ross Smith IV & Nasir Ali for their inputs while reviewing this content and validating the guidance mentioned in the blog post, Special thanks to Kary Wall for providing inputs with Log parser studio queries and Nino Bilic for helping to get this blog post ready!

Siddhesh Dalvi
Support Escalation Engineer

Discontinuation of support for Session Border Controllers in Exchange Online Unified Messaging

Exchange Team Blog -

In July 2018, we will no longer support the use of Session Border Controllers (SBC) to connect 3rd Party PBX systems to Exchange Online Unified Messaging (UM). We’re making this change to provide a higher quality of service for voicemail, using standard Exchange and Skype for Business protocols. Customers considering a new deployment of this scenario should be aware that they will have a little less than a year to complete one of the migrations below. Customers with existing deployments remain fully supported until July 2018, including moving voicemail-enabled mailboxes from Exchange on-premises and voicemail-enabling new mailboxes.

The following configurations are not affected by this change:

  • Skype for Business Server (on-premises) connected to Exchange Online UM
  • 3rd party voicemail solutions that deposit voicemail messages into Exchange Online mailboxes through APIs, rather than an SBC connection
  • All forms of Exchange Server UM (on-premises)

There are several alternative solutions for impacted customers, one or more of which must be implemented prior to July 2018.

  • Option 1: Complete migration from 3rd party on-premises PBX to Office 365 Cloud PBX.
  • Option 2: Complete migration from 3rd party on-premises PBX to Skype for Business Server Enterprise Voice on-premises.
  • Option 3: For customers with a mixed deployment of 3rd party PBX and Skype for Business, connect the PBX to Skype for Business Server using a connector from a Microsoft partner, and continue using Exchange Online UM through that connector. For example, TE-SYSTEMS’ anynode UM connector can be used for that purpose.
  • Option 4: For customers with no Skype for Business Server deployment or for whom the solutions above are not appropriate, implement a 3rd party voicemail system.

Although only a small number of customers are affected by this change, we know that planning for changes to voice platforms requires time to evaluate options, and to implement the selected option. We encourage you to start this process soon. For more information, please visit the following pages:

You can also ask questions regarding these changes on the Office 365 Tech Community.

Exchange Team

Released: June 2017 Quarterly Exchange Updates

Exchange Team Blog -

The latest set of Cumulative Updates for Exchange Server 2016 and Exchange Server 2013 are now available on the download center. These releases include fixes to customer reported issues, all previously reported security/quality issues and updated functionality.
Updated functionality in Cumulative Update 6

With Cumulative Update 6 we are adding two highly anticipated features; Sent Items Behavior Control and Original Folder Item Recovery. These features are targeted to Exchange Server 2016 only and will not be included in Exchange Server 2013. Exchange Server 2013 already has its own implementation of Sent Items Behavior Control which is different than the version we are releasing today. The Cumulative Update 6 behavior is more closely aligned with how this worked in Exchange Server 2010. Due to architectural differences, the configuration of this feature is not retained if mailboxes are moved between Exchange Server 2010 and Exchange Server 2016 or between Exchange Server 2013 and Exchange Server 2016.
Latest time zone updates

All of the packages released today include support for time zone updates published by Microsoft through May 2017.
TLS 1.2 Exchange Support Update

We previously announced that Cumulative Update 6 would include support for TLS 1.2. The updates released today do have improved support for TLS 1.2 but we are not encouraging customers to move to a TLS 1.2 only environment at this time. We are working with the Windows and .Net teams to make configuring TLS 1.2 a more streamlined experience. Customers should continue to watch this space and be prepared to deprecate TLS 1.0 and 1.1 in the near future.
.Net 4.7 compatibility with these releases

The Exchange team is still completing validation of the June releases with .Net 4.7. We have not found any compatibility issues at this time, but are asking customers to delay using .Net 4.7 until we have completed our validation. Once this validation is complete we will provide further guidance on .Net 4.7 and Exchange Server.
Release Details

KB articles that describe the fixes in each release are available as follows:

Exchange Server 2016 Cumulative Update 6 does include new updates to Active Directory Schema. If upgrading from an older Exchange version or installing a new server, Active Directory updates may still be required. These updates will apply automatically during setup if the logged on user has the required permissions. If the Exchange Administrator lacks permissions to update Active Directory Schema, a Schema Admin must execute SETUP /PrepareSchema prior to the first Exchange Server installation or upgrade. The Exchange Administrator should execute SETUP /PrepareAD to ensure RBAC roles are current.

Exchange Server 2013 Cumulative Update 17 does not include updates to Active Directory, but may add additional RBAC definitions to your existing configuration. PrepareAD should be executed prior to upgrading any servers to Cumulative Update 16. PrepareAD will run automatically during the first server upgrade if Exchange Setup detects this is required and the logged on user has sufficient permission.
Additional Information

Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation.

Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.

Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current (e.g., 2013 CU17, 2016 CU6) or the prior (e.g., 2013 CU16, 2016 CU5) Cumulative Update release.

For the latest information on Exchange Server and product announcements please see What’s New in Exchange Server 2016 and Exchange Server 2016 Release Notes. You can also find updated information on Exchange Server 2013 in What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.

Note: Documentation may not be fully available at the time this post is published.

Post release update concerning Cumulative Update 5

Several customers have reported problems with 3rd party solutions which provide brick level backup or single mailbox recovery as a reported feature after installing Cumulative Update 5. Cumulative Update 5 included an update to our database schema which caused some of these products to not function as they had previously. That change carries forward into Cumulative Update 6 as well. The practice of updating the database schema has long been in place with Exchange Server. Microsoft has urged developers to not consider the schema to be immutable nor to program against it. The schema is not publicly defined and is a structure internal to the operation of Exchange Server. Access to store level objects is provided through publicly documented interfaces and structures only.

The Exchange Team

.NET Framework 4.7 and Exchange Server

Exchange Team Blog -

We wanted to post a quick note to call out that our friends in .NET are releasing .NET Framework 4.7 to Windows Update for client and server operating systems it supports.

At this time, .NET Framework 4.7 is not supported by Exchange Server. Please resist installing it on any of your systems after its release to Windows Update.

We will be sure to release additional information and update the Exchange supportability matrix when .NET Framework 4.7 becomes a supported version of .NET Framework with Exchange Server. We are working with the .NET team to ensure that Exchange customers have a smooth transition to .NET Framework 4.7, but in the meantime, delay this particular .NET update on your Exchange servers. Information on how this block can be accomplished can be found in article 4024204, How to temporarily block the installation of the .NET Framework 4.7.
It’s too late, I installed it. What do I do now?

If .NET Framework 4.7 was already installed and you need to roll back to .NET Framework 4.6.2, here are the steps:

Note: These instructions assume you are running the latest Exchange 2016 Cumulative Update or the latest Exchange 2013 Cumulative Update as well as .NET Framework 4.6.2 prior to the upgrade to .NET Framework 4.7 at the time this article was drafted. If you were running a version of .NET Framework other than 4.6.2 or an older version of Exchange prior to the upgrade of .NET Framework 4.7, then please refer to the Exchange Supportability Matrix to validate what version of .NET Framework you need to roll back to and update the steps below accordingly. This may mean using different offline/web installers or looking for different names in Windows Update based on the version of .NET Framework you are attempting to roll back to if it is something other than .NET Framework 4.6.2.

1. If the server has already updated to .NET Framework 4.7 and has not rebooted yet, then reboot now to allow the installation to complete.

2. Stop all running services related to Exchange.  You can run the following cmdlet from Exchange Management Shell to accomplish this: 

(Test-ServiceHealth).ServicesRunning | %{Stop-Service $_ -Force}

3. Depending on your operating system you may be looking for slightly different package names to uninstall .NET Framework 4.7.  Uninstall the appropriate update.  Reboot when prompted.

  • On Windows 7 SP1 / Windows Server 2008 R2 SP1, you will see the Microsoft .NET Framework 4.7 as an installed product under Programs and Features in Control Panel.
  • On Windows Server 2012 you can find this as Update for Microsoft Windows (KB3186505) under Installed Updates in Control Panel.
  • On Windows 8.1 / Windows Server 2012 R2 you can find this as Update for Microsoft Windows (KB3186539) under Installed Updates in Control Panel.
  • On Windows 10 Anniversary Update and Windows Server 2016 you can find this as Update for Microsoft Windows (KB3186568) under Installed Updates in Control Panel.

4. After rebooting check the version of the .NET Framework and verify that it is again showing version 4.6.2.  You may use this method to determine what version of .NET Framework is installed on a machine. If it shows a version prior to 4.6.2 go to Windows Update, check for updates, and install .NET Framework 4.6.2.  If .NET Framework 4.6.2 is no longer being offered via Windows Update, then you may need to use the Offline Installer or the Web Installer. Reboot when prompted.  If the machine does show .NET Framework 4.6.2 proceed to step 5.

5. After confirming .NET Framework 4.6.2 is again installed, stop Exchange services using the command from step 2.  Then, run a repair of .NET 4.6.2 by downloading the offline installer, running setup, and choosing the repair option.  Reboot when setup is complete.

6. Apply any security updates specifically for .NET 4.6.2 by going to Windows update, checking for updates, and installing any security updates found.  Reboot after installation.

7. After reboot verify that the .NET Framework version is 4.6.2 and that all security updates are installed.

8. Follow the steps here to block future automatic installations of .NET Framework 4.7.

The Exchange Team

Announcing Original Folder Item Recovery

Exchange Team Blog -

Cumulative Update 6 (CU6) for Exchange Server 2016 will be released soonTM, but before that happens, I wanted to make you aware of a behavior change in item recovery that is shipping in CU6.  Hopefully this information will aid you in your planning, testing, and deployment of CU6.

Item Recovery

Prior to Exchange 2010, we had the Dumpster 1.0, which was essentially a view stored per folder. Items in the dumpster stayed in the folder where they were soft-deleted (shift-delete or delete from Deleted Items) and were stamped with the ptagDeletedOnFlag flag. These items were special-cased in the store to be excluded from normal Outlook views and quotas. This design also meant that when a user wanted to recover the item, it was restored to its original folder.

With Exchange 2010, we moved away from Dumpster 1.0 and replaced it with the Recoverable Items folder. I discussed the details of that architectural shift in the article, Single Item Recovery in Exchange 2010. The Recoverable Items architecture created several benefits: deleted items moved with the mailbox, deleted items were indexable and discoverable, and facilitated both short-term and long-term data preservation scenarios.

As a reminder, the following actions can be performed by a user:

  • A user can perform a soft-delete operation where the item is deleted from an Inbox folder and moved to the Deleted Items folder. The Deleted Items folder can be emptied either manually by the user, or automatically via a Retention Policy. When data is removed from the Deleted Items folder, it is placed in the Recoverable Items\Deletions folder.
  • A user can perform a hard-delete operation where the item is deleted from an Inbox folder and moved to the Recoverable Items\Deletions folder, bypassing the Deleted Items folder entirely.
  • A user can recover items stored in the Recoverable Items\Deletions folder via recovery options in Outlook for Windows and Outlook on the web.
  • However, this architecture has a drawback – items cannot be recovered to their original folders.

Many of you have voiced your concerns around this limitation in the Recoverable Items architecture, through various feedback mechanisms, like at Ignite 2015 in Chicago where we had a panel that included the Mailbox Intelligence team (those who own backup, HA, DR, search, etc.). Due to your overwhelming feedback, I am pleased to announce that beginning with Exchange 2016 CU6, items can be recovered to their original folders!

How does it work?
  1. When an item is deleted (soft-delete or hard-delete) it is stamped with the LastActiveParentEntryID (LAPEID). By using the folder ID, it does not matter if the folder is moved in the mailbox’s hierarchy or renamed.
  2. When the user attempts a recovery action, the LAPEID is used as the move destination endpoint.

The LAPEID stamping mechanism has been in place since Exchange 2016 Cumulative Update 1. This means that as soon as you install CU6, your users can recover items to their original folders!




Are there limitations?

Yes, there are limitations.

First, to use this functionality, the user’s mailbox must be on a Mailbox server that has CU6 installed. The user must also use Outlook on the web to recover to the original folder; neither Outlook for Windows or Outlook for Mac support this functionality, today.

If an item does not have an LAPEID stamped, then the item will be recovered to its folder type origin – Inbox for mail items, Calendar for calendar items, Contacts for contact items, and Tasks for task items. How could an item not have an LAPEID? Well, if the item was deleted before CU1 was installed, it won’t have an LAPEID.

And lastly, this feature does not recover deleted folders. It only recovers items to folders that still exist within the user’s mailbox hierarchy. Once a folder is deleted, recovery will be to the folder type origin for that item.


We hope you can take advantage of this long sought-after feature. We continue to look at ways we can improve user recovery actions and minimize the need for third-party backup solutions. If you have questions, please let us know.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

TooManyBadItemsPermanentException error when migrating to Exchange Online?

Exchange Team Blog -

Some of you may have noticed that more migrations might be failing due to encountering ‘too many bad items’. Upon closer review, you may notice that the migration report contains entries referencing corrupted items and being unable to translate principals. I wanted to take a few minutes and provide more information to help understand what this means, why these are now occurring, and what can be done about them. Ready to geek out?

During a mailbox migration, there are several stages we go through. We start off with copying the folder hierarchy (including any views associated with those folders), then perform an initial copy of the data (what we call the Initial Sync). Once the initial data copy process is complete, we then copy rules and security descriptors. Reviewing a move report shows entries similar to these.

Stage: CreatingFolderHierarchy. Percent complete: 10
Initializing folder hierarchy from mailbox <guid>: X folders total
Folder hierarchy initialized for mailbox <guid>: X folders created
Stage: LoadingMessages
Copying messages is complete. Copying rules and security descriptors.

For our discussion today, we are interested in the stage of “Copying rules and security descriptors”. Security descriptors are Access Control Lists (ACLs), which are then comprised of Access Control Entries (ACEs, or the individual permissions entries) and stored in SDDL format. In the context of a mailbox, we include both the Mailbox security descriptor (Mailbox permissions) as well as Folder security descriptors (permissions on individual folders). When we look at the Mailbox Security descriptor, it should be noted that only Explicit mailbox permissions are copied. These would include permissions granted by using the Add-MailboxPermission cmdlet, by using the Exchange Management Console (2010) or Exchange Admin Center (2013 and 2016) to add Full Access rights. Any Inherited permissions are not evaluated during the copy process. For example, granting the Receive-As permission on a database object in Active Directory results in an Inherited Allow for Full Access for all mailboxes on that database. When mailboxes on that database are migrated to Exchange Online, those Inherited permissions will not get copied.

Now that we have briefly covered security descriptors, let’s look at the issue. About midway through 2016, a change was introduced to Exchange Online whereby if a security principal could not be successfully validated/mapped to an Exchange Online object, it would be marked as a bad item. Previously, the behavior was that invalid permissions would simply be ignored, and administrators were then left to wonder why some permissions no longer worked after the migration. With this new behavior, corrupt/invalid permissions are now logged so that administrators will know that there are problems with permissions. From my perspective as a Support Engineer, this is a change for the better because as Administrators, you are now able to see when there are issues with permissions. It is possible that this behavior will continue to evolve over time, but I would advise to become familiar with this new behavior so that you understand what is happening.

Now how does this affect you? Since we are now incrementing the bad item count for each corrupt/invalid permission, this means that if we encounter more corrupt/invalid permissions than your current bad item limit is set to (default is 10 for a migration batch), the migration will fail. Depending on the state of permissions, you could potentially see a LOT of bad entries being logged. If you are looking at the migration report text file (downloadable from the Exchange Online Portal), you may see entries similar to the following:

11/12/2016 8:44:43 AM [EXO MRS Server] A corrupted item was encountered: Unable to translate principals for folder “Folder Name”/”FolderNTSD”: Failed to find a principal from the source forest.
5/19/2016 6:33:50 PM [EXO MRS Server] A corrupted item was encountered: Unable to translate principals to the target mailbox: Failed to find a principal in the target forest that corresponds to the following source forest principal values: Alias: <alias>; DisplayName: <Display Name>; MailboxGuid: <mailbox guid>; SID: <SID of User>; ObjectGuid:
<Object GUID>; LegDN: <legacyExchangeDN>; Proxies: [X500:<legacyExchagneDN format>;;];.
5/19/2016 6:33:50 PM [EXO MRS Server] A corrupted item was encountered: Unable to translate principals to the target mailbox: Failed to find a principal in the target forest that corresponds to the following source forest principal values: SID: <SID of User>; ObjectGuid: <Object GUID>;.

So, what is the logic used to validate permissions?

I’m glad you asked! Here is the process spelled out. There are four basic steps to this process, broken out as follows.

  1. Exchange Online – I need to resolve this SID which is present in the security descriptor (Folder or Mailbox)
  2. Exchange Online – Make a request to the On-Premises MRS Proxy, passing the SID to resolve
  3. On-Premises MRS Proxy – Look up the SID against Active Directory and return a set of attributes (including primary SID and legacyExchangeDN)
  4. Exchange Online – Take the legExchangeDN value provided, and attempt to match it up with a user account in the cloud which has that stamped as an X500 proxy address.

Normally, Directory Synchronization will take care of stamping the legacyExchangeDN from each side as an X500 proxy address, but this does mean that the On-Premises legacyExchangeDN must match a Mail-enabled recipient (i.e. Mailbox, MailUser, Mail-enabled Security Group) in the cloud by an X500 Proxy. If it does not, then resolving that permission entry will fail.

I do want to differentiate between the different types of permissions errors you may see.

SourcePrincipalMappingException – these mean that when MRS Proxy tried to look up the SID against On-Premises Active Directory, it couldn’t be resolved. This is a common scenario when users leave the company and their accounts are deleted. You could also encounter these issues if the SID in question is part of the SIDHistory of an On-Premises account. When MRS Proxy attempts to look up the SID, we only search by ObjectSID or msExchMasterAccountSID. MRS Proxy does not evaluate against SIDHistory, so the SID failing to be resolved would be expected behavior. SIDHistory being populated won’t be a common scenario, but it is nonetheless something to be aware of.

Note: Exchange Online has a special built-in bad item limit of 1000 for these Source Principal Mapping errors, so these moves will not fail unless you encounter more than 1000 of these types of bad items.

TargetPrincipalMappingException – these mean that we can’t map the permission to a user account in the Target forest (Exchange Online). A common scenario here would be if a user or group was given permissions on a mailbox, but that user or group is not in your dirsync scope. After trying to move that mailbox via MRS, that user or group is not going to be present in Exchange Online, so this error would be expected. Another scenario is if a security group (not mail-enabled!) was used to assign permissions. Non mail-enabled security groups are not synchronized to Exchange Online, so they won’t exist in the Target forest.

To resolve this issue, there are really two options.

  1. Increase the bad item limit to account for permissions errors. In complex legacy environments where multiple Exchange versions have been in place, and there has been a lot of user turnover, I’ve seen where permissions errors can number into the thousands. Be prepared that you may need to increase the bad item limit to a number higher than you expect. The good news here is that with improvement to Exchange over the years, the odds of encountering actual bad messages is relatively slim, so odds are good that the vast majority of bad items are bad permissions. The second bit of good news here is that we log the type of bad item that is encountered and make this information available in the move report. I’ll show you how to dig into a move report and look at the bad items later on in this blog post.
  2. Cancel the move, fix the bad permissions from the folder or mailbox by either removing them or fixing the issue causing the user/group to not be resolved in Exchange Online, and then submit the move again. But – you may ask – what if I want to fix the permissions on the current move and then resume it? Well, I’m not going to stop you from fixing bad permissions. But I will tell you that it won’t make any difference for the current move. We only evaluate permissions once, at the end of the initial data copy. If the move fails due to bad items (permissions), even if you fix the bad permissions we won’t re-evaluate the now fixed-up permissions and allow the move to complete successfully. You either have to up the bad item limit, or remove the move and fix the permissions and submit a new move.

Now, I promised earlier that I would go through how to review the permissions errors. You can do this by using PowerShell and saving the move report into a variable where it is stored in memory. I typically have the move report exported out to an XML file because I don’t have direct access to customer tenant information. If you are reviewing failed moves within your own tenant, there is no need to do that if you don’t want. I’ll provide the context to do both just in case you want to know both methods.

To save the move report to a variable, you would run the following from PowerShell connected to Exchange Online.

$movereport = Get-MoveRequestStatistics <move request identity> -IncludeReport

To save the move report to an XML file, then import the XML file into PowerShell, you would run the following from PowerShell connected to Exchange Online.

Get-MoveRequestStatistics <move request identity> -IncludeReport | Export-CliXml c:\temp\movereport.xml

Once the file is saved, then you import it into PowerShell. Note that this PowerShell instance does not have to be connected to Exchange Online. It can be just a regular PowerShell instance.

$movereport = Import-CliXml c:\temp\movereport.xml

If you never dug into a move report, let me just say that there are all sorts of golden nuggets of information buried inside (which won’t show in the text file from the Portal, by the way!)

Now that you have the move report imported as a variable, you can access all the rich information within the report. We specified our variable earlier as $movereport, so we just need to call that variable, and access the information stored inside it.

$ – this gives you a list of all the bad items encountered. A cool tip is that you can use the Out-GridView PowerShell function to open another window with the list.

$ | Out-GridView

What is nice about the Grid View is that you can then filter the output. For example, to validate that all of your bad items are permissions errors, you can simply choose “Add criteria”, check the “Kind” box, and click “Add”.

Change “Contains” to “Does not contain”, and type Security. This will quickly show you if there are any other types of bad items.

Now that we have identified the behavior change, and gone over how to address it, let’s end by talking about what approach should be taken for migrating mailboxes.

The recommended approach to this new change in behavior would be to continue to migrate using low bad item counts, and then manually remediate those that fail. We recommend this approach because migrations that fail would indicate either a LOT of bad source permissions (more than 1000), or it indicates there are valid, working permissions On-Premises that are failing to be correctly mapped to objects in Exchange Online. Both of these conditions should not be common, so investigation would be warranted to ensure that you are in fact dealing with bad permissions.

Special thanks to Brad Hughes and the rest of the MRS team for their assistance and review of this content.

Ben Winzenz

S'abonner à Philippe BARTH agrégateur - Exchange (Anglais)