Exchange (Anglais)

Get Ready for Microsoft Ignite 2018

Exchange Team Blog -

Unless you’ve been living under an IT rock, you’ll know that Microsoft Ignite is happening soon. September 24th to 28th to be exact, in Orlando Florida.

If you didn’t buy a ticket already then I’m sorry to break to you that you are too late. It’s sold out! But it’s not all bad news; far from it. We have some great sessions planned and you’ll be able to watch them LIVE.

Yes, we’re streaming many sessions at the same time as they are delivered to the attendees live. Make sure you go back to the Microsoft Ignite 2018 site on the 24th and watch them there, or get links to breakout sessions.

The Session Catalog went live this week and you can use it to find the sessions you want to see right away. There are a few sessions I wanted to shout out to make sure you knew about them.

There are many more sessions, breakout and theaters. And many of the sessions are being delivered by the awesome MVP’s we have, but I can’t list them all here. So go take a look at the catalog and start figuring out what you want to go and see, or tune in to, LIVE.

For those of you actually in Orlando we have a special treat. We are sponsoring the Scheduled Maintenance party this year. If you have heard of that party (hosted by a Gold Partner - ENow Software) you’ll know it’s the hottest party of the week – and this year it’s being sponsored by Exchange and Outlook. So, if you want a chance to come and socialize with the engineering team, MVP’s and speakers, go and sign up. We know it will be over-subscribed and not everyone who wants to be there will be able to, but you can’t join if you don’t sign up and we would love to see as many of you there as we can.

See you in Orlando (or LIVE streaming)!

Greg Taylor
Director of Product Marketing
Exchange Server and Online

Deploy Exchange Server 2019 on Windows Server Core

Exchange Team Blog -

Hurrah! If you have not yet heard: Exchange Server 2019 Public preview was announced earlier, and it is the first version of Exchange that you can install on Server Core!

Now, while that’s great news, if you haven’t worked on Server Core, there may be bit of a learning curve. The purpose of this post is to help you install the Exchange Server 2019 on Server Core in your lab.

We are going to assume that you have:

  1. Installed an Active Directory global catalog domain controller. Exchange Server 2019 will work with writable DCs running Windows 2012 R2 and above. Here’s a link to get you going with Active Directory, in case you have not installed it yet.
  2. Installed Windows Server 2019 (or Windows Server 2016) Server Core operating system.

(In case you need help with Server Core deployment, please follow this link).

Getting started

Once you have installed Server Core and booted it up, you may find yourself staring at this strange, unfamiliar login prompt:

From here on, this command line interface is your friend!

Once you’re logged in, you will get the basic Command prompt window. From here, you can use the start command to launch processes into a new window. For instance, if you type start powershell, PowerShell will be launched into a new window. You can also type start cmd to launch an additional instance of the command interpreter. You can use exit to close any process. Typing taskmgr will launch the graphical based TaskMgr application.


If you close all command prompt windows and want to open a new one, you can do that from the Task Manager. To launch Task Manager try the CTRL+ESC shortcut, or if you’re logged in via Remote Desktop you may need to use CTRL+ALT+DELETE, click Start Task Manager. Then, , click More Details > File > Run, and then type cmd.exe. (Or Powershell.exe to open a PowerShell command window.) Alternatively, you can sign out and then sign back in.

Prepare the OS for Exchange installation

The following are preliminary tasks you will need to perform to configure the OS for Exchange installation. You can use Sconfig to configure the IP Address, install Windows Updates, enable remote desktop and join the server to AD domain. Alternatively, you can use PowerShell commands to perform each of these tasks, which is useful for scripted installations as well.

Configure IP Address:

Use the Get-NetIPAddress PowerShell command and identify interface index you want to configure the static IP on. Mostly, this should be the one that has Interface Alias Ethernet and AIPA auto assigned DHCP Address.

Sample Get-NetIPAddress output:

Then use the following command to assign a static IP:

New-NetIPAddress -InterfaceIndex 6 -IPAddress -PrefixLength 24 -DefaultGateway

If you are going to use a DHCP assigned IP Address, inspect the IP configuration provided.

Configure a DNS Server

Set-DNSClientServerAddress -InterfaceIndex 6 -ServerAddress ""

Enable Remote Desktop:

cscript C:\Windows\System32\Scregedit.wsf /ar 0

Windows features

Use the following PowerShell command to install the OS component required for Microsoft UCMA 4.0 and the OS component required for Active Directory Preparation.

Install-WindowsFeature Server-Media-Foundation, RSAT-ADDS

Download necessary software

From an admin workstation, download the following software and copy it over to the Server Core we are preparing for the Exchange installation (let’s say you copy the files into a C:\Software folder):

Then login to Server Core and do the following:

Install VC++ 2013 Redistributable

