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

I’ve written a few blog posts now that get into the deep technical details of Managed Availability. I hope you’ve liked them, and I’m not about to stop! However, I’ve gotten a lot of feedback that we also need some simpler overview articles. Fortunately, we’ve just completed documentation on TechNet with an overview of Managed Availability. This was written to address how the feature may be managed day-to-day.

Even that documentation doesn’t address how you respond when Managed Availability cannot resolve a problem on its own. This is the very most common interaction with Managed Availability, but we haven’t described how specifically to do so.

When Managed Availability is unable to recover the health of a server, it logs an event. Exchange Server has a long history of logging warning, error, and critical events into various channels when things go wrong. However, there are two things about Managed Availability events that make them more generally useful than our other error events:

• They all go to the same place on a server without any clutter
• They will only be logged when the standard recovery actions fail to restore health of the component

When one of these events is logged on any server in our datacenters, a member of the product group team responsible for that health set gets an immediate phone call.

No one likes to wake up at 2 AM to investigate and fix a problem with a server. This keeps us motivated to only have Managed Availability alerts for problems that really matter, and also to eliminate the cause of the alert by fixing underlying code bugs or automating the recovery. At the same time, there is nothing worse than finding out about incidents from customer calls to support. Every time that happens we have painful meetings about how we should have detected the condition first and woken someone up. These two conflicting forces strongly motivate the entire engineering team to keep these events accurate and useful.

The GUI

Along with a phone call, the on-call engineer receives an email with some information about the failure. The contents of this email are pulled from the event’s description.

The path in Event Viewer for these events is Microsoft-Exchange-ManagedAvailability/Monitoring. Error event 4 means that a health set has failed and gives the details of the monitor that has detected the failure. Information event 1 means that all monitors of a health set have become healthy.

The Exchange 2013 Management Pack for System Center Operations Manager nicely shows only the health sets that are currently failed instead of the Event Viewer’s method of displaying all health sets that have ever failed. SCOM will also roll up health sets into four primary health groups or three views.

The Shell

This wouldn’t be EHLO without some in-depth PowerShell scripts. The event viewer is nice and SCOM is great, but not everyone has SCOM. It would be pretty sweet to get the same behavior as SCOM to show only the health sets on a server that are currently failed.

Note: these logs serve a slightly different purpose than Get-HealthReport. Get-HealthReport shows the current health state of all of a server’s monitors. On the other hand, events are only logged in this channel once all the recovery actions for that monitor have been exhausted without fixing the problem. Also know that these events detail the failure. If you’re only going to take action based on one health metric, the events in this log is a better one. Get-HealthReport is still the best tool to show you the up-to-the-minute user experience.

We have a sample script that can help you with this; it is commented in a way that you can see what we were trying to accomplish. You can get the Get-ManagedAvailabilityAlerts.ps1 script here.

Either this method or Event Viewer will work pretty well for a handful of servers. If you have tens or hundreds of servers, we really recommend investing in SCOM or another robust and scalable event-collection system.

My other posts have dug deeply into troubleshooting difficult problems, and how Managed Availability gives an overwhelmingly immense amount of information about a server’s health. We rarely need to use these troubleshooting methods when running our datacenters. However, the only thing you need to resolve Exchange problems the way we do in Office 365 is a little bit of event viewer or scheduled script.

Abram Jackson
Program Manager, Exchange Server

Introduction

Often times in Exchange Support we get cases reporting that the size of one or more Exchange databases is growing abnormally. The questions or comments that we get will range from “The database is growing in size but we aren’t reclaiming white space” to “All of the databases on this one server are rapidly growing in size but the transaction log creation rate is “normal”. This script is aimed at helping collect the data necessary in determining what exactly is happening. For log growth issues, you should also reference Kevin Carker’s blog post here.

Please note when working with Microsoft Support, there may still be additional data that needs to be captured. For instance, the script does not capture things like mailbox database performance monitor logging. Depending on the feedback we get, we can always look at building in additional functionality in the future. Test it, use it, but please understand it is NOT officially supported by Microsoft. Most of the script doesn’t modify anything in Exchange, it just extracts and compares data.

Note: The space dump function will stop (and then restart) the Microsoft Exchange Replication service on the target node and replay transactions logs into a passive copy of the selected database, so use this with caution. We put this function in place because the only way to get the true white space of a database is with a space dump. People often think that the AvailableNewMailboxSpace is the equivalent of whitespace, but as Ross Smith IV notes in his 2010 Database Maintenance blog“Note that there is a status property available on databases within Exchange 2010, but it should not be used to determine the amount of total whitespace available within the database. AvailableNewMailboxSpace tells you how much space is available in the root tree of the database. It does not factor in the free pages within mailbox tables, index tables, etc. It is not representative of the white space within the database.” So again, use caution when executing that function of script as you probably don’t want to bring a lagged database copy into a clean shutdown state, etc.

Before we get into an example of the script, I wanted to point out something you should always check when you are troubleshooting database growth cases – what is the total deleted item size in the database and are any users on Litigation hold.

The following set of commands will export the mailbox statistics for any user that is on Litigation Hold for a specific database and furthermore will give you the sum of items in the recoverable items folder for those users (remember we use the subfolders Versions and Purges when Lit Hold is enabled).

1. Export the users mailbox statistics per database that have litigation hold enabled

get-mailbox -database <database name> -Filter {LitigationHoldEnabled -eq $true} | get-mailboxstatistics | Export-CSV LitHoldUsers.csv

2. Import the new CSV as a variable:

$stats = Import-Csv .\LitHoldUsers.csv

3. Get the sum of Total Deleted Item Size for the Lit Hold users in the spreadsheet

$stats | foreach { $bytesStart = $_.TotalDeletedItemSize.IndexOf("(") ; $bytes = $_.TotalDeletedItemSize.Substring($bytesStart + 1) ; $bytesEnd = $bytes.IndexOf(" ") ; $bytes = $bytes.Substring(0, $bytesEnd) ; $bytes } | Measure-Object –Sum

This will give you the sum for the specific database of recoverable items for users on litigation hold. I’ve seen cases where this amount represented more than 75% of the total database size. You also want to confirm what version of Exchange you are on. There was a known store leak fix that was ported to Exchange 2010 SP3 RU1. I don’t believe the KB is updated with the fix information, but the fix was put in place, so before you start digging in too deep with the script, make sure to install SP3 RU1 and see if the issue continues.

Ok moving onto the script. What can the script do you ask? The script can do the following:

• Collects mailbox statistics across the specified database, adding mutable note properties for future use in differencing
• Collects database statistics for the specified database, adding mutable note properties for later differencing.
• Collects mailbox folder statistics for all mailboxes on the specified database, adding mutable properties for later differencing
• Compares size and item count attributes of the input database from the differencing database, returning a database type object with the modified attributes
• Compares size and item count attributes of the input mailbox from the differencing mailbox, returning a mailbox type object with the modified attributes
• Compares size and item count attributes of the input folder from the difference folder, returning a folder type object with the modified attributes.
• Compares size and item count attributes of the input report from the difference report, returning a report type object with the modified attributes.
• Exports a copy of a report (database, mailbox, and folder statistics) to the specified path or current directory in *.XML format
• Imports an *.XML report and exports it to *.CSV format.
• Imports the report details from the specified file path (database, mailbox, and folder statistics)
• Outputs database details and top 25 mailboxes by size and top 25 folders by size
• Collects a space dump, ESEUTIL /MS, from a passive copy of the specified database and writes to *.TXT
• Searches for events concerning Online Maintenance Overlap and Possible Corruption, outputting them to the screen
• Collects and exports current Store Usage Statistics to *.CSV

