Our September 2016 release blog included a statement that is causing some confusion with customers. The confusion relates to our support of Windows Server 2016 with Exchange Server 2016. The blog included a statement that read, “Domain Controllers running Windows Server 2016 are supported provided Forest Functional Level is Windows Server 2008R2 or Later.” We would like to provide additional clarity on what this statement means, and more importantly what it doesn’t.

Question #1: If I want to deploy Exchange Server 2016, must my Active Directory environment use Forest Functional Level 2008R2 or later?

Answer: No. Exchange Server 2016 is supported in environments configured to Forest Functional Level 2008 and later.

Question #2: If I want to install Exchange Server on a server running Windows Server 2016, does my Active Directory environment need to advance Forest Functional Level to 2008R2 or later?

Answer: No. Exchange Server 2016 installation on Windows Server 2016 is supported if Active Directory is configured to Forest Functional Level 2008 and later.

Question #3: What is the real requirement you are calling out here?

Answer: If you are running Exchange 2016 anywhere in your environment, and if any of the Domain Controllers used by Exchange are running Windows Server 2016, then the Forest Functional Level must be raised to 2008R2 or later.

In our experience, customers who keep their Domain Controllers deployed at the latest OS revision level, also employ the highest level of reliability, security and functionality and this requirement should not be a deployment blocker.

Question #4: Why is 2008R2 Forest Functional Level or later required?

Answer: Advancing the directory to a higher level of functionality requires DC’s on older operating systems to be retired. Our goal is to make certain that Exchange Server uses the highest level of security settings reasonably possible, including newer cryptographic standards. Windows Server 2008 no longer meets the minimum standard we are requiring and being requested by customers. Customers who are deploying the latest version of Exchange and Windows Server are often doing so to improve the security of their overall ecosystem. Our goal is to make certain that Exchange Server functions correctly under these assumptions and requirements. Limiting the use of old standards allows Exchange Server to meet the requirements of current security standards.

Question #5: Will Exchange Setup block installing Exchange Server 2016 if I am using Windows Server 2016 on a Domain Controller but have not raised the Forest Functional Level?

Answer: At this time, there is no Setup block. This pre-requisite is a soft requirement enforced by policy only. If a customer calls into support and is using Windows Server 2016 Domain Controllers with Exchange Server 2016 and they have not raised the Forest Functional Level to the minimum value, we may ask them to do so as part of root cause elimination.

Question #6: When will Exchange Setup force the use of 2008R2 Forest Functional Level for an Exchange Server installation?

Answer: The minimum supported Forest Functional Level will be raised to 2008R2 in Cumulative Update 7 for all Exchange Server 2016 deployments. We know that customers need time to plan and deploy the necessary migration/decommission of Active Directory Servers. 2008R2 Forest Functional Level will be a hard requirement in Cumulative Update 7, enforced by Exchange Setup. Cumulative Update 7 ships in the 3^rd quarter of 2017, one year after the first announcement.

For a complete list of Exchange requirements please see this TechNet article.

The Exchange Team

Several weeks ago, we enabled a new Office 365 feature to some tenants where the removal of the Exchange License didn’t immediately mail disable the user and disconnected the mailbox. The new behavior then required to manually (via RPS – remote PowerShell) go and run through EXO RPS the Disable-Mailbox -PermanentlyDelete cmdlet to achieve the same result we previously had – a permanent deletion of the disconnected mailbox.

Due to extensive feedback from customers we are rolling back this feature to the original behavior in order to improve the feature before we release it again in an easier format (and with better documentation).

As of today (10/31/2016) – going forward until feature is re-introduced in the future:

The removal of Exchange license from a user will trigger a mail disable operation in Exchange Online as it did before. The user’s mailbox will then be disconnected and will enter a tombstone state. This is not a soft deletion operation; if you want to preserve the mailbox for later recovery please use the Soft Deletion feature or Inactive mailboxes with in-place or litigation hold.

Adding the license back to this user within 30 days will result in a ‘best effort’ reconnect with the old content of the mailbox. This is the behavior we had before the change, we are just reverting to it.

Note: we have already started the rollback of this feature but it might take about 24 hours until all of our customers see changed behavior. To be safe, please assume that behavior has changed already starting right now.

What happens to the users whose license was removed within the time frame of the feature being enabled?

We are grand-fathering in these users. The mailbox and user will remain connected and mail enabled for an indefinite amount of time. You have some options for these users:

How to find them?

Users in this state can be found through EXO remote PowerShell using Get-Mailbox and looking for the SKUAssigned flag in EXO being set to “False”.

Sample user with removed license during feature being on:

What do I do with them?

You have 4 options (since a mailbox without a license has access blocked within 30 days of creation):

• Soft Deletion: Retention for a short period in case mailbox needs to be recovered. Mailboxes in this state are removed from Exchange after 30 days, at which time they can no longer be recovered. By default, a mailbox is soft-deleted if the user’s Office 365 account is removed.

The entire object (including the UPN and identity) are in a soft deletion state across the service. This allows for full data recovery and full re-use of any and all properties of the user in soft deletion state in a new user.

• Permanent removal (hard-deletion). In this case, the mailbox can no longer be recovered. You can permanently purge a mailbox from Exchange Online by running the Disable-Mailbox cmdlet (UI to come)
  • [PS] C:\> Disable-Mailbox -Identity <User> -PermanentlyDelete

The user object also loses Exchange properties in this case; that frees all email/proxy addresses and allows the object to be stamped with External Email address a new. The process requires for you to remove the license, then run the above command and then update the necessary attributes.

• Retained indefinitely (inactive mailbox). A mailbox becomes inactive if it is under a litigation or in-place hold for compliance or regulatory purposes and is then deleted. Exchange recognizes that the hold exists and retains the mailbox for as long as the hold applies. During this time, the mailbox can be recovered or restored. When the hold is removed, the mailbox is permanently deleted.

• Add a license back to the user – this will restore access and the mailbox will become fully active.

We apologize for the back and forth on this, and realize that we have to do better when releasing features to the service, which the team is committed to doing when we release this feature again.

Mario Trigueros Solorio

This document explains the configuration steps needed to get rich document collaboration working between Exchange Server 2016, SharePoint Server 2016, and Office Online Server, in your On-Premises environment.

Please use this link if you’re looking for configuration steps for Exchange Server 2016 On-Premises and SharePoint Online

Introduction

When used together, Exchange Server 2016, SharePoint Server 2016, and Office Online Server provide a rich set of document collaboration features.

For example, rather than directly attaching a document to an e-mail message you may now send a link to the document stored in OneDrive for Business (ODB). Outlook and Outlook on the Web (new name for OWA) will still display the file as if it was directly attached to the message like a classic attachment would be, as well as allow people to work with the file like they would with a classic attachment. Additionally, many people will be able to read and edit the same file at the same time while it is stored in OneDrive for Business (ODB).

You can see a short demo of how this collaboration can look like right here.

Pre-requisites

The solution requires you have the following set up On-Premises:

• Exchange Server 2016 CU2 (or higher)
• OneDrive for Business (ODB) configured on SharePoint Server 2016
• Office Online Server (OOS)
• Make sure the certificate used for ODB, OOS and Outlook on the Web supports the appropriate name space. Also, ensure the certificate used by each service is either issued by same authority or the issuing authority is trusted on each server.

Configuration

The basic setup for these rich document collaboration features involves configuring OneDrive for Business (ODB) in the SharePoint 2016 farm, establishing a server-to-server trust (also referred to as S2S or OAuth) between SharePoint Server 2016 and Exchange Server 2016. Once completed, users will have the ability to attach ODB-based documents to email messages. Installing and configuring Office Online Server will introduce the additional capability of device-independent side-by-side viewing as well as edit & reply functionality in Outlook on the Web.

Note that editing documents is a premium feature of OOS and requires appropriate licenses!

Office Online Server

Install OOS and create a new OOS farm. Make sure the farm URL is accessible from Internet if you want users to be able to view and possibly edit documents via Outlook on the Web from outside of the corporate network:

Example:

For an OOS farm that is going to use same internal and external FQDN, with editing enabled:

New-OfficeWebAppsFarm -InternalURL “https://oos.contoso.com” -ExternalURL “https://oos.contoso.com” -CertificateName “Unified Certificate” -EditingEnabled

For an OOS farm that is going to use different internal and external FQDNs, with editing enabled:

New-OfficeWebAppsFarm -InternalURL “https://internaloos.contoso.com” -ExternalURL “https://externaloos.contoso.com” -CertificateName “Unified Certificate” -EditingEnabled

SharePoint Server 2016

In order to leverage the OneDrive for Business-based attachments on-premises, users must have a OneDrive for Business site hosted by SharePoint Server 2016 on-premises.

Follow steps from here, if the MySite Host (which gives you OneDrive for Business) is not already configured.