Install UCMA (Microsoft Unified Communications Managed API 4.0)

The UCMA installable is present on the Exchange Server 2019 media itself. Use the following PowerShell command to mount the Exchange Server media:

Mount-DiskImage c:\<FolderPath>\ExchangeServer2019-x64.iso

The UCMA installable is located under the “UCMARedist” folder on the Exchange Server 2019 .ISO. Start the UCMA installation:

.Net 4.7.1

Check the .Net version installed by following this link

If you are not on .Net version 4.7.1 already, use the following command to install the .Net 4.7.1 (not required on Windows Server 2019 Server Core):

C:\<FolderPath>\NDP471-KB4033342-x86-x64-AllOS-ENU.exe /q /log c:\temp\ndp.log

The .Net installation will continue in quiet mode, i.e. no progress bar will be displayed. At the end of successful installation, you will be asked to restart the computer. You can also take a look at the log file to check progress of the installation.

Start Notepad c:\temp\ndp.log

Do not reboot the server just yet; join the computer to an AD domain and then reboot it.

Joining the computer to AD domain

The following command will:

  • Rename the computer to E19Core1
  • Add the computer to domain

Add-Computer -DomainName -NewName E19Core1 -DomainCredential contoso\administrator

Restart the server

Use the following PowerShell command to restart the computer:

Restart-Computer -Force

Exchange installation

After rebooting the server mount the Exchange .ISO image again using Mount-DiskImage as you did before.

Use the following command to start Exchange Server installation. The PowerShell command will also install the required OS components for Exchange:

.\Setup.exe /m:install /roles:m /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents

Notepad is available on Server Core, in case you want to open the Exchange Setup log just for review or to troubleshoot any exchange setup issues. Launch it as follows:

start notepad c:\ExchangeSetupLogs\ExchangeSetup.log

Once Exchange is installed, you can launch the Exchange Management Shell using LaunchEMS command from the command line.

Alternatively, you can also use web browser from an admin workstation to access Exchange Admin Center.


We hope this article will help you to get started with your Exchange Server 2019 deployment on Server Core and help you perform various Exchange admin tasks once you are done!

Here are some more links that you can use to learn more!

Getting started with Server Core

Use the following information to install, configure, and manage the Server Core installation option of Windows Server.

Server Core installation:

Using Server Core:

Bhalchandra Atre

Exchange Server 2019 Public Preview

Exchange Team Blog -

Update 7/24: We have received some reports that some of started downloads result in files that cannot be opened after the download is completed. We are investigating the problem.

We’re pleased to announce a preview build of Exchange Server 2019 is now available. You can download it here.

We strongly believe Office 365 delivers the best and most cost-effective experience to our customers, but we understand that some customers have reasons to remain on-premises. Exchange Server 2019 is designed to deliver security, performance, and improved administration and management capabilities. These are the attributes our largest on-premises customers tell us they need from Exchange. We also have features end-users will love too of course.

Here are some of the key features in each of these areas:

Security: We’ve included support for installing Exchange Server 2019 onto Windows Server Core. Exchange Server 2019 installed on Windows Server 2019 Core provides the most secure platform for Exchange. You also have the option of installing the Exchange 2019 Preview onto Windows Server 2016 Core or Windows Server 2016/2019 with Desktop Experience, but we have worked hard to make sure running Exchange on Windows Server Core 2019 is the best choice for our code.

Performance: We’ve done work to allow Exchange Server to take advantage of the larger core and memory packed systems our customers buy these days. We’re confident you can be very successful running Exchange Server with up to 48 processor cores and 256GB of RAM.

We’ve re-engineered search using Bing technology to make it even faster and provide better results, and in doing so have made database failovers much faster, and administration easier.  The search indexes are now within the database itself. There are no more separate log files to manage. As the index data is now within the database, normal log shipping includes the database and search data in a single replication and the index is always up to date on all database copies.

At Ignite last year, we told you that Exchange Online had started using Solid State Drives. Yes, SSD’s. Many people were shocked at this.  For years we’ve been telling you to use cheap low-cost storage, and then we switched and started using SSD? What’s up with that Exchange team?

Well, that isn’t exactly what we said, what we said was we were using SSD’s in addition to cheap low-cost spinning disks. Why? Well we’ve pretty much reached the limits of what we can do with cheap storage, read latency in those disks hasn’t really improved yet storage capacity just keeps getting larger. It led us to conclude we needed to re-think our strategy. And we did, and the short version is that we store some of the data from those spinning disks on the SSD, and we use that super-fast device to store key search data, to make logins faster, and message retrieval faster. We still use low-cost storage for storing all of data but intelligently use SSD’s to make the overall user experience better.