You can download the script from here.

Sample script run

Issue reported: “Mailbox Database 0102658021” is rapidly growing in size.

• List options to use with -mode switch:

• Choose Collect and Export the data for the database that is growing in size (enter mode 1)
• Specify a path or use the current working directory. Quotes around the path is optional, but the path must already exist.
• Specify the database name. It will run against the active copy. Quotes are optional.

• Depending on the size of the database, folder counts, etc. this could take some time to run from here. Once the report is generated you will be prompted to select the top # of items to display from each report. 25 is the default if you just press enter.

• The onscreen reports will now generate. Note DB size on disk here is 1.38GB.

The onscreen reports that you can scroll through include the Database size details and individual reports for the Top 25 of the following: mailboxes by item size, mailboxes by DeletedItemSize, mailboxes by item count, mailboxes by deleted item count, mailboxes by associated items, Folders by size, Folders by item count, and Folders by deleted item count.

The Full XML report will be stored in the location you specified.

If you close out of the PowerShell window and wish to review the reports again, just run the script in mode 2 (quotes are optional).

Now we have a valid report at a single point in time of what's going on in the database. Since we are troubleshooting a “Database Growth” issue, we will need to wait some time for the database to grow. If you have ample space on the database drive, then I would run the report every 24 hours.

Once you ready, compile a second report of the database (same way you did the first above)

Press enter for top 25 items and the onscreen report will start scrolling through. As you can see below our database size increased on disk from 1.38 GB to 1.63 GB.

So what grew? Well now we will use Mode 3 of the script to compare the 2 XML reports. Note the second XML report in the directory:

Run the script with –mode 3. You will be prompted to enter the full file path for the original report and then the second report after the DB growth was recognized.

Once the differential is completed you will see a report that is similar to the first two reports. Keep in mind this is a DIFFERENTIAL Report, so it is reporting on how many items in a particular folder grew or how much the DB grew, etc.

As you can see above the size on disk shows 256mb. This is actually how much the database grew as we know that it went from 1.38gb to 1.63gb. If I scroll through the reports, I can see that the Administrator mailbox is where most of the growth took place (which is where I added the content).

This data can be used to tell what user(s) might be causing the additional growth. As noted earlier, we have had some “phantom” growth cases as well where we had known store leaks which is why it is imperative to make sure you have installed Exchange 2010 SP3 RU1. Its possible that you could run into that type of scenario here, but the data should support that as you would see DB on disk grow but no real growth in the mailboxes at which point you would need to engage Microsoft Support.

A quick note on the Actual Overhead value. This is calculated by taking the physical size of the database and subtracting the AvailableNewMailboxSpace, TotalItemSize and TotalDeletedItemSize. Remember that AvailableNewMailboxSpace is not the true amount of whitespace, so the actual number may be a little higher than what is reported here.

Other script parameters

The remaining modes of the script should be pretty self explanatory.

Mode 4 – Export Store Usage Statistics just uses the built in Get-StoreUsageStatistics function allowing you to run it at a server or database level.

Mode 5 – Will search the application log for events concerning Online Maintenance Overlap and Possible Corruption, outputting them to the screen. We probably didn’t get every event listed here, so we can add events as we see them.

Mode 6 – Will search the server that it is run on for passive copies of databases. It will alert you to any that are configured as lagged copies. If you choose to run this against a passive copy to get the true white space, then it will stop the Microsoft Exchange Replication service, do a soft replay of logs needed to bring the passive copy into a clean shutdown, and then run an ESEUtil /MS against the passive copy. Once completed it will restart the Replication service.

Mode 7 – will just read in one of the XML reports created from Mode 1 and break it out into its individual component reports in CSV format.

Jesse and I decided to build this because we continue to see cases on database growth, so a special thanks to him for running with the idea and compiling the core components of the script. We both had been running our own versions of this while troubleshooting cases, but alas, his core script was better (I still got to add some of the fun ancillary components). We’d like to thank Bill Long for planting the idea in our heads as he worked so many of these cases from a debugging standpoint as well as David Dockter and Rob Whaley for their technical review.

Hopefully this helps you troubleshoot any database growth issues you run across. We look forward to your comments and are definitely open to suggestions on how we can make this better for you.

Happy Troubleshooting!

Jesse Newgard and Charles Lewis
Sr. Support Escalation Engineers

Exchange and Outlook have, for years, been great collaboration platforms, where our customers could share information easily with others. One of the things that came to light when a lot of our customers adopted Office 365, is that many often have trouble matching their business needs to actual features in the product (stuff they would see in user interfaces and need to configure). In a purely on-premises world, the internal helpdesk and training can help bridge that gap. For those of our customers that have moved to the Office 365 world (especially smaller organizations), this can be a bit of a challenge.

We have worked to understand what most commonly looked for (and not found!) sharing scenarios are, and have leveraged the Guided Walkthrough (GWT) framework to help guide customers to correct features they need to get them enabled, taking into the consideration various clients and editions of service they might have.

It is worth mentioning that scenarios and steps listed in these GWTs apply to both Exchange Online and on-premises Exchange Server deployments. Typically, the on-premises workflow is the same as can be found if one chooses the “Enterprise Edition” option in those GWTs. Because many of these scenarios are what end-users can accomplish, I would be interested to hear your feedback whether a purely on-premises version would be useful, seeing that on-premises organizations are likely to have resources such as internal help desks and training. Please elaborate a bit in comments if you can, in case you see the value is separate versions?

Here are the new GWTs:

• Sharing calendar and contacts in Office 365
• Setting up a mailbox that multiple users can access and use in Office 365
• Sending email from another person's mailbox or from a group in Office 365
• Accessing other people’s mailboxes in Office 365
• Creating and managing resource mailboxes (conference rooms/equipment) in Office 365

It has become a bit of a tradition to thank people who worked on GWTs when we announce them, so not to disappoint, I’d like to thank: Nagesh Mahadev, Jon Bradley, Charlotte Raymundo, Jon Hoerlein, Kweku Ako-Adjei, Sharon Shen, Chen Jiang as well as Scott Vidican, Adam Dudsic and Victor Zhang (ECO).

Hope you find this useful. You can give us feedback on Exchange GWTs by either posting a comment in this post (if it is about the 5 GWT listed above) or emailing ExchGWTfeedback AT microsoft.com if it's about any Exchange GWTs.

Nino Bilic

Recently, we have seen some questions about what the Update-DatabaseSchema cmdlet in Exchange 2013 is about. So I thought I would share some additional information on the subject.

The Update-DatabaseSchema cmdlet is a part of the infrastructure that we’ve built into Exchange 2013 to safely upgrade database schema in a DAG deployment. Unlike previous releases, a database schema upgrade in Exchange 2013 can only occur after all DAG members are upgraded to a version of software that supports the schema version and there is control over when the schema upgrade occurs (setting RequestedDatabaseSchemaVersion to a value higher than CurrentSchemaVersion up to the MaximumSupportableDatabaseSchemaVersion supported by all members of DAG). The RequestedDatabaseSchemaVersion of a database cannot be incremented to a value higher than the minimum of MaximumSupportableDatabaseSchemaVersion supported by any DAG member. This design prevents issues like those encountered during upgrade Exchange 2010 DAG members to post-RTM service packs and automatically upgrading database schema version when mounting database on an upgraded server (no longer able to mount on a server that has not yet been upgraded).