Additionally, to enable integration of Office Online Server for document previewing and online editing, WOPI bindings must be created in the SharePoint farm.

• WOPI Bindings – WOPI bindings (or Web Application Open Platform Interface bindings) define related applications and available actions for a file extension. The New-SPWOPIBinding cmdlet is used to create these bindings between OOS and SharePoint. As with the other configurations, HTTPS is encouraged for production use, but non-production environments can be configured to communicate without SSL/TLS security by including the -AllowHTTP switch on the cmdlet: New-SPWOPIBinding -ServerName oos.contoso.com
• S2S/OAuth Trust and Service Permissions – The SharePoint Server provides set of commands to configure Server to Server authentication, create App Principals and configure correct permissions that are needed to make this level of collaboration real.

The commands can be put together in a script to make life easy. A sample script for performing this configuration is provided here

Usage:

• Download the script
• Save this script as a .ps1 file on your SharePoint Server 2016, for example ‘Config-SPSOAuth.ps1’.
• Open the SharePoint Management Shell and execute the script.
• Script will prompt for:
  • An ExchangeServer URL – the hostname provided to access Exchange Server 2016.
  • A SharePoint MySite Host – URL of the SharePoint website hosting the MySite collection.

Example:

.\Config-SPSOAuth.ps1 -ExchangeServer mail.contoso.com -MySiteHostUrl https://sp01.contoso.com/

Exchange Server 2016

The user’s mailbox must be hosted on an Exchange Server 2016 server on-premises to enable the document collaboration functionality. There are a few settings to configure on Exchange Server to enable the full experience.

• OOS Endpoint – Configuring the OOS Endpoint in Exchange enables preview options for file attachments, as well as the edit and reply functionality. The OOS endpoint can be set in two locations – the Organization level, and at the Mailbox Server level. The Organization level is used to enable a global configuration for all servers with a single setting. This is useful for a single server, or single location deployment. It also serves as a fallback/failsafe when the endpoint configured at the mailbox server level is unavailable. The Mailbox Server level allows administrators to distribute client requests to multiple OOS servers. This can be done to balance load, or when building geographically dispersed deployments.

Set-OrganizationConfig -WacDiscoveryEndpoint https://oos.contoso.com/hosting/discovery
Set-MailboxServer exch.contoso.com -WacDiscoveryEndpoint https://oos.contoso.com/hosting/discovery

If you have Exchange 2013 servers in your organization, do not configure an OOS endpoint at the organization level. Doing so will direct Exchange 2013 servers to use OOS, which is not supported.

• My Site Host URL – Exchange must know the My Site Host URL to enable ODB-based attachments. This can be set in two locations, the OWA Virtual Directory, and through an OWA Mailbox Policy. The preferred approach setting the My Site Host URL is through an OWA Mailbox Policy. It is recommended for all environment configurations, but it is a requirement when running an Exchange environment with a mixture of Exchange 2016 and Exchange 2013 servers. Mailbox policies allow features to be enabled selectively for users or groups. Each organization will have at least a Default policy which can be assigned to all users. Additional policies can be created using the New-OWAMailboxPolicy cmdlet. The OWA Virtual Directory can only be used to set the My Site Host URL when Exchange 2016 is the only version of Exchange that frontends client access traffic.

Example 1:

Creating new policy for My Site host access:

New-OwaMailboxPolicy -Name ODBPolicy
Set-OwaMailboxPolicy -Name ODBPolicy -InternalSPMySiteHostURL https://sp01.contoso.com -ExternalSPMySiteHostURL https://sp01.contoso.com

Finally, assign the policy to mailboxes:

Set-CASMailboxPolicy JohnR@contoso.com -OWAMailboxPolicy ODBPolicy

Example 2:

In this example, only users connecting to the server ‘Exch’ need to be enabled for document collaboration:

Get-OwaVirtualDirectory -Server exch.contoso.com -ADPropertiesOnly | Set-OwaVirtualDirectory -InternalSPMySiteHostURL https://my.contoso.com -ExternalSPMySiteHostURL https://my.contoso.com

This configuration is useful in scenarios where only specific servers are going to frontend the Outlook on the Web traffic

• S2S/OAuth Trust and Service Permissions – Enable secure communication between the SharePoint 2016 and Exchange 2016 servers. Production environments should have traffic to both Exchange and SharePoint encrypted by HTTPS. Additionally, neither server should receive a certificate error when communicating with the other or else the integration will fail. The half of the trust configured on Exchange is configured via a script included with the Exchange 2016 installation binaries. The script can be found in the scripts directory, which is by default found at “C:\Program Files\Microsoft\Exchange Server\V15\scripts” (your installation path may vary based on your installation choices). This location is referenced by the $ExScripts variable within the Exchange Management Console.

& $ExScripts\Configure-EnterprisePartnerApplication.ps1 -ApplicationType Sharepoint -AuthMetadataUrl https://sp01.contoso.com/_layouts/15/metadata/json/1

Limitations

These are currently some limitations we hope to address in the future. Please be aware of what they are for the time being:

• The Outlook 2016 client can only interact with OneDrive for Business attachments in Office 365, it cannot connect to on-premises OneDrive for Business attachments. This limitation does not apply to Outlook on the Web 2016
• For On-Premises deployments, only internal recipients (mailboxes) that are present in same organization as that of sender can be granted permissions on the OneDrive for Business document. The sender is informed via separate email if the automatic permission process fails. This means you cannot send ODB attachments to users outside of your on-premises organization.
• OneDrive for Business must be provisioned and initialized (the user has logged in at least once) for both the sender and the recipient. Without both the sender and recipient being provisioned and initialized the side-by-side documents preview will not work for the recipient.

I wanted to thank Neil Hodgkinson, Jon Frick, Brian Day and Jason Haak for their help in putting this together!

Bhalchandra Atre

We wanted to raise your attention to an issue that some customers have reported running Exchange Server 2016 on Windows Server 2016. Crashes of the IIS (W3WP.exe) process have been reported causing instability of Exchange Server on Windows Server 2016. The Exchange team has worked with the Windows team to isolate the source of the problem. An update for Windows Server 2016 will be made available to resolve this issue. Microsoft recommends that customers delay deploying Exchange Server on Windows Server 2016 until this update is made available. For the latest guidance on known issues, please consult the Windows Server release notes on TechNet.

When there are updates on this, we will update this blog post.

The Exchange Team

Multi-Factor Authentication (MFA), which includes Two-factor authentication (2FA), in Exchange Server and Office 365, is designed to protect against account and email compromise.

Microsoft has evaluated recent reports of a potential bypass of 2FA. We have determined that the technique described is not a vulnerability and the potential bypass does not exist on properly configured systems.

The reported technique does not pose a risk to Exchange Server or Office 365:

• In Exchange Server, authentication configuration settings for client endpoints are not shared across protocols.  Supported authentication mechanisms are configured independently on a per protocol endpoint basis.  Multi-Factor Authentication in Exchange Server can be enabled in multiple ways, including OAuth.  Before implementing MFA with Exchange Server it is important that all client protocol touchpoints are identified and configured correctly.
• In Office 365, when Azure MFA is enabled within a tenant, it is applied to all supported client protocol endpoints. Exchange Web Services (EWS) is an Office 365 client endpoint which is enabled. Outlook on the Web (OWA) and Outlook client access are also enabled in Office 365. Office 365 users may experience a small delay in activation of MFA on all protocols due to propagation of configuration settings and credential cache expiration.

Additional information on enabling OAuth in Office 365 and Exchange Server can be found on Office.com and MSDN.

The Exchange Team

If you are using Public Folders (legacy or Modern) and would like to migrate some of them to Office 365 Groups, we are working on a solution for that. We are starting with the migration of Calendar folders and will move on to other types as we complete work on calendars. We would like to have customers who would like to try this migration to provide feedback. Please email us with below information if interested. You can also send us your information if you would like to try migrating other types of public folders (other than Calendar) as we extend the support to those folder types.

Drop us an email at: pftogroupmigration@service.microsoft.com

• Customer name:
• Tenant domain name in Exchange Online:
• Location of public folders; on-premises or Exchange Online:
• If on-premises, Exchange version of public folder servers:
• Public folder types to migrate (Mail, Calendar, Task, Contact):
• Expected month/year of migration:

Your organization might need to join our TAP program (depending on public folder location) – and if so, we will share those details with you after reviewing the above.

Public Folder Migration team

We are in the process of rolling out a new migration experience that will greatly simplify your journey to Office 365 and Exchange Online.

This new experience will help any customer running at least one Exchange 2010, 2013 and/or 2016 server on-premises to migrate to the cloud seamlessly. When you initiate the migration, we evaluate what you have configured already in Exchange Online and we walk you through the Hybrid Configuration Wizard to evaluate the on-premises environment. Once all the information on your current state is collected, we ask a couple of questions about your desired state (things like how fast you want to move to Exchange Online and whether you require advanced features). The hybrid wizard then walks you through the configuration needed to migrate your users to Exchange Online.

