We wanted to let you know that we have released a Beta version of Microsoft Office 365 Best Practices Analyzer for Exchange Server 2013. You can download the bits and read more about the release here. While this Beta has been available for a little while, we have been updating the build once a month with more improvements.

A couple of notes on this release:

• This is a Beta (pre-release) release; we plan to make changes to the tool look and feel, as well as add many additional rules to the tool.
• In order to download the tool, you will need an Office 365 tenant or Azure Active Directory user id. This is because in the future, we plan to include some value-add features that will enable you to store some information in our service (for example, we could enable the running history of BPA reports etc.) Note though that even though login to Azure Active Directory is required to download the tool, you do not need to have an Office 365 tenant to use it. This release can be used by customers who have:
  • Exchange Server 2013 on-premises only
  • Exchange Server 2013 hybrid configuration
  • Office 365 customers who leverage Exchange Online exclusively
• For versions of Exchange earlier than Exchange 2013, please use the already released version of BPA.

We’d like to hear your feedback on this release. You are welcome to post comments here, but if you have specific BPA feedback, we’d like to get an email from you so we can get all the details we might need.

Nino Bilic

Update 11/14/13: We believe that we have resolved all of the related issues; if you still see problems with Remote Connectivity Analyzer, please send us feedback.

We’re having some technical issues with the Remote Connectivity Analyzer site, which is causing occasional errors when running tests.  Although we continue to monitor, please send us feedback using the tool if you're impacted.  While we can’t respond to each inquiry, this helps us measure the impact.  Sorry for the inconvenience; we're working hard to mitigate it! 

For status updates, you can follow us on Twitter @ExRCA

RCA Team

We’ve listened to your feedback for improving the on-premises and hybrid Exchange Server deployment experience, and we’re happy to announce the release of the new, consolidated Deployment Assistant!

The Exchange Server Deployment Assistant now combines all the on-premises and hybrid deployment scenarios from both the Exchange 2013 Deployment Assistant and the Exchange 2010 Deployment Assistant into a single tool. We’ve eliminated the need for the installation of Silverlight and provide guidance for all Exchange Server deployments in a true one-stop shop experience. We’ve also kept the same, convenient question-and-answer format to create a customized, step-by-step checklist with instructions to deploy Exchange 2013 or Exchange 2010.

Starting your Exchange deployment is familiar and convenient, no matter whether you’re deploying Exchange 2013 or Exchange 2010. Just select the one of the three basic deployment tracks: On-premises, Hybrid, or Cloud Only to get started, as shown in Figure 1.

Figure 1: The Exchange Server Deployment Assistant home page

After selecting your basic deployment track, you’ll be able to choose from either an Exchange 2013-based or Exchange 2010-based path for either on-premises or hybrid deployment scenarios. If you selected the Cloud Only scenario, the deployment path is the same for both Exchange 2013 and Exchange 2010 organizations and you’re on your way to getting started with an Exchange Online-only deployment.

Figure 2: Choose either the Exchange 2013 or Exchange 2010 deployment path

After you’ve chosen either the Exchange 2013 or Exchange 2010 deployment path (see Figure 2), you’ll answer a few questions about your deployment needs and you’re off to the races with your customized deployment checklist! For example, see Figure 3, which shows a checklist for an on-premises Exchange 2013 deployment.

Figure 3: Exchange 2013 on-premises deployment path

And, here’s some more good news! If you’ve bookmarked links to the Exchange 2013 and Exchange 2010 Deployment Assistants, there’s no action required to go to the new tool when using your bookmarks. You’ll be automatically redirected to the new tool when using the URL for the previous version of the Deployment Assistant.

We hope you enjoy the convenience of having all the Exchange 2013 and Exchange 2010 deployment scenario guidance in a single tool. We’d love your feedback and comments! Please feel free to leave a comment here, or send an email to edafdbk@microsoft.com directly or via the 'Feedback' link located in the header of every page of the Deployment Assistant.

Happy deploying!

The Deployment Assistant Team

Note: Part 2 of this series can be found here.

One of best troubleshooting tools for Exchange ActiveSync (EAS) is mailbox logging. This logging allows us to see the incoming request sent by the device and the outgoing response from the Exchange server. Exchange ActiveSync Mailbox Logging provides the steps for enabling ActiveSync mailbox logging and breaks down the components of the log. Here we're going to use one of these logs to analyze how a mobile device running an EAS client (for e.g. a Windows Phone) initializes a profile with Exchange and a few standard commands.

Provision

A device must be provisioned before it can synchronize with Exchange. The device sends the Provision command with the device settings contained within the request. The server response includes the security settings based on the ActiveSync mailbox policy associated with the mailbox. It is important to note now that there are two status codes for most ActiveSync requests. The HttpStatus code only provides the IIS response to the request, and a 200 response does not mean the request was successful. The second status code is for the ActiveSync command and varies depending on the command sent by the device. A status code of 1 is most commonly a success.

The following example shows the request and response from a Provision command:

The device sends another Provision command to complete the provisioning process.This request includes the policy key from the previous response. The following example shows the second Provision command sending the PolicyKey.

For more detailed analysis of EAS provisioning process & Policies, see Provisioning, Policies, Remote Wipe, and ABQ in Exchange ActiveSync on The Exchange Dev Blog.

FolderSync

Once the device is provisioned, it will send a FolderSync command to obtain the folder hierarchy of the mailbox. If you capture this FolderSync request in the ActiveSync mailbox log, you will have the folder name that correlates to the CollectionId values in future ActiveSync requests. Alternatively, see ActiveSync - Mapping a Collection ID to a Mailbox Folder to determine which folder the CollectionId represents. The following example shows the response from a FolderSync request:

Sync

After the EAS client has obtained the folder hierarchy of the mailbox from Exchange, it can begin to populate folders on the device . Windows Phone leverages a hangingSync request to retrieve data from these folder. We should however expect the first Sync request by this device to have an immediate response with new items for one or more folders. It is also important to notice the SyncKey sent by the device in this first request is 0. This is because the folders (have just been created on the device and) currently have no synchronization state. The response for each Sync request will include a new SyncKey value that the subsequent Sync request should send. The following example shows the request and response for a Sync command:

We will typically either see no status code or a status code of 1 in the response for a Sync request. Any other status code would require further investigation by reviewing the protocol document. A status code of 1 represents a successful Sync request and no status code simply means there were no changes within the heartbeat interval for the request.

Typically you will see items being added to the device in the Sync response. You can see detailed information including the sender and subject if verbose logging has been enabled on the CAS servers. The following example shows a response sending a new item to the Inbox:

ItemOperations

There are several uses for the ItemOperations command and one of the most common requests is for downloading an attachment onto the device. The request will contain the FileReference value for the attachment which can be seen in the Sync response if available. The following examples show two responses for the ItemOperations command. We can see the first response is a success and the server sending the attachment. However the second response throws an exception and has a different status code. Lookup this status code in the protocol documentfor more information on the exception.

Were you able to determine the issue? The exception within the ActiveSync mailbox log for this example does provide enough detail to know the attachment was too large. It is very important to know how to use the protocol document to look up status codes for the various ActiveSync commands.

Calendaring

Now that we have covered the most common command that will be found in the ActiveSync mailbox log (that is the Sync command), it is now time to dig a little bit deeper. One of the most common issues with ActiveSync devices is calendaring. Most ActiveSync users rely on their mobile device to have accurate calendar information so they do not miss an appointment. Calendar items can be added to a mailbox as either an appointment created by the mailbox or a meeting request sent by either the mailbox owner or another organizer.

We are going to review the life of an appointment as we find it within the ActiveSync mailbox log. This appointment will start as a meeting request sent by an organizer within the organization. The following example shows a Sync response where this appointment is first added to the device:

Here we can see the appointment has a unique ServerId value for this item on the device. We also know that the appointment is currently showing a status of tentative in the BusyStatus. This is the standard placeholder that Exchange creates in the calendar when a new meeting request is received. The following example shows the corresponding meeting request:

The complex part of this process begins when the user responds to the appointment on the device. This response results in several requests which include MeetingResponse, SendMail, MoveItems, and Sync commands. We are going to cover each of these steps to see how the commands impact the items on the device and within the mailbox.

The MeetingResponse command is in the first ActiveSync command sent by the device to accept, decline, or tentatively accept the meeting. This request does not sent the response to the organizer. The request includes the meeting request item within the Inbox the response is for while the response from the Exchange server also includes the appointment item. The following examples show the request and response for a MeetingResponse command:

The SendMail command is the response message sent back to the organizer. The following is an example of the request for a SendMail command:

The MoveItems command is sent by the device to move the meeting request item from the Inbox to the Deleted Items folder. The following example shows the request for a MoveItem command:

The Sync command is sent by the device to update the calendar item on the mailbox. This Sync request is sending a Change for the appointment to update this status from Tentative to Busy. The following example shows the request sending a change for the BusyStatus:

You may also notice another Sync command sent by the device and that the response includes an Add for the Sent Items folder. Here we are getting the meeting acceptance message from the Sent Items and adding in onto the device.