The initial database schema version will be based on the server version(s) deployed in the DAG. The Exchange 2013 RTM database schema version is 0.121 and can be displayed using get-MailboxDatabase or get-MailboxDatabaseCopyStatus in CU2 and later. MaximumSupportableDatabaseSchemaVersion has incremented in each CU release, so databases created with server versions after RTM may be created with a schema version higher than 0.121. Prior to CU3, the Update-DatabaseSchema cmdlet could be used to manually set RequestedDatabaseSchemaVersion value higher than CurrentSchemaVersion (version at database creation). In CU3, setup (during build-to-build upgrade) was modified to automatically request upgrade of database schema version on existing databases to MaximumSupportableDatabaseSchemaVersion (0.126) for databases created with a lower schema version. By design, the attempt to set RequestedDatabaseSchemaVersion to 0.126 only succeeds when the last member of DAG is upgraded to CU3. All database schema upgrades are serial and are performed at mount time after a RequestedDatabaseSchemaVersion value is set, so an upgrade from 0.121 (RTM) to 0.126 (CU3) will involve 5 distinct schema upgrades (transactions).

It should be noted that database schema upgrades only involve global tables in a database. There is also a schema associated with tables associated with each mailbox and a mailbox schema upgrade can modify any table associated with a mailbox. After a database schema upgrade is performed during database mount, corresponding mailbox schema upgrades can be performed on subsequent logon to a mailbox. The schema version of a mailbox can be displayed using get-MailboxStatistics and will match the database schema version after first logon occurs after database schema upgrade completes.

We internally have the ability to control the MaximumSupportedDatabaseSchemaVersion for each target environment (test, dogfood, production service, on-premises) where an Exchange Server can be deployed explicitly and only increment the value supported in an environment in a given build after we have built high confidence with that change. We progressively built high confidence in the safety of performing a schema upgrade in our test, dogfood and Exchange Online environments and completed in-place database schema upgrades in Exchange Online prior to shipping CU3. It was this validation in our production service that led to the decision to enable this automated upgrade for our on-premises customers so that they could begin to reap the benefits enabled by these schema changes. This same validation will be performed for any schema upgrades included with future CU/SP releases.

You might ask yourself at this point: what are those benefits? Since the release of Exchange 2013, we have used database schema upgrades to help tweak performance on the database level, and envision that we will continue to do so in the future. Another thing to note is that we will not be automatically incrementing the version at every release (a cumulative update or a service pack) but will change the schema only when there is a specific benefit to be had.

The following shows the cmdlets that can be used to display the schema versions supported by servers hosting each database copy, the schema version of each database, and schema version of each mailbox.

[PS] D:\data\scripts>$identity = "forest noll"
[PS] D:\data\scripts>$m = get-mailbox $identity
[PS] D:\data\scripts>Get-MailboxDatabaseCopyStatus $m.database | FL Identity,status,*schema*

Identity : D12 MBX Store 18\15M31
Status : Mounted
MinimumSupportedDatabaseSchemaVersion : 0.121
MaximumSupportedDatabaseSchemaVersion : 0.126
RequestedDatabaseSchemaVersion :

Identity : D12 MBX Store 18\D15M41
Status : Healthy
MinimumSupportedDatabaseSchemaVersion : 0.121
MaximumSupportedDatabaseSchemaVersion : 0.126
RequestedDatabaseSchemaVersion :

Identity : D12 MBX Store 18\15M30
Status : Healthy
MinimumSupportedDatabaseSchemaVersion : 0.121
MaximumSupportedDatabaseSchemaVersion : 0.126
RequestedDatabaseSchemaVersion :

Identity : D12 MBX Store 18\D15M40
Status : ServiceDown
MinimumSupportedDatabaseSchemaVersion :
MaximumSupportedDatabaseSchemaVersion :
RequestedDatabaseSchemaVersion :

[PS] D:\data\scripts>Get-MailboxDatabase $m.database -status | FL *schema*
CurrentSchemaVersion : 0.126
RequestedSchemaVersion : 0.126

[PS] D:\data\scripts>Get-MailboxStatistics $m | FL *schema*
CurrentSchemaVersion : 0.126

Hopefully this helps understanding what this is for!

Todd Luttinen

What is Directory Based Edge Blocking?

The Directory Based Edge Blocking (DBEB) feature in Exchange Online Protection (EOP) lets you reject messages for invalid recipients at the service network perimeter. DBEB lets admins add mail-enabled recipients to Azure Active Directory and block all messages sent to email addresses that aren’t present in Azure Active Directory.

If a message is sent to a valid email address present in Azure Active Directory, the message continues through the rest of the service filtering layers (anti-malware, anti-spam, transport rules). If the address is not present, the service blocks the message before filtering occurs, and a non-delivery report (NDR) is sent to the sender informing them that their message was not delivered.

How is DBEB enabled?

Admins can manage the DBEB feature through configuration of the domain type in the Exchange admin center (EAC). The EAC exposes two domain types:

• Authoritative - Email is delivered to valid recipients in your organization which may include local recipients as well as recipients whose messages are being routed to a shared environment. All email for unknown recipients is rejected. Setting this domain type is what enables DBEB.
• Internal relay - Email is delivered to recipients in your organization or relayed to an email server at another physical or logical location.

What does this mean for you?

There are three ways for you to purchase Exchange Online Protection (EOP). In most ways they are the same, but there are some differences. How new features are deployed is one of the differences.

EOP Standalone

You now have the ability to change your domain type in the EAC. Once the feature has been fully deployed the messages for invalid recipients will start being rejected for domains that have been configured as Authoritative.

The default domain type for a new domain in EOP Standalone is Internal relay. This domain type allows your email messages to route through EOP and have all the rules and filtering applied to them for all recipients for each of your domains.

In order to enable DBEB you need to change your domain type to Authoritative after configuring directory synchronization and ensuring that all of your mail enabled objects are present. This changes the behavior of the service so that it rejects all messages at the network perimeter to any recipient for your domain that is not present in Windows Azure Active Directory. For more information about how to set up directory synchronization, see "Use directory synchronization to manage recipients" in Manage Recipients in EOP.

EOP as part of the Exchange Enterprise CAL with Services and with Exchange Online

You have always had the ability to change your domain type in the EAC. This means that you may already have synchronized your users and configured your domains as Authoritative in order for recipient blocking to occur within EOP. The difference for you is more subtle.

Currently, messages for invalid recipients enter the filtering network and are being rejected during the same process which processes your Transport Rules. With the introduction of DBEB, messages will now be blocked ahead of the Transport Rules in the messaging pipeline.

You’ll know that the deployment is complete for your organization when you see an increase in your SMTP blocked message count in the received spam report. A reporting update is coming soon that will separate the DBEB specific blocks from the other SMTP blocks, so if you have the updated report before DBEB finished deployment, you’ll see the message count in the DBEB section of the received spamreport.

Information for Upgraded FOPE Customers

In FOPE Directory Based Edge Blocking (DBEB) allows you to upload a list of legitimate SMTP addresses to the service and take action based on those addresses. The only action that’s being introduced for DBEB in EOP is the equivalent of “Reject”.

We’ll migrate all enabled users that are present in the FOPE Administration Center to Office 365 as part of your transition from FOPE to EOP. This will ensure that your current list of FOPE users is present in the Windows Azure Active Directory when you’re upgraded. We strongly recommend that if you have any clean-up to do for the users currently in FOPE, you should do so prior to your upgrade. We also recommend that you configure directory synchronization with Office 365 before updating your MX record to point to EOP. The directory synchronization has built in logic to match up any existing user objects in Office 365 with their on-premises directory objects, based on properties like SMTP proxy address. For more information about how to set up directory synchronization, see "Use directory synchronization to manage recipients" in Manage Recipients in EOP.