Based on your current configuration and the options selected while running the hybrid wizard, you will be taken down one of the following paths.

• Full Hybrid: This is a common configuration for customers that are larger in size and will take some time to migrate or customers that will not be able to move all their mailboxes to Exchange Online in the short to medium term. This is the most complex option to configure, but will give you enhanced features like cross-premises free/busy and enhanced mail flow options. For more on Full Hybrid you can go here.
• Minimal Hybrid: This is a recently introduced option that was added to the Hybrid Configuration Wizard in June. It allows you to configure your environment to support hybrid migrations and recipient administration without the need for the additional overhead of configuring free/busy and other enhanced features of full hybrid. Often this is used for customers that want to move all their mailboxes to Exchange Online over the course of a couple of months or less, but want to keep directory synchronization in place. For more information on Minimal Hybrid please go here.
• Express Migration: The newest option we have added is the Express Migration. This is the path in the Hybrid Configuration Wizard that will benefit smaller customers or a customer that truly wants to move to Exchange Online over the course of a couple of weeks or less. If you have a need to keep directory synchronization in place, then this is not the option for you. This option will configure your users and walk you through the new migration experience to get the mailboxes to Exchange Online with minimal disruption for your users.

More About Express Migration

In the past, an administrator of the small to medium business had to choose to either take the complex configuration route of hybrid or the complex user experience of a cutover or staged migration. Now you can get a greatly simplified Express Migration experience.

With the Express Migration option, you will get a onetime directory synchronization of your users along with the Minimal Hybrid configuration to allow you to perform the migrations. After that initial synchronization of user accounts, directory synchronization will be automatically disabled in both Office 365 and on-premises. This will give small and medium customers that would have previously perform a cutover migration the ability to get the benefits of the hybrid migration without the overhead.

The following are the benefits of performing an Express Migration over a more traditional cutover migration:

• Usernames and passwords will sync from on-premises
• Users will not have to recreate Outlook profiles
• Mail flow will continue to work between users before, during, and after the migration
• There is essentially no down time for users during the migration

How to initiate the migration

All the migration approaches discussed in this article (Full, Minimal, and Express) can be initiated from one interface now. We will guide you to the proper option as we go.

One of key components in this new experience is the migration pane. This is a new pane we have created in the Office 365 Admin Portal that will match the modern look and feel of the rest of the portal. However, it is not just the look and feel that is revamped, we also have a lot of intelligence built in. For instance, when you enter the migration pane we will detect if you have executed the Hybrid Configuration Wizard, already synchronized your users, and whether there is a migration endpoint already created. Depending on what is already in place we can take you toward the proper migration approach.

