What are we talking about today?

In Exchange 2013 CU5 (yes 5, V, cinco, fem, and cinque) we started implementing changes to how Legacy Public Folder endpoint discovery will be performed by Outlook (for Windows) in the future. This work continues behind the scenes and will be completed with the release of Cumulative Update 7. This becomes important in on-premises Exchange coexistence environments where some or all of your on-premises user mailboxes have been moved to Exchange 2013 and your Public Folder infrastructure is still on Exchange 2007 or Exchange 2010. Anyone whom has gone through the Legacy Public Folder hybrid configuration steps for Exchange Online will recognize what we are about to go through for the on-premises edition of Exchange 2013.

Why should I care about this?

Prior to CU7, Exchange 2013 mailboxes using the Outlook client were proxied to the legacy mailbox server hosting the Public Folder being accessed either via RPC/TCP or RPC/HTTP depending on the client’s location, the connectivity model being used, and the configuration on the legacy Exchange servers.

With the introduction of MAPI/HTTP in Exchange 2013 SP1, we identified an issue where clients could not always access the legacy Public Folder environment after moving to the MAPI/HTTP protocol.

An analysis of this behavior led us to understand that a combination of RPC Client Access code and older code within the Outlook client enabled the client to be redirected to the legacy Public Folder store under certain circumstances. While you may be thinking this is great news, it is not the desired state – both Exchange and Outlook need to utilize a common pathway for directing clients to connect to mailbox and Public Folder data. That common pathway is Autodiscover.

In the future, both Exchange and Outlook will remove the old code that enabled the older redirection logic. As a result new configuration steps exist which customers should undertake to coexist with legacy Public Folders and support connectivity with Outlook (for Windows) clients whose mailboxes reside on Exchange 2013, regardless of the connectivity protocol (RPC/HTTP or MAPI/HTTP) in use by their clients.

We are providing you with this information in advance of CU7’s release (No, we’re not going to answer when it will be released other than ‘when it is ready.’J) so you may prepare your environments for the new legacy public folder coexistence method. All of the commands discussed here were available starting in CU5 so you may configure your environment in advance of deploying CU7 if you would like to.

Give me the short version. What do I have to do?

The configuration steps for enabling this new discovery method have been published in the following article.

There are two new commands you will need to execute prior to installing CU7 or just after (we recommend before) to ensure Exchange 2013 CU7 and later will provide Outlook the information it needs to properly discover legacy public folders.

• From a CU5 or later Exchange 2013 Server: Use the Set-OrganizationConfig cmdlet to assign the legacy public folder discovery mailbox(es) to the RemotePublicFolderMailboxes value of the organization.
• From a CU5 or later Exchange 2013 Server: Use the Set-OrganizationConfig cmdlet to set the PublicFoldersEnabled attribute of your Exchange organization from Local to Remote.

With the above settings configured Exchange 2013 will begin returning a new section in Autodiscover responses to Exchange 2013 mailbox users similar to the following and using the new coexistence code paths;

<PublicFolderInformation>
<SmtpAddress>PFDiscovery-001@contoso.com</SmtpAddress>
</PublicFolderInformation>

With this information Outlook will then perform a second Autodiscover request using the provided SMTP address. This SMTP address is for a legacy Public Folder discovery mailbox that resides on an Exchange 2007 or Exchange 2010 mailbox server that also serves a public folder database (PFDB). In the above example Outlook would perform an Autodiscover request for PFDiscovery-001@contoso.com to discover the connection endpoint (RPC, or RPC/HTTPS) to use when the Exchange 2013 user is accessing your organization’s legacy Public Folder. Outlook is not logging on as this mailbox, nor is it actively using this mailbox to access the legacy public folder content. The mailbox strictly exists to be able to perform an Autodiscover request/response such that Outlook receives a valid connection endpoint for your legacy Public Folders.

Without these new settings being configured, Exchange 2013 will continue to use the old code paths which will be removed at some point in the future. It is important that all on-premises Exchange 2013 organizations fully configure their environment to ensure uninterrupted legacy Public Folder access in the future.