We’re adding this tiered storage read/write capability to Exchange Server 2019 but it’s not enabled in the Preview build. We know you will all have lots of questions about this new feature and we will of course have planning and configuration guidance available when we ship, but we will be talking a lot more about these changes at Microsoft Ignite 2018. You are going, aren’t you? We are.

End user experience: One of the most important capabilities in Exchange is calendaring. All large enterprises are heavy calendar users and those organizations rely on calendars to help people get their work done. We’re bringing a few key features such as Do Not Forward and Simplified Calendar Sharing from Office 365 to On-Premises Exchange. We’re sure a lot of end users will be very happy with those features. Administrators get some new calendaring features too, as we’re adding the ability for admins to manage events on user’s calendars and to assign delegate permissions more easily.

One thing to note is that Unified Messaging role will not be available in Exchange Server 2019. Customers who currently connect either a 3rd party PBX or Skype for Business Server to Exchange Server won’t be able to do so with Exchange Server 2019 mailboxes. Those customers considering an upgrade to Exchange Server 2019 should consider migrating to Skype for Business Server 2019 and using Cloud Voicemail, or migrating to Office 365 with Cloud Voicemail. More information on this change will be available prior to launch.

That’s a brief roundup of many of the changes we have baked into Exchange Server 2019.

We plan on launching Exchange Server 2019 later this year, and we’re planning on talking about it a lot more at Microsoft Ignite.

Take a look at the Preview, and we really suggest you install it on Windows Server Core, and Windows Server 2019 Core if you have access to that. We will be publishing a blog post with tips for running Exchange on Server Core in a few days.

But please remember it’s not a production release, so please don’t install into production at all.

We look forward to your feedback, and in case we didn’t say it enough times, we’ll see you at Microsoft Ignite!

The Exchange Team.

Hybrid Configuration Wizard and licensing of your on-premises server used for hybrid

Exchange Team Blog -

A few years ago, we created a web site that would allow our hybrid customers to obtain what’s generally known as the “hybrid key”. This self-service site would validate your O365 tenant and after a few clicks, give you the key to license your on-premises server used for hybrid purposes. This site is no longer available for use, and we’ve come up with a better way for you to get the key.

We are excited to inform you we are now working on a feature that will allow the Hybrid Configuration Wizard (HCW) to detect and license your designated on-premises “hybrid server”, without having to go to a separate web site or call our support team. We expect this change to be live in HCW by August 7th.

What will the new experience be?

When you choose the “Detect the optimal Exchange server” option, HCW will perform the license check on the server and give you a new “license this server now” option, if the server is currently not licensed. Note: HCW will not let you continue from this point on if this server is not licensed, unless you specify an alternate Exchange server to run Hybrid against (second radio button below):

Selecting the “license this server now” link will prompt you for your online administrator credentials. We realize this is an extra credential prompt at this time, but it is needed to validate and obtain the key (the old key distribution site also required authentication).

HCW will then indicate the progress of applying the server license to your on-premises server:

Next up, you will get a confirmation that the server has been licensed. You will also have an option to copy the product key (and the CMDlet needed to use it) if you wish to do so:

At this time, unless you want to complete the setup of Hybrid in the HCW, you can exit / cancel the wizard. Full completion of the HCW workflow is not needed for this process to be executed; your on-premises server will remain licensed, and you can re-run HCW at a later date / time.

Let us know what you think!

The Exchange Hybrid Team

Issue with July Updates for Windows on an Exchange Server

Exchange Team Blog -

The Exchange team is aware of issues with the Windows Operating System updates published July 10th, 2018 causing Exchange to not function correctly. The Windows servicing team has advised us that they will be releasing updates to the affected packages. We encourage Exchange customers to delay applying the July 10th updates, including the security updates released on the same date, on to an Exchange server until the updated packages are available.

The Exchange Team

Upcoming changes to Exchange Web Services (EWS) API for Office 365

Exchange Team Blog -

Over the last few years, we have been investing in services that help developers access information in Office 365 in a simple and intuitive way, specifically through Microsoft Graph.  Microsoft Graph and the use of OAuth 2.0 provide increased security and seamless integration with other Microsoft cloud services and is rapidly expanding developer access to the rich data sets behind Microsoft applications.  

As we make progress on this journey, we have continued to evaluate the role of Exchange Web Services (EWS). Today we are sharing our plans to move away from Basic Authentication access for EWS over the next two years, with support ending Oct. 13, 2020.   

These plans apply only to the cloud-based Office 365/Exchange Online products; there are no changes to EWS capabilities of on-premises Exchange products

Exchange Web Services will not receive feature updates 

Starting today, Exchange Web Services (EWS) will no longer receive feature updates. While the service will continue to receive security updates and certain non-security updates, product design and features will remain unchanged. This change also applies to the EWS SDKs for Java and .NET as well. 