To get to the new migration experience you will have to expand the “Users” section in the portal (Http://portal.office.com) and then select the “Data Migration” option. Once there, select the Exchange email source to initiate the experience. This is a page where we list various sources from where you can migrate. In this case, you would select the Exchange option.

Once the source is selected we perform a quick check of the tenant to see if you have executed the Hybrid Configuration Wizard. If you have not yet executed it, that means we know you have not prepared your on-premises environment for migration. Therefore, we will take you through downloading and running the hybrid wizard.

When in the hybrid wizard you will see a welcome screen, just select next on that:

You will then see the Server detection screen, again just select next since the correct server should be detected. By default, we will try to connect to the Exchange server running the latest version.

Provide your credentials for both Exchange on-premises and Exchange Online.

Select the appropriate migration option. For this example, we are demonstrating Express Migration so we will select the Minimal Hybrid option.

Select update, which will perform all the configurations needed to allow you to start moving mailboxes at a later step.

Next up: Provisioning users

If you have not synchronized your users already at this point you will see an option to perform a onetime sync of your users or to install AAD Connect separately. As mentioned, if you plan on moving all of your mailboxes to Exchange Online and do not have the need to keep directory synchronization around, then select the one-time sync option. Selecting this option is what we consider an “Express Migration”. If you need directory synchronization for any reason, then you need to install and setup AAD Connect separately.

Note: if you did select the one-time sync and later decided that you do need to have directory synchronization, you can setup AAD Connect to perform directory synchronization.

If you did not select Minimal Hybrid as an option in the wizard, then you will not be given the one-time directory synchronization option. The reason you would not get it if you opted for Full Hybrid is because that deployment scenario requires the advanced coexistence features and directory synchronization.

Once the option for “Synchronize my users and passwords one time” is selected, the hybrid wizard displays a progress bar. The wizard is waiting for the AAD Connect to be configured and for the initial set of users to synchronize.

To complete the hybrid configuration setup, you will need to configure AAD Connect. In almost all cases the default options in AAD Connect are the best options.

Once completed you will see the ending page for the hybrid application that will allow you to give feedback. Once closed you will be taken to the user list page to start moving mailboxes.

On the user list page you will have the option to select the users you want to migrate. Under the hood this is using MRS to migrate the users just like a hybrid migration. You can use this new pane to migrate mailboxes, regardless of the hybrid deployment option chosen. The experience is as simple as selecting the users and clicking start migration. At that time, we will perform a lookup to see if the prerequisites are in place. If anything is missing, we will walk you through taking care of the missing prerequisite.

Limitations

There are some limitations with the new Migration pane that need to be called out. We are working to overcome these limitations in the future:

• Only one migration endpoint is supported: If there is more than one endpoint we will choose the one created by the Hybrid wizard or by the new Migration experience.
• Only one batch can be started at a time: we do not yet support multiple batches with this migration pane. This means that you need to wait for the previous migration to finish before you can start another migration. We know multiple batch support is important for medium and larger customers, we have this as a top priority.
• We do require you license users separately: we require that all users being migrated through this experience be licensed before the migration begins (except for shared mailbox object type), this is not an automatic process so you need to license users before migrating.

Conclusion

These updates will make the Exchange Online onboarding experience more seamless for many Exchange customers. We have created and are continuing to improve the Migration pane to meet the needs of our customers. While running through the experience if you have any feedback please use the provided feedback button that are available throughout the experience.

Office 365 On-boarding Team

Introduction

Since the release of Microsoft Exchange Server 2013, we have heard questions regarding the sizing and deployment of modern public folders. It is important to plan migrations for public folders so the client experience with their use is good. In this blog post, we will discuss some of best practices and recommendations regarding modern public folder deployment as well as discuss various related concepts. We will assume that you are already familiar with basic modern public folders concepts so we will not go there (but might link to relevant articles).

There is a lot here as we are going through several examples. Use it as a reference!

How clients connect to the public folder hierarchy mailbox

When the user launches the Outlook desktop client on Windows or Mac, client contacts the Autodiscover service to determine connection settings for the user’s primary mailbox and their archive mailbox if they have one. During the initial response, the Autodiscover service may indicate there are public folders available in the environment by including an XML element named <PublicFolderInformation>. This element will contain the SMTP address of a public folder mailbox within the environment. An additional Autodiscover request will be made to request connection settings for the SMTP address of the public folder mailbox.

To provide a value for this element during the initial request/response interaction, the Autodiscover service calls a function named GetPublicFolderRecipient. This function gathers information for the available public folder mailboxes in the environment available for serving hierarchy connections.

In most cases the GetPublicFolderRecipient function will (randomly) pick a public folder mailbox from the available list to be handed over to the Autodiscover Service, which in turn gets returned to the client.

Another possibility is that the user’s mailbox has a static DefaultPublicFolderMailbox assigned. When a mailbox has a default public folder mailbox assigned, the client will always attempt to connect to this public folder mailbox for hierarchy connections. If that public folder mailbox is not available for some reason, the client will fail to reach the public folder infrastructure and will not fall back to a random public folder mailbox. Something to keep in mind!

Note: In the case of Outlook on the web (we’ll call it OWA for short) clients accessing public folders, public folder mailbox access does not rely on the Autodiscover service even though the same selection process logic is used. In other words, OWA uses similar functionality that the Get-Mailbox cmdlet uses to get list of available public folder mailboxes the user can utilize. Even if Autodiscover is offline for some reason in the environment, you may see users successfully accessing public folders via OWA, but not Outlook clients.

When are new mailboxes eligible for this process?

By default, all public folder mailboxes deployed in the environment can serve hierarchy connections to the clients. However, immediately after creation a new public folder mailbox will not be used by Autodiscover. This is due to the newly created public folder mailbox has not yet completed an initial full hierarchy sync from the primary hierarchy public folder mailbox. This logic is automatically calculated and is reflected in the parameter IsHierarchyReady. By default, the value will be set to $False. If this value remains $False, the GetPublicFolderRecipient function will not return that public folder mailbox to the Autodiscover Service as it is assumed to contain an incomplete copy of the hierarchy (a user connecting to it would not have a complete view of the public folder infrastructure). Once the value of the newly created public folder mailbox’s IsHierarchyReady has changed to $True, the Autodiscover service will be able to hand it out to clients.

Under normal conditions this initial full hierarchy sync should start automatically within 24 hours of the public folder mailbox being created. You may also invoke the hierarchy sync manually if you so choose by using the below command:

Update-PublicFolderMailbox -Identity “Public folder mailbox name” -SuppressStatus -Fullsync -InvokeSynchronizer

The time it takes for the fully hierarchy replication to complete depends on several factors such as (but not limited to) network speed, number of public folders, geographical location of PF mailboxes, and connection load on the primary hierarchy mailbox.

The initial hierarchy sync happens using a pull operation model. The secondary public folder mailboxes will poll the primary hierarchy public folder mailbox to fetch the hierarchy information. Once the initial FullSync is complete, the value of IsHierarchyReady will change to True automatically and the public folder mailbox will be available to serve the hierarchy information to requesting clients.

To confirm, the following command can be run:

Get-Mailbox -PublicFolder | fl name,ishierarchyready

Note: While IsHierarchyReady value can be manually forced to True using PowerShell, this is not supported. Doing this can cause the public folder mailboxes to serve incomplete hierarchy to clients. The recommendation is wait for the initial sync to complete or manually invoke the hierarchy sync to get the hierarchy replicated to the new public folder mailboxes.

Once the initial hierarchy sync is complete for the public folder mailbox, the next hierarchy sync hereon will happen using the push model, where the primary hierarchy mailbox will push the changes to the secondary hierarchy public folder mailbox every 10 minutes.

Another setting an administrator has at their disposal is the attribute IsExcludedFromServingHierarchy. This attribute can be set to $False (default) or $True using the Set-Mailbox cmdlet and will prevent this mailbox from being used by Autodiscover or OWA to serve hierarchy connections to clients. Even after IsHierarchyReady becomes automatically set to $True the public folder mailbox will be excluded from Autodiscover and OWA hierarchy usage if IsExcludedFromServingHierarchy is set to $True. This option is useful when you want a public folder mailbox utilized only for content of public folders and can be set immediately after the public folder mailbox is created.

Note: If DefaultPublicFolderMailbox is populated on a user mailbox it will override the $True value of IsExcludedFromServingHierarchy (on the mailbox they are connecting) and will allow that user to connect to the public folder mailbox specified in DefaultPublicFolderMailbox for hierarchy. We will discuss this later in the post.

Scenario 1: What happens when default public folder mailbox value has not been set on the user mailbox?

Let’s say we have 50 public folder mailboxes in their default state, all of which have sync’d hierarchy, and there are 20,000 users who try to access public folders. The Autodiscover service will provide a random public folder mailbox to each user to service hierarchy requests.

The specific public folder mailbox being returned to the client can change randomly, or if Outlook is closed and reopened, based on what GetPublicFolderRecipient function returns to Autodiscover which in turn returns the data to the client.

On the client side, public folder mailboxes being accessed will appear under the connection status in Outlook, as shown below:

The first public folder GUID value in here is a random primary public folder hierarchy mailbox. The remaining public folders GUIDs are populated and returned when user tries to access individual public folders which reside within those public folder mailboxes.

Scenario 2: Restricting clients to contact a specific public folder mailbox for hierarchy.

It is possible to override the behavior of random selection of default public folder hierarchy mailbox.

First, you need to confirm that the public folder mailbox has IsHierarchyReady populated with value of $True which confirms that it has completed its initial full hierarchy sync with the primary public folder mailbox.

Run the command:

Get-Mailbox -PublicFolder “Public Folder mailbox name” | FL Name,ExchangeGuid,*Hierarchy*

Once the above is confirmed, the next step is to assign the desired public folder mailbox as the DefaultPublicFolderMailbox on the user mailbox. In our example this would be accomplished by running the below command:

Set-Mailbox “user mailbox identiy” -DefaultPublicFolderMailbox “PF-MBX-002” -Verbose

Now, when the client opens Outlook, Autodiscover provides the DefaultPublicFolderMailbox’s SMTP address in the <PublicFolderInformation> XML element and the client then performs a second Autodiscover request to learn how to connect to this public folder mailbox.

When we check the Outlook connection status, it will list the assigned public folder mailbox.

Scenario 3: Setting the default public folder mailboxes close to the user’s location for better client experience

Our customers deal with communication links that may be highly latent and expectedly inoperable for periods of time. For demonstration purposes let’s consider our favorite company called Contoso which has the following configuration:

Three company sites are listed below:

• Hyderabad: India with 23,000 mailboxes. Local servers have 10Gbps LAN connectivity and there are three public folder mailboxes in this site.
• Adelaide: Australia with 5,000 mailboxes. Local servers have 10Gbps LAN connectivity and there is one public folder mailbox in this site.
• A cruise ship with 500 mailboxes for employees on-board. Local server has 1Gbps LAN connectivity and there is one public folder mailbox per ship.

To maintain communications with their ships at sea, Contoso has established a 384Kbps satellite link to each ship and has also installed a dish at their Hyderabad site. All network routes to/from ships are routed via Hyderabad’s own satellite link.

Contoso has also purchased 1Gbps of bandwidth on a submarine cable link to Australia. All WAN routes to/from Australia site traverse this link.

Challenges with the above deployment

If we were to simply deploy modern public folders with all the default values, we could see some interesting things happen. For example, all users could be offered any of the five public folder mailboxes for hierarchy regardless of their location.

The worst-case scenario here would be a ship based user trying to access PFMBX-AUS-001 for hierarchy information or an Adelaide based user trying to access PFMBX-SHIP-001 for hierarchy information. In either of those scenarios we see client traffic traversing round-trip not only along the longest network path, but also the one with the least bandwidth and most latency. In this extreme example, you would more than likely have clients calling the help desk reporting the Outlook RPC popup after they attempted to expand the public folder tree.

Considering the above problems, we recommend administrators with similar decentralized and complex network topologies consider configuring user mailboxes to access public folder mailboxes located within local or geographically closer sites as their default public folder mailbox.

What would work better?

In an environment like the one in the example, it may make sense to set IsExcludedFromServingHierarchy to $True for the public folder mailboxes on all cruise ships and Australia. This will remove them from being returned as valid public folder hierarchy endpoints for Autodiscover and OWA, leaving only the three well-connected Hyderabad based public folder mailboxes setup for automatic discovery.

Additionally, the DefaultPublicFolderMailbox attribute at the mailbox level should be utilized for employees based on the cruise ship or the Australia continent to ensure they always attempt to connect to a public folder mailbox that makes sense based on their geolocation. One caveat here is if a user from the Australia office were to visit the cruise ship (for work purposes sadly and not fun in the sun!), their client would continue to connect back to Australia for their PF hierarchy connection. In addition, the Hyderabad office with 23,000 mailboxes would need to monitor user concurrency to determine if they need additional public folder mailboxes or not over time to stay within supported user concurrency limits.

Things to remember and plan during the deployment:

1. Understand the company topology completely before making any decision to deploy public folders for offices located in different geographical locations. Correct deployment of public folders using the recommended approach will make life easier for administrators and end users.
2. Make use of the attribute IsExcludedFromServinginHierarchy by setting it to $True when it makes sense to exclude public folder mailboxes from being discovered by Autodiscover for providing hierarchy information to clients and avoid any unwanted connections.
3. The DefaultPublicFolderMailbox attribute at the mailbox level should be considered when you need to ensure the users in less-connected sites must connect to public folder mailboxes close to their geographical location for hierarchy information. Misconfiguration can lead to serious issues such as latency in accessing public folder information and poor end user experience.
4. No more than 2000 active connections being made to the same public folder mailbox at any point of time are currently supported. This will require advanced planning, to ensure that the public folders being heavily used by the clients are being distributed across the public folder mailboxes, which are in turn close to the user’s geographical site for better access and experience if necessary.
5. You can add one or more additional Hierarchy Only Secondary Public Folder Mailboxes (HOSPFM) and Content Only Secondary Public Folder Mailboxes (COSPFM) depending upon the geographical location and identification of commonly used public folder mailboxes by the end users for better end user experience. Yeah, we like our acronyms. Yup, we just made that up.

What are those (HOSPFM) and (COSPFM), and why do we require them?

• Hierarchy Only Secondary Public Folder Mailbox (HOSPFM): does not contain public folder content and only serves hierarchy. IsExcludedFromServingHierarchy is set to False
• Content Only Secondary Public Folder Mailbox (COSPFM): has public folder content in it but is excluded from serving hierarchy. IsExcludedFromServingHierarchy is set to True

There are 2 type of connections being made to the public folder mailbox, when it is accessed.

1. Hierarchy connection
2. Content connection

Public folder mailbox connections (both hierarchy and content) should not exceed 2000 to remain within the support boundaries. Given this requirement, you should plan to have enough public folder mailboxes serve hierarchy and/or content so that you maintain a level of less than 2000 active and simultaneous client connections per secondary public folder mailbox.

The primary public folder mailbox must be excluded from providing hierarchy to clients (IsExcludedFromServingHierarchy parameter set to True). This allows the primary public folder mailbox to spend its time maintaining the hierarchy and dealing with hierarchy replication tasks. Overloading this public folder mailbox with client connections can in turn lead to performance and reliability issues with your PF hierarchy.

How to move the public folder data close to the user’s geographical location

Consider another company also called Contoso, which has many offices around the world and modern public folders have been deployed in the environment. Sarah is a user whose mailbox is in a datacenter which is in India and she frequently works with public folders. There is another large group of users who also frequently work with the same set of public folders, but they are in a different geographical location, in Australia.

The public folders being accessed are in the India site, close to Sara’s geographical location, so she has a better experience when accessing public folders.

In contrast, when Australia users try to connect to public folder mailboxes, the local hierarchy public folder mailbox in their datacenter will provide the content location for required public folders. Users will initiate a connection to the actual public folder located in India holding the content for the public folder. Since the actual folder content is in different geographical location, the connection request may be not as performant for the Australian group of users, resulting in user frustration.

This deployment is not recommended. The focus should be on identifying the most frequently used public folders by a common set of users, and moving the public folders with that content closer to users’ location. In this scenario, the content should be moved closer to the larger group of users in Australia.

Note: Moving public folders only moves the physical contents of the public folder; it doesn’t change the logical hierarchy, or layout of folders in the folder tree.

To move the public folder content, run the command:

New-PublicFolderMoveRequest -Folders “\path of the public folder to be moved” -TargetMailbox “target public folder mailbox name”

Note: To verify that the PublicFolderMoveRequest is complete, the command Get-PublicFolderMoveRequest can be run.

Like mailbox move requests, completed public folder move request must be removed before any other public folder can be moved to another public folder mailbox. To do this, run the command Remove-PublicFolderMoveRequest. If any other public folder move request is initiated without removing the old request, it will error out like this:

To remove the existing PublicFolderMoveRequest, run the command:

Get-PublicFolderMoveRequest | Remove-PublicFolderMoveRequest

Note: If a parent public folder and its subfolders need to be moved to another public folder mailbox, this can be done using Move-PublicFolderBranch.ps1 script, located in \scripts folder.

For more details, see: Move a public folder to a different public folder mailbox

Once the public folder content has been moved to a different public folder mailbox, users in Australia site accessing the public folder will be updated by the local public folder mailbox hierarchy connection to the folder’s new content location and connect to the local public folder mailbox. To continue with our example, Sarah will continue to connect to local public folder mailbox for hierarchy (which has been set by the administrator), but will then get her content from the Australia datacenter. Even though the experience may not be as great for that one user, Sarah can add frequently used public folders to Favorites using Outlook client or OWA to help with latency issues.

Looking at the above example, it becomes very important to determine network latency and bandwidth before you start deployment of public folder mailboxes in geographically dispersed environment to avoid any latency issues when accessed by end users. In such situations, the recommendation will be to use tools like Netmon which can help in determining the connections happening to public folder mailboxes. There is a great tool written by Mark Russinovich called Psping, which can be helpful in determining the round-trip latency. Based on the results customers can decide whether the current network is suitable for their environment or if there are any changes that needs to be done.

Summary: deployment considerations

Considerations when deploying public folder mailboxes in the organization, to ensure they are protected and readily available to the clients:

• Public folder mailboxes, both hierarchy and content, should be protected by placing them in databases protected by multiple copies in a Database Availability Group. By doing this, mailboxes will remain protected in case of any outage and be available to end users.
• There should be no public folders hosted within the primary public folder mailbox. This way we dedicate the primary public folder mailbox to specifically focus on its job of replicating hierarchy changes to other public folder mailboxes.
• You should exclude the primary public folder mailbox from serving hierarchy to clients. This is done by setting the IsExcludedFromServingHierachy to $True.
• The recommendation is to activate database copies hosting public folder mailboxes on mailbox servers which are geographically located close to the client location.
• The general recommendation is having one public folder hierarchy mailbox for every 2000 users accessing public folders. Additional hierarchy only public folder mailboxes can always be created to divide the connection load among users to ensure that the 2000 connection limit is not reached.
• Plan and create more secondary hierarchy public folder mailboxes and content mailboxes to ensure there are fewer than 2000 active and concurrent connections to public folders and that they are close to the users geographical location to ensure there are no latency issues and users have good experience.
• Since Exchange Server 2016 CU3 has released, you can make use of up to 1,000 public folder mailboxes. Of the 1,000 public folder mailboxes, 100 of them can be used for hierarchy (or 99 once you exclude the primary PF) and the remaining 900 can be used for content storage.

Post summary

In the above post, we have provided information on how public folder mailboxes are accessed, and the importance of correctly deploying them in a geographically dispersed environment. In upcoming posts, we will discuss topics related to public folder logging analysis, management and quota related information

We would like to say thanks to Public Folders Feature Crew team for their valuable inputs while this blog post was being written.

Special Thanks to Ross Smith IV, Nasir Ali, Scott Oseychik for reviewing this content and validating the guidance mentioned in the blog post and Charlotte Raymundo, Nino Bilic for helping us to get this blog post ready!

Siddhesh Dalvi and Brian Day

Today we are announcing the latest set of Cumulative Updates for Exchange Server 2016 and Exchange Server 2013. These releases include fixes to customer reported issues and updated functionality. Exchange Server 2016 Cumulative Update 4 and Exchange Server 2013 Cumulative Update 15 are available on the Microsoft Download Center. Update Rollup 22 for Exchange Server 2007 Service Pack 3 and Update Rollup 16 for Exchange Server 2010 Service Pack 3 are also available.

A new Outlook on the web compose experience

Exchange Server 2016 Cumulative Update 4 includes a refresh to the compose experience. The body of the message is now “framed” and formatting controls have been moved to the bottom of the view. This mirrors the current experience in Office 365.

Support for .Net 4.6.2

Exchange Server 2013 and Exchange Server 2016 now fully support .Net 4.6.2 on all supported operating systems. Customers who have already updated their Exchange servers to .Net 4.6.1 can proceed with the upgrade to 4.6.2 before or after installing the cumulative updates released today. Customers who are still running .Net 4.5.2 are advised to deploy Cumulative Update 4 or Cumulative Update 15 prior to upgrading to .Net 4.6.2.

The upgrade to .Net 4.6.2, while strongly encouraged, is optional with these releases. As previously disclosed, the cumulative updates released in our March 2017 quarterly updates will require .Net 4.6.2.

Change to Pre-Requisites installed by Setup

Since Exchange Server 2013, the Windows feature Media Foundation has appeared as a pre-requisite in our setup checks on Windows Server 2012 and later. However, if you chose to allow Exchange setup to install the required OS Components, Desktop Experience has been installed on all supported operating systems. Desktop Experience is required on Windows Server 2008R2. The Desktop Experience feature includes additional components which are not necessary for Exchange Server and require frequent patching. Windows Server 2012 and later modified feature definitions to include Media Foundation. Exchange Setup in Exchange Server 2016 Cumulative Update 4 and Exchange Server 2013 Cumulative Update 15 has been updated to install Media Foundation instead of Desktop Experience on Windows Server 2012 and later. This change will only apply to newly installed servers. Applying either cumulative update will not change the existing configuration of the server. If desired, an administrator can add Media Foundation and remove Desktop Experience from the list of installed Windows features on Windows Server 2012 and later.

Update on Windows Server 2016 support

The Windows team has released KB3206632. This update addresses the issue where IIS would crash after a DAG is formed and the server is subsequently restarted. This update is now required on all servers running Exchange Server 2016 on Windows Server 2016. Setup will not proceed unless the KB is installed.

Latest time zone updates

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

Important Public Folder fix included in these releases

Exchange Server 2013 Cumulative Update 14 and Exchange Server Cumulative Update 3 introduced an issue where new posts to a public folder may not have been indexed if there was an active public folder migration (KB3202691). This issue is now resolved. To ensure all public folders are indexed appropriately, all public folder mailboxes should be moved to a new database after applying the appropriate cumulative update released today.

Release Details

KB articles which contain greater depth on what each release includes are available as follows:

• Exchange Server 2016 Cumulative Update 4 (KB3177106), Download, UM Lang Packs
• Exchange Server 2013 Cumulative Update 15 (KB3197044), Download, UM Lang Packs
• Exchange Server 2010 Service Pack 3 Update Rollup 16 (KB3184730), Download
• Exchange Server 2007 Service Pack 3 Update Rollup 22 (KB3184712), Download

Exchange Server 2016 Cumulative Update 4 does not include new updates to Active Directory Schema. If upgrading from an older Cumulative Update or installing a new server, Active Directory updates may still be required. These updates will apply automatically during setup if user permissions and AD requirements are met. If the Exchange Administrator lacks permissions to update Active Directory Schema, a Schema Admin needs to execute SETUP /PrepareSchema prior to the first Exchange server installation or upgrade. The Exchange Administrator should also execute SETUP /PrepareAD to ensure RBAC roles are updated correctly.

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

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 CU15, 2016 CU4) or the prior (e.g., 2013 CU14, 2016 CU3) Cumulative Update release.

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

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