For each domain within your organization, the User List Source and Directory-Based Edge Blocking mode will determine the domain type used for your upgrade. If your User List Source in FOPE is configured to use Admin Center or Directory Synchronization Tool and your DBEB mode is set to Reject, your domain will be added to EOP and configured as Authoritative. All other User List Source + DBEB mode combinations will be added as Internal relay, so if you want to enable DBEB you’ll need to change this to Authoritative after your transition is complete.

What about everything else?

• User List Source = Secure FTP: SFTP is not supported in EOP, however we are adding the ability to manage users and groups via PowerShell and will provide guidance for updating them using PowerShell. We understand that this is a change, but we believe it will be significantly better in the long term. You will still be able to manage your users and groups in bulk, as well as schedule and automate the import, so we are hopeful this will fill the same feature niche which SFTP was filling in FOPE. In EOP there are no Virtual Domains as the functionality has been replaced by being able to define specific Transport Rules, Spam Policy and Criteria Based Routing based on Groups. If your current User List Source is Secure FTP, you will not be migrated until the ability to use PowerShell for loading the recipients, and the associated guidance, has been provided. This should be coming soon. After your upgrade is finalized you will need to add your users to Office 365 and update your domain type to Authoritative.
• User List Source = Legacy Directory Synchronization Tool: The Legacy Directory Synchronization Tool is not supported in EOP. In order to maintain DBEB for your domain you will need to configure directory synchronization with Office 365 and update your domain type to Authoritative.
• Directory-Based Edge Blocking mode = Reject-Test: Reject-Test will be migrated as Internal Relay. Reject-Test in FOPE allows all mail for valid recipients to pass through the service, and will redirect messages for invalid recipients to a specific mailbox. This is useful in scenarios where you’re not 100% confident that your entire user list is populated in the service. This condition is meant to be temporary only. Transport Rules in EOP can be used to mimic the behavior and would have to be tested to each customer’s desired configuration.
• Directory-Based Edge Blocking mode = Pass-Through: Pass-Through will be migrated as Internal Relay. Pass-Through in FOPE allows filtering to be applied only for a sub-set of recipients who are provisioned in the service, and bypass filtering for all other recipients. This is useful in scenarios where you’re routing mail through the service and want to see what the filtering impact is for a subset of your domain recipients. This condition is meant to be temporary only. Transport Rules in EOP can be used to mimic the behavior and would have to be tested to each customer’s desired configuration.
• Directory-Based Edge Blocking mode = Passive (Virtual Domain Creation Only): Passive will be migrated as Internal relay. Passive mode in FOPE allows you to configure Virtual Domains for that domain without needing to provide a user list for the Parent Domain. In EOP there are no Virtual Domains, as the functionality has been replaced by the ability to define specific Transport Rules, Spam Policy, and Criteria Based Routing based on Groups.

Wendy Wilkes
Senior Program Manager
Office 365 Customer Experience

Message trace enables administrators to trace email messages as they pass through Exchange Online or Exchange Online Protection (EOP) service. It helps you determine whether a message was received, rejected, deferred, or delivered by the service.

You’ve told us that you need to be able to trace messages older than the current period of one week. We’re excited to announce that we’re increasing the look back period for message trace in Exchange Online to 90 days!

The existing functionality of looking up messages for the last week will persist and those results will be viewable immediately. When you search for messages older than a week, the request will be submitted as an extended message trace request. After the request has been processed, the trace results will be delivered to you in a CSV file by email. An example of an extended message trace request is shown below.

We’re already rolling out this feature. Look for more details later this month.

This feature applies to Exchange Online and Exchange Online Protection services. On-premises customers have the capability to manage and search message tracking logs in Exchange Server.

Want to know more about this topic? Join the Exchange engineering team and MVPs at MEC 2014 for a chance to get your questions answered. Register today at IAMMEC.com.

Vandana Kumbla
Senior Program Manager

Many users rely on their smartphones and other mobile devices to access their email and calendar using Exchange ActiveSync (EAS). Any issues with mobile device access and EAS are noticed and reported immediately and a solution is expected just as quickly.

To assist you in troubleshooting EAS issues in your organization, we just released the Exchange ActiveSync Guided Walkthrough (GWT). You can use this walkthrough for troubleshooting some common EAS issues such as:

• Creating a profile on the device
• Connectivity issues
• Mail flow issues (unable to send/receive email)
• Calendaring issues
• Delays or server performance issues

Here's what it looks like:

Figure 1: The Exchange ActiveSync Guided Walkthrough

The goal for this walkthrough is to help you scope & resolve issues on your own by providing troubleshooting steps that can be used to address most common EAS issues. The tool also helps in log collection, analysis and taking appropriate steps to address common EAS issues.

Special thanks to Sharon Shen, Sainath Vijayaraghavan, Miguel Ortiz, and Matt Bromberger for their contributions in developing this troubleshooting tool.

Jim Martin

It’s been a while since we posted something related to intent and operation of this blog. Since our first post in 2004, we have worked hard to give you the latest news and upcoming details about various versions of Exchange that were “new” and “in-market” at the time. Yup, some of us have been with the blog from day one.

First and foremost, this blog is the official blog of the Exchange Product Group (the “Exchange Team”). This is the same team of program managers, developers, testers, and other engineers at Microsoft that build Exchange for both on-premises releases and for Exchange Online/Office 365. In many respects, one could think of this scenario as us creating one product and then shipping different product SKUs. While this is a bit of an oversimplification, think of it as a single code base that gets shipped to different customers in different ways. We went into some detail around explaining how this process works in our Servicing Exchange 2013 post(one of the crucial points being that the speed of innovation/engineering).

Please note that this post is not about the benefits or challenges of choosing one approach to deploying Exchange over the other. Suffice it to say that there are many different considerations organizations go through when deciding what the right approach is for them. We understand this diversity is here to stay, hence our recent post about The Road Ahead.

We Listen and Respond to Your Feedback

As always, we listen to and consider all customer feedback. It’s clear from the comments from readers of this blog that some of you feel that we are trying to deliberately push more Service-related content, with the ultimate motive being “to get everyone to Exchange Online.” And you’ve said that you want more “Exchange Team” and fewer “Office 365 Team” blog posts.

Since from engineering viewpoint, there is no difference, we plan to continue sharing engineering advancements with you about it all on this blog. Restricting this blog to on-premises content simply does not make sense, given the diversity of our customer base (on-premises, Exchange Online, hybrid mode, etc.).

Thus, in response to your feedback, we've created an On premises tag for all posts that are related to on-premises subjects, allowing you to readily view only on-premises content. Please know that if you only follow on-premises content, you might miss out on early views of product features delivered to Exchange Online first, and include those features in future on-premises releases or updates as appropriate (Rajesh’s post Development cadence in a cloud world reflects this). We believe this approach is the best way to provide a single location for all things Exchange while providing you the choice to select the types of content you feel is appropriate to your current situation. To be really clear: if a specific post applies to both on-premises as well as Exchange Online, it would be tagged as both.

A note about post comments

For a while now, we've been considering turning off anonymous comments. It has become a bit of a necessity to go through comments posted over a typical weekend and clean off the inevitable (and creative!) comment spam. While already making tweaks to the blog, we've decided we will turn off anonymous commenting on March 1st. That will give you a bit of time to register with TechNet and keep giving us feedback, and will give us a way to keep the blog comments free of those “special offers” much easier.

We commit to keep sharing relevant content with all of you, no matter which combination of our products you are using (and even if you’re not using them <g>).

Nino Bilic

Perry Clarke is back to geek out with you through his blog and the Geek out with Perry video series.

In this edition, Perry is joined by a new co-host, Julia White to discuss what it looks like to run a secure service in Exchange Online. The discussion covers the investments in the data center as well as customer control features available in the service to help customers manage risks. Read the blog and check out the video to hear the full conversation.