While we are no longer actively investing in it, EWS will still be available and supported for use in production environments.  However, we strongly suggest migrating to Microsoft Graph to access Exchange Online data and gain access to the latest features and functionality. For more information and details on how to make the transition, please refer to the following articles: 

While EWS and Graph have mostly overlapping functionality, there are some differences. If you rely on an EWS API that does not have a Graph counterpart, please let us know via UserVoice of features needed for your app scenarios.   

Basic Authentication for EWS will be decommissioned 

Exchange Web Services (EWS) was launched with support for Basic Authentication. Over time, we've introduced OAuth 2.0 for authentication and authorization, which is a more secure and reliable way than Basic Authentication to access data. Please refer to the following article for more information: 

Getting started with OAuth2 for Microsoft Graph 

Today, we are announcing that on October 13th, 2020 we will stop supporting and fully decommission the Basic Authentication for EWS to access Exchange Online. This means that new or existing apps will not be able to use Basic Authentication when connecting to Exchange using EWS.  

Next Steps 

The deprecation of these APIs follows our service deprecation policies. We understand changes like this may cause some inconvenience, but we are confident it will ensure more secure, reliable, and performant experiences for our customers. 

We're here to help if you need it. If you have questions, please let us know in Stack Overflow with the [MicrosoftGraph] tag. 

Thank you in advance for updating and opening your apps to a wider range of useful and intelligent features on Microsoft Graph. We are extremely excited about the growing opportunities that Microsoft Graph offers to our customers, and we remain fully committed to continue our journey to empower developers to access Office 365 data with the most modern features and tools. 

Frequently Asked Questions  

Q: Will my application stop working when you make this change? 

A: It might, yes, it depends on the app itself and how it was coded. If it’s using EWS, and if it’s using Basic authentication then yes, on October 13th 2020 it will fail to connect. However, if the app is using Modern Auth/OAuth, then no, it will keep working as it did before.  

Q: Why October 13th 2020? Why that date? 

A: Starting October 13, 2020, Office 365 ProPlus or Office perpetual in mainstream support will be required to connect to Office 365 services. This announcement is posted here Office 365 ProPlus Updates.  

This change requires that Office 2013/Office 2016 are also required to use Modern Auth. Please see this.

Q: Our in-house team created an app for meeting room scheduling, how do we go about changing that over to Graph and OAuth2.0?  

A: Don’t forget you can keep using EWS if you want to, so then really, it’s just the question of authentication. To get a better understanding of how to use OAuth 2.0 take a look here.

Q: How does this impact my On-Premises Exchange deployment? 

A: It does not. This change only affects Exchange Online.  

Q: We require Modern Authentication + Multi Factor Auth for all our Outlook users connecting to O365, how do apps work when I have that set as a requirement? 

A: Applications can be written so they are treated as ‘trusted applications’. That way they can bypass the MFA requirement, more details are here.

Q: How do I know which of my apps use Basic authentication to EWS? 

A: If you only Outlook to connect to Exchange Online then you don’t need to worry, as long as you are using Office 2019 or Office 2019 Pro Plus you’ll be fine come October 2020. However, if you also have integrated apps into your Office 365 tenant you’ll need to check with the application developers to verify how it authenticates to Exchange Online if you aren’t’ sure. We are investigating how we can share this information with tenant admins, but have nothing available at the time of writing this blog.  

Q: What features does EWS have that Graph can’t provide? 

A: Graph is constantly evolving and adding features and functionality to provide the richest set of experiences we can. To see the latest features we’ve added to Graph, go here Overview of Outlook mail API on Microsoft Graph 

Q: Will this affect my Exchange Hybrid configuration? Exchange On-Premises calls into Exchange Online using EWS doesn’t it? 

A: Yes, it does. But it doesn’t use Basic Authentication, it uses token-based authentication, and it’s described in this blog post. How Hybrid Authentication Really Works.  

The Exchange Team

Resource Based Throttling and Prioritization in Exchange Online Migrations

Exchange Team Blog -

We often get questions about throttling in Mailbox Replication Service (MRS) based migrations in Exchange online. When migrating, you may see messages such as StalledDueTo_TargetDiskLatency for some periods of time. These messages come from our resource-based throttling infrastructure in Exchange Online.

This is how this would look like in the output of Get-MoveRequestStatistics:

PS C:\> Get-MoveRequestStatistics <user> | fl Status,StatusDetail
Status : InProgress
StatusDetail : StalledDueTo_TargetDiskLatency

Or in a move report, you may see:

The job has been paused temporarily due to unfavorable server health, with request throttling state: 'StalledDueToTarget_DiskLatency'.

