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), however we do not have a locked in timeline at this point.

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 filtering on-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

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 KB2892464.

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 KB2888315.

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 new and existing groups in the Exchange Administration Console
• Online RMS available for use by non-cloud based Exchange deployments
• Improved admin audit log experience
• Windows 8.1/IE11 no longer require the use of OWA Light

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

Cumulative Update 3 includes Exchange related updates to Active Directory schema and configuration. For information on extending schema and configuring the active directory please review the appropriate TechNet documentation. Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.

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

Reminder: Customers in hybrid deployments where Exchange is deployed in-house and in the cloud, or who are using Exchange Online Archiving with their in-house Exchange deployment are required to maintain currency on Cumulative Update releases.

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

Today the Exchange team released security bulletin MS13-105. Updates are being made available for the following versions of Exchange Server:

• Exchange Server 2007 SP3
• Exchange Server 2010 SP2
• Exchange Server 2010 SP3
• Exchange Server 2013 CU2
• Exchange Server 2013 CU3

Customers who are not running one of these versions will need to upgrade to an appropriate version in order to receive the update.

Security bulletin MS13-105 contains details about the issues resolved, including download links.

For Exchange Server 2007/2010 customers, the update is being delivered via an Update Rollup per standard practice. Due to the timing of the release of our most recent Update Rollups, the only difference between the previously released Update Rollup and the Security Update Rollup released today is the inclusion of the security updates identified in MS13-105. We did not include updates for any other customer reported issues in these packages to ease their adoption.

For Exchange Server 2013 customers, security updates are always delivered as discrete updates and contain no other updates. Security updates for Exchange 2013 are cumulative in nature based upon a given Cumulative Update. This means customers who are running CU2 who have not deployed MS13-061 can move straight to the MS13-105 update because it will contain both security updates. Customers who are already running MS13-061 on CU2 may install MS13-105 on top of MS13-061 without removing the previous security update. If MS13-061 was previously deployed, Add/Remove Programs will indicate that both updates are installed. If MS13-061 was not previously deployed, only MS13-105 will appear in Add/Remove Programs.

These updates are being made available via Microsoft Update and on the Microsoft Download Center.

Exchange Team

In Exchange 2010 and Exchange Online, we introduced Litigation Hold to allow you to immutably preserve mailbox content to meet long term preservation and eDiscovery requirements. When a mailbox is placed on Litigation Hold, mailbox content is preserved indefinitely.

Placing a mailbox on Litigation Hold You can place a mailbox on Litigation Hold by using the Exchange Administration Center (EAC) or the Shell (set the LitigationHoldEnabled parameter). In Exchange 2010, you can also use the Exchange Management Console (EMC) to do this.

Figure 1: Enabling Litigation Hold for a mailbox using the EAC in Exchange 2013 and Exchange Online

Figure 2: Adding a note and a URL to inform & educate users placed on Litigation Hold

Preserving items for a specified duration To preserve items for a specified period, we added the LitigationHoldDuration parameter to Exchange Online. This helps you meet your compliance needs by preserving all items in a mailbox for the specified duration, calculated from the date the item was created (date received in case of inbound email). For example, if your organization needs to preserve all mailbox data for seven years, you can place all mailboxes on Litigation Hold and set the LitigationHoldDuration to 7 years (in days).

This functionality is also available in Exchange 2013, allowing you to preserve items for a specified duration in your on-premises organization – one example of how developments in Exchange Online benefit Exchange Server on-premises.

In-Place Hold in Exchange 2013 and Exchange Online

In Exchange 2013 and the new Exchange Online, we introduced In-Place Hold, which allows more flexibility in preserving your data. Hold functionality is integrated with In-Place eDiscovery to allow you to search and preserve using a single wizard or a single cmdlet (New-MailboxSearch). You can use the In-Place eDiscovery & Hold wizard or the cmdlet to search for and preserve items matching your query parameters, known as a query-based In-Place Hold, preserve items for a specified period, known as a time-based hold, and also preserve everything indefinitely, which emulates the old Litigation Hold feature. Check out In-Place eDiscovery and In-Place Hold in the New Exchange - Part I and Part II for more info.

Use the hold feature that best meets your needs

You can use either hold feature to preserve mailbox data in Exchange 2013 and Exchange Online, based on your preservation needs. Here are some scenarios to help you choose between the two holds.

¹ Distribution group is expanded when you run the command. Future changes to the group require running the command again.
² Distribution groups are expanded only when you create or refresh the In-Place Hold. Future changes to the group require refreshing the search object.
³ Inactive mailboxes is an Exchange Online feature. The linked documentation is being updated to clarify you can also use Litigation Hold to make a mailbox inactive.

Bharat Suneja

Updates
- 12/11/2013: Added 'Specify types of items to preserve' row to comparison table.
- 12/11/2013: Added 'ItemHoldDuration' parameter to comparison table