Meeting Updates

All that we just covered was the original meeting request being received by the device. That is the origin of the appointment for our example. Next we need to look at how this appointment changes as time moves forward. The next evolution in this appointment’s life is a when the organizer sends an update for a single instance of the series.

A change to a recurring appointment is called an exception and that is exactly what we will see in the ActiveSync mailbox log. The first part of the response shows us that we have a Change for an item and further down within that response we will see the exceptions. The following example shows our appointment receiving a change and the exception includes a new start time:

Wait. Our appointment has not stopped experiencing life changes. The organizer has decided to cancel an instance of this recurring appointment. The following example once again shows a change for our appointment but this time the exceptions have grown. This example was done intentionally so we can see how difficult it becomes to read these logs when an appointment has a large number of exceptions.

The good news is these exceptions are sent in the order in which they were made, so the last exception is the most recent. In our example above, the last exception shows this instance of the meeting has been canceled.

The focus has intentionally been on the Calendar item and its changes. However we cannot forget that with each change to the appointment the user also gets an updated meeting request. This means we will also see a Sync request that includes a response adding the meeting request to the Inbox. The following example shows the response adding the updated meeting request:

Just like the original meeting request for the series, the user has the ability to accept and decline the changes from the device. If you do not remember the process, don’t hesitate to jump back and take a second look. That is exactly what this article is intended to show.

SendMail

The last topic we are going to cover is sending a message from a Windows Phone device. There are two commands that we may see from an ActiveSync device when a user is sending a message. The Search command will be sent when a user types text into the To field and perform a search against the Global Address List. The following examples show a request and response for a Search command:

Then the device will send a SendMail command when the user hits the Send icon. Unless an error is encountered during this request there should be an empty response from the Exchange server. The following example shows a request for the SendMail command:

Conclusion

At this point you should have some understanding of how Exchange ActiveSync functions and what to look for in the ActiveSync mailbox log. Here are a few reminders:

• Whenever the device initiates a new item or change, the request from the device will contain this data. Whenever the change is made on the mailbox, the response from the Exchange server will contain the data.
• Windows Phone uses a hanging Sync command to wait for changes on the mailbox. This request contains a heartbeat interval which determines how long the server should wait before sending a response. A success will return a status code of 1 indicating there are changes. If there are no changes, then no status code is returned.
• An updated meeting contains all of the exceptions for that appointment and the last exception is the most recent.
• Accepting a meeting request on an EAS device is a complex process with multiple steps. It is recommended that you review this process if many users use their devices to accept meetings.
• Current versions of Exchange require a minimum search length of four characters before Exchange will perform the query.
• The SendMail command does not return a status code unless an error is encountered.

Jim Martin (EXCHANGE)

Update 11/5/2013: added a section on firewall rules to try.

Overview

When designing a site resilient Exchange Server solution, one of the required planning tasks is to determine how many transaction logs are generated on an hourly basis. This helps figure out how much bandwidth will be required when replicating database copies between sites, and what the effects will be of adding additional database copies to the solution. If designing an Exchange solution using the Exchange Server Role Requirements Calculator, the percent of logs generated per hour is an optional input field.

Previously, the most common method of collecting this data involved taking captures of the files in each log directory on a scheduled basis (using dir, Get-ChildItem, or CollectLogs.vbs). Although the log number could be extracted by looking at the names of the log files, there was a lot of manual work involved in figuring out the highest the log generation from each capture, and getting rid of duplicate entries. Once cleaned up, the data still had to be analyzed manually using a spreadsheet or a calculator. Trying to gather data across multiple servers and databases further complicated matters.

To improve upon this situation, I decided to write an all-in-one script that could collect transaction log statistics, and analyze them after collection. The script is called GetTransactionLogStats.ps1. It has two modes: Gather and Analyze. Gather mode is designed to be run on an hourly basis, on the top of the hour. When run, it will take a single set of snapshots of the current log generation number for all configured databases. These snapshots will be sent, along with the time the snapshots were taken, to an output file, LogStats.csv. Each subsequent time the script is run in Gather mode, another set of snapshots will be appended to the file. Analyze mode is used to process the snapshots that were taken in Gather mode, and should be run after a sufficient amount of snapshots have been collected (at least 2 weeks of data is recommended). When run, it compares the log generation number in each snapshot to the previous snapshot to determine how many logs were created during that period.

Script Features

Less Data to Collect

Instead of looking at the files within log directories, the script uses Perfmon to get the current log file generation number for a specific database or storage group. This number, along with the time it was obtained, is the only information kept in the output log file, LogStats.csv. The performance counters that are used are as follows:

Exchange 2013:

MSExchangeIS HA Active Database\Current Log Generation Number

Exchange 2007/2010:

MSExchange Database ==> Instances\Log File Current Generation

Note: The counter used for Exchange 2013 only contains the active databases on that server. The counter used for Exchange 2007/2010 contains all databases on that server, including passive copies. To only get data from active databases on an Exchange 2007/2010 server, make sure to manually specify the databases for that server in the TargetServers.txt file.

Multi Server/Database Support

The script takes a simple input file, TargetServers.txt, where each line in the file specifies the server, or server and databases to process. If you want to get statistics for all databases on a server, only the server name is necessary. If you want to only get a subset of databases on a server (for instance if you wanted to omit secondary copies on an Exchange 2007 and 2010 server), then you can specify the server name, followed by each database you want to process.

Built In Analysis Capability

The script has the ability to analyze the output log file, LogStats.csv, which was created when run in Gather mode. It does a number of common calculations for you, but also leaves the original data in case any other calculations need to be done. Output from running in Analyze mode is sent to multiple .CSV files, where one file is created for each database, and one more file is created containing the average statistics for all analyzed databases. The following columns are added to the CSV files:

• Hour: The hour that log stats are being gathered for. Can be between 0 – 23.
• TotalLogsCreated: The total number of logs created during that hour for all days present in LogStats.csv.
• TotalSampleIntervalSeconds: The total number of seconds between each valid pair of samples for that hour. Because the script gathers Perfmon data over the network, the sample interval may not always be exactly one hour.
• NumberOfSamples: The number of times that the log generation was sampled for the given hour.
• AverageSample: The average number of logs generated for that hour, regardless of sample interval size. Formula: TotalLogsCreated / NumberOfSamples.
• PercentDailyUsage: The percent of a full days’ worth of logs that the AverageSample value for that hour accounts for. Formula: (AverageSample / AverageNumberOfLogsPer24Hours) * 100.
• AverageSamplePer60Minutes: Similar to AverageSample, but adjusts the value like each sample was taken exactly 60 minutes apart. Formula: (TotalLogsCreated / TotalSampleIntervalSeconds) * 3600 * 24.
• PercentDailyUsagePer60Minutes: Similar to PercentDailyUsage, but adjusts the value like each sample was taken exactly 60 minutes apart. (AverageSamplePer60Minutes / AverageNumberOfLogsPer24Hours) * 100.

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 TargetServers.txt and 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.
• -MaxSampleIntervalVariance: The maximum number of minutes that the duration between two samples can vary from 60. If we are past this amount, the sample will be discarded. Defaults to a value of 10.
• -MaxMinutesPastTheHour: How many minutes past the top of the hour a sample can be taken. Samples past this amount will be discarded. Defaults to a value of 15.
• -MonitoringExchange2013: Whether there are Exchange 2013 servers configured in TargetServers.txt. Defaults to $true. If there are no 2013 servers being monitored, set this to $false to increase performance.

Usage

Run the script in Gather mode, taking a single snapshot of the current log generation of all configured databases:

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

Run the script in Gather mode, and indicates that no Exchange 2013 servers are configured in TargetServers.txt:

PS C:\> .\GetTransactionLogStats.ps1 -Gather -MonitoringExchange2013 $false

Run the script in Gather mode, and changes the directory where TargetServers.txt is located, and where LogStats.csv will be written to:

PS C:\> .\GetTransactionLogStats.ps1 -Gather -WorkingDirectory "C:\GetTransactionLogStats" -ResetStats

Run the script in Analyze mode:

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

Run the script in Analyze mode, sending the output files for the analysis to a different directory. Specifies that only sample durations between 55-65 minutes are valid, and that each sample can be taken a maximum of 10 minutes past the hour before being discarded:

PS C:\> .\GetTransactionLogStats.ps1 -Analyze -LogDirectoryOut "C:\GetTransactionLogStats\LogsOut" -MaxSampleIntervalVariance 5 -MaxMinutesPastTheHour 10

Example TargetServers.txt

The following example shows what the TargetServers.txt input file should look like. For the server1 and server3 lines, no databases are specified, which means that all databases on the server will be sampled. For the server2 and server4 lines, we will only sample the specified databases on those servers. Note that no quotes are necessary for databases with spaces in their names.

Output File After Running in Gather Mode

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 File After Running in Analyze Mode

The following shows the analysis for a single database after running the script in Analyze mode:

Notes

