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

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:

• Exchange Server 2016 Cumulative Update 10 (KB4099852), Download, UM Lang Packs
• Exchange Server 2013 Cumulative Update 21 (KB4099855), Download, UM Lang Packs
• Exchange Server 2010 Update Rollup 22 (KB4295699), Download

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

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):

• Use batch migration to migrate Exchange 2013 public folders to Exchange Online
• Use batch migration to migrate Exchange 2016 public folders to Exchange Online

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

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

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

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

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: 

• Overview of Microsoft Graph 
• Overview of Outlook mail API on Microsoft Graph 

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

The Exchange team is aware of issues with the Windows Operating System updates published July 10^th, 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 10^th updates, including the security updates released on the same date, on to an Exchange server until the updated packages are available.

The Exchange Team

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 7^th.

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

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.

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.

Example:

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 192.168.12.123 -PrefixLength 24 -DefaultGateway 192.168.12.100

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 "192.168.12.121"

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):

• Exchange Server 2019 Public Preview
• Visual C++ Redistributable Packages for Visual Studio 2013 (vcredist_x64.exe)
• .Net 4.7.1 offline installer (required only for Windows Server 2016)

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 corp.contoso.com

Add-Computer -DomainName corp.contoso.com -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.

Summary

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:

• Roles, Role Services, and Features included in Server Core
• Roles, Role Services, and Features not in Server Core
• Install the Server Core installation option
• Configure Server Core with the SConfig tool

Using Server Core:

• Basic Server Core administration tasks using Windows PowerShell or the command line
• Manage Server Core
• Patching Server Core
• Configure memory dump files
• Windows Admin Center

Bhalchandra Atre

Unless you’ve been living under an IT rock, you’ll know that Microsoft Ignite is happening soon. September 24^th to 28^th 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 24^th 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.

• We have a session with more details on Exchange Server 2019. That’s BRK2176 - Welcome to Exchange Server 2019! And it’s on Monday, September 24, 4:00 PM - 5:15 PM.
• We’re going to wheel Scott Schnoll back out for the 873^rd edition of Scott Schnoll’s Exchange and Office 365 tips and tricks – that’s BRK3147 and is planned for Friday, September 28 12:30 PM - 1:45 PM
• Jeff Kizner is going to update you all on the latest happenings in all things Hybrid and more. If you missed Jeff’s session last year you missed one of the most informational sessions at Ignite. Watch it this year - BRK3143 - Hybrid Exchange: Making it easier and faster to move to the cloud - Wednesday, September 26 - 10:45 AM - 12:00 PM
• Brandon Koeller is going to demo the most common attacks against Exchange Online and explore what you can do to prevent, detect, investigate, and remediate those attacks. Don’t miss that - BRK3148 - Securing Exchange Online from modern threats - Tuesday, September 25 10:45 AM - 12:00 PM
• Ross Smith IV will of course be there too, and he’s going to explain how to securely deploy Microsoft Outlook for iOS and Android - BRK3145 - Deploying Outlook mobile securely in the enterprise - Thursday, September 27 10:45 AM - 12:00 PM
• One of the highest rated sessions at Ignite last year was delivered by Julia Foran. So make sure you see her (and Jennifer Lu too this year, and those two are quite a double act I promise you.) They will tell you What's amazing and new in calendaring in Outlook! In BRK3146 - Thursday, September 27, 9:00 AM - 10:15 AM

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

What just happened?

During a rousing presentation that was marked by wild cheers and standing ovations, we announced a few features designed to simplify hybrid Exchange deployments and speed onboarding to Exchange Online (EXO).

The features we discussed focused on two key problems, hybrid administration and configuration as customers prepare to move to the cloud and the complexities and security blockers some customers face when publishing their on-premises environments.

Let’s review.

Administration and Configuration

Back in June, we launched Organization Configuration Transfer (OCT). The idea is to take the configurations made in Exchange Server on-premises and transfer them to Exchange Online to reduce the burden of re-configuring all your settings before onboarding. Today we announced OCTv2, due out October 2018.

What does OCTv2 do?