We throttle and prioritize work in the Exchange Online service based on priority and resource load. The highest priority is the end-user experience, so some workloads like OWA access, Outlook access, and email delivery are the highest priority. Other things, like select mailbox assistants and customer migrations, are in the second tier but with lower priority than client access and mail flow. There are also some even lower-priority workloads such as load-balancing mailbox moves, maintenance, and other discretionary tasks. We throttle lower priority workloads at the point where they could degrade the end-user experience or the performance of higher priority workloads. For instance, we throttle migrations when they might negatively impact OWA access or email delivery.

Take this example: As a customer, you migrate your data to Exchange online. Imagine one day you receive a notification stating: “Your email delivery will be delayed by 1-2 hours today to allow another customer to migrate to Exchange Online more quickly.” You would not accept this scenario and we don’t either. We absolutely understand migration is important, but it is not the highest priority workload in Exchange Online.

In summary, there are some things you should understand to make your migration experience go smoothly.

  1. The throttling you see is not per-user or per-tenant. We throttle only based on resource load in MRS-based migrations. So, when you see a message indicating a stall, it is simply happening to preserve the overall health of the Exchange Online service. We do not have any ability to lift MRS migration throttling for a particular tenant or user. Additionally, you may get better migration throughput during off-peak hours since the resources consumed during these times will probably be lower.
  2. Seeing a “StalledDueTo” or throttling message does not mean that Office 365 has a problem. You should expect some amount of throttling in any migration you perform. This throttling may occur at unpredictable or inconvenient times; you should plan your migrations accordingly. There is no action you need to take; the migration will resume automatically when resources become available.
  3. Do not set very short timelines for migrations of individual user mailboxes, because you are unable to predict migration resource availability in Office 365. Instead make sure you complete the initial sync well ahead of time and complete the migrations at a later time.

Note: Some migration stalls can originate from the on-premises environment. It’s important to take note of the directionality of the stall. If the message says “Source” and you are moving mailboxes to Exchange Online, it means the stall is from the on-premises environment. Likewise, if the message says “Target” and you are moving mailboxes from Exchange Online (back to on-premises), the stall is also originating from the on-premises environment.

Brad Hughes

Update on mail flow insights

Exchange Team Blog -

Last month, we announced the release of mail flow insights in the Office 365 Security & Compliance Center in this blog post. We're making changes to the mail flow insights dashboard to make it more intuitive. These changes are currently in deployment, and will be available in the week of June 25, 2018.

We've changed some widgets in the mail flow dashboard, as shown in the following screenshot:

We've combined the TLS report for inbound and outbound email traffic and the connector report into one widget. Clicking View details will give you all the TLS status for your organization, and the connector report link will lead you to the detailed connector report. We will retire the TLS report in the near future since it's no longer needed.

We've changed the "Forwarding overview report" widget to "Auto-forward messages" to give you a quick summary of the auto-forwarding status for your organization:

Click the message number in the "Auto-forwarded messages" widget and the flyout will show the auto-forwarded message status. You can see the details by clicking "Forwarding Report" link, as shown below:

We encourage you to take advantage of mail flow insights in the Office 365 Security & Compliance Center. We will continue to improve the current insights as well as add new insights, and we're looking forward for your valuable feedback.

Carolyn Liu

Correcting Shared Mailbox provisioning and sizing

Exchange Team Blog -

We are correcting how shared (and resource) mailboxes are created in Exchange Online.

As per our documentation (here and here), shared and resource mailboxes in Exchange Online should be created with the size of 50GB and if a larger size is desired, a license should be assigned to the mailbox. For some time now, though, while our documentation has (correctly) stated this, the Exchange Online system would, for many of our customers, create both new shared and resource mailboxes with a default size of 100GB even if a license was not assigned. We knew that this was happening, and we were working to address this in our mailbox provisioning system.

This is what is now being corrected to the documented behavior.

The new shared or resource mailbox creation behavior (starting end of July) will by default be 50GB, as per our documentation – and if you require a shared mailbox that is larger than 50GB, an Exchange Online Plan 2 license will need to be assigned to it. Once a license is assigned, the mailbox size should quickly increase to 100GB (equivalent size for an Exchange Online Plan 2 licensed user mailbox).

To help you with understanding how this change might impact your existing shared mailboxes and what the behavior is going forward, we have prepared the following Q&A:

When the 50GB shared mailbox creation correction goes into effect, will all the already created unlicensed shared mailboxes with a default size of 100GB be automatically switched to 50GB?

No, not automatically; but they could revert to 50GB under certain situations, read on to understand these scenarios.

When would a currently unlicensed shared mailbox lose its existing 100GB status?

Changing the state of the license on the mailbox will apply the corrected 50GB default state. If license on the mailbox is changed, the 100GB status for that mailbox will be irreversibly lost and to increase the mailbox size back to 100GB, an appropriate license will be required.

I currently have an unlicensed 100GB shared mailbox with 80GB of data and I need archiving for it. What will happen if I assign the Exchange Online Archiving license?