The Exchange Team

Many organizations have been using certificate based authentication for Exchange Online while the feature was in preview. Today, we are excited to announce that the feature is generally available in Office 365 Enterprise, Business, Education, and Government plans. For more details, please reference our preview post which has been modified to reflect this announcement. As always, we look forward to hearing your suggestions and feedback!

Tyler Lenig
Program Manager
Office 365

We are interested in working with Exchange 2016 customers or partners to help us validate Exchange hybrid scenarios using Microsoft Graph. This will be a self-paced development project where your developers will scope and get technical help to unblock Graph API issues from the product team. In order to participate, you will need to join the Exchange TAP program. Here is a mini FAQ about this program:

What are the technical requirements?
To develop and validate an Exchange hybrid solution, you will need to have Exchange 2016 CU3 or later deployed with your on-premises Active Directory synced with Azure AD. To learn more about the hybrid deployment: https://channel9.msdn.com/Events/Ignite/2016/BRK3045

How many developers will I need?
Expect to have 1 maybe 2 developers to scope and develop a Microsoft Graph solution.

Do I need to have an existing Exchange Web Services solution?
It would be a nice-to-have but we do not require it. We’re more interested in finding customers who want to support hybrid Exchange 2016 deployments and validating the benefits that the Microsoft Graph provides.