First and foremost, seven additional objects have been added to OCT as part of v2.

But the real difference in v2 is how we deal with object conflicts.

In OCTv1, we run a bunch of new-* commands and when we find an object on-prem that matches and object with the same name in the cloud, we simple skip over it. As part of v2, if an object with the same name already exists both on-premises and online, you can now choose to either overwrite the values of the objects in EXO or keep them as is. And, just in case you overwrite the cloud settings and didn’t mean to, we’ve provided a rollback script to undo those changes.

What are the Exchange Server Versions supported?

OCT supports Exchange Server 2016, 2013 and 2010. OCT requires the latest cumulative update or update roll-up available for the version of Exchange you have installed in the on-premises organization. But if that’s really too much of a burden, the immediate previous release is also supported. You want to run any other CUs or RUs, you’re out of luck.

Exchange Server 2019 will be supported once it reaches GA.

Hybrid Publishing

To establish a hybrid Exchange environment, customers must publish their on-premises environments. This includes, but is not limited to, adding external DNS entries, updating certificates, and allowing inbound network connections through your firewall. Over time, we’ve learned of two consistent problems here, (1) this is hard for some customers. The number of support cases asking for help in these areas tells us that. And (2) some customers, really their security wonks, do not want to publish their on-premises environments to the internet.

The Microsoft Hybrid Agent

Today, we introduced the world to the Hybrid Agent. Put simply, the goal of the Hybrid Agent is to fix those customer problems. Now, when running the Hybrid Configuration Wizard (HCW) you are presented with the option to use Exchange Modern Hybrid

This will install an agent, built on the same technology as Azure Application Proxy, this will publish your Exchange on-premises environment to EXO without requiring any of the changes customers have struggled with.

V1 of the Hybrid Agent will support the core scenarios of mailbox moves and free/busy for your hybrid deployment and is in private preview now. We’re focused on getting to public preview and GA as quickly as possible. In the meantime, we’re also working on additional scenarios we can support with the Hybrid Agent.

What’s next?

Well, if you missed the session at Ignite, go back and watch the replay (when available). Then come back here and stay tuned for updates.

Kavya Chandra, Georgia Huggins

In the security advisories released on 10/09/2018, CVE-2010-3190 was updated to apply to Exchange Server. This bulletin now applies to all versions and cumulative updates for Exchange Server released prior to October 2018.

The Exchange team is aware that the installation program for Exchange Server is applying an unpatched version of a Visual Studio released binary which was updated in the package to address CVE-2010-3190.

The Exchange team encourages customers to apply the KB2565063 update described in MS11-025 to all Exchange servers.

This action is necessary to ensure servers are protected against the vulnerability outlined in the advisory.  Windows Update and Microsoft Update will not automatically apply this update to an Exchange Server.  The installation of a cumulative update released prior to October 2018 will overwrite the affected binary even if MS11-025 was previously applied to the server.  The advisory lists the MS11-025 update as important indicating there is low to medium risk associated with the vulnerability.  Microsoft is not aware of any instances where the exploit has been used against an Exchange Server.

Applying this update does not require a reboot of the server or stopping any Exchange services.

The Exchange team considers ensuring the security of your servers and data our top priority.  We have examined the Exchange installation process to identify any additional similar scenarios where dependent binaries are not being properly updated when Exchange is installed.  We have modified Exchange installation so that all cumulative updates released after September 2018 will no longer install dependent Visual Studio binaries.  We have added pre-requisite rules to ensure that the correct version of the Visual C++ and Microsoft Foundation Class (MFC) libraries are installed via their native redistribution package before Exchange installation will proceed.  The steps taken will ensure that the correct versions of system and shared binaries are installed and that Windows Update and Microsoft Update are able to detect the need for any future updates to these dependent binaries.

The Exchange Team

The latest cumulative update for Exchange Server 2016 is now available on the download center. There is no release for Exchange Server 2013 or Exchange Server 2010 as these products are both in the extended support phase of lifecycle. The cumulative update released today includes fixes to customer reported issues, all previously reported security/quality issues and updated functionality.