Any change to the licensing state of the shared mailbox will make the shared mailbox lose its 100GB status. In other words – even assigning the Archiving license only to a currently unlicensed shared mailbox will change the mailbox quota to 50GB and an Exchange Online Plan 2 license (or equivalent) will be needed to increase the mailbox size to 100GB. In this scenario, if you wanted to assign an Archiving license, you would also need to assign at least an Exchange Plan 2 license.

When this change goes into effect, let’s say I have an 80GB user mailbox and want to convert it to a shared mailbox. What will happen?

When mailbox conversion happens, the currently assigned license will stay assigned on the mailbox (by default) and shared mailbox will keep sending/receiving email. If you then remove the license from this converted shared mailbox, the 50GB mailbox quota will get enforced. The mailbox size will still be 80GB, but because the mailbox will be over quota, sending and receiving of email will not work (incoming email will error with “Mailbox is full” error, code 5.2.2). Assigning the required license to the mailbox again will resolve this problem (this change might take a little bit of time). If you intend to use a shared mailbox larger than 50GB actively, we recommend that you keep the license assigned after conversion so there are no work disruptions. You are also able to leverage Inactive Mailboxes if you just need to keep mailbox data around in inactive state.

If I have a user mailbox that is under 50GB in size and convert it to a shared mailbox – what will happen?

When mailbox conversion happens, the license will stay assigned on the mailbox (by default). If you remove the license, the mailbox will still be available for sending and receiving email because the size of the converted shared mailbox is under 50GB and shared mailboxes under 50GB do not require a license. If the size of this shared mailbox goes over 50GB, you will need to add a license to it (to increase its size to 100GB) or remove some email from it (to stay under the 50GB).

If I have a shared mailbox that is approaching 50GB and need it to be larger, what should I do?

Simply assign it an Exchange Online Plan 2 license; you do not need to do anything else. Shared mailbox size will be increased to 100GB automatically within 15 minutes.

Licensing change already went into effect. I just converted a 50GB unlicensed shared mailbox into a user mailbox and now I have a 50GB user mailbox. What’s going on?

When you convert an unlicensed mailbox from shared to user (using Exchange Admin Center, for example), the resultant mailbox will be an unlicensed user mailbox (because the starting shared mailbox did not have a license). This mailbox is not ‘attached’ to an account as there is no license assigned. When the license is assigned to the user, the mailbox will be re-attached to the account and its size will be set according to the license that was assigned to it. So, if you assign a license that gives the user a 100GB mailbox, the mailbox size will be increased to 100GB. Reminder: without a license, such an ‘unattached’ mailbox will be deleted after 30 days (as it does today).

I have an 80GB shared mailbox on-premises and I need to migrate it to Exchange Online. What should I do?

Because the target Exchange Online shared mailbox needs to be larger than the default (unlicensed) 50GB size, the shared mailbox cloud MailUser object needs to be licensed before migration is attempted. Otherwise, the migration attempt will immediately fail with the “Mailbox size exceeds target quota” error. Once the Exchange Online Plan 2 license is assigned, migration can be started.

Nino Bilic

Announcing the support for modern public folder migrations without dumpster data

Exchange Team Blog -

Long time Exchange administrators will remember that Exchange Server had a feature that was for a while unceremoniously referred to as the “dumpster”. We have since renamed the feature to a more descriptive Recoverable Items Folder. This blog post also contains a bit of history of this feature for those interested.

Up to now, during public folder migration, all the public folder data including dumpsters was migrated from on-premises servers to the cloud. Administrators did not have an option to exclude this data at migration.

We are introducing the ability to migrate public folders to cloud without migrating the dumpster data. To do this, administrators need to pass the ExcludeDumpsters parameter while creating the migration batch. This option can be used when source server version is Exchange 2013 or 2016. Here is an example of how to use this parameter:

New-MigrationBatch -Name PublicFolderMigration -CSVData $bytes -SourceEndpoint $PfEndpoint.Identity -ExcludeDumpsters

Why would you want to do this?

Excluding this data can help you scale your public folder migration if you do not need the data to come over. This will result in faster public folder migration as the amount of data that will need to be migrated is going to be smaller.

To check the dumpster folders size, you can run the following:

Get-PublicFolder \NON_IPM_SUBTREE\DUMPSTER_ROOT -Recurse -ResultSize:unlimited | ?{$_.FolderClass -ne "$null"} | ft name,foldersize

In addition to size consideration, we have seen some organizations where dumpster data got corrupted (for various reasons) and administrators did not want that corrupted data migrated to cloud. If you find yourself in that situation, this feature will enable you to leave that data behind.

The obvious drawback to doing this is that users will lose the ability to recover items that were previous deleted from public folders (pre-migration).