What is the timeframe for this?
We are planning to start this project in January 2017 and look to finish before the summer of 2017.

Do we have to travel to Redmond?
No. The tech is already in Preview and available to use from any dev laptop with internet access.

Why are you offering this?
We find collaborating directly with our customers and partners help us to make improvements to the Microsoft Graph to support deeper and broader customer needs. We hope to add what we learn to our product roadmap.

If you are interested in applying for this program, then please send an email to exchangehybridgraph@service.microsoft.com and include the following information:

1. Who will be the primary lead for this project?
   • Company:
   • First, Last Name:
   • Business Title:
   • Work e-mail:
   • Work phone:
2. Is your company enrolled in the Exchange TAP?
3. What hybrid scenario do you envision working on?
4. Describe how you would like to technically solve it?
5. Have you or your team tried to solve this hybrid scenario using Exchange Web Services? How did it go?
6. Have you or your team programmatically used the Microsoft Graph? Please describe a project if you have built one.
7. Please tell us about your development team that will work on this project.

Cheers!

Microsoft Outlook Team

Greetings Exchange Community!

Today, I am pleased to announce the release of a major update to the Exchange Generate Message Profile script. This release primarily focuses on two enhancements.

The first enhancement is the script will now use multiple “threads” (currently in the form of PowerShell jobs with Runspaces under consideration for a future version) to collect data from multiple servers simultaneously. This should significantly speed up data collection in environments with a large number of servers in a site. A few notes on this:

1. Each thread creates its own fully RBAC compliant connection to a local Exchange server (defaulting to itself). Because each session is using the RBAC compliant IIS based PowerShell proxy, the CPU utilization of the server running the script is not only increased by the multiple threads that are spawned, but also by the IIS service that they are each are connected to.
2. When run on a full Exchange Server, the script defaults to using the number of threads equal to approximately ¼ of the CPU cores on the server. This helps ensure that by default the script does not use more than ~50% CPU resources on the server running the script, as it accounts for the CPU load of the threads (1/4 = 25%) and the load they place (another 25%) on the IIS service.
3. When run on an system with just the Exchange Management tools loaded, the script default to using the number of threads equal to approximately ½ of the CPU cores of the system.
4. The script will gracefully shut down any background jobs still running if CTRL-C is used to stop the script.

The second enhancement is regarding the script’s behavior of skipping the creation of a message profile for a site when a single server in it is unavailable or has data collection issues. This is still the default behavior of the script, but this behavior can now be overridden by specifying the minimum percentage of servers in a site that must be online and return data for a message profile to still be generated for that site. It is highly recommended to leave this at the default setting, but this requested feature will allow the script to provide even a slightly skewed message profile versus nothing when a small percentage of servers were unresponsive or have data collection issues.

For a complete list of all enhancements and bug fixes please review the Version History on the TechNet Gallery posting.

As always I welcome feedback through the TechNet Gallery posting.

Dan Sheehan
Senior Premier Field Engineer

Today, we released an updated version of the Exchange Server Role Requirements Calculator.

This release focuses on bug fixes with the DAG auto-calculation functionality that was introduced in 8.3, as well as, support for ReplayLagMaxDelay.

In addition to allowing you to configure the ReplayLagMaxDelay value (default is 24 hours), the calculator has also been updated to ensure that the SafetyNetThreshold is configured to a value that is equal to or greater than the sum of ReplayLagTime+ReplayLagMaxDelay.

For all the other improvements and bug fixes, please review the Release Notes, or download the update directly.

As always we welcome feedback and please report any issues you may encounter while using the calculator by emailing strgcalc AT microsoft DOT com.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

This post explains the configuration steps needed to get rich document collaboration working between Exchange Server 2016, SharePoint Server 2016, and Office Online Server, in your On-Premises environment.

Please use this link if you’re looking for configuration steps for Exchange Server 2016 On-Premises and SharePoint Online

Introduction

When used together, Exchange Server 2016, SharePoint Server 2016, and Office Online Server provide a rich set of document collaboration features.

For example, rather than directly attaching a document to an e-mail message you may now send a link to the document stored in OneDrive for Business (ODB). Outlook and Outlook on the Web (new name for OWA) will still display the file as if it was directly attached to the message like a classic attachment would be, as well as allow people to work with the file like they would with a classic attachment. Additionally, many people will be able to read and edit the same file at the same time while it is stored in OneDrive for Business (ODB).

You can see a short demo of how this collaboration can look like right here.

Pre-requisites

The solution requires you have the following set up On-Premises:

• Exchange Server 2016 CU2 (or higher)
• OneDrive for Business (ODB) configured on SharePoint Server 2016
• Office Online Server (OOS)
• Make sure the certificate used for ODB, OOS and Outlook on the Web supports the appropriate name space. Also, ensure the certificate used by each service is either issued by same authority or the issuing authority is trusted on each server.

Configuration

The basic setup for these rich document collaboration features involves configuring OneDrive for Business (ODB) in the SharePoint 2016 farm, establishing a server-to-server trust (also referred to as S2S or OAuth) between SharePoint Server 2016 and Exchange Server 2016. Once completed, users will have the ability to attach ODB-based documents to email messages. Installing and configuring Office Online Server will introduce the additional capability of device-independent side-by-side viewing as well as edit & reply functionality in Outlook on the Web.

Note that editing documents is a premium feature of OOS and requires appropriate licenses!

Office Online Server

Install OOS and create a new OOS farm. Make sure the farm URL is accessible from Internet if you want users to be able to view and possibly edit documents via Outlook on the Web from outside of the corporate network:

Example:

For an OOS farm that is going to use same internal and external FQDN, with editing enabled:

New-OfficeWebAppsFarm -InternalURL “https://oos.contoso.com” -ExternalURL “https://oos.contoso.com” -CertificateName “Unified Certificate” -EditingEnabled

For an OOS farm that is going to use different internal and external FQDNs, with editing enabled:

New-OfficeWebAppsFarm -InternalURL “https://internaloos.contoso.com” -ExternalURL “https://externaloos.contoso.com” -CertificateName “Unified Certificate” -EditingEnabled

SharePoint Server 2016

In order to leverage the OneDrive for Business-based attachments on-premises, users must have a OneDrive for Business site hosted by SharePoint Server 2016 on-premises.

Follow steps from here, if the MySite Host (which gives you OneDrive for Business) is not already configured.

Additionally, to enable integration of Office Online Server for document previewing and online editing, WOPI bindings must be created in the SharePoint farm.