Updated Pre-requisite requirements

.NET Framework 4.7.2 Support

.NET Framework 4.7.2 is now supported with Exchange Server 2016 Cumulative Update 11. .NET Framework 4.7.2 will be required on Exchange Server 2016 with the Cumulative Update released in June, 2019.

We have validated .NET Framework 4.7.2 on the previously released Exchange Server 2013 Cumulative Update 21 and are announcing .NET Framework support with Exchange Server 2013 Cumulative Update 21 as well.

.NET Framework 4.7.2 will be required on the forthcoming Exchange Server 2019. Windows Server 2019, which is also required for Exchange Server 2019, installs .NET Framework 4.7.2 by default.

Changes to Visual C++ Version Dependencies

With today’s release we are updating the Visual C++ runtime version dependencies on Exchange Server 2016. Effective with Cumulative Update 11, all Exchange Server 2016 roles (Management Tools, Mailbox, Edge) will require installation of Visual C++ 2012 runtime. This is a change from Cumulative Update 10 where Visual C++ 2013 was incorrectly listed as being required on all roles. Visual C++ 2013 runtime, in addition to Visual C++ 2012, is required on the Mailbox role only.

Versions of Exchange setup before Cumulative Update 11 silently installed Visual C++ 2010 and 2012 components. Exchange setup has been changed in Cumulative Update 11 and later to enforce the Visual C++ runtime requirements using setup pre-requisite rules. When installing Cumulative Update 11 or later for the first time on an existing server, setup will detect the presence of the previously installed instances of Visual C++ placed there by Exchange setup and will not indicate that the Visual C++ 2012 runtime needs to be installed.

However, when setup performs the first upgrade of a server to Cumulative Update 11 or later, it will remove the versions of the Visual C++ binaries placed there by Exchange setup previously. This removal is necessary to change setup behavior, correct the condition which caused us to issue an advisory to install MS11-025 and ensure that future Visual C++ updates are applied by Windows Update and Microsoft Update.

Important: To avoid a setup failure, it is necessary to install the Visual C++ 2012 runtime before installing Cumulative Update 11 or later for the first time on an existing server. The setup pre-requisite rule works as expected when using Cumulative Update 11 or later to install a new server using the Cumulative Update 11 or later package.

Note: Exchange Server 2019, when released, will include the Visual C++ pre-requisite rules enforced by setup.

Release Details

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

• Exchange Server 2016 Cumulative Update 11 (KB4134118), Download, UM Lang Packs

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.

Cumulative Update 11 does require an Administrator to execute SETUP /PrepareAD to ensure RBAC roles are current before applying the cumulative update released today.

Adjustment to Cumulative Update Release Schedule

Due to the delay associated with Cumulative Update 11, there will not be a cumulative update released in December 2018. Our next planned set of quarterly updates will occur in March 2019 and will include Exchange Server 2016 Cumulative Update 12 and Exchange Server 2019 Cumulative Update 1.

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 currently supported cumulative update for the product version in use, e.g., 2013 Cumulative Update 21, 2016 Cumulative Update 10 or 9.

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

Several months ago we added a feature to the Microsoft 365 Roadmap which generated a lot of interest. The feature was named Disable Basic Authentication in Exchange Online using Authentication Policies and as the roadmap items stated - it provided the capability for an Admin to define protocols which should allow Basic Authentication.

Why was that so interesting? Well as you probably know, Basic authentication in Exchange Online accepts a username and a password for client access requests and blocking Basic authentication can help protect your Exchange Online organization from brute force or password spray attacks. Lately there has been an increase in the occurrence of these types of attacks, and so we are accelerating our release of this feature as it helps prevent them.

If your organization has no legacy email clients or doesn’t want to allow legacy email clients, you can use these new authentication policies in Exchange Online to disable Basic authentication requests. This forces all client access requests to use modern authentication, which will stop these attacks from impacting your organization.

We are still working on some aspects of this feature, and we’ll highlight those for you here, but in response to the increase of attacks we are seeing, we want to make authentication policies available to you now, and are therefore rolling this out worldwide immediately.