Note: The ExcludeDumpsters parameter is optional and if not passed to migration batch, all dumpsters will migrate to cloud. Once you choose to exclude dumpsters and the migration is finalized, there is no way to go back and re-include the dumpsters into cloud public folders. If, during the migration in which you used the ExcludeDumpsters parameter, you decide that you do want to migrate the dumpsters data to the cloud, remove the current migration batch and create another without the ExcludeDumpsters parameter.

This option can be added at point 4 of Step 7 in below TechNet articles for public folder migration (we will work to change the documentation next):

Keep checking this blog for further updates on the subject!

In case of any questions, please do reach out to us via the comments section below.

Public folder team

Released: June 2018 Quarterly Exchange Updates

Exchange Team Blog -

The latest cumulative updates for Exchange Server 2016 and Exchange Server 2013 are now available on the download center. An update rollup for Exchange Server 2010 is also available. The updates released today include important changes to the pre-requisites required to install Exchange Server. The installation packages include fixes to customer reported issues, all previously reported security/quality issues and updated functionality.

Updated Pre-requisite requirements .NET Framework 4.7.1

As announced previously, Exchange Server 2016 Cumulative Update 10 and Exchange Server 2013 Cumulative Update 21 require .NET Framework 4.7.1. Exchange Setup will enforce this requirement during cumulative update installation. Customers who are running an older version of .NET Framework will need to update their server to .NET Framework 4.7.1 then install the latest cumulative update.

VC++ 2013 runtime library is required

The Exchange Server updates released today require the VC++ 2013 runtime library installed on the server. The VC++ runtime library is required to provide current and future security updates for a third party component shipped with Exchange Server. The component provides WebReady Document Viewing in Exchange Server 2010 and 2013 and Data Loss Prevention in Exchange Server 2013 and 2016. Setup will enforce the installation of the pre-requisite on Exchange Server 2013 and 2016 when a cumulative update is applied. Exchange Server 2010 Update Rollup 22 and later will force the installation of the VC++ runtime before the update can be applied. Future security updates for all versions of Exchange Server will force installation of the runtime package if not already installed. Customers who use Windows Update to patch or update their servers, will need to ensure that the VC++ 2013 runtime package is applied before running Windows Update. Update Rollup 22 and future security updates for all versions of Exchange server will fail to install manually or via Windows Update if the runtime library is not installed.

The packages released today include an updated version of the third party component to resolve the issues identified in Microsoft Advisory ADV180010. Customers are encouraged to apply the updates released today as soon as possible. The Exchange team has previously stated they will not ship security fixes in a cumulative update not previously released separate from a cumulative update. That goal and official plan of record are unchanged. Shipping the updated third party components in a cumulative update was necessary to integrate a new version of the components and a new product dependency not previously required by Exchange in a manner customers are accustomed to with minimal disruption to the Windows Update process.

Important Updates for Exchange Server 2010 Support for Windows Server 2016 Domain Controllers

Exchange Server 2010 Service Pack 3 Update Rollup 22 and later add support for Windows Server 2016 domain controllers. There are no restrictions to adding Windows Server 2016 domain controllers in forests where Exchange Server 2010 is deployed. Support for Active Directory Forest Functional Levels through Windows Server 2016 is included. Domain Controllers must be running Windows Server 2016 updates released through June 2018 to be supported. Customers are encouraged to remain current by applying monthly operating system quality updates.

Fix for Exchange Web Services Impersonation in Co-existent Environments

The issue identified in KB4295751 is now resolved in Update Rollup 22. Customers who have Exchange Server 2010 deployed in the same forest as Exchange Server 2016 are encouraged to deploy Update Rollup 22 to ensure that unauthorized access to mailboxes on Exchange Server 2010 does not occur.

Latest time zone updates

All of the packages released today include support for time zone updates published by Microsoft through May 2018.

Exchange Server 2013 Extended Support

Exchange Server 2013 entered extended support in April 2018. Cumulative Update 21 is the last planned quarterly update for Exchange Server 2013. Customers must upgrade to Cumulative Update 21 to continue to receive future security updates.

Release Details

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

The updates released today do not 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 before applying either of the cumulative updates released today.

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 CU20, 2016 CU9) or the prior (e.g., 2013 CU19, 2016 CU8) 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.

The Exchange Team

Hybrid Organization Configuration Transfer

Exchange Team Blog -

We are very happy to announce a new feature that will help you the admin reduce the amount of time needed to configure config objects once hybrid setup is complete.

What does this feature do?

This feature enables a one-time transfer of key organization policy objects during the onboarding process from Exchange on-premises to Exchange Online. This feature is tightly integrated into the existing Hybrid Configuration Wizard. The administrator running the HCW can choose to migrate either all the detected objects while onboarding from Exchange on-premises to Exchange Online or choose not to transfer any. This is only a one-time transfer though, to avoid the need to have you set them up manually. Once the one-time transfer is complete, you will need to manually update values in either On-prem or Online to keep them in sync if you change anything.