By default, the Windows Firewall on an Exchange 2013 server running on Windows Server 2012 does not allow remote Perfmon access. I suspect this is also the case with Exchange 2013 running on Windows Server 2008 R2, but haven’t tested. If either of the below errors are logged, you may need to open the Windows Firewall on these servers to allow access from the computer running the script.

ERROR: Failed to read perfmon counter from server SERVERNAME

ERROR: Failed to get perfmon counters from server SERVERNAME

Update:

After noticing that multiple people were having issues getting this to work through the Windows Firewall, I tried enabling different combinations of built in firewall rules until I could figure out which ones were required. I only tested on an Exchange 2013 server running on Windows Server 2012, but this should apply to other Windows versions as well. The rules I had to enable were:

File and Printer Sharing (NB-Datagram-In)
File and Printer Sharing (NB-Name-In)
File and Printer Sharing (NB-Session-In)

Mike Hendrickson

Office 365 Service Descriptions provide comprehensive details about features and functionality available in different Office 365 subscription plans.

Now there’s a quick way to compare features in different plans. The Office 365 service descriptions Excel web part allows you to select a service or on-premises scenario, select the specific Office 365 service (e.g. Exchange Online, SharePoint Online, Lync Online), and an Office 365 plan to see the features available in the selected plan.

Let us know what you think!

Exchange Team

Based on the feedback I received it looks like our readers enjoyed the previous set of articles (Part 1, Part 2, and Part 3) that were published about IIS ARR and because of that, the pirates Arrr!!! back with another article on how to use IIS ARR for O365 Exchange Online Hybrid configurations.

We have many customers who are running Hybrid with O365 today or are planning to sign up to O365 and coexist in a Hybrid configuration, and this article was written to help those customers effectively use or plan for IIS ARR as a Reverse Proxy solution.

As you may or may not know, if you use TMG in a hybrid configuration with Exchange Online, it is not supported to have TMG performing any pre-authentication against ADFS, Exchange Web Services (EWS) or AutoDiscover. So, when you are in an Exchange Hybrid Configuration, out of a total of five services we can only perform pre-authentication against two of available services (Outlook Anywhere and OWA), and this is not even considering the web traffic for Lync on-premises and Lync Online, which should not be pre-authenticated either.

When you look at it like this, if you read the previous articles that describe what IIS ARR offers, these limitations should lead you to conclude that IIS ARR is a great solution as it can provide both Reverse Proxy and L7 Load Balancing capabilities for your O365 Hybrid Configuration.

When an organization is setup as an Exchange Hybrid we can break down the traffic into two types ie: Inbound Traffic and Outbound Traffic. We are going to use these terms to explain how to control these two types of traffic in a Hybrid Scenario.

Illustration of the setup:

Inbound Traffic (Internet/O365 –> On-Premises)

When we refer to Inbound Exchange Traffic, from the Internet to on-premises, it usually means traffic for the usual Exchange clients such as Outlook Anywhere, EAS, OWA and EWS (users whose mailboxes are still on-premises). However in Hybrid scenarios we have additional requests for the Security Token Service (STS), or ADFS Proxy Servers by another name. Hence when configuring IIS ARR for inbound traffic we have to make sure that we add the necessary configuration required for the STS.

STEP1: Follow the earlier articles (here, here and here) which explain how to create the Web Farms and their corresponding URL Rewrite rules for the Exchange Services (Outlook Anywhere, OWA, EAS, AutoDiscover etc). For this example I have chosen the simplest implementation described in the previous blog posts (Option1) for the Exchange traffic.

STEP2: Create a new Web Farm for your STS endpoints (sts.roopdemo.co.uk in my example) and add each of your ADFS Proxy servers. This assumes that you have not setup any network load balancing between the ADFS Proxy servers, which is fine because we’ll be making use of IIS ARR’s load balancing capabilities to achieve load balancing and high availability of the ADFS Proxy servers.

STEP3: Configure the properties of the Web Farm (sts.roopdemo.co.uk)

1. Caching–> Disable Disk Cache
2. Health Test: There is no Health Check URL for ADFS and thus we need to create one so that IIS ARR can test for service availability of the ADFS service and make appropriate decisions in the event of a failure.
   1. Log on to one of the ADFS Proxy servers and create a HealthCheck.txt file on the ADFS Proxy server (in my example I do this at the root of the web site).
      1. On the ADFS Proxy server, open IIS Manager –> Default Web Site –> Explore

      2. Create a text file named HealthCheck.txt with the word Healthy in it.
      3. Repeat the above steps on all the ADFS Proxy servers.
   2. To verify that the HealthCheck.txt file renders properly, open the file in a Web browser.

   3. Once this is working, in IIS Manager expand the server node and select the sts.roopdemo.co.uk server farm.
   4. In the Server Farm pane, double-click Health Test.
   5. On the Health Test page, enter the following details:

      Make sure you enter the Healthy in the Response match box (response match is an optional test that searches the body of a response and looks for an expected string. Since the HealthCheck.txt file contains the word “Healthy,” the response match test will look for the word “Healthy”).

   6. Click Apply and hit “Verify URL Test” (it should come back with a Pass).
3. Load Balance–> Choose “Least current request”. Here we are making use of IIS ARR’s L7 load balancing capabilities, to effectively load balance the ADFS traffic between the ADFS Proxy servers.
4. Proxy–> Change the below two values. The actual value for these settings may need to be tweaked for your deployment, but these usually work well for a start.
   1. Time-Out: 300 seconds
   2. Response Buffer threshold: 0
5. Routing Rules - Uncheck “Enable SSL Offloading”.
6. Server Affinity - No changes required.

STEP4: Edit the URL rewrite rule.

1. You should see two URL Rewrite rules created (these were created when you selected “Yes” at the end of Server Farm creation)
2. Delete the one for HTTP(as shown below).

3. Open the properties of the newly created STS URL Rewrite Rule and make the changes shown below.

   Under Action:

In the end you should be left with something that looks similar to this;

Outbound Traffic (On-Premises –> O365)

When your organization is in a Hybrid configuration there is of course web traffic flowing from your on-premises environment to the O365 services and this traffic needs to be controlled. Most organizations don’t allow traffic that is destined to the internet, go directly out from the end-users workstation. Instead all internet based traffic would be first sent to a Web Proxy (installed on-premises) where some form of filtering would take place (based on corporate policy) and only then would the requested page/content on the internet be accessible. Thus keeping this situation in mind we are going to use the IIS ARR server to filter or allow only traffic to O365 URL’s.

By performing the below steps we are going to configure IIS ARR as a Forward proxy for all the Outbound traffic.

We’ll not be creating any Web Farms here, as all this traffic is going outbound. However we’ll be creating various URL Rewrite Rules to control what requests/web queries are being sent externally.

Follow the below steps;

STEP1: Create URL Rewrite rules for each of the O365 services.

1. In IIS Manager –> Server object –> URL Rewrite à Add Rule(s)
2. Select, Inbound Rules –> Blank Rule
3. Name –> O365_General_URLs (you can give it any name you like)
4. Pattern –> *
5. Conditions
   1. Logical Grouping –> Match Any
   2. Click, Add and enter a {HTTP_HOST} for every URLs/FQDNs from the below link.

      Office 365 URLs and IP address ranges

      http://onlinehelp.microsoft.com/Office365-enterprises/hh373144.aspx

      Note: Under Logical Grouping make sure you select Match Any.

   3. Under Action add the values as shown below.

      What we are doing above is providing back-references to the Rewrite URL. Back-references to Condition Patterns are identified by {C:N} where N is from 0 to 9; back-references to Rule Pattern are identified by {R:N} where N is from 0 to 9. Note that for both types of back-references, {R:0} and {C:0}, will contain the matched string.

      So for example, if any user tries to access https://portal.onmicrosoft.com/login , then the URL is broken down as shown below.

      {C:0} –> portal.onmicrosoft.com

      {R:0} –> login

      This is then evaluated by IIS ARR against the “Match URL” and “Conditions”. If it passes both, then it is rewritten as https://{C:0}/{R:0}, which is effectively the same URL. As we have many conditions to match against, using back-references (which is nothing but a variable) we can easily check to see if a URL is allowed and take the appropriate action i.e.: block it or forward it as is.

   4. You should now have a URL Rewrite Rule which should look like the below.

       

STEP2: Now repeat the process to add the Exchange Online URL’s. Note that the exceptions for Exchange Online have already been listed in the O365_General_URLs. However you can create this URL Rewrite Rule for ease of management purposes i.e.: if there were any new URL’s in the future for Exchange Online then all you need to do is add those new URL’s to this URL Rewrite rule.

STEP3 (Optional): If your organization also has Lync Online then create a URL Rewrite Rule and repeat the above process to add the exceptions.

So in the end you should see something similar. In my lab I have also configured Lync Online and thus you would see additional web services like meet.roopdemo.co.uk, dialin.roopdemo.co.uk etc.

Components involved in Inbound Web Traffic:

Components involved in Outbound Web Traffic:

That is it!!!.....you now have a solution that you can be used for your O365 Exchange Online Hybrid configurations.

Additional Information 1

If you want to lock down the protocols allowed by IIS ARR within a single URL Rewrite rule then you can write a Regular Expression as below. This is a much better control of the web request that are being forwarded to the CAS servers, as opposed to a wildcard (*). In the example below, within my URL Rewrite Rule for mail.roopdemo.co.uk, I have added the below Pattern which would thus only allow the below mentioned protocols/services.

Additional Information 2 – Bonus Time!

Recommendations for sizing the IIS ARR servers:

There is currently no specific guidance published for sizing of IIS ARR servers, however you can use the sizing guidance for the TMG servers as a starting point. The IIS ARR servers are only performing URL Filtering and thus the guidance shown below should be ideal.

In summary, we have seen that IIS ARR server (or server farm) can act as the ingress and egress point for all your O365 Hybrid web traffic. This thus makes IIS ARR act like a traffic controllerfor all the corresponding traffic and hence provides a better management experience for the admins. For all inbound traffic, IIS ARR provides a great Reverse Proxy solution, but it also natively provides a L7 load balancing solution. So you don’t have to invest in 3^rd party HLB’s and in effect reduce the total overall cost of implementing an O365 Hybrid solution.

My heartiest thanks to Greg Taylor (Principal PM Lead) for his help with reviewing this article.

Good luck and feel free to post comments and questions if you have them.

Roop Sankar Bagepalli
Senior Premier Field Engineer, UK

Windows 8.1 and Windows RT include a built-in email app named Windows Mail. Mail includes support for IMAP and Exchange ActiveSync (EAS) accounts.

This article includes some key technical details of Windows Mail in Windows 8.1. (See Supporting Windows 8 Mail in your organization for Windows 8.0.) Use the information to help you support the use of Mail in your organization. Read this article start to finish, or jump to the topic that interests you. Use the reference links throughout the article for more information.

NOTEMail, Calendar, and People apps run on Windows 8.1 and Windows RT. Although this article discusses the Mail app, please note that much of the information in this article also applies to the Calendar, and People apps. When connected to a server that supports Exchange ActiveSync, the Calendar, and People apps may also display data that was downloaded over the Exchange ActiveSync connection.

Protocol Support

Mail lets users connect to any service provider that supports either of the following two protocols:

Post Office Protocol (POP) is not supported.

NOTE All Windows Communications apps (Mail, Calendar, and People) can use the data that is synchronized using Exchange ActiveSync. After a user connects to their account in the Mail app, their contacts and calendar data is available in the other Windows Communications Apps and vice versa.

Sync Configuration

Mail can be configured to synchronize data at different times as follows:

• Push email (default)
• Polling at fixed intervals
• Manually

If a push email connection can’t be established, it will automatically switch to poll at fixed intervals.

Push Email

Push email requires that accounts are either Exchange ActiveSync (which all support Push) or IMAP with the IDLE extension. Not all IMAP servers support IDLE, and it is supported only for the Inbox folder.

When a push connection can’t be established, Mail will change to polling on 30 minute intervals. Push email on Exchange ActiveSync requires that HTTP connections must be maintained for up to 60 minutes, and IMAP IDLE requires TCP connections to be maintained for up to 30 minutes.

Account Setup Features

Windows 8.1 and Windows RT users can add email accounts to Mail using the Settings charm. The Settings charm is always available on the right side of the Windows 8.1 and Windows RT screen. (For more visual details about Charms & the Windows 8.1 user interface, see Search, share, print & more.)

NOTE This section provides an overview of account setup in Mail. For step-by-step procedures for setting up an account, see What else do I need to know? at the end of this guide.

To make it as easy as possible to add accounts, account setup only prompts the user to enter the email address and password for the account they want to set up. From that data, Mail attempts to automatically configure the account as follows:

1. The domain portion of the email address is matched against a database of well-known service providers (such as Outlook.com). If it’s a match, its settings are automatically configured.
2. The domain portion of the email address is used to discover the user's email settings using the Autodiscover.
3. If automatic configuration fails, the user is prompted for additional details such as an email server name and domain name.

Add an Exchange ActiveSync account

Figure 1: Exchange ActiveSync (EAS) configuration in Windows Mail

If automatic configuration fails, the following additional information is required to connect to a server via Exchange ActiveSync:

• Server address
• Domain
• Username

Add an IMAP/SMTP account

Figure 2: IMAP/SMTP configuration in Windows Mail

The information required to connect to a server via IMAP/SMTP is:

• Email address
• Username
• Password
• IMAP email server
• IMAP SSL (if your IMAP server requires SSL encryption)
• IMAP port
• SMTP email server
• SMTP SSL (if your SMTP server requires SSL encryption)
• SMTP port
• Whether SMTP server requires authentication
• Whether SMTP uses the same credentials as IMAP (If not, user must also provide SMTP credentials)

Security Features

Mail provides administrators with some level of security through Exchange ActiveSync policies (Mobile Device Mailbox Policies in Exchange 2013). It doesn’t support any means of managing or securing PCs that are connected via IMAP. EAS includes support for certificate-based authentication and remote wipe.

Exchange ActiveSync Policy Support

Exchange ActiveSync devices can be managed using Exchange ActiveSync policies. Mail supports the following EAS policies. :