There is already an excellent article describing how this feature works and we strongly suggest you read, understand and follow the article before enabling this feature.

There are three important caveats to this feature:

• There is a lack of telemetry for tenant admins allowing them to report on which users are using Basic Auth (and with which protocol) and once a block is enabled, whether such traffic was blocked. In other words, we can’t really tell you how well the block is working.
• A policy change can take up to 24 hours to take effect, unless the admin calls a cmdlet (such as Set-User) to ‘tickle’ each user. (Note that ‘tickling’ is a technical term, first used here). So the block might not kick in right away, and you might have to take some action if you want it to happen faster.
• If a user’s identity has not been replicated to Azure AD/Exchange Online, they will not be blocked and so any request received by Exchange Online will be routed to the authoritative Security Token Service (STS) where it is likely to fail. This same behavior also means that any authentication requests for unknown users in a tenant (such as might happen during a password spray attack) will also be forwarded to the authoritative STS for the domain.

We had been holding back on moving from private to public preview primarily due the first two of these - a tenant admin could misconfigure something and not realize until it’s too late due to the lack of reporting and the delayed effect of policy change.

However, given the increasing frequency of these types of attacks we would rather give you access to the capability, knowing you will all carefully read the documentation before configuring. We’ll continue to work on improving the feature set, but you don’t need to wait for us.

We acknowledge that for large customers, tickling every user using Exchange Online PowerShell (which can be unreliable for long running scripts) is challenging, but again we feel the benefit outweighs the negatives at this stage.

It’s in all our interests to prevent these types of attacks from compromising our data and users, and we hope you find these tools useful and helpful. Use them wisely!

The Exchange Team

Up to now, Administrators did not have control over which users would see public folders in their Outlook clients. If public folders were created within the organization or if an Exchange Online organization is configured to access on-premises public folders, all clients would make a connection to and show the “Public folders” object in Outlook. From there, one could control access to individual public folders (controlled through folder permissions). However, it was difficult to have only some of Outlook clients connect to public folders.

We are now introducing the ability to show the public folder object in Outlook to only a set of users who might need them. To get started, this will be available for Outlook for Windows users only.

To do this, administrators can use two parameters:

• PublicFolderClientAccess is an optional parameter on the user object. By default, its value is set to ‘false’. Setting this to ‘true’ on a specific user designates this user as one of users who will see public folders in Outlook.
• PublicFolderShowClientControl parameter on the organization config. By default, the value of this parameter is also ‘false’ and once it is set to ‘true’, the controlled access of public folders is enabled.

Here is an example of how to use these parameters; to enable access to only the user “Administrator” and turn the feature on for the organization:

Set-CASMailbox “Administrator" -PublicFolderClientAccess $true
Set-OrganizationConfig -PublicFolderShowClientControl $true

Important note: setting the organization parameter to true without setting user attributes to true first will make it so no users will see the public folder object in Outlook for Windows. In other words – if you want to implement this, we suggest that you plan ahead and populate user attributes first (PublicFolderClientAccess on users that need access set to true) and then set the organization level parameter (PublicFolderShowClientControl set to true). That way, users who need to have access will not lose access unexpectedly.

Why would you want to do this?

Tenant admins will now have more flexibility over which users connect to public folders in Outlook. This will benefit very large organizations who might have issues with connection limits to public folders and will reduce the load to that infrastructure.

This will also be helpful to organizations during mergers and acquisitions if moving to EXO. Imagine one organization having existing public folders, but after the companies merge – without this feature all of the users would unnecessarily connect to the public folder hierarchy.

Note: This feature is not intended to be replacement for public folder permissions, it is merely providing means to have more control over which clients connect to the public folder tree.

A few more questions answered that you might be interested in:

Will this work for only Outlook on Windows?

At this time, yes. We are working to bring this to additional clients (like Outlook for Mac or Outlook on the web) in the future and will talk about this later.

What about on-premises servers?

We are considering support for on-premises in a future CUs and we will provide details at the later time.

Is there a specific version of Outlook that I need to see changed behavior?