We’re supporting this config transfer whether you are migrating from Exchange Server 2010, Exchange Server 2013 or Exchange Server 2016, and we’re delivering this feature in phases. Phase 1 will be launched at the end of June 2018. Which is… kind of… pretty much now, really.

What kind of Policy objects are in scope?

The objects we’re including in phase 1 are:

  • Retention Policy
  • Retention Policy Tags
  • OWA Mailbox Policy
  • Mobile Device Mailbox Policy
  • Active Sync Mailbox Policy

However, in phase 1 only new objects/policies will be copied over from on-premises to cloud. Any existing objects/policies in Exchange Online will not be modified.

How do I use this cool new feature?

This feature is completely integrated into the existing Hybrid Configuration Wizard. Just downloading the latest HCW is all you need to do. As you can see from the screenshot, we’ve added a checkbox at the bottom of the Hybrid Features page to allow you to enable this feature and to copy over objects from your Exchange on-premises organization to Exchange Online.

What’s next?

In phase 2, in addition to copying several new objects (Organization Config, DLP Policy, Active Sync Device Access Rule and Active Sync Organization Settings) from on-premises to cloud, the admin will be given a choice to update existing objects in the cloud if the attribute values are different from those on-premises.

We hope you enjoy this new feature and look forward to hearing any feedback or comments, either here on the blog or directly in HCW – we’ve built an awesome feedback system into the HCW and we love to hear what our customers have to say.

Kavya Chandra
Program Manager, Office 365 Enterprise Cloud

Sender Rewriting Scheme (SRS) coming to Office 365

Exchange Team Blog -

The introduction of email authentication mechanisms like SPF, DKIM, and DMARC have improved email security and spoofing prevention. However, some scenarios have been disrupted by these authentication mechanisms, namely auto-forwarding and relaying. Here in Office 365, we are committed to ensuring the security of our customers and the general integrity of the email ecosystem that we are a part of.

From July 16th, we will begin rolling out Sender Rewriting Scheme (SRS) functionality to solve the problem of auto-forwarding being incompatible with SPF. The SRS feature will rewrite the P1 From address (also known as the Envelope From address) for all applicable messages being sent externally from Office 365. The From header (also known as Display From address or P2 From address) which is displayed by email clients will remain unchanged. This change will improve deliverability of applicable messages since SPF checks that were failing in the past for such messages will now pass.

Regarding ‘applicable’ messages, we anticipate the following scenarios will be affected and result in SRS rewriting the P1 From address:

  1. Messages that are auto-forwarded (or redirected) from hosted mailboxes using one of the supported methods – SMTP forwarding, Mailbox Rule (or Inbox rule) redirection, Transport Rule redirection.
  2. Messages that are auto-forwarded (or redirected) from our customer’s on-premise environments and relayed through Office 365.

Note: SRS rewriting would also rewrite the P1 From address of messages that are relayed from our customer’s on-premise environment, where the P1 From domain is NOT a verified domain. Customers should only be sending messages from domains in their Accepted Domains list. Find out more about Accepted Domains in Office 365 here.

This change results in Non-Delivery Reports (NDRs) returning to Office 365 instead of the original sender as it occurs today without SRS. Part of the SRS implementation, therefore, is to reroute returning NDRs to the original sender in the case where a message could not be delivered.

Details Auto-forwarding emails for an Office 365 hosted mailbox

A message auto-forwarded for a hosted mailbox by mechanisms such as SMTP forwarding or Mailbox Rule redirection or Transport Rule redirection will have the P1 From rewritten before it leaves Office 365 using the following pattern:

<Forwarding Mailbox Username>+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Forwarding Mailbox Domain>


A message is sent from Bob ( to John's mailbox in Office 365 ( John has set up auto-forwarding to his home email address (

Original message Auto-forwarded message Recipient P1 From From header Relaying from a customer's on-premises server

A message relayed from a customer's on-premises server or application through Office 365 from a non-verified domain will have the P1 From address rewritten before leaving Office 365 using the following pattern:

bounces+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Customer's Default Accepted Domain>

Important: In order to receive NDRs for relayed messages that are rewritten by SRS, a mailbox (either hosted or on-premises) needs to be created with the username 'bounces' and the domain being the default Accepted Domain of the customer.


A message is sent from Bob ( to John's mailbox ( on his company's own Exchange server. John has set up auto-forwarding to his home email address (

Original message Relayed message received by Office 365 Relayed message sent from Office 365 Recipient P1 From From header

Find out more about the draft SRS standard that this change is took design ideas from here:

Sean Stevenson

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