• Password required
• Allow simple password
• Minimum password length (to a maximum of 8 characters)
• Number of complex characters in password (to a maximum of 2 characters)
• Password history
• Password expiration
• Device encryption required (on Windows RT and editions of Windows that support BitLocker. See What's New in BitLocker for details about BitLocker improvements in Windows 8.1.)
• Maximum number of failed attempts to unlock device
• Maximum time of inactivity before locking

Important If AllowNonProvisionableDevices is set to false in an EAS policy and the policy contains settings that are not part of this list, the device won’t be able to connect to the Exchange server.

Getting into Compliance

Most of the policies listed above can be automatically enabled by Mail, but there are certain cases where the user has to take action first. These are:

• Server requires device encryption:
  • User has a device that supports BitLocker but BitLocker isn’t enabled. User must manually enable BitLocker.
  • User has a Windows RT device that supports device encryption but it is suspended. User must reboot.
  • User has a Windows RT device that supports device encryption, but it isn’t enabled. User must sign into Windows with a Microsoft account.
• An admin on this PC doesn’t have a strong password: All admin accounts must have a strong password before continuing.
• The user’s account doesn’t have a strong password: User must set a strong password before continuing.

Certificate-Based Authentication

Communications applications can connect to a corporate Exchange service configured to require certificate-based authentication. User authentication certificates can be provisioned to Windows 8.1 devices by administrators or end-users can browse to certificate and install to user certificate storage.

User can add and connect an email account using a certificate. (For account setup, password entry is required per standard account setup.) User may be prompted to give the Mail application permission to access their user certificate, and should accept the prompt to enable certificate usage. In cases where multiple certificates are available, the user can go to account Settings to select the desired certificate.

Non-PIN protected software certificates are supported.

Remote Wipe

Mail supports the Exchange ActiveSync remote wipe directive, but unlike Windows Phone (which deletes all data on the device), Mail scopes the data deleted to the specified Exchange ActiveSync account for which the remote wipe command is issued. The user's personal data is not deleted. Additionally, attachments saved from that account are made inaccessible.

For example, if a user has an Outlook.com account for personal use and a Contoso.com account for work use, a remote wipe directive from the Contoso.com server would impact Windows 8.1 and Windows Phone 7 as follows:

Account Roaming

To make it as easy as possible for users to have all of their accounts set up on all of their devices, Windows 8.1 uploads vital account information to the user’s Microsoft account. This information includes email address, server, server settings, and password. When a user signs into a new PC with their Microsoft account, their email accounts are automatically set up for them.

Passwords are not uploaded from a PC for any accounts which are controlled by any Exchange ActiveSync policies. Users will have to enter their password to begin syncing a policy-controlled account on a new PC.

If using client certificate authentication, the client certificate, and the certificate selection for an account will not be roamed. Users will have to select their desired client certificate to begin syncing a client certificate account on a new PC.

Microsoft Accounts

By default, users are required to have a Microsoft account, formerly known as Windows Live ID, to use the Windows Communications apps. This will usually be the Microsoft account that the user is signed into Windows with, but if they have not done so, they will be prompted to provide one before proceeding.

Data Consumption

By default, Mail only downloads one month of email (up from 2 weeks in Windows 8.0). This is user configurable and can potentially download the user’s entire mailbox. For Exchange ActiveSync accounts, all contacts are downloaded and calendar events are downloaded only for three months behind the current date and 18 months ahead.

Additionally, messages can be only partially downloaded to reduce bandwidth use as follows:

Embedded images in email messages are downloaded on-demand as the user reads them, and attachments which are not downloaded can be downloaded on-demand as the user attempts to open them.

Mail downloads all folders for an account. Users can configure the period of email which is downloaded to adjust the size of data for an account. Mail does not enforce any limits on number and size of attachments users can send.

Automatic Replies

Mail allows users to view and set their automatic reply messages (aka Out of Office or OOF messages). There is a visual indication when auto-reply is enabled. Users can view and set automatic reply plain text content. For corporate accounts, separate internal and external auto-reply messages are supported.

There is no date/time support for specifying start or end time for automatic replies.

Enterprise Connectivity

Authenticated Proxies

The communications applications can connect over LAN or WiFi connections via authenticated proxies which use standard authentication methods including: NTLM, Digest, Negotiate, and Basic authentication.

Any user credentials entered can be cached for the session, or remembered persistently.

Self-Signed Certificates

The communications applications warn the user with a prompt providing an option to connect anyway when trying to connect to services with common service certificate issues. See Self-Signed Certificates in Limitations below for details and recommendations.

Limitations

The following features are currently not supported by Mail:

• Direct mailbox connections using POP: Only EAS and IMAP protocols are supported.

  Note This does not mean that Windows 8.1 does not support POP. This post is about the Mail app. See Using email accounts over POP on Windows 8.1 and Windows RT 8.1 for workarounds.

• Opaque-Signed and Encrypted S/MIME messages When S/MIME messages are received in Mail, it displays an email item with a message body that begins with “This encrypted message can’t be displayed.”

  To view email items in the S/MIME format, users must open the message using Outlook Web App, Microsoft Outlook, or another email program that supports S/MIME messages. For more information, see Opaque-Signed and Encrypted S/MIME Message on MSDN.

Self-Signed Certificates in Windows Mail 8.1

Users may experience connectivity errors when trying to connect to an Exchange server that uses a self-signed certificate or a certificate with other common issues. The user may receive the following error message.

There’s a problem with a server’s security certificate. It might not be safe to connect to the server because… <details>.

You can use one of the following options to resolve this issue.

At the prompt, users can connect anyway to ignore common service certificate issues such as self-signed certificates, allowing the communications applications to use an encrypted connection to the email service with the certificate issue. If users choose to connect anyway and ignore the service certificate issues, their selection will be remembered, (can be viewed and changed any time via Settings for account).

We recommend that users select Cancel when they receive a certificate-related error and contact the administrator to fix the issue (option 1).

See Digital Certificates and SSL for more information.

Troubleshooting Mail Client Connectivity

If a Mail user can't successfully connect to an account, consider the following:

• Verify that the user is using the latest version of the Mail app. A user can check for updates to the Mail app by doing the following: from the Start screen, go to Store> Settings> App updates> Check for updates.
• To rule out any transient issues, the user can wait a few minutes and try again.
• Some cloud-based email services (for example, Microsoft Office 365) require that the user register their account before they can use email clients such as Mail. Office 365 users register their account when they sign in to the service for the first time. If the user is not an Office 365 user, the user registers their account when they sign in to their account using their Microsoft account or sign in to Outlook Web App. The user must sign out of Outlook Web App before they try to connect using Mail again.

TIP The user will see the following message if they haven't registered their account: “We couldn’t find the settings for. Provide us with more info and we’ll try connecting again.”

What else do I need to know?

• Set up your Office 365 or Exchange-based email in Windows 8 Mail
• Mail app for Windows: FAQs
• 2784275 How to configure an Exchange account and how to troubleshoot Exchange account connectivity issues in the Mail app in Windows 8 and Windows RT
• 2792112 80070057 error, and Windows Phone 8 cannot sync with Microsoft Exchange
• 2464593 Error 85010013, 8600C2B, or 86000C29 when you try to synchronize a Windows Phone-based device to an Exchange server
• You may also find Building the Mail app and Right from the Start: Delivering the best email experience on any tablet with Windows 8.1 on the Building Windows 8 blog of interest.

Updates

• 10/21/2013: Added note about Windows 8.x picture passwords and Exchange ActiveSync policies.
• 10/21/2013: Added link to Using email accounts over POP on Windows 8.1 and Windows RT 8.1.

I continue to run into this issue over and over in the field so I wanted people to be aware of this possible problem. In a Database Availability Group (DAG), if your databases are randomly mounting or flipping from one server to another, for no apparent reason (including across datacenters) you may be suffering from your network interface card (NIC) going to sleep. And that’s not a good thing.

Power Management on the NIC

In the power management settings for the NIC on Windows Server, make sure you are not allowing the NIC to go into power save mode. Why is this important? It seems like at least once a month I’ve run into customers who have this power management setting turned on and more than one of them even had it turned on for their replication network. They were seeing some odd behavior - for example, their databases randomly flipping from one DAG node to another for no apparent reason. And yes, they were all on physical machines.

Here are the steps to look at this configuration: use Device Manager to change the power management settings for a network adapter.

To disable all Power Management settings in Device Manager, expand Network Adapters, right-click the adapter > Properties> Power Management, and then clear the Allow the computer to turn off this device to save power check box.

Figure 1: Disable power management for the network adapter from the Power Management tab

Some of your network adapters may not have the Power Management tab available. This is a good thing, as your NIC is not able to go to sleep. This means there is one less item to worry about in your setup!

CAUTION Be careful when you change this setting. If it's enabled and you decide to disable it, you must plan for this modification as it will likely interrupt network traffic. It may seem odd that by just making a seemingly non-impacting change that the NIC will reset itself, but it definitely can. Trust me; I had a customer ‘test’ this during the day by accident… oops!

PowerShell to the rescue

In addition, now that PowerShell is able to be used for just about everything, there is this page that has a PS script available to make this change. There are additional links and related forum threads to review with supplementary information near the bottom of the script download page.

This modifying script will run against all physical adapters to the machines you deploy it to, and you can also modify the script to disable wireless NIC’s. With PS, don’t forget that you can use this script to blast down these changes to all of your Exchange servers with a single step.

GPO and regedit

For those of you that are more comfortable with regedit and creating GPO’s to help control these settings, that option is also available. This page has information on both ‘one off’ fixes that you can download a .reg file and manually deploy, or using GPO Preferences, you can edit the values in a GPO and apply those changes to an Exchange Server OU (Organizational Unit).

The one step to note with the regedit process is which NIC you are working with and how many NIC’s your server has. The registry only knows of the first, second, third, etc. number of NIC’s. Now if you have identical builds between all of your servers, then this option certainly will ensure that all current and any future servers placed into an OU with the GPO applied will adhere to the proper registry settings.

Also don’t forget, you can record all of your changes on a Windows Server 2008R2 or higher OS, by using the Problem Steps Recorder (PSR) tool.

There you have it: if your DAG Databases are randomly becoming active from one server to another with no apparent reason, you may have a sleepy NIC. Please confirm that you have avoided this setting as you build out not only your DAG environment, but all Exchange related servers. Thank you.

Mike O'Neill

Microsoft Office Content Publishing is now producing guidance on cross-product solutions involving Exchange Server 2013, SharePoint 2013, Lync Server 2013, Office 365, and Windows Azure. Our goal is to help our customers solve bigger business problems than could be solved through any of these products individually.

We have some ideas regarding what solutions to get started on but we need your input to find out if these are the right ones and what other ones we should do.

We are forming a Solutions Advisory Board (SAB) consisting of customers, Microsoft Most Valuable Professionals (MVPs), and people in various roles inside of Microsoft. The SAB will:

• Send out newsletters on a regular basis about upcoming solutions, and suggestions for new ones.
• Host regular online meetings in which:
• Microsoft presents ideas for solutions to the group and collects your feedback
• Microsoft opens the floor to SAB members to present their requests for solutions
• SAB members can showcase their own solutions (and businesses) to the SAB
• Send out an annual survey for the members to complete

If you would like to participate in the discussion around solutions that use any combination of Exchange 2013, SharePoint 2013, Lync Server 2013, Office 365, or Windows Azure, we invite you to join this new group.

Please contact us at sab@microsoft.com to join.

Office Solutions Content Team

We have received consistent feedback from our customers that the ability to reject messages for invalid recipients at the service network perimeter is important. We are aggressively working to design a solution that will make Directory Based Edge Blocking (DBEB) available within Exchange Online Protection (EOP).  This functionality is targeted to be added to the service in the first quarter of 2014.

In the meantime, here are some suggested configurations to help customers who want this type of capability until the service is able to offer recipient validation:  

• Enabling Recipient filteringon-premises on your Exchange servers.  This is the recommended solution until the EOP functionality is available. This essentially adds one step to the process of communications.  EOP will communicate with your Exchange servers and then Exchange recipient filtering can handle as configured:  
  • Customer Concern:  Increased load on on-premises servers?
  • Microsoft response:  Impact to the customer’s servers should be minimal. The Recipient Validation feature will reject recipients after the RCPT TO:  command within the SMTP conversation well before accepting the message into the org.  Because of this the resources expended are very minimal and the cost of NDR generation is on the EOP side which will result in minimal impact to your on-premises servers.
• Transport rules can be used to mimic the behavior as well, and would have to be tested to each customers' desired configuration.

Wendy Wilkes
Senior Program Manager
Office 365 Customer Experience

Updated 11/21/2013 to include the target release timeframe.

In the last related blog post we discussed recovering public folders and its contents from dumpster when they are deleted and various recovery steps using the Outlook client and Exchange Management Shell. In this blog we will be moving further and discussing some more advanced recovery scenarios.

Recovering a deleted public folder mailbox

Secondary Hierarchy mailboxes

Secondary hierarchy mailboxes contain public folder content as well as read-only copy of the public folder hierarchy. At mailbox creation, each public folder mailbox gets associated with its own disabled active directory user account. Those user accounts should never be deleted or modified! When deletion happens though, access to public folders in that content mailbox will get disrupted. The affected public folders will still be seen in the public folder hierarchy, but they might not be accessible since the mailbox holding the folder content is unavailable.

To understand this better let’s consider a scenario where active directory user account which is associated with the Secondary public folder hierarchy mailbox gets mistakenly deleted and it needs to be recovered. The name of the secondary public folder mailbox is calledPF-2and its associated disabled user account is now gone. The associated mailbox will be available in the associated database in disabled state till the retention period expires. During that time, public folders which are hosted on the disconnected secondary public folder mailbox will still show up in Outlook because they are still present in the hierarchy. The associated mailbox content information will be unavailable for the folders associated with the affected public folder content mailbox in Exchange Admin Center as illustrated here:

In order to perform recovery for such types of issues, you will need to create a new disabled user account and reconnect the disconnected public folder content mailbox by connecting to the new created account using Connect-Mailbox.

To view the disabled mailboxes run the command:

Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisconnectReason -eq "Disabled" } | ft DisplayName,Database,DisconnectDate,DisconnectReason,*type*