• WOPI Bindings – WOPI bindings (or Web Application Open Platform Interface bindings) define related applications and available actions for a file extension. The New-SPWOPIBinding cmdlet is used to create these bindings between OOS and SharePoint. As with the other configurations, HTTPS is encouraged for production use, but non-production environments can be configured to communicate without SSL/TLS security by including the -AllowHTTP switch on the cmdlet: New-SPWOPIBinding -ServerName oos.contoso.com
• S2S/OAuth Trust and Service Permissions – The SharePoint Server provides set of commands to configure Server to Server authentication, create App Principals and configure correct permissions that are needed to make this level of collaboration real.

The commands can be put together in a script to make life easy. A sample script for performing this configuration is provided here

Usage:

• Download the script
• Save this script as a .ps1 file on your SharePoint Server 2016, for example ‘Config-SPSOAuth.ps1’.
• Open the SharePoint Management Shell and execute the script.
• Script will prompt for:
  • An ExchangeServer URL – the hostname provided to access Exchange Server 2016.
  • A SharePoint MySite Host – URL of the SharePoint website hosting the MySite collection.

Example:

.\Config-SPSOAuth.ps1 -ExchangeServer mail.contoso.com -MySiteHostUrl https://sp01.contoso.com/

Exchange Server 2016

The user’s mailbox must be hosted on an Exchange Server 2016 server on-premises to enable the document collaboration functionality. There are a few settings to configure on Exchange Server to enable the full experience.

• OOS Endpoint – Configuring the OOS Endpoint in Exchange enables preview options for file attachments, as well as the edit and reply functionality. The OOS endpoint can be set in two locations – the Organization level, and at the Mailbox Server level. The Organization level is used to enable a global configuration for all servers with a single setting. This is useful for a single server, or single location deployment. It also serves as a fallback/failsafe when the endpoint configured at the mailbox server level is unavailable. The Mailbox Server level allows administrators to distribute client requests to multiple OOS servers. This can be done to balance load, or when building geographically dispersed deployments.

Set-OrganizationConfig -WacDiscoveryEndpoint https://oos.contoso.com/hosting/discovery
Set-MailboxServer exch.contoso.com -WacDiscoveryEndpoint https://oos.contoso.com/hosting/discovery

If you have Exchange 2013 servers in your organization, do not configure an OOS endpoint at the organization level. Doing so will direct Exchange 2013 servers to use OOS, which is not supported.

• My Site Host URL – Exchange must know the My Site Host URL to enable ODB-based attachments. This can be set in two locations, the OWA Virtual Directory, and through an OWA Mailbox Policy. The preferred approach setting the My Site Host URL is through an OWA Mailbox Policy. It is recommended for all environment configurations, but it is a requirement when running an Exchange environment with a mixture of Exchange 2016 and Exchange 2013 servers. Mailbox policies allow features to be enabled selectively for users or groups. Each organization will have at least a Default policy which can be assigned to all users. Additional policies can be created using the New-OWAMailboxPolicy cmdlet. The OWA Virtual Directory can only be used to set the My Site Host URL when Exchange 2016 is the only version of Exchange that frontends client access traffic.

Example 1:

Creating new policy for My Site host access:

New-OwaMailboxPolicy -Name ODBPolicy
Set-OwaMailboxPolicy -Name ODBPolicy -InternalSPMySiteHostURL https://sp01.contoso.com -ExternalSPMySiteHostURL https://sp01.contoso.com

Finally, assign the policy to mailboxes:

Set-CASMailboxPolicy JohnR@contoso.com -OWAMailboxPolicy ODBPolicy

Example 2:

In this example, only users connecting to the server ‘Exch’ need to be enabled for document collaboration:

Get-OwaVirtualDirectory -Server exch.contoso.com -ADPropertiesOnly | Set-OwaVirtualDirectory -InternalSPMySiteHostURL https://my.contoso.com -ExternalSPMySiteHostURL https://my.contoso.com

This configuration is useful in scenarios where only specific servers are going to frontend the Outlook on the Web traffic

• S2S/OAuth Trust and Service Permissions – Enable secure communication between the SharePoint 2016 and Exchange 2016 servers. Production environments should have traffic to both Exchange and SharePoint encrypted by HTTPS. Additionally, neither server should receive a certificate error when communicating with the other or else the integration will fail. The half of the trust configured on Exchange is configured via a script included with the Exchange 2016 installation binaries. The script can be found in the scripts directory, which is by default found at “C:\Program Files\Microsoft\Exchange Server\V15\scripts” (your installation path may vary based on your installation choices). This location is referenced by the $ExScripts variable within the Exchange Management Console.

& $ExScripts\Configure-EnterprisePartnerApplication.ps1 -ApplicationType Sharepoint -AuthMetadataUrl https://sp01.contoso.com/_layouts/15/metadata/json/1

Limitations

These are currently some limitations we hope to address in the future. Please be aware of what they are for the time being:

• The Outlook 2016 client can only interact with OneDrive for Business attachments in Office 365, it cannot connect to on-premises OneDrive for Business attachments. This limitation does not apply to Outlook on the Web 2016
• For On-Premises deployments, only internal recipients (mailboxes) that are present in same organization as that of sender can be granted permissions on the OneDrive for Business document. The sender is informed via separate email if the automatic permission process fails. This means you cannot send ODB attachments to users outside of your on-premises organization.
• OneDrive for Business must be provisioned and initialized (the user has logged in at least once) for both the sender and the recipient. Without both the sender and recipient being provisioned and initialized the side-by-side documents preview will not work for the recipient.

I wanted to thank Neil Hodgkinson, Jon Frick, Brian Day and Jason Haak for their help in putting this together!

Bhalchandra Atre

Today, we released an updated version of the Exchange Server Role Requirements Calculator.

This release focuses on bug fixes with the DAG auto-calculation functionality that was introduced in 8.3, as well as, support for ReplayLagMaxDelay.

In addition to allowing you to configure the ReplayLagMaxDelay value (default is 24 hours), the calculator has also been updated to ensure that the SafetyNetThreshold is configured to a value that is equal to or greater than the sum of ReplayLagTime+ReplayLagMaxDelay.

For all the other improvements and bug fixes, please review the Release Notes, or download the update directly.

As always we welcome feedback and please report any issues you may encounter while using the calculator by emailing strgcalc AT microsoft DOT com.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Today, we are excited to announce the ‘Send-as’ and Send-on-behalf of feature for groups in Outlook, which brings you one step closer to turning your email into a great customer support solution.

With the new ‘Send as’ and ‘Send on behalf of’ feature, members of the group can respond to conversations using the shared identity of the Group instead of their individual personal identity – without losing the personal, individual touch. Because sometimes, that’s just what you need.

Like other groups in Outlook, members can read all messages sent to the group. But with this feature turned on, responses look like they come from the group rather than the individual.

Here’s what Send on Behalf and Send As look like from the recipient’s perspective:

Send on Behalf	Send As

If your business is looking for a lightweight, email-centric customer support solution, you’re in luck. This feature might be what you need. The consistent use of a single email address will help your customers develop recognition and trust—ensuring that your email messages are seen.

This feature is particularly helpful in scenarios where you want to set up a group to connect with external customers. Collective knowledge of group helps resolve those customer inquiries faster and everyone on the team benefits from shared knowledge of the Group.

Here are some example scenarios:

1. Support@Contoso.com can be set as group to receive all customer support inquiries. When your customers send email to this group, any member of the group could respond to inquiry in a timely fashion without disclosing their individual identity. Subsequent responses from the customer also go back to the group, keeping all information in one place and making it faster for support representatives to respond to new inquiries. Additionally, because all of the group conversation history is available, other team members will be able to see that specific customer emails have already been answered to.

The support team member would see the following:

The recipient (customer) would see the following:

2. Some organizations may also want to use ‘Send as’ or ‘Send on behalf of’ for an internal group. For example, if you want all expense reports sent to a Billing department alias rather than bombarding a specific person.

Billing@contoso.com can be set up as a group to receive all your organization’s billing inquiries. Individuals who work in the billing department and are a part of this group can respond back as the Billing department identity.

Sound like what your business needs? Learn how to turn it on.

Allow members to send as or send on behalf of an Office 365 Group – Admin help
Allow members to send email as an Office 365 Group

The Groups Team

Since we posted this blog post, we have received positive responses from many of our customers, who have proceeded with changing their connectors (as per instructions in the post), thereby protecting their email/domain reputation. However, we are also aware of customers who are either in the midst of making this change or need some additional time to complete their changes. We understand a change like this can take some time, so we have decided to move our deadline from Feb 1^st, 2017 to July 5^th, 2017.

We have also added more details in the original post. If you are an Office 365 email customer and your organization is hybrid (you have an on-premise environment), please take some time to read it!

Carolyn Liu

Almost 4 years ago, I wrote a script called GetTransactionLogStats.ps1, and originally blogged about it here. At the original time of writing, the primary purpose of the script was to collect transaction log generation data, and use that to determine the percentage of transaction logs generated per hour in an environment. This could in turn be used to populate the related fields in the Exchange Server Role Requirements Calculator.