No. The feature works by removing the public folder information from the Autodiscover response to Outlook for Windows clients. Therefore, if the user is not enabled for public folder access they will simply not connect to the public folder tree no matter the version of Outlook for Windows they use.

In case of any questions, please do reach out to us via the comments section below. We are updating official documentation to add those parameters.

Public folder team

We’re pleased to announce the final build of Exchange Server 2019 is now available and can be downloaded from the Volume Licensing Service Center.

Exchange Server 2019 is designed to deliver security, performance and improved administration and management capabilities; attributes our largest on-premises customers expect from Exchange.

If you haven’t yet seen the session delivered at Microsoft Ignite 2018 we suggest you watch the video and download the slides here. During that session we talked for the first time about how the code paths between on-premises and online have separated, and the impact to on-premises customers – in short, less code churn and more stability.

Here is a selection of other key features in Exchange Server 2019:

Security: Exchange Server 2019 requires Windows Server 2019. In fact, we recommend installing Exchange Server 2019 onto Windows Server 2019 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 Exchange 2019 onto Windows Server 2019 with Desktop Experience, but we have worked hard to make sure running Exchange on Server Core is the best choice for our code.

We’re aware all media for Windows Server 2019 and Windows Server, version 1809 has been temporarily removed and Microsoft will provide an update when refreshed media is available. Exchange Server 2019 will be fully compatible with version 1809, and the refreshed version.

We also built Exchange Server 2019 to only use TLS 1.2 out of the box, and to remove legacy ciphers and hashing algorithms. To understand how this affects coexistence with earlier versions, please reference our previous series of posts on TLS.

Performance: We’ve done significant work to allow Exchange Server to take advantage of larger core and memory packed systems available in market today. With our improvements, Exchange Server can use 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.

We’re adding dual storage read/write capabilities to Exchange Server 2019 using Solid State Drive (SSD) technology to provide a super-fast cache of key data for improving end user experience. We also talked about this in our Email Search in a Flash! Accelerating Exchange 2019 with SSDs session at Ignite.

We also changed the way database caching works to allocate more memory to active database copies, again improving the end user experience. You can learn more about Dynamic Database Cache from Welcome to Exchange Server 2019! video and slides.

The improvements we have made to Exchange Server 2019 will enable you to scale to a larger number of users per server than ever before, use much larger disks, and see the latency of many client operations being cut in half.

End user experience: We all rely on Exchange for calendaring, and we know large enterprises are heavy calendar users. We are bringing a few key features such as restricting the forwarding of meeting requests and better control over OOF settings to Exchange Server 2019. Administrators get some new calendaring features too, as we’re adding the ability to manage events on user’s calendars and assign delegate permissions more easily.

We are also adding support for routing mail to and from EAI/IDN recipients and hope to add additional capabilities in this area in the future.

The session recording also goes into some of the other features we have plans for, so make sure you watch it to the very end.

As we mentioned in the Preview post in July, the 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.

Our official product documentation is now live, and we’ll be publishing the updated Preferred Architecture documentation soon.

We’re also pleased to also announce there are even more Office Server products releasing today! You can read more about those releases here.

We look forward to your feedback and thank you for your continued support and love of Exchange.

The Exchange Team

Microsoft Ignite 2018 ended a few weeks ago, and what a great event it was. It was great to see so many of our customers, partners and friends there – thank you for coming to our sessions, thank you for coming to the booth, thank you for hanging out with us whenever the opportunity arose and thank you for giving us great feedback on what we’re doing. We’re still recovering but we heard you and are focused on doing a better job because of it.

All of the sessions were recorded this year, and so here’s a handy reference to all the sessions in the Exchange and Outlook track, and some others we think you’ll find interesting, so you can refer back here whenever you want to find one.

You will need an account in Tech Community to access them, but that’s something you should have anyway.

So here’s a long list of sessions, in no particular order but grouped by technology as much as possible.

Exchange