If you want to geek out with Perry and the Exchange team join them at MEC 2014 in Austin, TX. Go to iammec.com to learn more about the event and register today.

Brian Shiers
Technical Product Manager, Exchange

Challenge

Over the last year, as more customers have gone down the path of Hybrid Migration, we have seen more questions and forum posts on the subject. When looking at the reasons for this, it seemed clear that customers are in need of some additional guidance on how and when to perform troubleshooting steps if something goes wrong.

Currently there's a wide array of troubleshooting documentation out there in the form of blog posts, KBAs and videos. Unfamiliarity with the moving parts involved in a hybrid migration can make troubleshooting tricky.

Introducing the Hybrid Migration Troubleshooter

To help you with troubleshooting, we have released a new guided walkthrough (GWT) for Hybrid Mailbox moves. This link will soon be surfaced in various KB articles as well as the support ticket creation process.

The intent of this GWT is to take a tenant administrator step-by-step though the common troubleshooting tasks to solve their hybrid mailbox move issues and allow the customer to continue their deployment. We took the most common migration failure scenarios and put them into this easy to follow guide.

http://aka.ms/HybridMigrationGWT

Feedback and Distribution

The Hybrid Migration Troubleshooter is a tool that will continue to evolve over time. If you see any issues with the troubleshooter or think there are situations that should be added or improved, please let us know at MigrationGWT@microsoft.com.

A special thanks to all that contributed to the creation of the GWT: Kevyn Pietsch, Nagesh Mahadev, Richard Roddy, Jeff Miller, Timothy Heeney. And to the writers and KE team for assisting with collaboration and coordination efforts: Charlotte Raymundo, Dee Dee Woodward, Sharon Shen.

More GWTs for Cutover, Staged, and IMAP migration coming very soon… stay tuned!

Timothy Heeney

We are excited to announce that the ExchangeOn-Premises TAP Programis accepting nominations! 

The purpose of this post is to provide you with the opportunity to nominate your company for the Exchange On-Premises Technology Adoption Program (TAP) Program. Joining the Exchange On-Premises TAP Program provides companies with a number of advantages, such as providing input and feedback for future releases, developing a close relationship with the Exchange Product Team; receiving pre-release information about Exchange, and more. 

Exchange On-Premises TAP Program Overview

The Exchange On-Premises TAP Program is designed to validate the next version of Exchange Server by having customers test deployments of pre-release builds of Exchange in their own production environment. This gives participants the opportunity to provide feedback to the Exchange product development team. Customers in the TAP Program are provided free support from Microsoft Customer Services and Support (CSS) for issues encountered with Exchange. Additional information on the TAP Program is discussed in this blog entry from a number of years ago, which is still quite relevant today: http://msexchangeteam.com/archive/2004/12/29/343848.aspx

What's in it for TAP Program customers?

• A close relationship with the Exchange product team.
• An opportunity to provide feedback on future releases of Exchange directly to the product team.
• Technical conference calls with members of the product team.
• Production grade pre-release builds of Exchange Server.
• Access to free CSS Support for Exchange issues for the duration of the Exchange TAP Program (CSS support is 24/7 for any critical issues found in production).
• A head start in the next deployment cycle, taking advantage of new and enhanced features available in the next version of Exchange Server.

What do I have to commit to in order to participate in the Exchange TAP Program?

• Jump through a few legal hoops (signing some legal documents such as an NDA).
• Go through a few steps that will help assure easy communication between you and Microsoft (details will be provided when applicable)
• Deploy pre-release versions of Exchange Server in your production environment.
• Commit to timely response of surveys and feedback requests from Microsoft.
• Commit to providing resources for TAP Program activities for the duration of the program - people/time as well as machines needed for testing and production, and associated operating system software licenses.
• Provide us with deployment plans, including details of network topologies and additional reports, as applicable.  (Required before we can give production approval for the pre-release code.)

What makes a good TAP Program candidate?

• Willing to dedicate the resources (people/time and machines) to testing pre-release builds of Exchange in production. We find that we get some of our best feedback through production deployments, and so we will prioritize nominations from customers willing to be aggressive in their production rollouts higher.
• Responsive to our requests for feedback, including responding to surveys and attending conference calls and participating in a distribution list.
• Gives constructive criticism with context - don't just stop at "I don’t like feature X," provide us more information like "Here's why feature X won’t work for my Exchange environment, and here's why I think doing it another way would be better."
• Gives feedback even when not requested. We may not have sent out a survey or had a call about a topic, but if something about the product is problematic for you-- or you love it! :-) - we want to know.

Summary

If you feel your Company fits what we are looking for, you can nominate yourself by filling out this form:

On-premises TAP Program self-nomination form

Note: This form is located on an Office 365 site and is for our business customers to self-nominate for inclusion in future Office pre-release programs. If you are a Microsoft representative and would like to nominate a customer you are working with, please contact us directly and we will provide appropriate guidance.

All nominations, internal and external, are reviewed and screened prior to acceptance into a program. No customers are allowed access to any pre-release downloads or information until all legal paperwork is properly executed. Nomination does not mean acceptance… not all nominees will be chosen for a program.

Thank you!

David Espinoza
Senior Program Manager, Customer Experience Team

Exchange 2013 debuted last year with the ability to configure a Hierarchical Address Book (HAB) for on premises deployments.

As many of our customers are migrating and evaluating the cloud, a consistent user experience between online and on premises deployments is not just a requirement, but an expectation. As such, we are really excited to announce the availability of HAB to Office 365 users, worldwide!   

Now, a tenant administrator for Office 365 is able to configure a HAB using the same commands one would in an on premises deployment.

For more information on how to configure and use a HAB, please refer to HierarchicalAddressBooks: Exchange 2013 Help‎.

FAQ

We are moving some of our user mailboxes to Office 365 while keeping some in our on premises infrastructure. Are the users able to see the same HAB?

No, we are working to resolve a possible issue of the HAB being out of sync in this hybrid deployment case. A solution will be available in the near future.

Can Outlook Web App (OWA) users use the HAB?

No, browsing the HAB is available for Outlook 2010/2013 only at this time.

Paul Lo

We wanted to make certain that Exchange admins are aware of an Outlook issue which may impact your plans to move to Exchange Server 2013. As discussed in KB:2934750, Outlook 2013 customers who deployed client updates released in November and December of last year may experience a profile migration error post mailbox migration. When this occurs, it might not be possible to use normal Profile Repair options to restore connectivity. Older versions of Outlook, including Outlook 2013 without the November and December updates will function normally. An Outlook update which resolves this issue is nearing completion and being worked with priority to be released as soon as possible. The Exchange team is working closely with the Outlook team to verify the fix.

The Exchange Team

With Exchange 2013, we released a new data loss prevention (DLP)capability based on deep content analysis that helps you identify, monitor, and protect sensitive information. We’re continually looking to expand our DLP capabilities, and today we’re bringing two new ones to you—Document Fingerprinting and Policy Tips in Outlook Web App (OWA). Both are being rolled out for Office 365 users right now, and they’ll be part of the Exchange Server 2013 SP1 release for our on-premises users (please stay tuned for more information on SP1).

Watch this short video that explains what DLP has to offer today and how the new capabilities can help your organization be more compliant.

Let’s look at these two new capabilities in more detail.

Document Fingerprinting

Document Fingerprinting enables you to match documents that are derived from the same template. This can be useful for organizations that frequently use standard forms or templates, for example:

• A hospital that has an insurance form that patients fill in, each with a different insurance provider.
• A tax processing office that uses several standard tax forms that it applies to a wide range of situations.
• A law firm that uses a standard template to drafts patent applications that it files on behalf of its clients.