Since originally writing this script, I’ve made some significant updates to how the script functions, and also added a handful of new features along the way, which were significant enough that I wanted to have a new post about it. Of note, the script now:

• Uses PowerShell Remoting to collect data from many remote servers in Parallel. This significantly speeds up collection speeds.
• Generates a database heat map, that compares the number of logs generated for each database to the number of logs generated for all databases. This can be used to identify databases that may be overloaded or underloaded.
• Uses only log generation information from active database copies to determine log generation statistics.
• Accepts the target servers via a script parameter instead of via a text file.

Requirements

The script has the following requirements;

• Target Exchange Servers must be running Exchange 2010, 2013, or 2016
• PowerShell Remoting must be enabled on the target Exchange Servers, and configured to allow connections from the machine where the script is being executed.

Parameters

The script has the following parameters:

• Gather: Switch specifying we want to capture current log generations. If this switch is omitted, the -Analyze switch must be used.
• Analyze: Switch specifying we want to analyze already captured data. If this switch is omitted, the -Gather switch must be used.
• ResetStats: Switch indicating that the output file, LogStats.csv, should be cleared and reset. Only works if combined with –Gather.
• WorkingDirectory: The directory containing LogStats.csv. If omitted, the working directory will be the current working directory of PowerShell (not necessarily the directory the script is in).
• LogDirectoryOut: The directory to send the output log files from running in Analyze mode to. If omitted, logs will be sent to WorkingDirectory.

Usage

Runs the script in Gather mode, taking a single snapshot of the current log generation of all databases on servers server1 and server2:

PS C:\> .\GetTransactionLogStats.ps1 -Gather -TargetServers “server1″,”server2”

Runs the script in Gather mode, specifies an alternate directory to output LogStats.csv to, and resets the stats in LogStats.csv if it exists:

PS C:\> .\GetTransactionLogStats.ps1 -Gather -TargetServers “server1″,”server2” -WorkingDirectory “C:\GetTransactionLogStats” -ResetStats

Runs the script in Analyze mode:

PS C:\> .\GetTransactionLogStats.ps1 -Analyze

Runs the script in Analyze mode, and specifies an alternate directory to send the output files to:

PS C:\> .\GetTransactionLogStats.ps1 -Analyze -LogDirectoryOut “C:\GetTransactionLogStats\LogsOut”

Output File After Running in Gather Mode

LogStats.csv

When run in Gather mode, the log generation snapshots that are taken are sent to LogStats.csv. The following shows what this file looks like:

Output Files After Running in Analyze Mode

LogGenByHour.csv

This is the primary output file for the script, and is what is used to populate the hourly generation rates in the Exchange Server Role Requirements Calculator. It consists of the following columns:

• Hour: The hour that log stats are being gathered for. Can be between 0 – 23.
• LogsGenerated: The total number of logs created during that hour for all days present in LogStats.csv.
• HourToDailyLogGenRatio: The ratio of all logs that that particular hour accounts for. The sum of values for this column in all 24 hours in the table should be 1, and can be copied directly into the Exchange Server Role Requirements Calculator.
• NumberOfHourlySamples: The number of hourly samples that were used to calculate each hour value.
• AvgLogGenPerHour: The average number of logs generated per database per hour.

LogGenByDB.csv

This file contains a heat map showing how many logs were generated for each database during the duration of the collection. This information can be used to figure out if databases, servers, or entire Database Availability Groups, are over or underutilized compared to their peers. It consists of the following columns:

• DatabaseName: The name of the database being measured.
• LogsGenerated: The total number of logs created by primary copies of that database during the duration of the collection.
• LogGenToTotalRatio: The ratio of logs generated for this database compared to logs generated for all databases.
• NumberOfHours: The number of hourly samples that were taken for this database.
• LogsGeneratedPerHour: The average number of logs generated per hour for this database.

LogGenByDBByHour.csv

This file is similar to LogGenByDB.csv, but shows the log generation rates per hour for each database. It consists of the following columns:

• DatabaseName: The name of the database being measured.
• Hour: The hour that log stats are being gathered for. Can be between 0 – 23.
• LogsGenerated: The total number of logs created by primary copies of that database during that hour.
• HourToDailyLogGenRatioForDB: The ratio of logs generated for this hour and this database compared to the total logs generated for this database.

Running As a Scheduled Task

Since the script is designed to be run an hourly basis, the easiest way to accomplish that is to run the script via a Scheduled Task. The way I like to do that is to create a batch file which calls Powershell.exe and launches the script, and then create a Scheduled Task which runs the batch file. The following is an example of the command that should go in the batch file:

powershell.exe -noninteractive -noprofile -command “& {C:\LogStats\GetTransactionLogStats.ps1 -Gather -TargetServers “server1”,”server2” -WorkingDirectory C:\LogStats}”

In this example, the script is located in C:\LogStats. Note that I specified a WorkingDirectory of C:\LogStats so that if the Scheduled Task runs in an alternate location (by default C:\Windows\System32), the script knows where to find and where to write LogStats.csv. Also note that the command does not load any Exchange snapin, as the script doesn’t use any Exchange specific commands.

Mike Hendrickson

On April 11, 2017, Exchange Server 2007 will reach End of Life. If you haven’t already begun your migration from Exchange 2007 to Office 365 or Exchange 2016, you need to start planning now.

End of life means that Microsoft will no longer provide the following for Exchange 2007:

• Free or paid assisted support (including custom support agreements)
• Bug fixes for issues that are discovered and that may impact the stability and usability of the server
• Security fixes for vulnerabilities that are discovered and that may make the server vulnerable to security breaches
• Time zone updates

Your installation of Exchange 2007 will continue to run after this date. However, because of the changes listed above, we strongly recommend that you migrate from Exchange 2007 as soon as possible.

To learn about your options for migrating from Exchange 2007 to Office 365 or a newer version of Exchange Server, check out Exchange 2007 End of Life Roadmap.

If you have other Office 2007 servers or clients, such as SharePoint Server 2007, PerformancePoint Server 2007, Office Communications Server, Project Server 2007, or Office 2007 client applications, check out Resources to help you upgrade from Office 2007 servers and clients for information about their end of life dates and upgrade options.

Exchange Team

You can now use an Administrator account that is enabled for Multi-Factor Authentication to sign in to Exchange Online PowerShell and the Office 365 Hybrid Configuration Wizard (HCW).

In case you are not aware, the Azure multi-factor authentication is a method of verifying who you are that requires the use of more than just a username and password. Using MFA for Office 365, users are required to acknowledge a phone call, text message, or app notification on their smart phones after correctly entering their passwords. They can sign in only after this second authentication factor has been satisfied. You can read more about the Office 365 Multi Factor Authentication option here.

Many Exchange Online customers wanted the extra level of security that is offered with Multi-Factor Authentication, which allows you to force the administrator account to use Multi-Factor Authentication. However, because of a limitation in Remote PowerShell, Exchange Online administrators could not connect with a Multi-Factor enabled account. In addition, as the Office 365 Hybrid Wizard also requires Remote PowerShell connections to Exchange Online, prior to now, the account you used to run the HCW could not be enabled for Multi-Factor Authentication.

The Exchange Online PowerShell Module

There is a new module that was created that can be downloaded to allow you to connect with an account that is enabled for Multi-Factor Authentication. You can download the module from the Exchange Online Administration Center (the steps are outlined in this article).

Note: We do not plan to discontinue traditional methods of connecting to Remote PowerShell; if you are not using Multi-Factor Authentication you can continue to connect using the methods you already have in place.

The Hybrid Wizard Update

The Hybrid Wizard has also been updated to allow for Multi-Factor Authentication enabled administrators to authenticate.

Note: There is an issue with this new Authentication method in the 21 Vianet Greater China tenants. For customers with Tenants in that region you cannot use the MFA module or Hybrid integration mentioned in this article and should instead use the Hybrid Wizard located here: http://aka.ms/HCWCN

In order to keep the sign in experience consistent for all customer whether they have MFA enabled or are using traditional credentials, we have updated our credentials page in the wizard.

On the Credential page of the wizard you will see that the “next” button is not available. You are required to pick your credential for on-premises (which by default will be the currently signed in credentials) and “sign in” to Office 365.

Once you select “sign in” you will be prompted for credentials in a familiar looking screen.

If you have Multi-Factor Authentication enabled for the administrator, you would then be prompted for the second factor of authentication.

Once verified, you would see the credential card for both the on-premises and Exchange Online administrators. You will also notice that the “next” button is now activated.

Conclusion

Your feedback about not being able to use MFA enabled account for Exchange Online administration was loud and clear! Please keep providing us feedback so we can continue to identify and address your needs.

The Exchange Team