If the public folder content mailbox is not listed in the disabled state but you know the account is missing, you need to force the cleanup on the store by running the below command:

Get-MailboxStatistics -Database “Database name“ | ForEach { Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$false }

Note: Update-StoreMailboxState is the Exchange 2013 replacement for the Clean-MailboxDatabase in previous versions. When running this command, make sure you have proper retention settings in place or else you might end up purging disconnected mailboxes that you did not intend to purge!

As mentioned earlier, create a new user account with same name (like the mailbox, to keep things simpler) or, if the account has been recovered through some sort of AD recovery process, we can simply reconnect the mailbox to it. By creating account with same name the Connect-mailbox will automatically try to connect to the matching user.

Connect the mailbox using the Exchange Admin Center or Exchange Management Shellas described in the article Connect a Disabled Mailbox.

Once the mailbox is connected, the public folder should automatically start serving the contents.

Things to note about mail enabled public folders:

• If the disconnected mailbox contained mail-enabled public folders, mail delivery to those folders will stop working once the content mailbox is connected with the new account. A sample of the error you might see:
• To get the mail enabled public folders working they have to be mail-disabled and mail-enabled again. Ref : Mail-Enable or Mail-Disable a Public Folder
• If the mail enabled public folders had some custom SMTP addresses configured they might be lost by the process of mail disabling and re-enabling. Make sure you export the details of PrimarySMTPAddress for the required mail enabled public folders and then add the custom address back to the required public folders.

Recovery of Secondary mailbox when it gets deleted from Store.

Note: Under usual circumstances, it is not possible to disable a public folder mailbox which is hosting the folders by using the Disable-Mailbox CMDLet. The associated folders and contents needs to be migrated to a different public folder mailbox prior to disabling it.

Let’s consider a scenario where a secondary public folder mailbox which contained a set of public folders with data has been deleted. In order to recover public folder data in such types of scenarios your only option is to restore the last full good backup for the affected mailbox.

Once the restore is completed using the recovery database, run the following CMDLet to see which mailboxes are available for recovery:

Get-MailboxStatistics –Database “Name of Recovery database”

To view a set of public folders which are orphaned in the organization run the command:

Get-PublicFolder –Recurse | Where { $_.ContentMailboxName –eq ‘’ }

Note: Before you begin with the restore process, you need to set the orphaned public folders to an active public folder content mailbox. You can create a public folder mailbox with same old name (you can get the mailbox name from the restored database by running Get-mailboxstatistics) and set the public folders to point to newly created mailbox. This can be done by executing the command:

Set-PublicFolder –Identity “\Name of the public folder” –OverrideContentmailbox “Name of the new content public folder mailbox”

If you skip above step and proceed further, the restore is going to fail since there is no target mailbox available to which data can be restored.

To set the mailbox for multiple orphaned public folders run the command:

Get-PublicFolder –Recurse | Where { $_.ContentMailboxName –eq ‘’ } | Set-PublicFolder –OverrideContentmailbox “Name of the content public folder mailbox”

Once the public folder has been pointed to an active public folder content mailbox, follow the method discussed earlier in the blog for merging the contents to required public folders from recovery database and that’s all. You should see the recovered contents in the recovered folders.

Note: In case you need to restore the contents from the entire public folder mailbox, do not use the –IncludeFolders switch. The restore process will restore the available data from recovery mailbox to all the available folders in the Target mailbox provided the folder structure is present. If you need to restore individual public folders, you can use the mentioned switch.

More information:

• Recovery Databases Exchange 2013
• Create a Recovery Database
• Restore Data Using a Recovery Database

Recover from loss of primary hierarchy mailbox

How to recover primary hierarchy public folder mailbox when the Active Directory account is deleted?

The primary hierarchy mailbox is pretty much the most important component when it comes to public folder hierarchy. The primary hierarchy mailbox is the one writable copy of the public folder hierarchy. The public folder hierarchy is copied to all other public folder mailboxes, but these will be read-only copies. If this mailbox is disconnected or is not accessible it will affect all the public folders access and administration. When this happens it will no longer be possible to create new public folders since the primary public folder hierarchy mailbox is unavailable.

The following error will be seen when creation of new public folder is attempted and your public folders are in this state:

If the associated account for the public folders is deleted then, the primary hierarchy mailbox will remain in the database till the retention settings expire. The mailbox will be in a disabled state. Public folders themselves will not be visible in the Exchange Admin Center as shown below:

The recovery of this mailbox is possible provided the associated primary hierarchy mailbox is available in disconnected state in the associated mailbox database. You can create a new disabled user account with same name and then reconnect the mailbox using the Connect or Restore a Deleted Mailbox command to connect the mailbox as mentioned prior in the blog.

Recovering the primary hierarchy mailbox if it is deleted

When a primary hierarchy mailbox is deleted and past the database retention period the only option would be to restore the last full good backup for the database on which the primary hierarchy mailbox resides.

Recovering the public folder hierarchy structure would be only possible if you restore the database directly to the production or use the dial tone recovery method to recover the public folder hierarchy.

As you are recovering the database, any folder content which was modified, deleted or created after the backup of that database was taken might be lost. Once the database is restored and mounted the first thing that happens is that the primary hierarchy mailbox will initiate full hierarchy sync with all the secondary hierarchy mailboxes and only the hierarchy present from that last restored backup will be available.

Looking at the above possibility it becomes very important to plan for the high availability of public folders especially the primary hierarchy mailboxes and this is where the Database Availability Group can be the answer.

Few related notes:

• To avoid issues with the deletion of the container and associated public folder accounts, we can enable the feature “Protect object from accidental deletion”on the AD container and the associated objects. For more information see Preventing Unwanted/Accidental deletions and Restore deleted objects in Active Directory
• Set proper retention settings on the database and if required at individual public folders. Also ensure to plan backups properly in the environment in case a recovery is required.
• Recommendation would be to use the Database Availability Group for public folder mailboxes to provide much needed high availability and prevent unwanted outages.

Conclusion

In the above blog post I tried to shed some light on how to recover the contents from secondary content public folder mailboxes after they are deleted and also discussed possible scenarios when primary hierarchy mailboxes could become unavailable. I plan to continue posting some additional more complex scenarios related to recovery of the public folder mailboxes / data.

I would like to again Thank Ben Winzenz, Bill Long, Charlotte Raymundo, Nino Bilic and Bhalchandra Atre for their help in reviewing this blog post.

Siddhesh Dalvi

We’re approaching the one-year anniversary of the release of Exchange Server 2013. This is traditionally the time when people start asking questions like:

When is Service Pack 1 coming?
What’s the timeline for the next Exchange Server release?
What are you cooking up for the next version of Exchange?

This time around, we’re also hearing a few customers ask:

Will there be another version of Exchange Server?

We hope the answer to that question is obvious, but we wanted to go on record to make sure no one is confused. Here are the facts:

• The Exchange engineering team is hard at work developing the next version of Exchange.
• We expect the next on-premises version to be released according to our traditional release cadence (2-3 years after the previous version).
• Microsoft has no plans to stop delivering on-premises releases of Exchange.

It’s true that customers are shifting their Exchange deployments from on-premises to the cloud, and it’s true that we are investing heavily in Office 365. We’re fans of Office 365 because we’ve seen that when customers run email in our cloud, they save money, they get larger mailboxes, and they get faster access to our latest innovations. IT admins spend less time maintaining servers and more time lighting up features that make users happy. Running Office 365 also brings us real-world experience that helps us build a better on-premises product.