We’re happy to announce that we’ve added some tests to Microsoft Remote Connectivity Analyzer (RCA), to help you test your mail flow configuration. These tests are intended for customers who use the Exchange Online Protection service to perform spam and malware filtering before sending email messages to your email servers. You can run these tests when setting up the service, or whenever you want to verify that your mail flow is set up correctly.

The Verify MX Record and Outbound Connector Test, shown in the image below, verifies that the MX record for your domain points to EOP, so that mail is routed to EOP for filtering before it reaches your mailboxes. This test also verifies that you have an Outbound on-premises connector configured to deliver email to your on-premises environment.

Figure 1: Verify MX Record and Outbound Connector Test

The Verify Service Delivery Test verifies delivery from the service to your on-premises environment by testing the connection between the service and your IP addresses or fully qualified domain names (FQDNs) defined in your Outbound on-premises connector.

For more information about how to run these tests, see Test Mail Flow With the Remote Connectivity Analyzer.

We welcome any feedback; please send comments to the following email address: exrcafb@microsoft.com.

Exchange Online Protection (EOP) Team

The Office Sustained Engineering team has an important update about a potential issue with Outlook 2013 after installing the September 2013 Update. For details about the issue and how to fix affected installations, see Outlook 2013 Folder Pane Disappears After Installing September 2013 Public Update on the Office Sustained Engineering blog.

Exchange Team

Introduction

In Exchange 2013 we introduced the concept of “Server Component States”. Server Component State provides granular control over the state of the components that make up an Exchange Server from the point of view of the environment it is running in. This is useful when you want to take an Exchange 2013 Server out of operation partially or completely for a limited time, but still need the Exchange services on the server to be up and running.

One example of such a situation is when “Managed Availability” (MA) comes to the conclusion that a specific server is not healthy in some respects and therefore should be bypassed temporarily until the bottleneck has been identified and removed. MA does so by utilizing so-called “Offline Responders”. They are explained in some detail in Lessons from the Datacenter: Managed Availability. Their counterpart are “Online Responders”, which bring the server back online when it is determined as being healthy again.

Another example is when a server is being updated, for example with a new CU.

In both situations, the server cannot be taken offline completely, but it also should not be considered as a fully operational member of its Exchange organization as well.

The primary purpose of Managed Availability is, to make the life of Exchange Administrators easier so that they usually do not have to bother themselves with the details. However, in other situations, a certain level of knowledge about the basic concepts behind “Server Component States” might prove to be useful.

Verify the current State of the Server Components

A first overview over the current State of all Server Components can be displayed in the Exchange PowerShell with the Get-ServerComponentState –Identity <ServerID> cmdlet:

You see, that the Server Components listed here do not map 1:1 to Exchange Services or processes running on the server. Instead, they provide an abstraction-layer and display “Components” which together make up the interfaces an Exchange Server provides to its environment. The majority of the components have a name like “*Proxy”. They are specific for the CAS Role, while other components like “HubTransport” and “UMCallRouter” are part of the Mailbox server role and “Monitoring” and “RecoveryActionsEnabled” belong to both roles.

In addition to the single components which can be managed individually, there’s also a component called “ServerWideOffline”, which is used to manage the state of all components together, with the exception of “Monitoring” and “RecoveryActionsEnabled”. For this purpose, “ServerWideOffline” overrides individual settings for all other components. It doesn’t touch “Monitoring” and “RecoveryActionsEnabled” because these two components need to stay active in order to keep MA going. Without them, no “OnlineResponder” could bring “ServerWideOffline” back to “Active” automatically.

About States and Requesters

Usually, Server Components are in one of two States: “Active” or “Inactive”. A third state, called “Draining”, is only relevant for the Components “FrontendTransport” and “HubTransport”.

Whenever the state of a component is supposed to be changed, it has to be done by a “Requester”. For example, the parameter –Requester is mandatory when you run the cmdlet Set-ServerComponentState:

There are altogether five “Requesters” defined:

• HealthAPI
• Maintenance
• Sidelined
• Functional
• Deployment

Requesters are labels - you can choose any of them when running Set-ServerComponentState. But each Requester is treated and stored individually (more on this in the next section) and you should select the Requester that best matches your intention. For example, when you need to set “ServerWideOffline” to “Inactive” for maintenance purposes, it makes no sense to use “HealthAPI” as Requester. You might get what you want that way in terms of functionality; but such a choice will make troubleshooting unnecessarily complicated in case something does not work as expected, and you might get into a conflict with MA. Whenever MA triggers an OfflineResponder or an OnlineResponder it uses “HealthAPI” as Requester; therefore it is a good idea to consider “HealthAPI” as reserved for use by MA.

Interaction between States and Requesters

As stated above, each Requester is handled and stored individually. There’s no relationship or hierarchy amongst them. However, in case of a conflict between two or more Requesters, “Inactive” has a higher priority than “Active”.

Here’s a practical example:

Imagine that “ServerWideOffline” has been set to “Inactive” by two different Requesters, say “Functional” and “Maintenance”:

Then, you set back “ServerWideOffline” to “Active” with one of the two Requesters

As a Result, “ServerWideOffline” and all dependent Components still remain in the state “Inactive”:

In order to set them back to “Active” again, Set-ServerComponentState … -State Active needs to be executed with the second Requester as well.

Obviously, administrators will rarely configure such combinations purposefully. However, we have seen them happening as the result of a mix of processes running in the background and manual configuration.

Where is the data stored and how can it be retrieved?

Information about “Server Components”, “Requesters” and “States” is stored in two different places: Active Directory and the server’s Registry. Storage in the Active Directory facilitates running Set-ServerComponentState against a remote server.

In order to determine precedence in case of a divergence between the two places, a timestamp is used. The newer setting is considered as the intended one.

In Active Directory, the settings are stored in the “msExchComponentStates” attribute of the Exchange Server object in the Configuration-namespace:

In the Registry, the settings are stored under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ServerComponentStates:

You can use the Get-ServerComponentState cmdlet from the Shell to retrieve these settings:

<variable>.LocalStates displays the settings in the local Registry and <variable>.RemoteStates displays the settings in the Active Directory.

Peculiarities of “FrontendTransport” and “HubTransport” Components

Most Exchange Server components pick up changes in their Component State “on the fly”. However, this is not the case for the two Components “FrontendTransport” (mapped to the “Microsoft Exchange Frontend Transport” service on CAS Servers) and “HubTransport” (mapped to “Microsoft Exchange Transport” on Mailbox Servers). They pick up changes upon their next restart only.
This can cause confusion about their actual state. For example, they might be displayed as “Inactive” in Get-ServerComponentState but functionally still be active since they haven’t been restarted since their state has changed.

In order to alert the Administrator about such an inconsistency they write warnings into the Application Event Log. These warnings (7011 for MSExchangeTransport and 7012 for MSExchangeFrontEndTransport) inform the Administrator about the current and the expected state:

MA has Responders which take care of such inconsistencies and resolve them after a while by a forced crash and restart of the affected services. These Responders have the name “FrontendTransport.ServiceInconsistentState.Restart.Responder” and “HubTransport.ServiceInconsistentState.Restart.Responder”. They can be identified in the Microsoft.Exchange.ActiveMonitoring/ResponderDefinition crimson channel using the methodology described in What Did Managed Availability Just Do To This Service? blog post.

In Exchange 2013 CU2 and CU3 they are only triggered once per day for standalone Mailbox Servers and up to four times per day for DAG members. This might change in future versions, though.

After the inconsistencies have been cleared, Events 7009 from Source “MSExchangeTransport” (or “MSExchangeFrontendTransport”) and Category “Components” are logged, which show the current state:

When the state of one or both of these components is set to “Inactive”, each attempt to connect to the SMTP service on the server (on TCP port 25) triggers the response “421 4.3.2 Service not active” (for the FrontendTransport component) and “451 4.7.0 Temporary Server error” (for the HubTransport component) and corresponding entries are written to the respective SmtpReceive Protocol Logs.

As mentioned in KB 2866822 , messages sent from internal stay in the Outbox or Drafts folder and “Service not active” entries are logged in the “Connect*”-Logs in the “Submission”-Folder underneath “TransportRoles\Logs\Mailbox\Connectivity\” when “HubTransport” is set to “Inactive”.

A problem with failing updates to CU2

While an Exchange 2013 Server is updated with CU2, the setup- sets “Monitoring”, “RecoveryActionsEnabled” and “ServerWideOffline” to Inactive using the Requester “Functional” at the beginning, as can be seen in the “ExchangeSetup”-Logfile:

However, when the update exits prematurely because it encounters an unrecoverable error-condition, it does not restore the original state. Even when the Administrator restarts all stopped Exchange services or reboots the server, the Exchange components still remain in the Inactive state.

In order to recover from this situation, you must either find the root cause for the error and remove it so that the setup completes successfully, or manually set the ServerComponentStates back to Active with the Requester “Functional”.

This issue might be fixed in future CUs and SPs.

When should you change Server Component States manually?

Perhaps the two most important scenarios where manual changes of Server Component States come into play are:

1. Planned server maintenance
2. Temporary isolation of some server components, so that they are not targets for proxy requests from other CAS servers any more.

Server component states and planned maintenance of DAG members

Scenario 1 is described for DAG-members in some detail in Managing Database Availability Groups on TechNet. However, in practice, it can prove to be trickier than expected, depending on the details of the planned maintenance measure.

The article does not mention that “FrontendTransport” and “HubTransport” have to be restarted, before a change in their Component State becomes effective at all. Without a restart, you continue to receive warning events 7011 and 7012 in the Application Event Log, but the state of the components remains the same as before, until eventually MA detects the inconsistency and force restarts the services.

Also, the problem with the prematurely exiting CU setups mentioned above in the section “Practical Experiences” cannot be resolved by following the recommendations in the article to the dot, because Setup uses the Requester “Functional”, while the article talks about the Requester “Maintenance”.

Special thanks to Bhalchandra Atre, Stephen Gilbert for their contributions as well as Abram Jackson and Bharat Suneja for their review.

Helmut Krüger