To understand how this works, let’s take a look at a scenario.

Contoso Pharma is a pharmaceutical company with a research division. Employees in the research division collaborate with their peers across the company to create new products and services, and file patents to protect their intellectual property. The law firm used by the company for patent filing uses a standard template for patent applications.

Say you’re an administrator at Contoso Pharma. You can use Document Fingerprinting to define a customized sensitive information type called “Patents.” To do so, you use the new administrative interface in the Exchange Admin Center (EAC) to create a new document fingerprint. Select the file you want to fingerprint, and then select the standard template that employees use for that file, in this case, patent applications.

 
You create document fingerprints in the EAC by selecting the file and then the sensitive information type.

This creates a template of that kind of document, which is used to detect other documents that are derived from the template.

When you fingerprint a document, a template of that kind of document is created (1) that is then used to detect documents (2) created with it.

Continuing with our Contoso Pharma scenario, once the patent template is fingerprinted, you (as an administrator) can use the existing Exchange Transport Rules and DLP infrastructure to create a rule to detect email with sensitive information of type “Patents” and define any of the supported actions in DLP. For example, you could block emails with patent documents attached from being sent externally. If Contoso Pharma uses an outside counsel for filing patents, you can allow users to send the email with an override option from Policy Tips! (See the introduction to Policy Tips in OWA section below.)

Although the scenario above refers to patents, you can easily imagine document fingerprinting being used to detect sensitive information in many other circumstances, like a hospital fingerprinting custom forms that contain personal health information, or a tax processing agency fingerprinting the 1040 EZ or W2 forms in the U.S.A.

Document fingerprinting is just one method organizations can use to detect sensitive content. Here’s a quick guide to the different methods of detecting sensitive content and the uses of each:

• Detection of standardized entities supported by Microsoft out of the box. If you want to detect standard entities like credit cards, debit cards, and so on, check if this kind of detection is supported in the out-of-the-box list provided by Microsoft and, if it is, use it. You can customize this method of detection; learn how in this TechNet topic.
• Developing Sensitive Information rule packages. If you need to detect entities that are specific to your organization (for example, an insurance number or an employee number),you can develop custom rules based on a combination of regular expressions and keywords. For details, see this TechNet topic.
• Document Fingerprinting. If you have an established business practice in which you use standard forms or templates (for example, patent filings, health insurance forms, tax forms, and so on), you can use document fingerprinting to detect the completed forms. For details, see the Document Fingerprinting topic on TechNet.

Policy Tips in OWA

Policy tips are designed to notify users in your organization when they are sending sensitive information over email. Policy Tips are similar to MailTips, and you can use them in Outlook in several different ways to help your users avoid sending sensitive information in email. For example, you can use Policy Tips to:

• Inform your users of the presence of sensitive information and block the email from being sent.
• Educate your users through a Notify Policy Tip when sensitive content is present in their emails.
• Empower your users to make case by case decisions by allowing them to override the sensitive information policy—with the option of including a business justification for the override.

With this new release in the Office 365 service and Exchange Server 2013 SP1, all the rich capabilities of Policy Tips previously available in Outlook 2013 will now also be available across the OWA interfaces.

As an administrator, you have the flexibility to set these different ways of using policy tips based on your business requirements. For example, you could set up a policy to only send a notification if an email contains one or two social security numbers, but block the mail from being sent and require a business justification if an email has a spreadsheet attached that contains more than 50 social security numbers.

DLP Policy Tips in OWA and OWA for Devices

As of Exchange 2013 SP1, OWA and OWA for Devices will both have Policy Tips support. The experience is in line with the experience in Outlook 2013, where users see a Policy Tip based on the DLP rules set by their administrator. If you already have a DLP policy with Policy Tips turned on, they will automatically apply in OWA. That means administrators do not need to create new configurations or turn switches on for this feature to work in OWA.

When you include sensitive information in an email message, a DLP Policy Tip notifies you before you send the message.

Policy Tips in OWA also show the user what sensitive content was detected in an email; in Outlook, it also allows the user to report back to the administrator if they think the email content is not sensitive. This empowers users that are closest to the data to provide feedback on the efficacy of detecting sensitive content.

A callout displays the sensitive content that was detected in the email and allows the user to report a mistake in the detection.

Administrators can also block emails that contain a large number of sensitive content (for example, an Excel attachment with more than 50 credit card numbers). Just as in Outlook 2013, the attachment with the sensitive content is highlighted so the user can easily identify it. Depending on the organization’s policy, users can be empowered to override the policy—with the option of requiring them to include a business justification—and send the email.

Policy Tips can be set up to block users from sending a large amount of sensitive content; attachments with sensitive content are highlighted for the user.

These experiences are also replicated on all mobile devices, from Windows Phone to iOS and Android devices.

Policy Tips can be set up on the Mobile devices to educate users

Different kinds of Policy Tips can be triggered based on conditions, like the amount of sensitive data in an email. No new configuration is required to do this, if DLP in Outlook has already been enabled.

Shared configuration

Policy Tips in Outlook 2013 are turned on when an administrator creates a rule with a action to notify the end user with a policy tip, or configures a DLP policy with such a rule. In Exchange 2013 these rules are applied on both the server and the client (that is, Outlook 2013). These same rules now get applied in exactly the same manner in OWA as well. This means that Exchange, Outlook, and OWA all share these configurations:

• Exchange Transport Rules. When you configure a transport rule to look for sensitive content in an email, and take Policy Tip-based actions on them, they are uniformly applied in Outlook and OWA. This includes the predicates likes detecting sender group membership, and other properties of recipients as well. Specifically, the NotifySender action in Exchange Transport Rules triggers Policy Tips for both Outlook and OWA.

Different kinds of Policy Tips options can be triggered based on conditions, such as the one above where we notify the user about sensitive information but allow them to send the message.

• Definitions of sensitive content. When you configure a transport rule to look for any of the out-of-the-box sensitive content or any custom sensitive types, they are evaluated in exactly the same manner in all three places, Exchange, Outlook, and OWA. Specifically, the MessageContainsDataClassifications predicate in Exchange Transport Rules defines the sensitive content for both Outlook and OWA.

You can defining sensitive content for Outlook and OWA when you configure a transport rule.

• Policy Tip configurations. When you edit the Policy Tip configurations to customize the text displayed in a Policy Tip, or the Compliance URL, they are updated in Outlook 2013, OWA, and OWA for Devices.

Custom Policy Tip configurations, like compliance URLs or customized notification texts, are applied uniformly in Outlook, OWA, and OWA for Devices.

DLP planning and implementation are crucial for most organizations, because they impact the organization as a whole and all the users who work with sensitive data. Protecting sensitive information without decreasing users’ productivity is a key principle of DLP in Office 365, and Policy Tips and Document Fingerprinting can help you do just that. We hope adding these capabilities to our DLP arsenal will help make DLP management easier for your users. Stay tuned for more news about our work in compliance.

Shobhit Sahay

The Exchange team is announcing the availability of the following updates:

• Update Rollup 5 for Exchange Server 2010 Service Pack 3
• Update Rollup 13 for Exchange Server 2007 Service Pack 3

Exchange Server 2010 Service Pack 3 Update Rollup 5 resolves customer reported issues and includes previously released security bulletins for Exchange Server 2010 Service Pack 3. A complete list of the issues resolved in this rollup is available in KB2917508.

Exchange Server 2007 Service Pack 3 Update Rollup 13 provides recent DST changes and adds the ability to publish a 2007 Edge Server from Exchange Server 2013. Update Rollup 13 also contains all previously released security bulletins and fixes and updates for Exchange Server 2007 Service Pack 3. More information on this rollup is available in KB2917522.

