I wanted to write a quick note to make sure that our Hybrid customers have seen the following two recent improvements made to transport in Office 365, as both of them could be something that you will run into or might want to be aware of:
Enhanced non-delivery reports (NDRs) in Office 365
Office 365 now supports larger email messages—up to 150 MB
Just a quick note that we have released a new service that some of you might be interested in, called Exchange Online Advanced Threat Protection. This is a complementary service to already existing Exchange Online Protection (EOP) and extends to additional types of advanced threats. To learn more, head over here:
Exchange Online Advanced Threat Protection is now available
In the near future, hybrid customers will be able to take advantage of the REST APIs for both Office 365 and on-premises mailboxes.
The REST APIs (Mail, Calendar, and Contact APIs) simplify programming against Exchange by providing a familiar syntax that is designed with openness (e.g., open standards support JSON, OAUTH, ODATA) and flexibility (e.g., granular, tightly scoped permission to access user data). These APIs allow developers to connect from any platform, whether it be web, PC, or mobile. SDKs exist for.NET, iOS, Android, NodeJS, Ruby, Python, Cordova, and CORS for use in single page JavaScript web apps.
As announced at Microsoft Ignite, Exchange 2016 Cumulative Update 3 (CU3) includes support for the REST API integration with Office 365. This integration enables customers that are in a hybrid deployment with Office 365 to have a seamless authentication and application experience regardless of mailbox location.
In order to take advantage of the REST APIs in your hybrid deployment, you must implement these prerequisites.
All on-premises mailboxes that will utilize the REST APIs must be located on databases residing on Exchange 2016 servers.
All Exchange 2016 servers must be upgraded to CU3 or later. In addition, when upgrading an existing Exchange 2016 server to CU3, /PrepareAD must be executed in the on-premises environment to enable support for the REST specific cmdlets and parameters.
While Exchange 2016 and Exchange 2013 servers can coexist in the same load balanced array, Exchange 2013 does not provide REST API integration. Therefore, in order to support a seamless REST API experience, all Exchange 2013 servers must be removed from the load balanced array.
From a DNS perspective, the Autodiscover namespace and on-premises client namespace must have Internet DNS records.
CU3 introduces a new virtual directory to support the REST API, the /api virtual directory. If you have deployed a firewall or application gateway that inspects and restricts access based on the virtual directory being accessed, you will need to update the appropriate settings to allow access to the REST API virtual directory.
The REST API takes advantage of a new Autodiscover method for determining authentication and mailbox location. In order to ensure REST API applications can access the on-premises infrastructure correctly, you will need to update the appropriate firewall or application gateway settings to allow access to the /autodiscover/autodiscover.json virtual directory file.
In a soon to be released update to the Hybrid Configuration Wizard (HCW), support will be added for the REST API integration with on-premises environments. Specifically, the HCW will add a new authentication provider and register a hostname with the Azure security token service.
You must also ensure that your on-premises Active Directory is fully synchronized with Azure Active Directory.
We hope you will take advantage of the new functionality and capabilities offered by the REST API in your hybrid deployments.
For more information and code examples on the REST API, please see https://dev.outlook.com/.
Principal Program Manager
Office 365 Customer Experience
We had a lot of fun last week, with hundreds of sessions that covered vast variety of Microsoft services and products. If you were there – we hope that it was time well spent for you! We had many Microsoft experts in sessions and on the Expo floor to give you access and help answer some of the questions that you might have.
Now that Ignite 2016 session recordings are showing up online, we have gone though and picked a set of sessions that we thought might be interesting. There are many more:
Keynotes:
Protection:
Office 365 Groups:
Hybrid:
Core Exchange / Exchange Online:
Outlook:
Office 365 user / mail reporting:
See you next year!
We have already announced that Ignite 2017 is going to be in Orlando; in fact you can already pre-register!
Recently there has been some helpful activity over on the Microsoft Script Center for Exchange and Office 365 administrators. Here are 3 scripts that we wanted to call out, as well as a bit of an overview of what they do:
Please see specific script downloads for support options and more details.
Install Exchange 2016 Pre-requisites.ps1
This script installs and adds all of the needed software, features, roles, and server settings to a Windows Server 2012 R2 Operating System in preparation for an Exchange 2016 installation. No more looking for which roles or which required software to install. Simply launch this script, select an option, and it goes out to the Internet, gets the installs, silently completes them, and adds all of the required roles and features. After a reboot, you can then install Exchange 2016.
This script simplifies IT administrators installs for all the required additional software/modules for a proper Office 365 PowerShell connection experience. Included in this script is a text based menu with options for creating connections to the different Office 365 services. Due to the fact that some installs are .exe downloads, some are .msi installs, and some are from a .zip file, each install can be slightly different. You can find additional information on how to use this ps1 file in this blog post.
This is a PowerShell module, written to quickly log into any or all the Office 365 services with a simple verb-noun CMDLet format.
With this installed onto your local client machine, with a single CMDLet, all the steps to log into Office 365 are combined for you. You just have to put in the proper credentials and PowerShell does all the work. Additional information on how to use this module is in this blog post.
There you have it; a few fast, simple ways to help you get your job done a little bit easier and a little bit quicker.
And – this goes without saying – please validate that things will work in your environment!
Seeing that we have been busily working on various things related to Public Folder migration options recently, we wanted to ask you to help us get an updated view of what your migrations plans for public folders are. The survey will only take a couple of minutes to complete.
(Note that ‘2016’ in the link and title does not mean that you have to have PFs on Exchange 2016 already; it references to current calendar year.)
Thank you! We want to make sure that we are going after right migration scenarios.
In this blog post I wanted to go through the documented TechNet process for migrating legacy public folders to Exchange 2013/2016, expanded with real world guidance gained from field support. I have been involved in a number of legacy public folder data migrations to Exchange 2013/2016 and I wanted to pass along some of the lessons learned along the way. Please note: in case of discrepancies in various CMDlets used, TechNet article is the guidance you should follow.
Note for Exchange 2007 customers reading this guidance – Exchange 2010 is the only version of Exchange explicitly mentioned in the TechNet article as this version of the guidance focuses only on Exchange 2016, and Exchange 2007 is not supported in coexistence with it. The Exchange 2010 guidance applies equally to Exchange 2007 unless otherwise noted.
This step is not included in the TechNet article, but it is vital to ensure that the data set being migrated is complete. If your public folder infrastructure only consists of one public folder database, you may proceed to Step 1, downloading the migration scripts. If, on the other hand, your public folders are replicated among two or more databases, you must ensure that at least one of those databases contains a fully replicated data set. The process to move data from legacy to modern public folders focuses on only one legacy database as the source, so our effort here will concentrate on selecting the most appropriate public folder database, then verifying it has all public folder data successfully replicated into it.
1. First, download this script from the TechNet Script Gallery.
2. The output of the script is an HTML page showing several metrics, most importantly the listing of each public folder replica and the replication status of each folder expressed as a percentage. Hovering over the percentage will pop up the size and item count of a specific folder replica.
3. It is important to note that we do not use the data stored in the legacy Non_IPM_Subtree folders, such as OWAScratchPad, SCHEDULE+ FREE BUSY or OFFLINE ADDRESS BOOK in the new Exchange 2013/2016 Modern Public Folders. Only concern yourself with making sure you have one public folder database with a complete set of the user data folders.
This section is intended to cover the most common issue related to replication, not an exhaustive reference for the task. Bill Long’s Public Folder Replication Troubleshooting blog series is the first, best option for tracking down a difficult replication issue. If you do not find a solution here or in Bill’s blog posts, please contact Microsoft support and open a case to resolve your issue.
Not all folders have a replica in every database – in this case, use the AddReplicaToPFRecursive.ps1 script in the built in Scripts directory of your Exchange installation. Using the -Server and -ServerToAdd switches allows you to be specific about which is the source and target database in the process, so be prepared to run the script from Server1 to Server2 and vice versa to fully replicate two public folder databases. Depending on the amount of data to be replicated, it may take some time for the target database to converge. Rerun the Get-PublicFolderReplication script at intervals to verify progress.
Yes, the migration scripts are included in the scripts directory of the Exchange installation directory (don’t forget you can use CD $Exscripts to easily change to that directory in the Exchange Management Shell), but it is recommended that you download them fresh from the link above to ensure you get the latest version.
Perform all steps in this section in the Exchange Management Shell on your Exchange 2010 server.
1. Open the Exchange Management Shell on your Exchange 2010 server.
2. For verification purposes at the end of migration, run the following commands to take snapshots of your current public folder deployment:
I’ve seen customers use some form of file difference comparison utility to great effect here. The files generated with the previous three commands will be compared to the same files generated after the migration process is completed to verify consistency. Thus far, I’ve not had a customer suffer any data loss or experience permissions issues post migration.
3. If the name of a public folder contains a backslash (\), the public folders will be created in the parent public folder when migration occurs. Before you migrate, you need to rename any public folders that have a backslash in the name if you don’t want this to happen.
1. Open the Exchange Management Shell on your Exchange 2010 server.
2. Run the following command to create a file that maps the folder name to the folder size for each public folder you want to migrate. You’ll need to specify an accessible network share where the CSV file created by the following command is run, and you’ll need to specify the FQDN of your Exchange 2010 server.
This command needs to be run by a local administrator and will create a CSV file that contains two columns: FolderName and FolderSize. The values for the FolderSize column will be displayed in bytes. For example, \PublicFolder01,10000.
.\Export-PublicFolderStatistics.ps1 <Folder to size map path> <FQDN of source server>
Example:
.\Export-PublicFolderStatistics.ps1 “\\FileServer\Share\FolderSize.csv” “EX2010.corp.contoso.com”
Here is a sample of what the output file will look like:
![clip_image001[6]](http://msdnshared.blob.core.windows.net/media/2016/10/clip_image0016_thumb2.png "clip_image001[6]")
Nothing to fear on this one. It’s purely informational output in the form of a .csv file. This output file becomes the input file for the next script. Feel free to run this script as needed before the migration process is actually started to get a feel for the script and to parse the output.
3. Run the following command to create the public folder-to-mailbox mapping file. This file is used to calculate the correct number of public folder mailboxes on the Exchange 2016 Mailbox server. You’ll need to specify the following parameters:
This part deserves substantial additional explanation.
First, let’s talk about the size and number of public folder mailboxes to be provisioned in Exchange 2016. Using an example of a 20 GB maximum PF mailbox size (100 GB is the current maximum – see Limits for Public Folders), let’s look at preparing to migrate 100 GB of public folder data. Following our guidance to only fill the public folder mailboxes to 50% of their capacity at migration, we would need 10 public folder mailboxes created to host the data. This example would modify the example command above to:
.\PublicFolderToMailboxMapGenerator.ps1 10737418240 “\\FileServer\Share\FolderSize.csv” “\\FileServer\Share\PFMailboxes.csv”
Finally, the output file may be manipulated prior to future steps in order to name the public folder mailboxes appropriately.
Note: in larger modern public folder installations, it’s recommended for the hierarchy mailbox (the first PF mailbox to be created that has the writable copy of the folder hierarchy) to be isolated onto a database and server that hosts no other PF mailboxes. That hierarchy mailbox should be configured not to answer hierarchy requests from users in order to dedicate it to the task of maintaining the hierarchy for the environment.
Here is a sample of what the initial output file will look like:
![clip_image001[8]](http://msdnshared.blob.core.windows.net/media/2016/10/clip_image0018_thumb2.png "clip_image001[8]")
Here is a modified file with the folder structure expanded and the PF mailbox names changed:
![clip_image001[10]](http://msdnshared.blob.core.windows.net/media/2016/10/clip_image00110_thumb2.png "clip_image001[10]")
While I have your attention on the screenshot of the public folder mapping file, let me advise that on one of my engagements, there were at least a dozen or so formatting errors that halted the beginning of the public folder migration (step 5 in the process). From what I could see, Exchange 2013/2016 processes the entire mapping file before starting the move of data to ensure that it is formatted correctly because the errors that exited the command to start the migration occurred very quickly, and some of the errors were hundreds of lines into the mapping file. The tedious aspect of encountering mapping file errors like this is that the command to start the migration exits immediately and must be rerun to find the next error. After restarting the command a dozen or so times, I was quite pleased when the command finally returned that the migration was queued.
The errors I encountered were not difficult to remedy. When the command errors out, it tells you which line of the file the error is located in. My recommendation is to have a utility on hand that displays line numbers (the venerable Notepad++ comes to mind) to make it easy to navigate the file. The types of errors I saw were either missing double quotes or too many double quotation marks defining the public folder mailbox or the path of the folder. As you can see in the screenshot above, the format is “PFMailbox”,”Total path of the folder”. Look the affected line over and ensure it is correctly punctuated.
Run the following command to create the target public folder mailboxes. The script will create a target mailbox for each mailbox in the .csv file that you generated previously in Step 3, by running the PublicFoldertoMailboxMapGenerator.ps1 script.
.\Create-PublicFolderMailboxesForMigration.ps1 -FolderMappingCsv PFMailboxes.csv -EstimatedNumberOfConcurrentUsers:<estimate>
Mapping.csv is the file generated by the PublicFoldertoMailboxMapGenerator.ps1 script in Step 3. The estimated number of simultaneous user connections browsing a public folder hierarchy is usually less than the total number of users in an organization.
First comment here is to determine if you really need to bother with the script to create the public folder mailboxes. If your modern public folder mailbox count to be created is significant, the script is quite efficient, but if you are only going to be creating a few mailboxes, it may be simpler to run a few quick EMS commands to put the needed mailboxes in place.
Working through the process of manually creating the mailboxes also allows us to discuss two specific switches you should know about – HoldForMigration and -IsExcludedFromServingHierarchy.
New-Mailbox -Name PFMB-HIERARCHY -PublicFolder –HoldForMigration –IsExcludedFromServingHierarchy:$True
This first Public Folder Mailbox contains the writable copy of the Public Folder Hierarchy. In this example command, the mailbox is named for that purpose, and the -IsExcludedFromServingHierarchy switch will be set to $True permanently.
Remember, it is recommended to locate the hierarchy public folder mailbox in a database with no other public folder mailboxes, mounted on a server with no other active public folder mailboxes, particularly in larger public folder environments.
New-Mailbox -Name PFMB-AMERICAS -PublicFolder –IsExcludedFromServingHierarchy:$True
New-Mailbox -Name PFMB-APAC -PublicFolder –IsExcludedFromServingHierarchy:$True
New-Mailbox -Name PFMB-EMEA -PublicFolder –IsExcludedFromServingHierarchy:$True
The -IsExcludedFromServingHierarchy switch set to $True for these mailboxes will NOT be a permanent setting here as it is for the hierarchy mailbox. Creating a new public folder mailbox without initially excluding it from serving the hierarchy creates a situation where users may connect to it for hierarchy requests before the initial hierarchy synchronization has completed. It’s easy to determine if a public folder mailbox is ready to serve the hierarchy with a short Exchange Management Shell command:
Get-Mailbox -PublidFolder | fl name,*hierarchy*
Note the IsHierarchyReady attribute of the newly created “PFMB3” compared to the other PF mailboxes in this output below. Once that attribute reports True, the IsExcludedFromServingHierarchy switch may be set to $False.
![clip_image001[12]](http://msdnshared.blob.core.windows.net/media/2016/10/clip_image00112_thumb.png "clip_image001[12]")
Hierarchy synchronization will occur automatically in short order, though it is possible to call the synchronizer into action immediately:
Get-Mailbox -PublicFolder | Update-PublicFolderMailbox -InvokeSynchronizer
A bit more on the IsExcludedFromServingHierarchy attribute from TechNet (highlight mine):
“This parameter prevents users from accessing the public folder hierarchy on the specified public folder mailbox. For load-balancing purposes, users are equally distributed across public folder mailboxes by default. When this parameter is set on a public folder mailbox, that mailbox isn’t included in this automatic load balancing and won’t be accessed by users to retrieve the public folder hierarchy. However, if you set the DefaultPublicFolderMailbox property on a user mailbox to a specific public folder mailbox, the user will still access the specified public folder mailbox even if the IsExcludedFromServingHierarchy parameter is set for that public folder mailbox.”
Based on this guidance, there will need to be enough public folder mailboxes provisioned to accommodate no more than an average of 2,000 concurrent users (see again the TechNet article Limits for public folders). This adds another dimension to the sizing guidelines. For example, you may well be able to place the public folder data set in as few as 5 public folder mailboxes, but if your system hosts 16,000 mailbox enabled users, a minimum of 8 public folder mailboxes would be necessary to support the user connections. Be sure to validate both size and user connection counts in your modern public folder design stage.
At this point, you’re ready to start the public folder migration. The steps below will create and start the migration batch. Depending on the amount of data in your public folders and the speed of your network connections, this could take a few hours or several days. During this stage of the migration, users will still be able to access their public folders and content on your Exchange 2010 server. In “Part 6: Complete the public folder migration (downtime required)”, you’ll run another sync to catch up with any changes made in your public folders, and then finalize the migration.
The progress and completion of the migration can be viewed and managed in the EAC. Because the New-MigrationBatch cmdlet initiates a mailbox migration request for each public folder mailbox, you can view the status of these requests by using the mailbox migration page. You can get to the mailbox migration page and create migration reports that can be emailed to you by doing the following:
The Status column will show the initial batch status as Created. The status changes to Syncing during migration. When the migration request is complete, the status will be Synced. You can double-click a batch to view the status of individual mailboxes within the batch. Mailbox jobs begin with a status of Queued. When the job begins the status is Syncing, and once InitialSync is complete, the status will show Synced.
In the deprecated “Serial Migration” TechNet article, the following guidance was given concerning the data transfer rate (highlight mine):
You’ll know that the command started successfully when the migration request reaches a status of Queued or InProgress. Depending on how much data is contained in the public folders, this command can take a long time to complete. If migration isn’t being throttled due to the load on the destination server, the typical data copy rate can be 2 GB to 3 GB per hour.
In my experience, it is difficult to set any real estimate on the data transfer rate, and the later TechNet article detailing the “Batch Migration” process on which this blog post is based has changed the verbiage to “this may take several hours“. The variables of network speed and available bandwidth combined with the quality of the hardware supporting both old and new versions of Exchange will have a significant impact on your data transfer rate at this stage.
The number and size of your public folders will also affect the speed of the migration. One particular migration I was involved with saw roughly 70% of the total public folder data located in one folder (high resolution pictures). During the time that particular folder was being moved, the data transfer rate was closer to 20 GB per hour, but the data rate slowed closer to the original 2-3 GB per hour estimate once the final 30% of the data was being moved from the many, smaller remaining folders.
Under normal circumstances, the migration of data will progress to the 95% synchronization mark and autosuspend. If you leave the migration in the suspended state for any length of time, the migration process will resynchronize to 95% at intervals in the same manner as moving a mailbox configured for manual completion. In one of my public folder migrations, the process progressed to 95%, but the reported state did not show the desired “AutoSuspended”, but rather an error. Looking at the onscreen report, the move failed due to TooManyLargeItemsPermamentException and called out two items, one 12 MB in size, the other 14 MB (organization maximum message size was 10 MB). These two items were located and saved offline from the folders by the customer using Outlook. I modified the migration request to skip the large items (simply added -LargeItemLimit 2 to the command) and resumed it, and the status moved to the AutoSuspended state.
More on the LargeItemLimit switch to allow the large items to be skipped (save the items out if you want to keep them!):
The LargeItemLimit parameter specifies the maximum number of large items that are allowed before the migration request fails. A large item is a message in the source mailbox that exceeds the maximum message size that’s allowed in the target mailbox. If the target mailbox doesn’t have a specifically configured maximum message size value, the organization-wide value is used.
For more information about maximum message size values, see the following topics:
- Exchange 2016 Understanding message size limits
- Exchange Online Exchange Online Limits
Valid input for the LargeItemLimit parameter is an integer or the value unlimited. The default value is 0, which means the migration request will fail if any large items are detected. If you are OK with leaving a few large items behind, you can set this parameter to a reasonable value (we recommend 10 or lower) so the migration request can proceed.
Until this point in the migration, users have been able to access the legacy public folders. The next steps will disconnect users from the Exchange 2010 public folders and will lock the folders while the migration completes its final synchronization. Users won’t be able to access public folders during this process. Also, any mail sent to mail-enabled public folders will be queued and won’t be delivered until the public folder migration is complete.
Before you can finalize the migration, you need to lock the public folders on the Exchange 2010 server to prevent any additional changes by doing the following:
If your organization has multiple public folder databases, you’ll need to wait until public folder replication is complete to confirm that all public folder databases have picked up the PublicFoldersLockedForMigration flag and any pending changes users recently made to folders have replicated across the organization. This may take several hours.
When you have progressed to this step, there is one helpful tip I’ve found to speed up the process. After running the command Set-OrganizationConfig -PublicFoldersLockedForMigration:$true, restart the information store service on the legacy Exchange server involved in the migration. This will refresh the Store cache on that server that the public folders are locked for migration, allowing you to move immediately to the Step 7 command Complete-MigrationBatch PFMigration. Considering that all your mailboxes have been moved before you migrate public folders anyway, there should be nothing to stop you from recycling the information store service. If you are unable to do this, the command to complete the migration batch in step 7 will not proceed until the information store service on the legacy server picks up the change.
First, run the following cmdlet to change the Exchange 2016 deployment type to Remote:
1. Set-OrganizationConfig -PublicFoldersEnabled Remote
Once that is done, you can complete the public folder migration by running the following command:
2. Complete-MigrationBatch PFMigration
Or, in EAC, you can complete the migration by clicking Complete this migration batch.
When you complete the migration, Exchange will perform a final synchronization between the Exchange 2010 server and Exchange 2016. If the final synchronization is successful, the public folders on the Exchange 2016 server will be unlocked and the status of the migration batch will change to Completing, and then Completed.
If you have advanced to this point, it’s likely that the final 5% synchronization of data will finish smoothly and the process will reach the Completed status. The only real note here is that 5% is a relative number. If your legacy public folder installation is 17 GB as one of my customers was, that’s only about 870 MB to finish syncing. If your legacy install has 1.5 TB of data, you still have multiple hours of sync time remaining.
After you finalize the public folder migration, you should run the following test to make sure that the migration was successful. This allows you to test the migrated public folder hierarchy before you switch to using Exchange 2016 public folders.
At this point, your Modern Public Folders are accessible to the users. Outlook will determine the updated location of the public folders via AutoDiscover, so it may be necessary to reopen Outlook in order to force an AutoDiscover query for the Public Folder list to show up and be accessible. Outlook performs an AutoDiscover query at startup and at regular intervals thereafter, so any open clients will eventually pick up the change under any circumstance.
Hope this is helpful! I want to acknowledge the fantastic help I received from Bill Long for reviewing the replication script and general knowledge transfer, Brian Day for his generous time and explanations during one particular public folder critical situation, and Dhaval Hansaliya and Nino Bilic for their assistance reviewing this post to get it ready for publishing. Thank you!
Premier Field Engineer
For many, the inbox is the command center for their day. It’s the way to keep track of what is going on and what needs to get done. Outlook’s Focused Inbox makes this process easier by helping you focus on the emails that matter most to you. It separates your inbox into two tabs—Focused and Other. Emails that matter most to you are in the Focused tab, while the rest remain easily accessible—but out of the way in the Other tab. You’ll be informed about email flowing to “Other”, and you can switch between tabs at any time to take a quick look.
For more about what makes Focused Inbox great, see Outlook helps you focus on what matters to you.
Ensure certain business critical mails land in the Focused tab.
Tenant admins will have controls to ensure certain business critical communications, like HR, Payroll, etc., always land in the user’s Focused tab of the Inbox. These whitelists can be set up using mail flow rules from the Admin center or via PowerShell cmdlets. After these are set up successfully, all future messages that satisfy these mail flow rules would be delivered in the Focused tab of the Inbox on Outlook clients that support Focused Inbox.
Tenant and mailbox level control to enable/disable Focused Inbox.
Tenant admins will have controls to enable/disable Focused Inbox on Outlook clients for all current and future mailboxes or select mailboxes in their tenant. These controls will be available via PowerShell cmdlets.
If tenant admins enable/disable Focused Inbox, the Focused Inbox experience on Outlook clients would be turned ON/OFF for these users the next time they boot the client.
These controls do not block the availability of the feature for these users. If the users so desire, they can still re-enable the feature individually again on each of their clients.
Focused Inbox is a refinement and improvement of a previous feature called Clutter. Clutter’s purpose was also to help you focus on the most important items in your inbox, but it did so by moving “Other” email to a separate folder. Focused Inbox makes it easier for you to stay on top of incoming email without having to visit another folder.
Active Clutter users will have to opt-in to Focused Inbox and will be able to do so from an in-app prompt in Outlook. After they opt-in, they will no longer receive less important email in the “Clutter” folder. Instead, email will be split between the Focused and Other tabs in their inbox.
The same machine learned algorithm that moved items to the Clutter folder now powers Focused Inbox, meaning that any emails that were set to move to Clutter will now be moved to Other. The learning and training that users invested into Clutter would be transitioned to Focused Inbox without any effort on the user’s part.
Users can keep using the existing Clutter experience through the transition. However, after the transition period, Clutter will be completely replaced by Focused Inbox. Tenant admins would be proactively notified before this change is made.
If you have previously disabled Clutter for users in your organization, we will not automatically re-enable Clutter for those users, nor will we automatically enable Focused Inbox for those users.
Focused Inbox will be rolled out in a staged manner in accordance with the change management policies for Office 365. The feature will be first rolled out to customers who have selected First Release cadence. Once it’s determined that feature is ready for broader audience, it will be rolled out to everyone in the service, including customers who have selected Standard Release cadence.
Updates to the stages of roll out will be announced on the Office 365 Public road map and more detailed information will be communicated closer to the roll out via the Office 365 Message Center.
During the recent Microsoft Ignite conference I heard questions related to hybrid and partner free/busy relationships quite often, so I wanted to write about it.
This scenario applies to companies with one or more external free busy relationships configured. For instance, you could have two or more companies on-premises sharing free/busy between each other.
Then one fine day, one of the companies deploys a hybrid configuration and moves mailboxes to Office 365; in our example, it is Tailspin. Suddenly, Contoso and Fabrikam users find availability information is not showing for the Tailspin mailboxes moved to Exchange Online.
This blog post discusses why free/busy is broken and what you can do about it.
For many years now we have allowed different organizations to share calendar availability between each other. It really started with the Availability Address Space feature in Exchange 2007, later moving on to the Microsoft Federation Gateway (Now called the Azure Authentication System) with Organization Relationships in Exchange 2010, 2013, and 2016.
This set of features allows an organization to share limited free/busy details with another organization without an AD Trust in place.
The main point of this article is to understand what to do when one of these organizations deploys a hybrid configuration with Office 365. Will free/busy sharing still work?
However, before we get into why this could be a problem when you deploy a hybrid configuration, we need to make sure you have a general understanding of how the cross-organization free/busy works.
In most scenarios, it is just a matter of configuring a Federation Trust and an Organization Relationship using the Exchange Admin Center (EAC). The following is a diagram of the basic configuration between two organizations.
Now let’s look at how a cross organization availability requests works. For this example, we will assume a user Bill (from Contoso) is looking up a user Ted’s (from Tailspin) free/busy information.
1. Bill creates a meeting request and adds Ted as an attendee.
2. The Exchange server in Contoso determines (usually based on target address of a mail-enabled user) that Ted is not local and has a domain name of TailspinToys.com set as the target address.
3. The Availability Service on the Exchange server in Contoso then checks to see if there is a path for it to find the free/busy information for TailspinToys.com.
Note: OAUTH is not a supported way to see free/busy between two on-premises organizations.
4. Assuming we used the typical options, we would have an Organization Relationship and a Federation trust (second option above). The ApplicationURI in the Organization Relationship is set to FYDIBOHF25SPDLT.TailspinToys.com, which is a unique identifier for the Tailspin trust in the Azure Authentication System (formerly known as the Microsoft Federation Gateway). A request is then made to the Azure Authentication System for a delegation token that will be accepted by Tailspin.
5. Once the delegation token is received back from the Azure Authentication System, the Exchange server in Contoso sends an Autodiscover and eventually an EWS request for the availability information.
6. The Tailspin Exchange server validates the token provided by the Azure Authentication System and once confirmed, returns the requested free/busy data.
Let’s continue with the Contoso and Tailspin example. What would happen if Tailspin deployed a hybrid configuration and moved Ted to Office 365?
1. Bill creates a meeting request and adds Ted as an attendee.
2. The Exchange server in Contoso determines the user Ted is not local and has a domain name of TailspinToys.com.
3. The Availability Service on the Exchange server in Contoso checks to see if there is a path for it to find the free/busy information for TailspinToys.com.
4. Like in the previous example, our configuration utilizes the Organization Relationship and Federation Trust. A request is then made for a delegation token that will be accepted by Tailspin.
5. Once the delegation token is received back from the Azure Authentication System, the Exchange server in Contoso sends an Autodiscover and eventually an EWS request for the availability information.
6. The Tailspin Exchange server validates the token provided by the Azure Authentication System and once confirmed, tells the Contoso server that the user is moved.
The result is that the Exchange server in Contoso returns to Bill’s client no information (hash marks) instead of free/busy information for Ted because there is no path for the Target Address that is returned Ted@TailspinToys.mail.onmicrosoft.com. In addition, if an organization relationship was in place for TailspinToys.mail.onmicrosoft.com, the request would still fail because the token received from the Azure Authentication system (marked for ted@TailspinToys.com) would not be valid for the tenant.
The main reason for this failure is because Organization Relationships are specific to a premises and the trust established is not transitive. Therefore, just because Contoso trusts the on-premises organization of Tailspin Toys does not mean that Contoso trusts the cloud-based Tailspin organization.
To solve the issue, you need to do a few things…
1. Create an Organization Relationship between Contoso on-premises and Tailspin on-premises. Use a unique SMTP namespace for the domain name in the Organization Relationship like OnPrem.Tailspintoys.com
Note: In most environments, the shared namespace “TailspinToys.com” can be used as the Target address for on-premises users and you would not need the additional namespace of onprem.TailspinToys.com. However, to account for all complex partnerships that could be in place, a unique namespace used as the target address will ensure free busy works properly.
2. Create an Organization Relationship between Contoso on-premises and Tailspin in Exchange Online. For this Organization Relationship the domain name should be TailspinToys.Mail.onmicrosoft.com.
3. Make sure that you have a solution in place to sync mailbox enabled objects between Tailspin and Contoso. As a mailbox is moved from Tailspin on-premises to Tailspin online, Contoso needs to be made aware and the related objects’ Target Address needs to be updated in Contoso. This is needed to ensure we direct the free/busy requests to the correct premises the first time. This step can be achieved via Forefront Identity Manager (FIM) or with a script.
Note: The domain name “TailspinToys.com” is not present in any of the Organization Relationships in the Contoso environment. Keeping this name out of the Organization Relationship will ensure that you can continue to use the shared namespace and see free/busy information.
When you move all your mailboxes to the cloud you have the option to switch the Autodiscover namespace to point to Office 365 instead of on-premises. So in our example, if you move all of the Tailspin mailboxes to the Exchange Online and wanted to just keep Exchange on-premises for recipient management purposes, you could follow the appropriate method for decommissioning the hybrid configuration In Tailspin. Then you would delete Contoso’s existing Organization Relationships and recreate the Organization Relationship in Contoso so that it has the cloud based information:
The Availability service does not treat free/busy between organizations as transitive and there are no plans to change that today. If you want to be in a hybrid configuration and maintain relationships with other external organizations, you will have to take into account the additional configuration requirements mentioned in this article.
Thanks to all that contributed to this content: Lou Mandich, Ray Fong, Henrik Walther, and Ross Smith IV
During the recent Microsoft Ignite conference, we had a party celebration of 20 years of Exchange Server. It was great fun and very dignified, of course.
During the said celebration, there was a great video shown, that poked fun at some of the significant moments in Exchange history. This is now available for you to enjoy:
Our September 2016 release blog included a statement that is causing some confusion with customers. The confusion relates to our support of Windows Server 2016 with Exchange Server 2016. The blog included a statement that read, “Domain Controllers running Windows Server 2016 are supported provided Forest Functional Level is Windows Server 2008R2 or Later.” We would like to provide additional clarity on what this statement means, and more importantly what it doesn’t.
Question #1: If I want to deploy Exchange Server 2016, must my Active Directory environment use Forest Functional Level 2008R2 or later?
Answer: No. Exchange Server 2016 is supported in environments configured to Forest Functional Level 2008 and later.
Question #2: If I want to install Exchange Server on a server running Windows Server 2016, does my Active Directory environment need to advance Forest Functional Level to 2008R2 or later?
Answer: No. Exchange Server 2016 installation on Windows Server 2016 is supported if Active Directory is configured to Forest Functional Level 2008 and later.
Question #3: What is the real requirement you are calling out here?
Answer: If you are running Exchange 2016 anywhere in your environment, and if any of the Domain Controllers used by Exchange are running Windows Server 2016, then the Forest Functional Level must be raised to 2008R2 or later.
In our experience, customers who keep their Domain Controllers deployed at the latest OS revision level, also employ the highest level of reliability, security and functionality and this requirement should not be a deployment blocker.
Question #4: Why is 2008R2 Forest Functional Level or later required?
Answer: Advancing the directory to a higher level of functionality requires DC’s on older operating systems to be retired. Our goal is to make certain that Exchange Server uses the highest level of security settings reasonably possible, including newer cryptographic standards. Windows Server 2008 no longer meets the minimum standard we are requiring and being requested by customers. Customers who are deploying the latest version of Exchange and Windows Server are often doing so to improve the security of their overall ecosystem. Our goal is to make certain that Exchange Server functions correctly under these assumptions and requirements. Limiting the use of old standards allows Exchange Server to meet the requirements of current security standards.
Question #5: Will Exchange Setup block installing Exchange Server 2016 if I am using Windows Server 2016 on a Domain Controller but have not raised the Forest Functional Level?
Answer: At this time, there is no Setup block. This pre-requisite is a soft requirement enforced by policy only. If a customer calls into support and is using Windows Server 2016 Domain Controllers with Exchange Server 2016 and they have not raised the Forest Functional Level to the minimum value, we may ask them to do so as part of root cause elimination.
Question #6: When will Exchange Setup force the use of 2008R2 Forest Functional Level for an Exchange Server installation?
Answer: The minimum supported Forest Functional Level will be raised to 2008R2 in Cumulative Update 7 for all Exchange Server 2016 deployments. We know that customers need time to plan and deploy the necessary migration/decommission of Active Directory Servers. 2008R2 Forest Functional Level will be a hard requirement in Cumulative Update 7, enforced by Exchange Setup. Cumulative Update 7 ships in the 3rd quarter of 2017, one year after the first announcement.
For a complete list of Exchange requirements please see this TechNet article.
Several weeks ago, we enabled a new Office 365 feature to some tenants where the removal of the Exchange License didn’t immediately mail disable the user and disconnected the mailbox. The new behavior then required to manually (via RPS – remote PowerShell) go and run through EXO RPS the Disable-Mailbox -PermanentlyDelete cmdlet to achieve the same result we previously had – a permanent deletion of the disconnected mailbox.
Due to extensive feedback from customers we are rolling back this feature to the original behavior in order to improve the feature before we release it again in an easier format (and with better documentation).
As of today (10/31/2016) – going forward until feature is re-introduced in the future:
The removal of Exchange license from a user will trigger a mail disable operation in Exchange Online as it did before. The user’s mailbox will then be disconnected and will enter a tombstone state. This is not a soft deletion operation; if you want to preserve the mailbox for later recovery please use the Soft Deletion feature or Inactive mailboxes with in-place or litigation hold.
Adding the license back to this user within 30 days will result in a ‘best effort’ reconnect with the old content of the mailbox. This is the behavior we had before the change, we are just reverting to it.
Note: we have already started the rollback of this feature but it might take about 24 hours until all of our customers see changed behavior. To be safe, please assume that behavior has changed already starting right now.
What happens to the users whose license was removed within the time frame of the feature being enabled?
We are grand-fathering in these users. The mailbox and user will remain connected and mail enabled for an indefinite amount of time. You have some options for these users:
How to find them?
Users in this state can be found through EXO remote PowerShell using Get-Mailbox and looking for the SKUAssigned flag in EXO being set to “False”.
Sample user with removed license during feature being on:
What do I do with them?
You have 4 options (since a mailbox without a license has access blocked within 30 days of creation):
The entire object (including the UPN and identity) are in a soft deletion state across the service. This allows for full data recovery and full re-use of any and all properties of the user in soft deletion state in a new user.
The user object also loses Exchange properties in this case; that frees all email/proxy addresses and allows the object to be stamped with External Email address a new. The process requires for you to remove the license, then run the above command and then update the necessary attributes.
We apologize for the back and forth on this, and realize that we have to do better when releasing features to the service, which the team is committed to doing when we release this feature again.
This post explains the configuration steps needed to get rich document collaboration working between Exchange Server 2016, SharePoint Server 2016, and Office Online Server, in your On-Premises environment.
Please use this link if you’re looking for configuration steps for Exchange Server 2016 On-Premises and SharePoint Online
When used together, Exchange Server 2016, SharePoint Server 2016, and Office Online Server provide a rich set of document collaboration features.
For example, rather than directly attaching a document to an e-mail message you may now send a link to the document stored in OneDrive for Business (ODB). Outlook and Outlook on the Web (new name for OWA) will still display the file as if it was directly attached to the message like a classic attachment would be, as well as allow people to work with the file like they would with a classic attachment. Additionally, many people will be able to read and edit the same file at the same time while it is stored in OneDrive for Business (ODB).
You can see a short demo of how this collaboration can look like right here.
The solution requires you have the following set up On-Premises:
The basic setup for these rich document collaboration features involves configuring OneDrive for Business (ODB) in the SharePoint 2016 farm, establishing a server-to-server trust (also referred to as S2S or OAuth) between SharePoint Server 2016 and Exchange Server 2016. Once completed, users will have the ability to attach ODB-based documents to email messages. Installing and configuring Office Online Server will introduce the additional capability of device-independent side-by-side viewing as well as edit & reply functionality in Outlook on the Web.
Note that editing documents is a premium feature of OOS and requires appropriate licenses!
Install OOS and create a new OOS farm. Make sure the farm URL is accessible from Internet if you want users to be able to view and possibly edit documents via Outlook on the Web from outside of the corporate network:
Example:
For an OOS farm that is going to use same internal and external FQDN, with editing enabled:
New-OfficeWebAppsFarm -InternalURL “https://oos.contoso.com” -ExternalURL “https://oos.contoso.com” -CertificateName “Unified Certificate” -EditingEnabled
For an OOS farm that is going to use different internal and external FQDNs, with editing enabled:
New-OfficeWebAppsFarm -InternalURL “https://internaloos.contoso.com” -ExternalURL “https://externaloos.contoso.com” -CertificateName “Unified Certificate” -EditingEnabled
In order to leverage the OneDrive for Business-based attachments on-premises, users must have a OneDrive for Business site hosted by SharePoint Server 2016 on-premises.
Follow steps from here, if the MySite Host (which gives you OneDrive for Business) is not already configured.
Additionally, to enable integration of Office Online Server for document previewing and online editing, WOPI bindings must be created in the SharePoint farm.
The commands can be put together in a script to make life easy. A sample script for performing this configuration is provided here
Usage:
Example:
.\Config-SPSOAuth.ps1 -ExchangeServer mail.contoso.com -MySiteHostUrl https://sp01.contoso.com/
The user’s mailbox must be hosted on an Exchange Server 2016 server on-premises to enable the document collaboration functionality. There are a few settings to configure on Exchange Server to enable the full experience.
Set-OrganizationConfig -WacDiscoveryEndpoint https://oos.contoso.com/hosting/discovery
Set-MailboxServer exch.contoso.com -WacDiscoveryEndpoint https://oos.contoso.com/hosting/discovery
If you have Exchange 2013 servers in your organization, do not configure an OOS endpoint at the organization level. Doing so will direct Exchange 2013 servers to use OOS, which is not supported.
Example 1:
Creating new policy for My Site host access:
New-OwaMailboxPolicy -Name ODBPolicy
Set-OwaMailboxPolicy -Name ODBPolicy -InternalSPMySiteHostURL https://sp01.contoso.com -ExternalSPMySiteHostURL https://sp01.contoso.com
Finally, assign the policy to mailboxes:
Set-CASMailboxPolicy JohnR@contoso.com -OWAMailboxPolicy ODBPolicy
Example 2:
In this example, only users connecting to the server ‘Exch’ need to be enabled for document collaboration:
Get-OwaVirtualDirectory -Server exch.contoso.com -ADPropertiesOnly | Set-OwaVirtualDirectory -InternalSPMySiteHostURL https://my.contoso.com -ExternalSPMySiteHostURL https://my.contoso.com
This configuration is useful in scenarios where only specific servers are going to frontend the Outlook on the Web traffic
& $ExScripts\Configure-EnterprisePartnerApplication.ps1 -ApplicationType Sharepoint -AuthMetadataUrl https://sp01.contoso.com/_layouts/15/metadata/json/1
These are currently some limitations we hope to address in the future. Please be aware of what they are for the time being:
I wanted to thank Neil Hodgkinson, Jon Frick, Brian Day and Jason Haak for their help in putting this together!
We wanted to raise your attention to an issue that some customers have reported running Exchange Server 2016 on Windows Server 2016. Crashes of the IIS (W3WP.exe) process have been reported causing instability of Exchange Server on Windows Server 2016. The Exchange team has worked with the Windows team to isolate the source of the problem. An update for Windows Server 2016 will be made available to resolve this issue. Microsoft recommends that customers delay deploying Exchange Server on Windows Server 2016 until this update is made available. For the latest guidance on known issues, please consult the Windows Server release notes on TechNet.
When there are updates on this, we will update this blog post.
Multi-Factor Authentication (MFA), which includes Two-factor authentication (2FA), in Exchange Server and Office 365, is designed to protect against account and email compromise.
Microsoft has evaluated recent reports of a potential bypass of 2FA. We have determined that the technique described is not a vulnerability and the potential bypass does not exist on properly configured systems.
The reported technique does not pose a risk to Exchange Server or Office 365:
Additional information on enabling OAuth in Office 365 and Exchange Server can be found on Office.com and MSDN.
If you are using Public Folders (legacy or Modern) and would like to migrate some of them to Office 365 Groups, we are working on a solution for that. We are starting with the migration of Calendar folders and will move on to other types as we complete work on calendars. We would like to have customers who would like to try this migration to provide feedback. Please email us with below information if interested. You can also send us your information if you would like to try migrating other types of public folders (other than Calendar) as we extend the support to those folder types.
Drop us an email at: pftogroupmigration@service.microsoft.com
Your organization might need to join our TAP program (depending on public folder location) – and if so, we will share those details with you after reviewing the above.
We are in the process of rolling out a new migration experience that will greatly simplify your journey to Office 365 and Exchange Online.
This new experience will help any customer running at least one Exchange 2010, 2013 and/or 2016 server on-premises to migrate to the cloud seamlessly. When you initiate the migration, we evaluate what you have configured already in Exchange Online and we walk you through the Hybrid Configuration Wizard to evaluate the on-premises environment. Once all the information on your current state is collected, we ask a couple of questions about your desired state (things like how fast you want to move to Exchange Online and whether you require advanced features). The hybrid wizard then walks you through the configuration needed to migrate your users to Exchange Online.
Based on your current configuration and the options selected while running the hybrid wizard, you will be taken down one of the following paths.
In the past, an administrator of the small to medium business had to choose to either take the complex configuration route of hybrid or the complex user experience of a cutover or staged migration. Now you can get a greatly simplified Express Migration experience.
With the Express Migration option, you will get a onetime directory synchronization of your users along with the Minimal Hybrid configuration to allow you to perform the migrations. After that initial synchronization of user accounts, directory synchronization will be automatically disabled in both Office 365 and on-premises. This will give small and medium customers that would have previously perform a cutover migration the ability to get the benefits of the hybrid migration without the overhead.
The following are the benefits of performing an Express Migration over a more traditional cutover migration:
All the migration approaches discussed in this article (Full, Minimal, and Express) can be initiated from one interface now. We will guide you to the proper option as we go.
One of key components in this new experience is the migration pane. This is a new pane we have created in the Office 365 Admin Portal that will match the modern look and feel of the rest of the portal. However, it is not just the look and feel that is revamped, we also have a lot of intelligence built in. For instance, when you enter the migration pane we will detect if you have executed the Hybrid Configuration Wizard, already synchronized your users, and whether there is a migration endpoint already created. Depending on what is already in place we can take you toward the proper migration approach.
To get to the new migration experience you will have to expand the “Users” section in the portal (Http://portal.office.com) and then select the “Data Migration” option. Once there, select the Exchange email source to initiate the experience. This is a page where we list various sources from where you can migrate. In this case, you would select the Exchange option.
Once the source is selected we perform a quick check of the tenant to see if you have executed the Hybrid Configuration Wizard. If you have not yet executed it, that means we know you have not prepared your on-premises environment for migration. Therefore, we will take you through downloading and running the hybrid wizard.
When in the hybrid wizard you will see a welcome screen, just select next on that:
You will then see the Server detection screen, again just select next since the correct server should be detected. By default, we will try to connect to the Exchange server running the latest version.
Provide your credentials for both Exchange on-premises and Exchange Online.
Select the appropriate migration option. For this example, we are demonstrating Express Migration so we will select the Minimal Hybrid option.
Select update, which will perform all the configurations needed to allow you to start moving mailboxes at a later step.
If you have not synchronized your users already at this point you will see an option to perform a onetime sync of your users or to install AAD Connect separately. As mentioned, if you plan on moving all of your mailboxes to Exchange Online and do not have the need to keep directory synchronization around, then select the one-time sync option. Selecting this option is what we consider an “Express Migration”. If you need directory synchronization for any reason, then you need to install and setup AAD Connect separately.
Note: if you did select the one-time sync and later decided that you do need to have directory synchronization, you can setup AAD Connect to perform directory synchronization.
If you did not select Minimal Hybrid as an option in the wizard, then you will not be given the one-time directory synchronization option. The reason you would not get it if you opted for Full Hybrid is because that deployment scenario requires the advanced coexistence features and directory synchronization.
Once the option for “Synchronize my users and passwords one time” is selected, the hybrid wizard displays a progress bar. The wizard is waiting for the AAD Connect to be configured and for the initial set of users to synchronize.
To complete the hybrid configuration setup, you will need to configure AAD Connect. In almost all cases the default options in AAD Connect are the best options.
Once completed you will see the ending page for the hybrid application that will allow you to give feedback. Once closed you will be taken to the user list page to start moving mailboxes.
On the user list page you will have the option to select the users you want to migrate. Under the hood this is using MRS to migrate the users just like a hybrid migration. You can use this new pane to migrate mailboxes, regardless of the hybrid deployment option chosen. The experience is as simple as selecting the users and clicking start migration. At that time, we will perform a lookup to see if the prerequisites are in place. If anything is missing, we will walk you through taking care of the missing prerequisite.
There are some limitations with the new Migration pane that need to be called out. We are working to overcome these limitations in the future:
These updates will make the Exchange Online onboarding experience more seamless for many Exchange customers. We have created and are continuing to improve the Migration pane to meet the needs of our customers. While running through the experience if you have any feedback please use the provided feedback button that are available throughout the experience.
Since the release of Microsoft Exchange Server 2013, we have heard questions regarding the sizing and deployment of modern public folders. It is important to plan migrations for public folders so the client experience with their use is good. In this blog post, we will discuss some of best practices and recommendations regarding modern public folder deployment as well as discuss various related concepts. We will assume that you are already familiar with basic modern public folders concepts so we will not go there (but might link to relevant articles).
There is a lot here as we are going through several examples. Use it as a reference!
When the user launches the Outlook desktop client on Windows or Mac, client contacts the Autodiscover service to determine connection settings for the user’s primary mailbox and their archive mailbox if they have one. During the initial response, the Autodiscover service may indicate there are public folders available in the environment by including an XML element named <PublicFolderInformation>. This element will contain the SMTP address of a public folder mailbox within the environment. An additional Autodiscover request will be made to request connection settings for the SMTP address of the public folder mailbox.
To provide a value for this element during the initial request/response interaction, the Autodiscover service calls a function named GetPublicFolderRecipient. This function gathers information for the available public folder mailboxes in the environment available for serving hierarchy connections.
In most cases the GetPublicFolderRecipient function will (randomly) pick a public folder mailbox from the available list to be handed over to the Autodiscover Service, which in turn gets returned to the client.
Another possibility is that the user’s mailbox has a static DefaultPublicFolderMailbox assigned. When a mailbox has a default public folder mailbox assigned, the client will always attempt to connect to this public folder mailbox for hierarchy connections. If that public folder mailbox is not available for some reason, the client will fail to reach the public folder infrastructure and will not fall back to a random public folder mailbox. Something to keep in mind!
Note: In the case of Outlook on the web (we’ll call it OWA for short) clients accessing public folders, public folder mailbox access does not rely on the Autodiscover service even though the same selection process logic is used. In other words, OWA uses similar functionality that the Get-Mailbox cmdlet uses to get list of available public folder mailboxes the user can utilize. Even if Autodiscover is offline for some reason in the environment, you may see users successfully accessing public folders via OWA, but not Outlook clients.
By default, all public folder mailboxes deployed in the environment can serve hierarchy connections to the clients. However, immediately after creation a new public folder mailbox will not be used by Autodiscover. This is due to the newly created public folder mailbox has not yet completed an initial full hierarchy sync from the primary hierarchy public folder mailbox. This logic is automatically calculated and is reflected in the parameter IsHierarchyReady. By default, the value will be set to $False. If this value remains $False, the GetPublicFolderRecipient function will not return that public folder mailbox to the Autodiscover Service as it is assumed to contain an incomplete copy of the hierarchy (a user connecting to it would not have a complete view of the public folder infrastructure). Once the value of the newly created public folder mailbox’s IsHierarchyReady has changed to $True, the Autodiscover service will be able to hand it out to clients.
Under normal conditions this initial full hierarchy sync should start automatically within 24 hours of the public folder mailbox being created. You may also invoke the hierarchy sync manually if you so choose by using the below command:
Update-PublicFolderMailbox -Identity “Public folder mailbox name” -SuppressStatus -Fullsync -InvokeSynchronizer
The time it takes for the fully hierarchy replication to complete depends on several factors such as (but not limited to) network speed, number of public folders, geographical location of PF mailboxes, and connection load on the primary hierarchy mailbox.
The initial hierarchy sync happens using a pull operation model. The secondary public folder mailboxes will poll the primary hierarchy public folder mailbox to fetch the hierarchy information. Once the initial FullSync is complete, the value of IsHierarchyReady will change to True automatically and the public folder mailbox will be available to serve the hierarchy information to requesting clients.
To confirm, the following command can be run:
Get-Mailbox -PublicFolder | fl name,ishierarchyready
Note: While IsHierarchyReady value can be manually forced to True using PowerShell, this is not supported. Doing this can cause the public folder mailboxes to serve incomplete hierarchy to clients. The recommendation is wait for the initial sync to complete or manually invoke the hierarchy sync to get the hierarchy replicated to the new public folder mailboxes.
Once the initial hierarchy sync is complete for the public folder mailbox, the next hierarchy sync hereon will happen using the push model, where the primary hierarchy mailbox will push the changes to the secondary hierarchy public folder mailbox every 10 minutes.
Another setting an administrator has at their disposal is the attribute IsExcludedFromServingHierarchy. This attribute can be set to $False (default) or $True using the Set-Mailbox cmdlet and will prevent this mailbox from being used by Autodiscover or OWA to serve hierarchy connections to clients. Even after IsHierarchyReady becomes automatically set to $True the public folder mailbox will be excluded from Autodiscover and OWA hierarchy usage if IsExcludedFromServingHierarchy is set to $True. This option is useful when you want a public folder mailbox utilized only for content of public folders and can be set immediately after the public folder mailbox is created.
Note: If DefaultPublicFolderMailbox is populated on a user mailbox it will override the $True value of IsExcludedFromServingHierarchy (on the mailbox they are connecting) and will allow that user to connect to the public folder mailbox specified in DefaultPublicFolderMailbox for hierarchy. We will discuss this later in the post.
Let’s say we have 50 public folder mailboxes in their default state, all of which have sync’d hierarchy, and there are 20,000 users who try to access public folders. The Autodiscover service will provide a random public folder mailbox to each user to service hierarchy requests.
The specific public folder mailbox being returned to the client can change randomly, or if Outlook is closed and reopened, based on what GetPublicFolderRecipient function returns to Autodiscover which in turn returns the data to the client.
On the client side, public folder mailboxes being accessed will appear under the connection status in Outlook, as shown below:
The first public folder GUID value in here is a random primary public folder hierarchy mailbox. The remaining public folders GUIDs are populated and returned when user tries to access individual public folders which reside within those public folder mailboxes.
It is possible to override the behavior of random selection of default public folder hierarchy mailbox.
First, you need to confirm that the public folder mailbox has IsHierarchyReady populated with value of $True which confirms that it has completed its initial full hierarchy sync with the primary public folder mailbox.
Run the command:
Get-Mailbox -PublicFolder “Public Folder mailbox name” | FL Name,ExchangeGuid,*Hierarchy*
Once the above is confirmed, the next step is to assign the desired public folder mailbox as the DefaultPublicFolderMailbox on the user mailbox. In our example this would be accomplished by running the below command:
Set-Mailbox “user mailbox identiy” -DefaultPublicFolderMailbox “PF-MBX-002” -Verbose
Now, when the client opens Outlook, Autodiscover provides the DefaultPublicFolderMailbox’s SMTP address in the <PublicFolderInformation> XML element and the client then performs a second Autodiscover request to learn how to connect to this public folder mailbox.
When we check the Outlook connection status, it will list the assigned public folder mailbox.
Our customers deal with communication links that may be highly latent and expectedly inoperable for periods of time. For demonstration purposes let’s consider our favorite company called Contoso which has the following configuration:
Three company sites are listed below:
To maintain communications with their ships at sea, Contoso has established a 384Kbps satellite link to each ship and has also installed a dish at their Hyderabad site. All network routes to/from ships are routed via Hyderabad’s own satellite link.
Contoso has also purchased 1Gbps of bandwidth on a submarine cable link to Australia. All WAN routes to/from Australia site traverse this link.
If we were to simply deploy modern public folders with all the default values, we could see some interesting things happen. For example, all users could be offered any of the five public folder mailboxes for hierarchy regardless of their location.
The worst-case scenario here would be a ship based user trying to access PFMBX-AUS-001 for hierarchy information or an Adelaide based user trying to access PFMBX-SHIP-001 for hierarchy information. In either of those scenarios we see client traffic traversing round-trip not only along the longest network path, but also the one with the least bandwidth and most latency. In this extreme example, you would more than likely have clients calling the help desk reporting the Outlook RPC popup after they attempted to expand the public folder tree.
Considering the above problems, we recommend administrators with similar decentralized and complex network topologies consider configuring user mailboxes to access public folder mailboxes located within local or geographically closer sites as their default public folder mailbox.
In an environment like the one in the example, it may make sense to set IsExcludedFromServingHierarchy to $True for the public folder mailboxes on all cruise ships and Australia. This will remove them from being returned as valid public folder hierarchy endpoints for Autodiscover and OWA, leaving only the three well-connected Hyderabad based public folder mailboxes setup for automatic discovery.
Additionally, the DefaultPublicFolderMailbox attribute at the mailbox level should be utilized for employees based on the cruise ship or the Australia continent to ensure they always attempt to connect to a public folder mailbox that makes sense based on their geolocation. One caveat here is if a user from the Australia office were to visit the cruise ship (for work purposes sadly and not fun in the sun!), their client would continue to connect back to Australia for their PF hierarchy connection. In addition, the Hyderabad office with 23,000 mailboxes would need to monitor user concurrency to determine if they need additional public folder mailboxes or not over time to stay within supported user concurrency limits.
There are 2 type of connections being made to the public folder mailbox, when it is accessed.
Public folder mailbox connections (both hierarchy and content) should not exceed 2000 to remain within the support boundaries. Given this requirement, you should plan to have enough public folder mailboxes serve hierarchy and/or content so that you maintain a level of less than 2000 active and simultaneous client connections per secondary public folder mailbox.
The primary public folder mailbox must be excluded from providing hierarchy to clients (IsExcludedFromServingHierarchy parameter set to True). This allows the primary public folder mailbox to spend its time maintaining the hierarchy and dealing with hierarchy replication tasks. Overloading this public folder mailbox with client connections can in turn lead to performance and reliability issues with your PF hierarchy.
Consider another company also called Contoso, which has many offices around the world and modern public folders have been deployed in the environment. Sarah is a user whose mailbox is in a datacenter which is in India and she frequently works with public folders. There is another large group of users who also frequently work with the same set of public folders, but they are in a different geographical location, in Australia.
The public folders being accessed are in the India site, close to Sara’s geographical location, so she has a better experience when accessing public folders.
In contrast, when Australia users try to connect to public folder mailboxes, the local hierarchy public folder mailbox in their datacenter will provide the content location for required public folders. Users will initiate a connection to the actual public folder located in India holding the content for the public folder. Since the actual folder content is in different geographical location, the connection request may be not as performant for the Australian group of users, resulting in user frustration.
This deployment is not recommended. The focus should be on identifying the most frequently used public folders by a common set of users, and moving the public folders with that content closer to users’ location. In this scenario, the content should be moved closer to the larger group of users in Australia.
Note: Moving public folders only moves the physical contents of the public folder; it doesn’t change the logical hierarchy, or layout of folders in the folder tree.
To move the public folder content, run the command:
New-PublicFolderMoveRequest -Folders “\path of the public folder to be moved” -TargetMailbox “target public folder mailbox name”
Note: To verify that the PublicFolderMoveRequest is complete, the command Get-PublicFolderMoveRequest can be run.
Like mailbox move requests, completed public folder move request must be removed before any other public folder can be moved to another public folder mailbox. To do this, run the command Remove-PublicFolderMoveRequest. If any other public folder move request is initiated without removing the old request, it will error out like this:
To remove the existing PublicFolderMoveRequest, run the command:
Get-PublicFolderMoveRequest | Remove-PublicFolderMoveRequest
Note: If a parent public folder and its subfolders need to be moved to another public folder mailbox, this can be done using Move-PublicFolderBranch.ps1 script, located in \scripts folder.
For more details, see: Move a public folder to a different public folder mailbox
Once the public folder content has been moved to a different public folder mailbox, users in Australia site accessing the public folder will be updated by the local public folder mailbox hierarchy connection to the folder’s new content location and connect to the local public folder mailbox. To continue with our example, Sarah will continue to connect to local public folder mailbox for hierarchy (which has been set by the administrator), but will then get her content from the Australia datacenter. Even though the experience may not be as great for that one user, Sarah can add frequently used public folders to Favorites using Outlook client or OWA to help with latency issues.
Looking at the above example, it becomes very important to determine network latency and bandwidth before you start deployment of public folder mailboxes in geographically dispersed environment to avoid any latency issues when accessed by end users. In such situations, the recommendation will be to use tools like Netmon which can help in determining the connections happening to public folder mailboxes. There is a great tool written by Mark Russinovich called Psping, which can be helpful in determining the round-trip latency. Based on the results customers can decide whether the current network is suitable for their environment or if there are any changes that needs to be done.
Considerations when deploying public folder mailboxes in the organization, to ensure they are protected and readily available to the clients:
In the above post, we have provided information on how public folder mailboxes are accessed, and the importance of correctly deploying them in a geographically dispersed environment. In upcoming posts, we will discuss topics related to public folder logging analysis, management and quota related information
We would like to say thanks to Public Folders Feature Crew team for their valuable inputs while this blog post was being written.
Special Thanks to Ross Smith IV, Nasir Ali, Scott Oseychik for reviewing this content and validating the guidance mentioned in the blog post and Charlotte Raymundo, Nino Bilic for helping us to get this blog post ready!
and
Today we are announcing the latest set of Cumulative Updates for Exchange Server 2016 and Exchange Server 2013. These releases include fixes to customer reported issues and updated functionality. Exchange Server 2016 Cumulative Update 4 and Exchange Server 2013 Cumulative Update 15 are available on the Microsoft Download Center. Update Rollup 22 for Exchange Server 2007 Service Pack 3 and Update Rollup 16 for Exchange Server 2010 Service Pack 3 are also available.
Exchange Server 2016 Cumulative Update 4 includes a refresh to the compose experience. The body of the message is now “framed” and formatting controls have been moved to the bottom of the view. This mirrors the current experience in Office 365.
Exchange Server 2013 and Exchange Server 2016 now fully support .Net 4.6.2. Customers who have already updated their Exchange servers to .Net 4.6.1 can proceed with the upgrade to 4.6.2 before or after installing the cumulative updates released today. Customers who are still running .Net 4.5.2 are advised to deploy Cumulative Update 4 or Cumulative Update 15 prior to upgrading to .Net 4.6.2.
The upgrade to .Net 4.6.2, while strongly encouraged, is optional with these releases. As previously disclosed, the cumulative updates released in our March 2017 quarterly updates will require .Net 4.6.2.
Since Exchange Server 2013, the Windows feature Media Foundation has appeared as a pre-requisite in our setup checks on Windows Server 2012 and later. However, if you chose to allow Exchange setup to install the required OS Components, Desktop Experience has been installed on all supported operating systems. Desktop Experience is required on Windows Server 2008R2. The Desktop Experience feature includes additional components which are not necessary for Exchange Server and require frequent patching. Windows Server 2012 and later modified feature definitions to include Media Foundation. Exchange Setup in Exchange Server 2016 Cumulative Update 4 and Exchange Server 2013 Cumulative Update 15 has been updated to install Media Foundation instead of Desktop Experience on Windows Server 2012 and later. This change will only apply to newly installed servers. Applying either cumulative update will not change the existing configuration of the server. If desired, an administrator can add Media Foundation and remove Desktop Experience from the list of installed Windows features on Windows Server 2012 and later.
The Windows team has released KB3206632. This update addresses the issue where IIS would crash after a DAG is formed and the server is subsequently restarted. This update is now required on all servers running Exchange Server 2016 on Windows Server 2016. Setup will not proceed unless the KB is installed.
All of the packages released today include support for time zone updates published by Microsoft through October 2016.
Exchange Server 2013 Cumulative Update 14 and Exchange Server Cumulative Update 3 introduced an issue where new posts to a public folder may not have been indexed if there was an active public folder migration (KB3202691). This issue is now resolved. To ensure all public folders are indexed appropriately, all public folder mailboxes should be moved to a new database after applying the appropriate cumulative update released today.
KB articles which contain greater depth on what each release includes are available as follows:
Exchange Server 2016 Cumulative Update 4 does not include new updates to Active Directory Schema. If upgrading from an older Cumulative Update or installing a new server, Active Directory updates may still be required. These updates will apply automatically during setup if user permissions and AD requirements are met. If the Exchange Administrator lacks permissions to update Active Directory Schema, a Schema Admin needs to execute SETUP /PrepareSchema prior to the first Exchange server installation or upgrade. The Exchange Administrator should also execute SETUP /PrepareAD to ensure RBAC roles are updated correctly.
Exchange Server 2013 Cumulative Update 15 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 15. PrepareAD will run automatically during the first server upgrade if Setup detects this is required and the logged on user has sufficient permission.
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 CU15, 2016 CU4) or the prior (e.g., 2013 CU14, 2016 CU3) 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 was published.
Many organizations have been using certificate based authentication for Exchange Online while the feature was in preview. Today, we are excited to announce that the feature is generally available in Office 365 Enterprise, Business, Education, and Government plans. For more details, please reference our preview post which has been modified to reflect this announcement. As always, we look forward to hearing your suggestions and feedback!
Program Manager
Office 365