While we are enthusiastic about the cloud, we also understand that our customers will transition to the cloud at their own pace. Many customers will remain on-premises or in hybrid deployments for the foreseeable future, and we want to keep delivering our newest and best features to them. Fortunately, our development process allows us to do that. We have a single code base that serves both cloud and on-premises customers, so we can deliver innovation to both groups.

Our development strategy continues to focus on Office 365 as the initial platform where we roll out new features. This approach allows us to introduce and test new features at scale before including relevant functionality into on-premises updates. The benefits of the strategy can be seen in Exchange 2013, where features such as Managed Availability are directly based on work done to automate and improve our datacenter operations. If you want clues about what’s coming in the next version of Exchange Server, keep an eye on what’s happening in Office 365.

It’s an exciting time for messaging and collaboration. Today’s technology trends— cloud, mobile devices, social computing, machine learning—all have the opportunity to make email more useful and powerful. We’ve got some great stuff cooking, and we’re committed to bringing innovation to all of our customers, whether they choose to deploy Exchange in the cloud or on-premises. The Exchange product team and our customers have a 17+ year history of successfully navigating changes in IT architecture and management together. We look forward to continuing that tradition with you.

Perry Clarke
Corporate Vice President
Microsoft Exchange

Outlook prompting users for credentials? Outlook users disconnected from their mailboxes? These are a couple of common issues and they can be frustrating to the user. Enter the Outlook Connectivity Guided Walkthrough (GWT).

Outlook connectivity issues with Exchange server can be a very frustrating for both the user and the administrator. Unfortunately, connectivity issues aren't uncommon and will likely occur at some point in time whether your mailboxes are hosted on-premises, in Office 365, or a combination of both, i.e. Hybrid setup. Earlier this year we released a guided walkthrough for Outlook connectivity issues in Office 365.

To assist you in troubleshooting Outlook connectivity issues in an Exchange on-premises environment, we’ve now released the Outlook Connectivity Guided Walkthrough (GWT). You can use this walkthrough for troubleshooting some common issues which include:

• Prompts for credentials
• Certificate errors
• Client disconnects
• Offline Address Book download issues
• Autodiscover issues

The goal for this guided walkthrough is to help you resolve Outlook Connectivity issues with Exchange in a timely manner by providing troubleshooting steps in a logical manner depending on the symptoms of the issue being experienced.

I’d like to thank everyone who contributed to the development of this troubleshooter with special recognition going to the following folks: Victor Zhang, Sainath Vijayaraghavan, Melissa Grewing, Shaun Gimberline and Amir Haque.

Jim Martin

Today on the Office blog we announced that service pack 1 for the 2013 set of products including Office, SharePoint and Exchange will be released early next year. We know our Exchange customers have been looking for confirmation of the release but also have a desire for an early look at what's coming with Exchange Server 2013 Service Pack 1 (SP1). So let's have a first look a few things you can expect to see in SP1. But wait… we haven’t released CU3– well, news about CU3 is imminent - stay tuned for more information about CU3 coming very soon.

In this post we are highlighting a few of the notable improvements to be included in SP1. This isn't an all-inclusive list, so stay tuned for additional details as we approach release.

• Windows Server 2012 R2 Support First answering one the most common questions since the release of Windows Server 2012 R2. Exchange 2013 SP1 will add Windows Server 2012 R2 as a supported operating system for Exchange Server 2013 with SP1. Let your planning begin.
• S/MIME support for OWA Support for S/MIME in OWA will be brought back in SP1. With SP1 customers will have S/MIME support across Outlook, Exchange ActiveSync clients, and OWA.
• Edge Transport Server Role The Edge Transport server role for Exchange Server 2013 will be available with SP1.
• Fixes and Improvements Of course, SP1 will include fixes and improvements in areas you've helped us identity. SP1 is the first service pack issued in the new Exchange Server cumulative update release model - thus SP1 is essentially CU4. The installation of SP1 will follow the same process as the prior Exchange 2013 CU releases. SP1 will include all fixes included in previously released cumulative updates for Exchange 2013.

SP1 will require customers to update their Active Directory schema - customers should assume this requirement for all Exchange Server 2013 updates. Plan for this required update to quickly take advantage SP1 updates. Active Directory Schema updates for Exchange are additive and always backwards compatible with previous releases and versions.

On behalf of the Exchange Product Group, thanks again for your continued support. As always, let us know what you think!

Brian Shiers
Exchange Technical Product Manager

The Exchange team is announcing today the availability of Update Rollup 3 for Exchange Server 2010 Service Pack 3. Update Rollup 3 is the latest rollup of customer fixes available for Exchange Server 2010. The release contains fixes for customer reported issues and previously released security bulletins. Update Rollup 3 is not considered a security release as it contains no new previously unreleased security bulletins. A complete list of issues resolved in Exchange Server 2010 Service Pack 3 Update Rollup 3 may be found in KB2891587.

Note: The KB article may not be fully available at the time of publishing this post.

The release is now available on the Microsoft Download Center.

The Exchange Team

The Exchange team is announcing today the availability of our most recent quarterly servicing update to Exchange Server 2013. Cumulative Update 3 for Exchange Server 2013 and updated UM Language Packs are now available on the Microsoft Download Center. Cumulative Update 3 includes fixes for customer reported issues, minor product enhancements and previously released security bulletins. A complete list of customer reported issues resolved in Exchange Server 2013 Cumulative Update 3 can be found in Knowledge Base Article KB 2892464.

Note: Some article links may not be available at the time of this post's publication. Updated Exchange 2013 documentation, including Release Notes, will be available on TechNet soon.

We would like to call attention to an important fix in Exchange Server 2013 Cumulative Update 3 which impacts customers who rely upon Backup and Recovery mechanisms to protect Exchange data. Cumulative Update 3 includes a fix for an issue which may randomly prevent a backup dataset taken from Exchange Server 2013 from restoring correctly. Customers who rely on Backup and Recovery in their day-to-day operations are encouraged to deploy Cumulative Update 3 and initiate backups of their data to ensure that data contained in backups may be restored correctly. More information on this fix is available in KB 2888315.

In addition to the customer-reported fixes in Cumulative Update 3, the following new enhancements and improvements to existing functionality have also been added for Exchange Server 2013 customers:

• Usability improvements when adding members to distribution groups in the Exchange Administration Console (EAC)
• Windows Azure AD Rights Management available for use for IRM protection in on-premises Exchange deployments
• Improved administrator audit logging experience
• Windows 8.1/IE 11 no longer require the use of OWA Light

More information on these topics can be found in What’s New in Exchange Server 2013, Release Notes and Exchange 2013 documentation on TechNet.

Before you deploy Exchange 2013 CU3...

Here are some things to consider before you deploy Exchange 2013 CU3.

• Active Directory schema and configuration update: Exchange 2013 CU3 includes Exchange related updates to the Active Directory schema and configuration. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation.
• PowerShell Execution Policy: 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 KB 981474 to adjust the settings.
• Hybrid deployments and EOA: 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 maintain currency on Cumulative Update releases.

Our next update for Exchange 2013, Cumulative Update 4, will be released as Exchange 2013 Service Pack 1. Customers who are accustomed to deploying Cumulative Updates should consider Exchange 2013 SP1 to be equivalent to CU4 and deploy as normal.

The Exchange Team

One of the requirements for properly integrating with Microsoft Office 365 is to ensure that your clients and (in some instances such as hybrid Exchange) servers have access to all of the proper endpoints. To achieve this, most customers simply allow their clients internet access and there is no outbound restrictions put in place that would prevent access to the services.

However, there are some customers that want to only allow access to a minimal amount of endpoints on the Internet and have an outbound proxy device that is in place to ensure that they can control this closely. This control can be done in one of two ways:

• A customer could use IP address filtering which will only allow their internal client machines access to the specific endpoint they specify.
• They can also use URL based filtering which allows customers to control access by only allowing access to specific URL’s.

Many customers ask, “What are the challenges involved with IP vs. URL filtering? Which option is best for me? Is there a recommended option?”

Keeping up with changes is the first challenge customers may face. The IP addresses and URL’s that are used in the service are mentioned here and if configured today, could change at any time. We do have an RSS feed for this page to try to alert customers of changes and we do try to prevent IP address changes by using larger IP ranges, but in the end there are still times when we have additional datacenters come online or other factors that lead to more IP addresses than is on the list.

Somefeatures will simply not work is the second challenge (such as OWA for customers that decide to use IP addresses as the mechanism for preventing outbound connectivity instead of URL based blocking). The reason behind this is documented here; some of the IP addresses we Use are dynamic and could change without notice for non-secure traffic. Things such as images for OWA are retrieved from third party content delivery networks (a.k.a. CDN) outside of the Microsoft controlled IP address space to improve performance.

Here is the “important” snip from the above mentioned article:

“Microsoft Office 365 relies on third-party content caching engines to achieve good performance and response times. The types of content cached with these third parties are non-SSL resources, such as the images downloaded to draw the Outlook Web App user interface. As stated above, it's possible and supported to use IP-based filtering for the SSL content downloaded from Office 365 and for the Office 365 end-points that make in-bound calls to an on-premises environment. However, it isn’t possible or supported to use IP-based filtering for the non-SSL resources hosted on third-party content caching engines. To express filtering rules that allow those non-SSL resources to be downloaded to clients on your intranet, you need to use hostname-based filtering (as opposed to IP-based filtering). This is because the IPs used by the third-party content caching engines change frequently in a manner which makes it impractical to track each individual IP change. Allow the following hostnames for these non-SSL resources:
r3.res.outlook.com
r4.res.outlook.com
prod.msocdn.com”

You may ask if URL based filtering requires no upkeep and will continue to work after you initially configure it.

The answer is no, not 100% anyway. There will still be times when URL’s for the service could change and changes will be reflected in the articles mentioned above. However, the frequency of the changes is dramatically decreased when URL filtering is used.

Often a customer will choose IP based filtering not because it is easier, but instead because their outbound proxy device cannot do URL based filtering. While this may be true for many older devices, we have seen many times where the application of a software update to your device may allow for URL based filtering functionality. URL based filtering is becoming more prevalent and most devices do give you the opportunity to adapt to this style of filtering.

Some features may not work depending on where users are physically situated is the third major challenge. In some situations we have seen customers attempt to allow only the IP addresses of only Office 365 geographical region datacenters they signed up in. For example, a North American Office 365 customer’s IT staff may attempt to allow only the North American datacenter IP ranges by watching what IP addresses their clients are connecting to then removing the IP ranges they do not see being accessed from the allowed IP list. At first, this may appear to work until (hypothetically speaking) you get a call from your CEO on business travel to Europe asking if Office 365 is down because they cannot access any of the services. Let’s first talk about why this may happen.

Microsoft utilizes geographically aware DNS (aka Geo-DNS) to respond to incoming DNS queries. Microsoft DNS servers first compare the IP address of an incoming request from the querying device against a database of industry standardized IP ranges and what regions of the planet they reside in. Microsoft DNS servers will then issue a DNS response back to the querying device that will be the closest physical entry point to the Office 365 services in the identified IP region. For example a traveling North American Office 365 customer in Europe will be given a European Office 365 entry point. This will prevent the user’s network traffic from having to travel long distances across the public Internet before reaching the desired services. Using Geo-DNS we get the user’s network traffic into the closest Microsoft datacenter and then pass their network traffic across our low latency global private network back to the user’s home datacenter region. This allows Microsoft to provide the best user experience possible for all regions of the planet by reducing dependencies on the public Internet where possible.

So back to our CEO example. The CEO may be in a European hotel on business using the hotel Wi-Fi with a company laptop to do some work. The DNS response they get back for outlook.office365.com will point them at European datacenter. Due to the fact you have only allowed the IP ranges of the North American datacenters, the user is unable to connect to services. You may think forcing the laptop to always utilize corporate DNS servers would help here. Remember that by going down that path you would be forcing the client to traverse the public Internet to reach the North American datacenter and not be able to take advantage of Microsoft’s low latency private network between its datacenters, thus giving your user a less optimal experience.

What is the best or recommended option is based on the challenges outlined above. Microsoft would like to see all customers use URL based filtering to overcome those challenges. URL based filtering will provide you with the fewest number of changes over time, prevent unwanted situations when some content may be unreachable due to changes at the third-party CDNs level, and allow users outside of their home region to always access the most appropriate datacenter for their client connectivity.

Thanks to Brian Day and Joshua Maher for review / comments on this post.

Timothy Heeney

Today we released v6.1 of the Exchange 2013 Server Role Requirements Calculator.  You can view what changes have been made, or download the update directly.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

The previous post for Exchange ActiveSync mailbox log analysis gave an overview of the various commands a device may send. Now we want to dig just a little bit deeper and provide a way to link items within an EAS mailbox log to the items inside the mailbox.

Unless verbose logging is enabled you do not see the full details of the item (subject, sender, etc.) This leads us to the question: How do you know what item the ActiveSync request/response was for within the mailbox? The next few sections will show you how to correlate an appointment, message, and attachment between the mailbox log and mailbox contents.

Calendar items

The first step is locating the item within the mailbox and pulling the Global Object ID (GOID) property value for the item. We cannot do this using Outlook, so we will need to download MFCMAPI. Launch MFCMAPI, go to the Session menu and select Logon to select your Outlook profile. Open the mailbox and expand the Root Container and Top of Information Store. Right-click on the Calendar and select Open contents table.

Find your appointment inside the Calendar table. Then right-click on the tag 0x80000102 and select Edit property. In this example, we will use the appointment with the subject “Blog demo”.

Copy this binary value so you will have it available for a search against the mailbox log.

The Mailbox Log Parser utility allows you to search and review mailbox logs easily. Here we can use this tool to search for the GOID of the appointment. Launch Mailbox Log Parser, click Import Mailbox Logs to Grid, locate your mailbox log and click Open. Once the log is open, enter the binary value you copied from MFCMAPI into the Search raw log data for strings text box and click Search. The search results will filter the log entries so you only see log entries containing the GOID value of your appointment. Here you will notice the UID value within the mailbox log matches the GOID value from MFCMAPI (click to see full resolution):

Review each log entry to determine what action was taken against the appointment. The above image shows a log entry where a Sync request resulted in a change to the appointment. The details for the update can be found within the log entry on the far right. You may also want to consider performing a search using the ServerId value for the appointment found in the log entry. There may be responses that do not contain the UID such as a Delete.

Now let us look at how we can take the calendar item from the mailbox log and find the appointment within the mailbox. For our example we will use the UID value from the mailbox log we used earlier (in image above). We need to open the Calendar contents table using the steps outlined earlier using MFCMAPI. Inside the Calendar table, go to the Table menu and select Set columns.

Click OK on the Set Columns window. In the Column set window, click the Add button. In the Property Tag Editor window, enter the Property Tag value 0x80000102 and click OK twice. This will add the UID column to our table view.

Sort your Calendar table by this Property tag column you just added and then scroll down until you find the matching UID from the mailbox log. Here you can see we found our appointment once again with the subject “Blog demo”.

E-mail message

Copy the binary value and paste it into a tool like Notepad. This value is not as straightforward as the Global Object ID for an appointment. We need to break down this value into a few parts. The following example is from the third message in a conversation thread:

01CEC617632457F0D646F5744F4990165503AB61C52F00000CF610

The value is broken down as follows:

1. Remove the first byte – 01
2. The next five bytes (10 characters) represent the Conversation Index for the message or the current system time- CEC6176324
3. The next 16 bytes (32 characters) represent the Conversation Id for the message or the globally unique identifier (GUID) - 57F0D646F5744F4990165503AB61C52F
4. The remaining bytes are added to the Conversation Index (only present for additional messages within the thread)

Note: Additional information on tracking conversations can be found here.

Alright, so what does that mean to us? Once again we will use the Mailbox Log Parser tool to search for our item. This time enter the ConversationId value extracted from the previous step into the Search raw log data for strings window. In the results below, you can see we found two messages with this ConversationId value. Remember, this search will return all messages related to the conversation including messages in Sent Items.

Analysis of the log entry shows the item being added to the folder on the device.

Keep in mind we have two results for this conversation. You need to use the Conversation Index value to locate the exact message in the log.

What about the reverse? Just make note of the ConversationId value from the mailbox log for your message. Then open MFCMAPI to open the content table for the folder where the message resides. Sort the table using the Conversation ID column and search for the ConversationId value from the mailbox log. You should find your message(s) for this conversation.

We can see in this example there are two messages within this conversation using the Conversation ID. We would need to examine the property further for each item to obtain the Conversation Index value to locate the exact message.

Attachments

What about those attachment errors you see in the mailbox log? The mailbox log does give us the information we need to locate the attachment inside the mailbox. The following example shows the FileReference value of the attachment is 5%3a10%3a1. This equates to 5:10:1 or attachment 1 for ServerId 5:10.

First we have to search the mailbox log for this ServerId to determine the message if we do not already know it. Using the example attachment above, we can see the message being added to the folder:

Now we can use the steps from earlier section to locate the message within MFCMAPI using the ConversationId. Once we locate the message, right-click on the message and select Attachments> Display attachment table.

We can determine what attachment the ActiveSync mailbox log reference by matching the Num column from the log value. In our example, the attachment referenced was _Read~1.pdf.

Conclusion

Each item that is synchronized to and from Exchange contains a unique identifier that we can use to locate the item in either the mailbox or ActiveSync client. Calendar items have a unique Global Object ID and mail items have a ConversationIndex and ConversationId value. Now you can review an Exchange ActiveSync mailbox log with more confidence, knowing that you can associate items within the log with items inside the mailbox.

Jim Martin