I like pictures and examples. Is there a longer version?

Yes, we have you covered. Let us go through configuring an Exchange 2013 environment for Exchange 2010 legacy public folder access as it is the more complicated of the two scenarios to configure. If you need to configure Exchange 2007 there are fewer steps involved and you can reference the TechNet documentation.

1. Identify the Public Folder database(s) you need users to be able to connect to initially by examining the PublicFolderDatabase attribute of your Exchange 2013 mailbox databases. This attribute defines the default legacy public folder database for each Exchange 2013 mailbox database.

   Below we can see there are two legacy public folder databases used as defaults for our Exchange 2013 databases.

   

2. Add the Client Access Server role if the PFDB resides on an Exchange 2010 Mailbox Server without CAS installed. The addition of the CAS role will ensure public folder replica referrals happen appropriately if a folder a user is accessing does not have a local replica in the PFDB. If the PFDB resides on a server with both the Mailbox and Client Access Server roles (Whether Hub Transport or UM are installed are irrelevant here), you can skip this step and go to step 3.
3. After installing the CAS role, if it was necessary, configure the role as you would any other CAS in this AD site with the proper virtual directory and other settings to ensure Autodiscover results for clients are not impacted by a bunch of default virtual directory values. You do not have to add this new CAS role to your load balancer pool if you do not want to. If you did not have to install the CAS role as it was already installed on the PFDB server, please skip to step 3.
4. Create a new empty mailbox database on the Mailbox Server containing the PFDB to be accessed. If this mailbox server is a member of a DAG, please do not create additional copies of this particular mailbox database. You can safely leave this mailbox database as a single copy.

   Note: If you are unable to create an additional mailbox database in this step due to using Exchange Server Standard Edition, you can utilize an existing mailbox database in this case.

5. Skip this step if you are re-using another mailbox database due to Exchange Server Standard Edition limitations. Using the Set-MailboxDatabase cmdlet, exclude this new empty mailbox database from automatic mailbox provisioning by setting the IsExcludedFromProvisioning flag to $True.
6. Skip this step if you are re-using another mailbox database due to Exchange Server Standard Edition limitations. Using the Set-MailboxDatabase cmdlet, set the RPCClientAccessServer value of the new empty mailbox database to the FQDN of the Mailbox Server holding the public folder database to be accessed. The RPCClientAccessServer value is only used for RPC/TCP connectivity and this does not mean a new name is added to your SSL certificate as HTTPS will not be used here (see Item #3 here for explanation).
7. Create a new mailbox inside the empty mailbox database you just created on the server holding your PFDB. This will be known as a Public Folder discovery mailbox. This mailbox is not accessed in any way. This mailbox is used as a target to retrieve connection settings via Autodiscover and nothing more. A naming convention such as PFDiscovery-<ServerName> or PFDiscovery-<###> is helpful to identify these mailboxes in the future. This mailbox must have an SMTP address which can be used by Autodiscover internally, and also used externally if you have external users requiring access to legacy public folders. If you are re-using another mailbox database due to Exchange Server Standard Edition limitations, the mailbox will reside in an existing database.

   Below you can see the mailbox we created and its SMTP address.

   

8. Using the Set-Mailbox cmdlet hide your new discovery mailbox(es) from address lists by setting the HiddenFromAddressListsEnabled parameter to $True.

   

9. Repeat steps 1-7 for additional Public Folder databases if you would like to distribute client connections across more than one PFDB.
10. Prior to running the next two commands we look at the current organization configuration in its default state.

    

11. From a CU5 or higher Exchange 2013 Server: Using the Set-OrganizationConfig cmdlet, assign the PF discovery mailbox(es) to the RemotePublicFolderMailboxes value of the organization.
12. From a CU5 or later Exchange 2013 Server: Using the Set-OrganizationConfig cmdlet, set the PublicFoldersEnabled attribute of your Exchange organization to Remote.

    Running our Set-OrganizationConfig commands.

    

    Note: If you need to add multiple mailboxes you can use this example PowerShell command format.

    Set-OrganizationConfig -RemotePublicFolderMailboxes "PFDiscovery-001", "PFDiscovery-002"

    Validating the changes took place.

    

13. After you configure these two new settings and a few caches expire you should be able to validate you are now getting the <PublicFolderInformation> section back in the initial Autodiscover response for users with Exchange 2013 mailboxes.

    

14. If you were to run your favorite HTTP proxy/logging tool while Outlook is running you would eventually see another Autodiscover query/response for in our example the mailbox PFDiscovery-010@corp.contoso.com returned above. This is when Outlook learns where and how to connect to your legacy Public Folder infrastructure.

    

15. Confirm via Outlook you can connect to the legacy Public Folder hierarchy. Below are examples of using MAPI/HTTP for the primary mailbox and either RPC/HTTP or RPC/TCP for the legacy Public Folders. In our example lab the Exchange 2010 server named CON-E2K10-002 holds the PFDB being accessed. This public folder database was accessed because it is the default public folder database of the Exchange 2013 mailbox database the user resides in. If you are not yet using MAPI/HTTP in your Exchange 2013 environment, then the screenshots below would look the same except for replacing “HTTP” with “RPC/TCP.”

MAPI/HTTP for the Primary mailbox and RPC/HTTP for legacy Public Folders

MAPI/HTTP for the Primary mailbox and RPC/TCP for legacy Public Folders

FAQ

Q: We're running Exchange 2013 SP1 (or earlier) and plan on upgrading directly to CU7. Our Exchange 2013 users seem to be accessing legacy Public Folders without issue today. Does this mean their legacy Public Folder access will break when CU7 is applied?

A: CU7 has logic that will only use the new code paths if RemotePublicFolderMailboxes is not empty and the PublicFoldersEnabled is set to ‘Remote’. If you were to upgrade directly from an SP1 or earlier to CU7, then Exchange will use the old code paths until you complete the necessary configuration steps to ensure users are not interrupted post-upgrade.

Q: Does Outlook Anywhere need to be enabled in the legacy (2007/2010) environment for this to work if we do not currently provide external access to Exchange via OA?

A: No, Outlook Anywhere does not need to be enabled if the only connectivity method you need to provide to legacy Exchange versions is RPC for internal users or external users connecting via a VPN tunnel. If OA is disabled in the 2007/2010 environment, then the Autodiscover results will inform Outlook to use RPC via the EXCH Outlook Provider instead of RPC/HTTP via the EXPR Outlook Provider to connect to the public folder database.

Q: Are there any specific Outlook versions/builds required for this to work?

A: As a general rule we always suggest keeping Outlook up to date with both service packs and public updates, and we maintain that suggestion here. As long as you are running a version of Outlook 2010 or 2013 supported by Office 365 this feature should work. If this guidance ever changes, we will update necessary documentation.

Q: How does Exchange 2013 choose what Remote Public Folder Mailbox to hand out to clients if more than one is configured in the RemotePublicFolderMailboxes variable? Is it random, round robin, looking at availability?

A: By default Exchange looks at the hash of the user calling into Autodiscover and will pick an entry from the array of mailboxes in RemotePublicFolderMailboxes or use the default public folder mailbox value if it is explicitly set on the mailbox. There is no logic based on user location versus PFDB location or anything of such nature.

Q: Will Exchange 2013 check to make sure the server holding a PF discovery mailbox is up and reachable before a client attempts to retrieve its connection settings via Autodiscover?

A: No, there is no availability check to ensure the legacy server is available before the PF discovery mailbox is given to a client to look up via Autodiscover.

Q: How many legacy public folder databases do I need accessible?

A: Public folder scalability guidance for Exchange 2007 and Exchange 2010 recommended no more than 10,000 active users connecting to a single PFDB. Based on that guidance, then at least one PFDB per 10,000 active users should be accessible. If you have 50,000 users in your organization then a conservative number would be to have no less than 5 public folder databases.

Note: This is a starting point. Your environment may vary and as a result require more or even less PF public folder databases as you monitor your system performance, user concurrency, and user client experience in your legacy environment.

Q: How many PF discovery mailboxes do I need?

A: At this time we are suggesting one per PFDB to be accessed.

Q: How do I control what particular PFDB the user connects to first?

A: For environments with geographically disperse locations it may be beneficial to ensure users connect to a PFDB close to their home location on a well performing network link path. You can make this happen by defining the default public folder database on the user’s Exchange 2013 mailbox database and locate users with similar geographical needs in the same Exchange 2013 mailbox database.

The commands are slightly different depending on if you are setting an Exchange 2010 or an Exchange 2007 public folder database as the default for an Exchange 2013 mailbox database. The command will tell you the ‘PublicFolderDatabase’ parameter has been deprecated, but it does do what it is supposed to do for coexistence purposes.

Using an Exchange 2007 Public Folder Database

Set-MailboxDatabase <2013DatabaseName> -PublicFolderDatabase <2007ServerName>\<Storage GroupName>\<PFDatabaseName>

Using an Exchange 2010 Public Folder Database

Set-MailboxDatabase <2013DatabaseName> -PublicFolderDatabase <2010PFDatabaseName>

Q: For Exchanage 2010 do I really need to install CAS on every Mailbox server with a PFDB to be accessed and create a new mailbox database?

A: At this time, yes, but we are evaluating a few other options to help improve and possibly streamline the coexistence configuration in the future. If we are able to streamline this process in the future we will be sure to update you. Remember, you do not need to add the server to your load balancer pool simply because CAS has been installed. The server should not see the volume of client traffic other CAS in the AD site experience.

Summary

After implementing this configuration you will have a more robust and predictable legacy Public Folder connectivity experience with Exchange 2013 Cumulative Update 7 and beyond by making your legacy Public Folder infrastructure discoverable via Autodiscover by your Outlook (for Windows) clients. We look forward to your comments and questions below. Be on the lookout soon for another article that will go into detail on deployment recommendations for Exchange 2013 public folders themselves.

Brian Day
Senior Program Manager
Office 365 Customer Experience

Note: Cumulative Update 7 (CU7) for Exchange Server 2013 will be released soon^TM.

Back in May, I discussed the changes we introduced in Exchange 2013 Cumulative Update 5. Specifically with CU5 and later, an OAB can only be assigned (or linked) to a single OAB generation mailbox. This architectural change addressed two deficiencies in the Exchange 2013 OAB architecture:

1. Enabled administrators to define where an OAB is generated.
2. Removed the capability to have multiple instances of the same OAB.

However, this change did not improve user accessibility in a distributed messaging environment. For example:

Let’s say the blue user, whom we shall now call Scott Schnoll, has his mailbox located in Redmond. Due to a clause in his work contract, Scott needs to work out of the Portland office for the next six months.

In order to keep Scott’s address book up to date, Outlook will trigger an OAB download every 24 hours (based on the time it was last successfully downloaded), connecting to the Redmond CAS infrastructure which proxies the request to the Redmond Mailbox server that hosts the OAB generation mailbox that generates the Redmond OAB.

Having Scott’s OAB files downloaded across the WAN is not an optimal experience. Obviously, the administrator could point Scott’s mailbox to the Portland OAB instance; however, that would require Scott’s client to undergo a full OAB download. Unfortunately, prior to CU7, this is the only way to mitigate this scenario.

Shadow Distribution in Cumulative Update 7

Exchange 2013 Cumulative Update 7 introduces the capability for an OAB generation mailbox to host a shadow copy of another OAB. This functionality enables additional Mailbox servers to be an endpoint for OAB download requests. By default, this feature is disabled and is configurable per OAB.

Referring back to our previous example, once shadow distribution is enabled for the Redmond OAB, Scott’s Outlook client, via the Autodiscover response his client gets from the Portland CAS (which as we know is actually going to be generated on the mailbox server in the Redmond site, as that’s where Scott’s mailbox is), will now access the Redmond OAB using a URL resolving to the Portland CAS infrastructure (https://pmail.contoso.com/oab/redmond oab guid/); this is accomplished by Autodiscover leveraging the X-SourceCafeHeader value specified in the HTTP proxy request. The first time an attempt is made to access this OAB will result in a 404 response as the OAB files do not exist on the Portland Mailbox server that hosts the OAB generation mailbox, OAB Mailbox 1. This event invokes the OABRequestHandler, which initiates an asynchronous transfer, via BITS, of the Redmond OAB files to the Portland MBX server hosting the OAB generation mailbox. During the next attempt to synchronize the OAB, Scott’s Outlook client is able to download the necessary OAB files locally.

How do I enable shadow distribution?

The GlobalWebDistributionEnabled and VirtualDirectoriesproperties of an OAB are still used by Autodiscover to determine which CAS OAB virtual directories are eligible candidates for distributing the OAB. Given the architecture in Exchange 2013, any CAS can proxy an incoming OAB request to the right location, therefore, with CU7 and later, the recommendation is to enable global web distribution for all OABs hosted on Exchange 2013.

Set-OfflineAddressBook <E15OAB> -VirtualDirectories $null
 
Set-OfflineAddressBook <E15OAB> -GlobalWebDistributionEnabled $true

Prior to enabling shadow distribution, you should deploy an OAB generation mailbox in each Active Directory site where Exchange 2013 infrastructure is deployed (assuming CU7 or later is deployed in each site).

New-Mailbox -Arbitration -Name "OAB Mailbox 3" -Database DB4 -UserPrincipalName oabmbx3@contoso.com –DisplayName "OAB Mailbox 3"
 
Set-Mailbox "OAB Mailbox 3" –Arbitration –OABGen $true

Once global distribution is enabled and OAB generation mailboxes are deployed, you can then enable shadow distribution on a per-OAB basis:

Set-OfflineAddressBook "Redmond OAB" -ShadowMailboxDistributionEnabled $true

How do I disable shadow distribution for an OAB?

You can disable shadow distribution on a per-OAB basis:

Set-OfflineAddressBook "Redmond OAB" -ShadowMailboxDistributionEnabled $false

Does accessing a shadow copy trigger a full OAB download?

As discussed in OAB Improvements in Exchange 2013 Cumulative Update 5, the reason we moved to having a single OAB generation mailbox generate an OAB was to ensure that the OAB instance remained unique within the organization. Prior to CU5, all OAB generation mailboxes generated their own unique instances of the OABs, which resulted in full downloads any time a client was proxied to a different OAB generation mailbox.

The shadow copy is only distributed on-demand and is an exact duplicate of the OAB that is generated by the “master” OAB generation mailbox. As a result, an Outlook client will not be forced to perform a full download upon accessing the shadow copy files. The OABv4 conditions in Using Offline Address Books describes the conditions that can trigger a full download of an OAB.

What does the client experience when a shadow copy is triggered?

If the OAB files do not exist on the Mailbox server hosting the OAB generation mailbox, then the Outlook client will report error 80190194 (BG_E_HTTP_ERROR_404).

How does a shadow distributed OAB get updated?

As soon as a new OAB is generated and published on the “master” Mailbox server, all the Mailbox servers hosting shadow copies will stop distributing their now-outdated copies. The first user who requests access to the OAB will trigger a full synchronization of the OAB to the shadow copy. The following events are reported:

Event ID: 102
Source: MSExchange OABRequestHandler
Description: The OABRequestHandler has begun downloading the OAB 9cc998e8-6226-4b60-957c-0125f8eabb57 from the server red-mbx-01.contoso.com.

Event ID: 103
Source: MSExchange OABRequestHandler
Description: The OABRequestHandler has finished downloading the OAB 9cc998e8-6226-4b60-957c-0125f8eabb57.

The OABRequestHandler will make up to three subsequent attempts to copy the OAB files from the Mailbox server where the master OAB generation mailbox is located. If all three attempts fail, the OABRequestHandler will retry the transfer after one hour.

Event ID: 104
Source: MSExchange OABRequestHandler
Description: Download of the OAB 9cc998e8-6226-4b60-957c-0125f8eabb57 failed. The job will be re-submitted. The error was: BG_ERROR_CONTEXT=BE_ERROR_CONTEXT_REMOTE_FILE; error code=0x80190194

Event ID: 105
Source: MSExchange OABRequestHandler
Description: Download of the OAB 9cc998e8-6226-4b60-957c-0125f8eabb57 has failed too many times. The job will not be resubmitted for the next hour.

What happens if I enable shadow distribution for an OAB, but there is no OAB generation mailbox in the site where the user is located?

When shadow distribution is enabled, Autodiscover will return the OAB URL for the site from which the user request initiated. If there is no OAB generation mailbox within that site, then CAS will simply proxy the request back to the Mailbox server hosting the OAB generation mailbox that is responsible for generating the OAB.

Summary

Shadow distribution completes our work on improving the OAB capabilities in the on-premises product and hopefully satisfies the requests from our customers that deploy distributed messaging environments. As always, we welcome your feedback.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Today, we released updated versions of both the Exchange 2010 Server Role Requirements Calculator and the Exchange 2013 Server Role Requirements Calculator.

The Exchange 2010 version is an incremental update and only includes minor bug fixes. You can view what changes have been made, or download the update directly.

In addition to bug fixes, the Exchange 2013 version, on the other hand, includes new functionality.  In particular, the ability to define how many AutoReseed volumes you would like in your design and mailbox space modeling. You can view what changes have been made, or download the update directly.

Mailbox space modeling provides a visual graph that indicates the expected amount of time it will take to consume the send/receive prohibit quota assuming the message profile remains constant.  As you can see from the example below, if I start with a 2GB mailbox with a 200 message profile and allocate a 10GB quota (and assuming no deletes), I expect to consume that quota in roughly 22 months.  Hopefully, this feature will allow you to plan out storage allocation more appropriately moving forward.

As always, we welcome your feedback.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

This morning on The Official Microsoft Blog, we revealed more details about our unified technology event for event for enterprises in May. The event will be known as Microsoft Ignite. If you are one of the many MEC conference alumni this is the conference for you. Microsoft Ignite is for Exchange customers using Office 365 or Exchange Server on-premises. Register now to reserve your spot and we will see you in Chicago on May 4^th!

Shape the event | Join the YamJam

We are committed to making Microsoft Ignite an incredible and valuable event for all of us who are passionate about Exchange, Office, SharePoint, Lync, Project and Visio. We want your feedback to help shape plans for this event. Join us for a YamJam on the Office 365 Technical Network on Tuesday, October 21^st 9:00 am – 10:00 am PDT to ask questions about the event and to provide feedback on what you want to see there. For those unfamiliar with a YamJam, it is similar to a “TweetJam” on Twitter or an “Ask Me Anything (AMA)” on Reddit, except it takes place on Yammer.

How to participate:

1. Request access to the Office 365 Technical Network.
2. Join the Ignite Event group. You can find it by using the Browse Groups function or through the search bar.
3. Log in at 9:00 a.m. PDT on Tuesday, October 21^st to ask questions and provide feedback on what you want to see from the Microsoft Office Division at the conference.

We wanted to give you a heads up that depending on the version of Exchange you are running, there might be some impact to either names of time zones that are changing on October 26, or the way that actual meetings are displayed in affected time zones. Customers using our newer versions of Exchange, 2010 and 2013, can expect meetings to appear on calendars correctly (provided underlying operating systems have been updated). Customers who are running Exchange 2007 might see meetings displayed at wrong times.

We are committed to correct these inconsistencies in our December release wave.

Update 11/11/14: We have just announced that the November 2014 Exchange releases are being delayed by one month, to December. Please see this. We updated the above wording accordingly.

Please see KB article 3004235 for more information.

Nino Bilic