• Welcome to Exchange 2019!
• Panel discussion: Microsoft Exchange/Calendar/OWA
• Hybrid Exchange – Making it easier and faster to move to the cloud
• Scott Schnoll's Exchange and Office 365 Tips & Tricks
• Securing Exchange Online from Modern Threats
• So long and thanks for all the (email) phish
• Email Search in a Flash! Accelerating Exchange 2019 with SSDs
• Turbo charge your Exchange on-premises and Hybrid environment – Notes from the field
• How to add MFA to your Exchange On-Prem/Online mailboxes in 20 minutes or less
• Preparing to Move (or remove) Those Public Folders to the Cloud
• Why do we need to keep an Exchange Server on-premises when we move to the cloud?
• Making the best of the cloud: How Exchange Online is different from Exchange on-premises
• Azure Information Protection and Exchange Online - better together
• Securing your Office 365 environment from advanced phishing campaigns with Office 365 Advanced Threat Protection

Outlook

• Deep dive into what’s new and coming soon to Outlook for Windows and Mac
• Outlook mobile in the Enterprise
• Deploying Outlook mobile securely in the enterprise
• What's Amazing and New in Calendaring in Outlook!
• Outlook on the web - What's new and why you should care!
• The Best (Outlook driven) Day of Your Life
• Success through people with LinkedIn and Microsoft 365
• What's New in groups in Outlook
• Panel discussion: Microsoft Outlook (Windows, Mac, and Mobile)
• Let the intelligence built into Outlook help you to make time for what really matters
• Simple room booking in Outlook using new built-in Intelligence
• The Power of People in Outlook
• Security made real with Outlook mobile in-app experiences
• Outlook on the web: Don’t block your users, restrict them with conditional access/limited access!
• Adaptive Cards in Teams, Windows, Outlook and your own applications
• Create engaging, powerful new business processes in Microsoft Outlook with Adaptive Cards

Office 365

• Notes from the field: how we moved a large global bank to Office 365
• Office 365 – Marriages, Divorces and Adoptions
• Getting stuff done: Solving Office 365 problems with PowerShell
• How to be an author and write about Office 365
• Real-world best practices for managing Office 365 groups
• Embrace Office 365 Groups: What's new and how to get started
• Office 365 Groups automation inside-out
• Delivering Office 365 as an evergreen service: What to do, and more importantly, what not to do
• Understanding how Microsoft Information Protection capabilities work together to protect sensitive information across devices, apps, and services
• Secure enterprise productivity with Office 365 threat protection services including EOP, ATP, and Threat Intelligence
• Strategies for building effective, optimal and future proof connectivity to Office 365 that will delight your users
• Implementing a modern network architecture to get the most out of Office 365
• Addressing global data residency needs with Multi-Geo in Office 365

Podcasts/Broadcasts

• Ross Smith IV & Greg Taylor on theCUBE
• Scott Schnoll & Jeff Mealiffe on theCUBE
• Ross Smith IV on Channel 9 talking about Outlook mobile
• Greg Taylor on Channel 9 talking about Exchange Server 2019
• Greg Taylor, Tony Redmond and Paul Robichaux – Office 365 Exposed talking about random stuff

It’s possible we missed a session you think we should have included (there were 750 or more after all), if so, add it to the comments section so people can find it. Thanks!

Happy watching!

And see you next year for more of the same. Microsoft Ignite 2019 here we come!

Greg Taylor
Director of Product Marketing
Exchange Server and Online

In an earlier post, we announced we were increasing the maximum number of public folders that could be migrated from Exchange Server 2010 to Exchange Online to 250K. We also highlighted in that post that the migration of public folders on Exchange Server 2013 and 2016 were limited to 100K.

We’ve been working hard to remove this limitation and we are very pleased to announce today that we now support migrating up to 250K public folders from Exchange On-Premises 2013/2016/2019 to Exchange Online.

What does all this mean to you?

• Any Exchange On-Premises customer running Exchange 2010/2013/2016/2019 with up to 250K public folders can now migrate them directly to Exchange Online.

Please do check this link for planning migration of public folders to Exchange Online. The current Exchange Online limits can be viewed here.

We’ve love to hear your feedback and please feel free to ask any questions via the comments section below.

Public folder team