Neither release is classified as a security release but customers are encouraged to deploy these updates to their environment once proper validation has been completed.

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

The Exchange Team

Exchange Server 2013 Service Pack 1 (SP1) is now available for download! Please make sure to read the release notesbefore installing SP1. The final build number for Exchange Server 2013 SP1 is 15.00.0847.032.

SP1 has already been deployed to thousands of production mailboxes in customer environments via the Exchange Server Technology Adoption Program (TAP). In addition to including fixes, SP1 provides enhancements to improve the Exchange 2013 experience. These include enhancements in security and compliance, architecture and administration, and user experiences. These key enhancements are introduced below.

Note: Some of the documentation referenced may not be fully available at the time of publishing of this post.

Security and Compliance

SP1 provides enhancements improving security and compliance capabilities in Exchange Server 2013. This includes improvements in the Data Loss Prevention (DLP) feature and the return of S/MIME encryption for Outlook Web App users.

• DLP Policy Tips in Outlook Web App – DLP Policy Tips are now enabled for Outlook Web App (OWA) and OWA for Devices. These are the same Policy Tips available in Outlook 2013. DLP Policy Tips appear when a user attempts to send a message containing sensitive data that matches a DLP policy. Learn more about DLP Policy Tips.
• DLP Document Fingerprinting – DLP policies already allow you to detect sensitive information such as financial or personal data. DLP Document Fingerprinting expands this capability to detect forms used in your organization. For example, you can create a document fingerprint based on your organization’s patent request form to identify when users are sending that form, and then use DLP actions to properly control dissemination of the content. Learn more about DLP Document Fingerprinting.
• DLP sensitive information types for new regions – SP1 provides an expanded set of standard DLP sensitive information types covering an increased set of regions. SP1 adds region support for Poland, Finland and Taiwan. Learn more about the DLP sensitive information types available.
• S/MIME support for OWA – SP1 also reintroduces the S/MIME feature in OWA, enabling OWA users to send and receive signed and encrypted email. Signed messages allow the recipient to verify that the message came from the specified sender and contains the only the content from the sender. This capability is supported when using OWA with Internet Explorer 9 or later. Learn more about S/MIME in Exchange 2013.

Architecture & Administration

These improvements help Exchange meet our customer requirements and stay in step with the latest platforms.

• Windows Server 2012 R2 support – Exchange 2013 SP1 adds Windows Server 2012 R2 as a supported operating system and Active Directory environment for both domain and forest functional levels. For the complete configuration support information refer to the Exchange Server Supportability Matrix. This matrix includes details regarding Windows Server 2012 R2 support information about earlier versions of Exchange.
• Exchange Admin Center Cmdlet Logging – The Exchange 2010 Management Console includes PowerShell cmdlet logging functionality. Listening to your feedback, we’re happy to announce that this functionality is now included in the Exchange Admin Center (EAC). The logging feature enables you to capture and review the recent (up to 500) commands executed in the EAC user interface while the logging window is open. Logging is invoked from the EAC help menu and continues logging while the logging window remains open.

• ADFS for OWA – Also new for Outlook Web App in SP1 is claims-based authentication for organizations using Active Directory Federation Services. Learn more about the scenario.
• Edge Transport server role – SP1 also reintroduces the Edge Transport server role. If you have deployed Exchange 2013 with a supported legacy Exchange Edge Transport role, you don’t need to upgrade. That configuration is still supported. But we do recommend that future deployments use the Exchange 2013 Edge Transport role. Learn more about Edge Transport in Exchange 2013.
• New communication method for Exchange and Outlook – SP1 introduces a new communication method for Exchange Server and Microsoft Outlook called MAPI over HTTP(MAPI/HTTP). This communication method simplifies connectivity troubleshooting and improves the user connection experience with resuming from hibernate or switching networks. MAPI/HTTP is disabled by default, allowing you to decide when to enable it for your organization. MAPI/HTTP can be used in place of RPC/HTTP (Outlook Anywhere) for your Outlook 2013 SP1 clients while Outlook 2013 RTM and older clients continue to use RPC/HTTP. Learn more about deploying MAPI/HTTP.
• DAGs without Cluster Administrative Access Points - Windows Server 2012 R2 introduces failover clusters that can operate without an administrative access point: no IP addresses or IP address resource, no network name resource, and no cluster name object. SP1 enables you to create a DAG without an administrative access point on Windows Server 2012 R2 from EAC or PowerShell. This is an optional DAG configuration for SP1 and requires Windows Server 2012 R2. DAGs with administrative access points continue to be supported. Learn more about creating a DAG without an administrative access point here and here.
• SSL offloading – SP1 now supports SSL offloading, allowing you to terminate incoming SSL connections in front of your CAS servers and move the SSL workload (encryption & decryption tasks) to a load balancer device. Learn how to configure SSL offloading in Exchange 2013.

User Experience

We know the user experience is crucial to running a great messaging platform. SP1 provides continued enhancements to help your users work smarter.

• Enhanced text editor for OWA - OWA now uses the same rich text editor as SharePoint, thereby improving the user experience, and enabling several new formatting and composition capabilities that you expect from modern Web application - more pasting options, rich previews to linked content, and the ability to create and modify tables.

• Apps for Office in Compose – Mail apps are now available for use during the creation of new mail messages. This allows developers to build and users to leverage apps that can help them while they are composing mails. The compose apps leverage the Apps for Office platform and can be added via the existing Office store or corporate catalogs. Learn more about Apps for Office.

Upgrading to SP1/Deploying SP1

As with all cumulative updates (CUs), SP1 is a full build of Exchange, and the deployment of SP1 is just like the deployment of a cumulative update.

Active Directory Preparation

Prior to or concurrent with upgrading or deploying SP1 onto a server, you must update Active Directory. These are the required actions to perform prior to installing SP1 on a server.

1. Exchange 2013 SP1 includes schema changes. Therefore, you will need to execute the following command to apply the schema changes.

setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

2. Exchange 2013 SP1 includes enterprise Active Directory changes (e.g., RBAC roles have been updated to support new cmdlets and/or properties). Therefore, you will need to execute the following command.

setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms

Server Deployment

Once the above preparatory steps are completed, you can install SP1 on your servers. Of course, as always, if you don’t separately perform the above steps, they will be performed by Setup when you install your first Exchange 2013 SP1 server. If this is your first Exchange 2013 server deployment, you will need to deploy both Client Access Server and Mailbox Server roles in your organization.

If you already deployed Exchange 2013 RTM code and want to upgrade to SP1, you will run the following command from a command line.

setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms

Alternatively you can start the installation through the GUI installer.

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/Service Pack releases.

Looking Ahead

Our next update for Exchange 2013 will be released as Exchange 2013 Cumulative Update 5. This CU release will continue the Exchange Server 2013 release process.

If you want to learn more about Exchange Server 2013 SP1 and have the opportunity to ask questions to the Exchange team in person, come join us at the Microsoft Exchange Conference.

Brian Shiers
Technical Product Manager, Exchange

A while back we promised an article on namespace planning and load balancing principles with Exchange 2013. We’re finally going to fulfill that promise as a series of articles.  The articles will span several topics, including namespace planning, load balancing, client connectivity coexistence, and certificate planning.  As the title suggests, this first article will cover namespace planning principles.

Namespace Planning

If you are like the vast majority of our customers, you already have some version(s) of Exchange deployed in your environment. Depending on the version, you may have different namespace requirements today.

Exchange 2007

In Exchange 2007 environments, at a minimum, you had two namespace scenarios:

1. An Autodiscover namespace – autodiscover.contoso.com.
2. One or more protocol-based namespaces – mail.contoso.com (for OWA, EAS, etc.); imap.contoso.com (for POP/IMAP clients); smtp.contoso.com (for SMTP client submissions, ad-hoc encryption or partner-to-partner encryption).

In addition, if you deployed in a multi-datacenter environment, you most likely had additional protocol-based namespaces for each region.

Exchange 2010

Like Exchange 2007, Exchange 2010 leverages the Autodiscover service for enabling client profile changes, so that namespace exists.

For customers that upgraded from Exchange 2007 (or Exchange 2003), a new namespace requirement was introduced for coexistence – the legacy namespace, legacy.contoso.com. Though it is important to note that the legacy namespace can be called anything you choose, alderaan.contoso.com for example.

Exchange 2010 introduced additional namespace requirements, which resulted in additional complexity around namespace planning, especially for site resilient solutions:

1. Primary datacenter Internet protocol namespace (mail.contoso.com)
2. Secondary datacenter Internet protocol namespace (mail2.contoso.com)
3. Primary datacenter Outlook Web App failback namespace (mailpri.contoso.com)
4. Secondary datacenter Outlook Web App failback namespace (mailsec.contoso.com)
5. Transport namespace (smtp.contoso.com)
6. Primary datacenter RPC Client Access namespace (rpc.contoso.com)
7. Secondary datacenter RPC Client Access namespace (rpc2.contoso.com)

Out of these nine namespaces, seven of them were required on certificates. The RPC Client Access namespaces were not required on the certificate because they were accessed via RPC connectivity and not via an Internet-based protocol, like HTTP.

Exchange 2013

One of the benefits of the Exchange 2013 architecture is that the namespace model can be simplified, when compared to Exchange 2010.

An example of how it can be simplified can be seen when thinking about a site resilience scenario. If you have two datacenters participating in a site resilient architecture, by replacing the Exchange 2010 infrastructure with Exchange 2013, five namespaces could potentially be removed:

1. Secondary datacenter Internet protocol namespace (mail2.contoso.com)
2. Primary datacenter Outlook Web App failback namespace (mailpri.contoso.com)
3. Secondary datacenter Outlook Web App failback namespace (mailsec.contoso.com)
4. Primary datacenter RPC Client Access namespace (rpc.contoso.com)
5. Secondary datacenter RPC Client Access namespace (rpc2.contoso.com)

There’s two reasons for this.

First, Exchange 2013 no longer leverages an RPC Client Access namespace. This is due to the architectural changes within the product - for a given mailbox, the protocol that services the request is always going to be the protocol instance on the Mailbox server that hosts the active copy of the database for the user’s mailbox. In other words, the RPC Client Access service is no longer decoupled from the store, like it was in Exchange 2010.

Second, as mentioned, CAS2013 proxies requests to the Mailbox server hosting the active database copy. This proxy logic is not limited to the Active Directory site boundary. Unlike Exchange 2010, Exchange 2013 does not require the client namespaces to move with the DAG during an activation event – a CAS2013 in one Active Directory site can proxy a session to a Mailbox server that is located in another Active Directory site. This means that unique namespaces are no longer required for each datacenter (mail.contoso.com and mail2.contoso.com); instead, only a single namespace is needed for the datacenter pair – mail.contoso.com. This also means failback namespaces are also not required during DAG activation scenarios, so mailpri.contoso.com and mailsec.contoso.com are removed.

Namespace Models

Depending on your architecture and infrastructure you have two choices:

1. Deploy a unified namespace for the site resilient datacenter pair (unbounded model).
2. Deploy a dedicated namespace for each datacenter in the site resilient pair (bounded model).

It’s also worth mentioning that these choices are also tied to the DAG architecture.

Unbounded Model

In an unbounded model, you have a single DAG deployed across the datacenter pair. This DAG has Mailbox servers in each datacenter – typically all Mailbox servers are active and host active database copies, however you could deploy all active copies in a single datacenter. Mailboxes for both datacenters are dispersed across the mailbox databases within this DAG. In this model, clients can connect to both datacenters in the event there is a WAN failure – neither datacenter’s connectivity is a boundary, hence the term unbound. It does not guarantee, however, the connectivity provides users an equal experience; meaning one connection may provide a better user experience because it has lower latency or more bandwidth.

In an unbounded model, a single namespace is preferred because either datacenter can service the user request. This means that from a load balancing perspective, the CAS infrastructure in both datacenters participate in handling traffic, as seen in the following diagram:

Figure 1: Single Namespace used across Site Resilient Datacenter Pair (Unbounded Model)

As a result, for a given datacenter, the expectation is that 50% of the traffic will be proxied from the other datacenter.

Bounded Model

As its name implies, in a bounded model, users are associated (or bound) to a specific datacenter. In other words, there is preference to have the users operate out of one datacenter during normal operations and only have the users operate out of the second datacenter during failure events. There is also a possibility that users do not have equal connectivity to both datacenters. Typically, in a bounded model, there are two DAGs deployed in the datacenter pair. Each DAG contains a set of mailbox databases for a particular datacenter; by controlling where the databases are mounted, you control connectivity.

In a bounded model, multiple namespaces are preferred, two per datacenter (primary and failback namespaces), to prevent clients trying to connect to the datacenter where they may have no connectivity. Switchover to the other datacenter is a controlled event.

Figure 2: Multiple Namespaces used across Site Resilient Datacenter Pair (Bounded Model)

Other Namespaces

Other namespaces are still required. Exchange 2013 takes advantage of the Autodiscover service for client profile manipulation; so the autodiscover.contoso.com namespace remains in place.

If you are planning to upgrade from Exchange 2007, a legacy namespace is required for connectivity. The legacy namespace provides connectivity for OWA, is the namespace returned in Autodiscover responses (e.g., Exchange Web Services URL), and provides access to Exchange 2007 mailboxes that exist in non-Internet facing Active Directory sites.

Internal vs. External Namespaces

Since the release of Exchange 2007, the recommendation is to deploy a split-brain DNS infrastructure for the Internet-based client namespaces. A split-brain DNS infrastructure enables different IP addresses to be returned for a given namespace based on where the client resides – if the client is within the internal network, the IP address of the internal load balancer is returned; if the client is external, the IP address of the external gateway/firewall is returned.

This approach simplifies the end-user experience – users only have to know a single namespace (e.g., mail.contoso.com) to access their data, regardless of where they are connecting. A split-brain DNS infrastructure, also simplifies the configuration of Client Access server virtual directories, as the InternalURL and ExternalURL values within the environment can be the same value.

In the event that you do not deploy a spit-brain DNS infrastructure, Exchange 2013 has introduced one improvement in this area – Outlook Anywhere now supports separate internal and external namespaces.

Regional Namespaces

The concept of regional namespaces has existed since OWA debuted in 1997 (can you believe OWA is almost 17 years old!?!). A regional namespace is a way for clients to connect to the Client Access endpoint that is closest to the Mailbox servers hosting the data.

Use of a regional namespace does not necessarily mean you are restricted to a bounded model, either. This is because depending on your infrastructure and network capabilities, you may choose to have a dedicated namespace for each datacenter pair. For example, your company may have a set of datacenters in North America and in Europe, and due to a desire to reduce cross-region network traffic, you deploy a dedicated namespace for each region (notice that within a region, the unbounded model is used):

Figure 3: Regional Namespaces

Conclusion

Exchange 2013 introduces significant flexibility in your namespace architecture, enabling deployment of a single unified namespace for a site resilient datacenter pair (or worldwide), or deployment of multiple namespaces.  As we delve into the intricacies surrounding load balancing principles, client connectivity, and certificate planning, you will understand (hopefully) how to choose the best namespace model.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience