Moving mailboxes is an important part of managing an email service. Check out the latest Geek Out with Perry blog and video to gain some deep insights on our approach to moving mailboxes with Mailbox Replication Service (MRS) and get Perry’s take on this topic and how it works. This technology is also incredibly important if you want to move mailboxes to the cloud on your terms with a hybrid deployment.

Want more details and info?

• Check out Ross’ past blog on mailbox moves and mailbox resiliency
• Read the TechNet info all about Understanding Move Requestswhich also includes information about the client experience during a move request.
• See Hybrid Deployments with the Hybrid Configuration Wizard on TechNet if you’d like to learn about setting up a hybrid deployment in order to move mailboxes to Exchange Online.

Need to Geek Out with Perry some more? Check out his blog and the playlist of videos on YouTube or from the MSN Video catalogue. He recently discussed immutability in Exchange which has been a really hot topic.

Keep on geeking out with us, send us your feedback and let us know if you have good questions for Perry to geek out on.

Ann Vu

This post describes an update to the Facebook provider for the Outlook Social Connector and the related policy settings that are available for Administrators.

Outlook 2010 includes a feature called the Outlook Social Connector which can show social updates for the people your users email with, directly in Outlook. Earlier this year, the Outlook team made an update to enable continued access to Facebook information as Facebook has moved to a new authentication model called OAuth. While making this change the transport has also been updated to use SSL to better secure the information transmitted between Facebook and Outlook.

Note: You do not need to enable the Outlook Social Connector to display GAL Photos in Outlook 2010. For more details, see GAL Photos in Exchange 2010 and Outlook 2010.

Starting on May 1st, 2012, users will see notifications in Outlook to update the Facebook provider for the Outlook Social Connector. If users have a previous version of the Facebook provider installed, the notification will lead the user to the updated version of the Facebook provider on Microsoft Download Center.

Current users of the Facebook provider must install the updated Microsoft Outlook Social Connector Provider for Facebook to avoid errors connecting to Facebook.

Users who don't have the Facebook provider installed but do have the Outlook Social Connector enabled will see a one-time notification that a new social network provider is available.

You can use Group Policy settings to control your user’s experience. For example, you can:

• block the notifications in the People Pane
• block a specific social network provider
• turn off the Outlook Social Connector entirely

To learn more about the available Group Policy settings, see KB 2020103: How to manage the Outlook Social Connector by using Group Policy.

Note: The Outlook Social Connector is also available as a separate download for Outlook 2007 and Outlook 2003. The same notifications and policy settings apply to OSC for Outlook 2007 or Outlook 2003.

The OSC team worked to help protect users' privacy. More details about how data is protected in Learn more about Outlook Social Connector and privacy.

The Outlook team also is blogging about this update. You can read their blog here.

Adam Glick

*But Were Afraid to Ask

This is a part 1 of a 3 part blog series. Please see this for Part 2 and this for Part 3.

If you find the inner workings of Exchange data backups using Volume Shadown Copy (VSS) a bit mystifying take comfort in not being alone. Administrators may ask, “What’s all the “freezing” and “thawing” I’m seeing in my event logs? What is the Exchange VSS Writer really, and what is it doing to my databases? How does it create a snapshot of a 135GB database in less than 60 seconds?”

If you ever asked these questions but only felt more confused with the answers, here’s a guide to clear some of that up. To understand how a VSS backup of Exchange works it’s critical to understand the basics of VSS itself. There is some excellent documentation on TechNet and MSDN on this, as well as the Windows Server Core Team blog, “Ask the Core Team.” My esteemed colleague Randy Monteleone sums up the basics of VSS very nicely early in his post, while also providing links (repeated here) to some good TechNet primers on VSS:

How To: VSS Tracing – Randy Monteleone
http://blogs.technet.com/b/askcore/archive/2012/04/29/how-to-vss-tracing.aspx

How Volume Shadow Copy Service Works
http://technet.microsoft.com/en-us/library/cc785914(WS.10).aspx

Volume Shadow Copy Service
http://technet.microsoft.com/en-us/library/ee923636.aspx

If you’re already familiar with at least the basics of VSS, then look forward to Part 2 in this series, where we will break down the events that occur in a VSS Exchange backup, and how Exchange logs them in the application event log.

If you need a quick primer or refresher on VSS basics and the Exchange Writer I’ve condensed them into some visual points below to complement the references above.

Snapshots

Bear in mind that VSS solutions for Exchange, and for all applications, vary greatly between different hardware and software configurations. There are clone and COW snapshots, hardware and software solutions, just a very wide variety of technologies based on the core VSS subsystem. For the purposes of understanding Exchange backups we’re only going to illustrate one specific type of solution out of the multitude. Detailed below is what’s called “copy-on-write”, or “COW” snapshots.

In a COW snapshot-based VSS backup of Exchange we have the creation of snapshots of the disks where Exchange data is hosted. No matter what is getting backed up, even if it’s a single database file and a few logs, VSS creates a snapshot of the entire disk where any data is stored. If the data resides across multiple disks, such as when an Exchange database is on one disk, and the logs are on another, VSS will create snapshots of any and all of those disks.

So what is a “snapshot”? A volume snapshot is an area of space inside what’s called “shadow storage”, which is itself a typically small area of space on the disk located in its System Volume Information folder.

After a disk snapshot is created a change to any data block from that time forward cannot get written until a copy of that block’s data before the change (as it was when the snapshot was created) gets written to the differencing area in shadow storage. In this way the data on the disk at the time the snapshot was created is preserved, block by block, in the shadow storage area. The snapshot data is then available either from the original disk, if the data blocks requested haven’t changed, or from the differencing area if they have. The fundamentals of this are illustrated below:

Disk E: has a snapshot created at 1PM:

A minute later one of the blocks gets written to, but not before the data as it was at 1PM gets preserved in the differencing area:

As the actual disk changes the data as it was at 1PM gets written into shadow storage, preserving a record of the disk as it was in that moment:

The following step:

In the figure above a backup server requests data from the snapshot of blocks 2 and 53. Block 53 from 1PM is preserved in the snapshot, so it’s copied directly from shadow storage. Block 2 is unchanged since 1PM, so it is copied via the VSS driver VOLSNAP.SYS, which operates much like a filter driver underneath the NTFS.SYS file system driver. By working in the IRP stack (the part of kernel memory that manages disk I/O) underneath the file system it can read blocks of data without NTFS objecting that a file is in use. VOLSNAP.SYS is also responsible for ensuring blocks are copied over to shadow storage if a write is requested to them, hence the name “Copy On Write”. Here is more about VOLSNAP.SYS from Tim McMichael:

Exchange / VSS / and differential block size…
http://blogs.technet.com/b/timmcmic/archive/2011/07/12/exchange-vss-and-differential-block-size.aspx

Now that we’ve got the basics of a COW snapshot down let’s look at how it works with Exchange, along with some other major concepts:

Microsoft Exchange Writer

So we know that any disk that stores Exchange data gets a snapshot created of it by VSS. How exactly, though, does a backup application find out which disks those are? Oftentimes an administrator selects databases for backup without specifying anything about what disks their data files are stored in. So something is required to provide the information about where the data files are, and therefore what disks VSS needs to create snapshots of. This information also tells a backup application, also known as a VSS requestor, what specific data files should be copied out of the snapshots for preservation on backup media, as we don’t want to copy out anything from the disk we don't need.

The mechanism at work here is the Microsoft Exchange VSS Writer. Like any application’s VSS writer (there are many, just run VSSADMIN LIST WRITERS to see them) its first job is to tell the backup application about the data needed for backup, especially the EDB file, logs, and checkpoint file for each database requested. The information about these specific Exchange data files is known as writer metadata.

(click thumbnail for full size version)

In the figure above we see the initial steps of an Exchange backup. The Exchange Writer tells the backup server (the requestor) that there is a database located in a folder on volume E:, and that transaction logs for that database are in a folder on D:. Based on that information the backup application will request snapshots of the D: and E: volumes when the job progresses.

The Exchange VSS Writer serves another critical role besides providing metadata to VSS requestors. It also has the job of stopping writes to the databases and logs on disk, or “freezing” them, for the time it takes to create the necessary snapshots. A COW snapshot typically takes a small amount of time to create, as all it consists of initially is the designation of an area in shadow storage for blocks to be preserved in when they change on the actual disk. Despite this relatively quick operation it can still take up to a minute, which is plenty of time for blocks of data to change on a disk between the start and the end of its snapshot creation process. If blocks of data change but don't have the originals preserved from the exact time the snapshot creation begins those blocks may become inconsistent with other snapshot data, especially between logs, database, and checkpoint files. Hence, the Exchange Writer prevents the Information Store Service, or the MS Exchange Replication Service, from writing what’s in RAM to the frozen database files. In the case of the Information Store Service, the current transaction log file (Exx.log) gets rolled and closed out before the Exchange Writer allows VSS to take the snapshot. This ensures nothing changes in the file data between the beginning of the snapshot and the completion, at which point the databases are “thawed”. When databases are thawed write I/O held in RAM is allowed to go to disk again.

Here's more information on how an application's VSS writer interacts with VSS with regards to freeze, thaws, and the time needed to get a snapshot completed:

CVssWriter::OnFreeze method
http://msdn.microsoft.com/en-us/library/windows/desktop/aa381563(v=vs.85).aspx

The last major responsibility of the Exchange Writer is to tell the Information Store Service (MS Exchange Replication Service in the case of a passive copy backup) that the backup was completed and, if applicable, carry out post-backup tasks like log truncation, marking the database as no longer with a backup in progress, etc.

In the part two and part three of this series we’ll look at a play-by-play breakdown of how the elements described above all come together in an Exchange backup, the application log events that get generated, and compare the process for a mounted database to that for a passive database copy.

Thanks go out for the collaboration on the content in these posts to Michael Blanton, Tim McMichael, Randy Monteleone, Dave Vespa, and Tom Kern.

Jesse Tedoff

* But Were Afraid to Ask

Part 2 of this series (Part 1 is here and Part 3 is here) breaks down the events that take place during the backup of a mounted and active replicated database in an Exchange 2010 Database Availability Group called, simply enough, “DAG”. In this example the backup server is asked to create a full backup of database DB1 on server ADA-MBX1, using non-persistent COW snapshots:

(please click thumbnails for full size version of graphics in this post)

Event 9606 indicates that the VSS requestor has engaged the Exchange writer, and reports the instance GUID for the backup job that is starting. In this case the instance is 830705de-32d9-4059-94ea-b9e9aad38615. This instance GUID persists throughout each job, and changes with each subsequent one. You can therefore use it to track the sequence of events for each individual job. At this time the Exchange Writer provides metadata about the databases and logs present to the backup application.

Events 2005 and 9811 indicate an instance number assignment for ESE. So along with the writer instance GUID from event 9606 we can also track a job’s progress using these ESE instance numbers which increment by one with each job. At this stage the database is marked with “backup in progress” in the Information Store Service's memory space.

Just after the backup application has determined which disks need snapshots created, based on the data locations provided by the Exchange Writer metadata, it goes ahead and requests those snapshots. As the snapshot requests arrive event 9608 gets generated, indicating the Exchange writer’s acknowledgment of what’s about to happen. It then must halt disk writes to the database(s) and logs, also known as a “freeze” for the duration of the snapshot generation process.

When event 2001 is generated the current transaction log is closed, and the freeze begins. Writes from STORE.exe to the disks are held in memory.

Once these events appear we know the snapshot(s) have been created, and writes are allowed to database data blocks again.

Once the snapshots are created the backup application can copy blocks of data from the VSS subsystem, getting blocks of data from shadow storage if they’ve been preserved due to a change, or from the actual disk volume if they haven’t. The Exchange Writer waits for the signal that the transfer of data is complete. This flow of data is represented by the purple arrows, which in this case indicates data getting copied out of the snapshots in storage, through I/O of the Exchange server, and on to the backup server.

Once the backup application finishes copying data it will signal VSS that it’s done. VSS in turn signals the Exchange writer, which then initiates post-backup steps, signified by the above events. Event 225 appears to state that log truncation won’t occur, but that event is misleading. For a standalone database, upon backup completion, ESE would go ahead and clear logs accordingly. However, when a DAG replicated database is involved a check of other database copies must be performed in coordination with the Exchange Replication Service to ensure log truncation can continue. Once that check is complete the logs eligible for truncation are deleted. The database header is marked with information about the backup and the backup in progress bit is switched off in memory. In this case the snapshots used for the job are destroyed as part of the completion. In other types of backups, such as incremental, the persistence of the snapshot varies, but in this case they are removed.

In the next post in this series we'll break down the backup of a passive DAG replicated database copy.

Jesse Tedoff

* But Were Afraid to Ask

In Part 1 and Part 2 of this series we looked at the fundamentals of Exchange backups using VSS, and the flow of an active DAG database backup.

In Part 3 we break down how a passive DAG database copy undergoes a full backup. The Exchange Writer responsible for passive copy backups doesn't run in the Information Store Service, but rather as part of the MS Exchange Replication Service. Among other functions, this service coordinates the backup process between the passive copy node and the active copy server. Similar to the backup of an active database described in Part 2, this post describes the backup of a passive database copy of DB1, hosted on server ADA-MBX1. The active mounted database copy is on ADA-MBX2, and again, a non-persistent copy-on-writer (COW) snapshot is utilized by the backup solution:

(please click thumbnails for full size version of graphics in this post)

The first steps to back up a passive database copy are about the same as for an active one. The backup application gets the metadata for DB1 from the Exchange Writer, but again, the writer is running in the MS Exchange Replication Service. A new writer instance GUID is generated which will persist throughout the job, as with an active database backup.

Event 2021 indicates that the backup application, or VSS requestor, has engaged the Exchange Writer. It will appear numerous times throughout the backup as different components are read from metadata, such as log and database file locations.

Events 2110 and 2023 indicate that the backup application has requested a particular set of components to back up, and the backup type.

The replication service for the passive copy’s server signals the active copy server that a backup is in progress. Events 910 and 210 on the active copy server, as well as 960 on the passive copy server, signify two things: First, they establish which server backing up a passive copy of the database; Second, the STORE service on the active copy server has marked the database with “backup in progress” in memory and acknowledges that the surrogate backup will proceed. Once this occurs it is not possible to backup the database again until either the current surrogate backup completes, or the “backup in progress” status is otherwise cleared.

Events 2025 and 2027 are generated when the replication writer prevents the replication service from writing logs copied from the active copy server to the local disk. Replay of logs also stops, thereby keeping the contents of the database files unchanged. At this point writes of data for the database getting backed up are “frozen”. VSS can now create the snapshots in shadow storage for each disk specified in the metadata.

VSS creates snapshots of disks D: and E:. Once these complete it signals the Exchange Writer, which in turns allows the replication service to resume log copy and replay. Events 2029 and 2035 are generated when the “thaw” is completed and normal disk writes are allowed to continue.

Once the snapshots are created the backup application can copy blocks of data through VSS, which transfers blocks of data from shadow storage if they’ve been preserved due to a change, or from the actual disk volume if they haven’t. The replication service writer waits for the signal that the transfer of data is complete. This flow of data is represented by the purple arrows, which in this case indicates data getting copied out of the snapshots in storage, through I/O of the Exchange server, and on to the backup server.

When the files necessary for backing up DB1 are safely copied to backup media, the backup application signals VSS that the job is complete. VSS in turn signals the replication writer, and Exchange generates events 963 and 2046 on the passive copy server. The replication service then signals the Information Store service on the active copy server that the job is done, and that log truncation can proceed if all necessary conditions are met. The active copy node generates events 913 and 213 signaling that the surrogate backup is done, and that the database header will be updated with the date and time of the backup.

Events 2033 and 2037 signal the end of the backup. The active copy node flushes and rolls the current transaction log containing database header updates. That log is then shipped and made eligible for replay according to schedule so that the passive database copy is marked with the new header information at the earliest available time. Log truncation also proceeds if possible. In this case the snapshots are destroyed, and normal operations continue.

For more on the subject of this series here are some more great references:

Volume Shadow Copy Service
http://technet.microsoft.com/en-us/library/ee923636(WS.10).aspx

Exchange VSS Writers
http://msdn.microsoft.com/en-us/library/bb204080.aspx

Overview of Processing a Backup Under VSS
http://msdn.microsoft.com/en-us/library/aa384589(VS.85).aspx

Backup Sequence Diagrams
http://msdn.microsoft.com/en-us/library/aa579076(v=exchg.140)

Troubleshooting the Volume Shadow Copy Service
http://technet.microsoft.com/en-us/library/ff597980(EXCHG.80).aspx

Jesse Tedoff

Last week, we announced The New Exchange. Today, we are excited to share its new, refreshed management experience.

For folks familiar with Exchange 2010, there are 3 ways to manage Exchange: the Exchange Management Console (EMC), the Exchange Control Panel (ECP), and the Exchange Management Shell (EMS).

As far as the GUI-based experience is concerned, customers are faced with an incongruous choice between EMC and ECP. While most of the management surface is exposed via EMC, some newer features such as Auditing, eDiscovery, RBAC management, Group naming policy, ActiveSync Quarantined Device management, etc., are only available in ECP. Since these features are applicable to both on-premises as well as online deployments, administrators are forced to learn multiple tools and juggle between them. Specifically for the MMC-based EMC, customers also have to bear IT overhead with respect to updates, patches and so on.

Wouldn’t it be pure bliss if you, the Exchange administrator (expert or novice), had just ONE seamless, integrated way to manage all of Exchange, be it on-premises, online, or even both?

Introducing the Exchange Administration Center (EAC)

With The New Exchange, we are proud to announce a brand new experience for the Exchange administrator: the Exchange Administration Center (EAC)! The EAC brings a completely refreshed, seamless, integrated and unified web-based experience.

(please click on thumbnails to see full size)

Figure 1: Introducing the new Exchange Administration Center (EAC).

EAC adopts some of the key tenets of the Windows 8 style. EAC is clean, light and open. While sporting a simplified look, rest assured that there is no sacrifice on functionality. Usability and visual design tests have driven best-fit functionality exposure. Frequently used elements are readily visible; everything else is available but just a little tucked away to reduce visual clutter. Significant attention has also been given to the Information Architecture model, ensuring that features are easily located across Exchange’s vast administrative surface (for instance, you won’t find oddities such as ActiveSync under Phone/Voice anymore). While designing EAC, we have constantly kept both the seasoned and the novice Exchange administrator in mind, and we believe that EAC scales well for both. Finally, the visual consistency across Office 2013, Windows 8 and Windows Phone is simply refreshing.

A quick tour

Let’s take a quick, whirlwind tour of the new EAC. Subsequent blogs will dig deeper into various key features.

To launch EAC, simply point your favorite browser to your new Exchange 2013 server. As soon as you login, the first thing you will notice is the immediate page load response – a stark difference from Exchange 2010’s EMC! Plus with EAC now relying on local PowerShell, MMC client requirements and annoying startup and WinRM issues are a thing of the past. (Note: The ToolBox still uses MMC).

EAC adopts a simple visual layout as described below:

Figure 2: Visual layout of EAC.

1. Hybrid navigation

This serves to rapidly navigate between on-premises and Office 365 Exchange deployments for customers that are running a Hybrid environment. With SSO in place, managing your complex, hybrid environment is a cinch – all it takes is a mouse-click to switch between your environments. You get the same, full-fidelity EAC experience across your entire deployment.

2. Notifications

Notifications are new in EAC. The infrastructure offers online (visual) as well as offline (email) notifications for any feature that is integrated with it. You no longer need to refresh the UI to be aware of updates. The infrastructure will notify you periodically as appropriate. Currently, the following features are plugged into the notification infrastructure, with more to come soon:

• Import and Export of PST
• Certificate expiration
• Mailbox migration

Figure 3: A closer look at Notifications in EAC.

Every Notification clearly identifies status, and offers contextual links to enable you to quickly navigate and take action as needed.

3. Me tile and Help

The Me tile indicates who’s currently logged in. It also offers an entry point for the Help Desk administrator to login on behalf of another user to troubleshoot his/her settings. The Help link here is the primary Help content entry point. Help, of course, is available throughout EAC, and is context-sensitive.

4. Feature panes

EAC employs an efficient Information Architecture model to surface Exchange’s administrative functions in an effective and meaningful manner. The model aims to collect related administrative features in a best-fit manner into each Feature pane or category. Currently, the Feature panes exposed are:

• Recipients – this covers all recipient management such as user, linked, room, equipment, shared mailboxes, distribution, security and dynamic groups, and mail user and contacts. The center also exposes a Migration entry point and dashboard to monitor all ongoing mailbox migrations in one place
• Permissions – this covers RBAC management functionality in addition to policies such as OWA policies
• Compliance Management – this covers various Compliance and eDiscovery related features such as In-place Discovery & Hold, Auditing, Data Loss Prevention (DLP), Retention Policies and Tags, and Journaling
• Organization – this covers Federation, Sharing, Apps (as described in the recent OWA blog article), and Address Lists
• Protection – this covers Anti-Malware/Anti-Spam
• Mail Flow – this covers Transport Rules, Delivery Reports, Accepted Domains, Email Address Policies, Receive and Send Connectors
• Mobile – this covers Mobile Device Access control and Policies
• Public Folders – this covers Public Folders and Public Folder Mailboxes
• Unified Messaging – this covers all UM administrative functionality such as Dial Plans, Policies, Gateways, etc.
• Servers – this covers Server configuration, High Availability (Databases, DAGs and DAG Networks), Virtual Directories and Certificates
• Hybrid – this covers Hybrid Setup (based on HCW) and Configuration

Note that EAC is fully RBAC-aware. This means that if a certain Feature pane is not applicable or unavailable due to underlying RBAC permissions, EAC will respect the same and not show the respective Feature panes. Additionally, EAC fully supports multiple forest topologies.

A quick glance at the above list should put both the seasoned and the budding Exchange administrator at ease. If you are coming from Exchange 2010, EAC offers the combined feature set of both EMC and ECP, and much more. For the novice Exchange administrator, by incorporating an effective Information Architecture, ensuring key data points/actions are easily available, and reducing visual clutter, we believe that EAC will be equally attractive.

5. Tabs

Tabs represent individual features in a given Feature pane. Each Tab goes deep to expose administrative functionality for a given feature.

Tabs are also RBAC-aware, and only show up depending on your permissions.

6. List view

This represents the core working area of EAC. While the List view may appear visually light, trust us when we say it is functionally rich. The List view has received extra attention to ensure that it performs well in large scale environments. Specifically for Recipient management, EAC’s list view offers asynchronous, background loading of large data sets, paging controls, and ensures that it does not impact your overall experience. The first page of data loads instantly, while the rest is being retrieved in the background. Also available on certain list views is the ability to export data to CSV format, and customizing the views by adding/removing columns. Bulk editing of objects is also available. Finally, with integrated Search experiences, the list view offers a quick, efficient way to work with large datasets.

Figure 4: EAC's new Search experience offers hints.

Figure 5: EAC's Bulk edit experience.

7. Details pane

The Details pane goes hand-in-hand with EAC’s list view. It serves as a context-sensitive work-area surfacing frequently viewed attributes and actions, with just one mouse-click. For example, to enable Archiving for a user, all you need to do is select that user, and click on the Enable link under “Archive” in the Details pane. Without the Details pane, you would need to bring up the user’s property page, navigate to the correct section, and then find the Archiving bit – cumbersome.

Figure 6: Configure Archiving and other common attributes for your users with just one click.

Interoperability

We realize that customers typically have complex, mixed version deployments, spanning multiple Exchange product versions. In line with our vision of a seamless, integrated and unified administrative experience, we have raised the bar on InterOp administration. EAC offers a much better and broader coverage across the board particularly around viewing/modifying lower-version Exchange objects. A subsequent article will dig deeper into this topic.

Accessibility

We have made great strides in making EAC accessible. We have ensured that EAC offers mouse-free, full-keyboard access across all of EAC. For keyboard access specifically, we have provided shortcut keys to work with navigation, forms and controls. Like the new OWA and other Office Web Apps, we also offer a navigation shortcut (CTRL+F6) to quickly navigate across EAC. We have tuned EAC to provide the best High-Contrast experience possible. Additionally, we are proud to say that we have adopted the Accessible Rich Internet Application (ARIA) industry standard to provide a great screen-reader experience for EAC, across Win8 Narrator and JAWS.

Platform support

We are aware that every user has his/her own favorite browser/OS combination, and we have worked hard to ensure that EAC works best across a broad set of popular platform combinations. We are happy to say that EAC works great on IE8, IE9, IE10, FireFox 13+ (Windows, Mac, Linux), Safari 5+ (Mac), and Chrome 20+ (Windows and Mac).

Additional reading

You can find EAC documentation here, and the EAC FAQ here.

Try EAC!

EAC is now available in the latest Exchange 2013 Preview download bits as well as via the Office 365 Customer Preview offering. We will be blogging more to drill-down on certain features. In the meantime, do try the new EAC, and give us your feedback!

The Exchange Manageability Team

Following our last article, introducing the new Exchange Administration Center (EAC), we follow up on how the new EAC makes it really easy to manage multi-forest Exchange deployments.

As described in Deploy Exchange 2010 in a Cross-Forest Topology, Exchange Server 2010 can be deployed in a cross-forest or resource forest topology. For the purpose of this article, we will employ the same approach to deploy a resource forest topology with The New Exchange.

First, let’s setup a resource forest environment as shown below, with a one-way forest trust setup so that Forest B trusts Forest A.

Figure 1: Layout of a resource-forest Exchange topology

Forest A is the account-forest, where all user accounts are provisioned. Forest A does not have any Exchange servers installed. Forest B is the resource forest – with Exchange Server 2013 installed and with linked mailboxes for each of Forest A’s user accounts. Forest B has no user accounts provisioned.

In a lab environment, we have a user, John Doe, setup in Forest A. We now want John Doe to be an Exchange administrator. To do this, we need to ensure that he has the appropriate Role-Based Access Control (RBAC) privileges in place in the Exchange resource forest. Since we are dealing with a multi-forest environment here, there are two ways of configuring RBAC, and we will try both:

1. Using linked mailboxes
2. Using linked role groups

You may already have users setup in an account forest. Configuring these users as linked mailboxes establishes their presence in the Exchange resource forest. By adding these linked mailboxes to existing RBAC role groups, the associated users thus effectively become Exchange administrators.

Using linked mailboxes

In the figure below, John Doe’s user account is setup in the accounts forest. Using EAC, an Exchange administrator can then create a linked mailbox for him, as shown below.

Figure 2: John Doe has been setup as a linked mailbox.

John’s mailbox can then be added to any of the built-in RBAC administrative role groups, thus making him an Exchange administrator. In the screenshot below, John has been made a member of the built-in Organization Management role group.

Figure 3: John Doe has been added as a member of the Organization Management role group.

Now, let’s try logging into EAC as John himself. John should now have Exchange administrative privileges, and that is what we see below.

Figure 4: Logging into EAC as John Doe, configured as a linked mailbox, and as a member of the Organization Management role group.

Using linked role groups

Linked role groups are essentially role groups, but linked via a Universal Security Group (USG) across a forest boundary. Thus members of this USG effectively become members of the linked role groups. This means that if John Doe is a member of such a USG, he automatically gets all RBAC permissions in an Exchange resource forest via the linked role groups. Linked role groups thus make it possible for a small set of USGs in one account forest to manage complex, multiple Exchange forest topologies.

To demonstrate the above, we will do the following:

1. In the account forest, using Active Directory Users and Computers (ADUC) management tool, we will create a USG called AdminSG. AdminSG will represent a group of Exchange administrators. We will then make John Doe a member of AdminSG
2. In the resource forest, we will setup a single linked role group, based on the built-in role group “Organization Management”, mapped to AdminSG, using the following Exchange Management Shell calls:

$accountForestCredential = Get-Credential

$OrgMgmt = Get-RoleGroup "Organization Management"

New-RoleGroup "Organization Management - Linked" -LinkedForeignGroup "AdminSG" -LinkedDomainController bjex062.extest.microsoft.com -LinkedCredential $accountForestCredential -Roles $OrgMgmt.Roles

Get-ManagementRoleAssignment -RoleAssignee "Organization Management - Linked" -Role My* | Remove-ManagementRoleAssignment

Get-ManagementRole | New-ManagementRoleAssignment -SecurityGroup "Organization Management - Linked" -Delegating

With the above steps, John Doe now has all RBAC privileges in the Exchange resource forest even though his user account is in the account forest.

We will now attempt to login to EAC as John Doe. We launch EAC from any desktop, and point it to a CAS server in the resource forest, and we are logged in. John has standard RBAC privileges as defined in the Organization Management RBAC role group and is able to manage Exchange in the resource forest accordingly.

Figure 5: Logging into EAC as John Doe, via the linked Organization Management role group.

Try EAC!

As you can see, EAC makes it a snap to manage multi-forest Exchange deployments. You don’t need to remote into dedicated management machines to manage a specific Exchange forest, nor do you need to create special administrative accounts in every Exchange resource forest. You can do all this right from your own desktop with EAC, with your existing user credentials!

EAC is available in the latest Exchange 2013 Preview download bits as well as via the Office 365 Customer Preview offering. We will continue to write more about EAC in the upcoming weeks. In the meantime, do try the new EAC, and give us your feedback!

The Exchange Manageability Team

A short while ago, we posted an article on how to Use Exchange Web Services and PowerShell to Discover and Remove Direct Booking Settings. We received a lot of constructive feedback with some noting that users can experience an issue when enabling the Resource Booking Attendant on mailboxes that were cleansed of their direct booking settings via the sample script we provided. Specifically, the following error can be encountered when the organizer is scheduling a regular non-recurring meeting against the resource mailbox:

“…declined your meeting because it is recurring. You must book each meeting separately with this resource.”

We have updated the script to account for this scenario to prevent and correct this from occurring and we have also updated the article to reflect the changes as well.

In a nutshell, the issue is encountered when we have a divergence of what settings are enabled/disabled between the Schedule+ Free/Busy System (Public) Folder item representing the user’s mailbox and the user’s local mailbox free/busy item. Outlook’s Direct Booking process actually queries the Schedule+ item’s Direct Booking settings when attempting to perform Direct Booking functionality. The Schedule+ folder tree normally contains an item that contains a synced set of Direct Booking settings of that which is stored in the user’s localfreebusy mailbox item. The issue is encountered when the settings between the Schedule+ item and the local mailbox item do not match.

Normally, Outlook triggers a sync of the local mailbox item to the Schedule+ item via deliberate native MAPI code. However, in our case we are using EWS in the sample script, and that syncing trigger does not natively exist. We therefore updated the script to find the Schedule+ item and ensure its settings are congruent with the local item’s settings. The logic for this is actually a bit complicated for two main reasons:

1. No Schedule+ item exists in the organization – There are valid scenarios where the Schedule+ item may not exist, such as the mailbox was never opened with Outlook and the Direct Booking settings were enabled via another means, such as MFCMAPI and so on.
2. Co-existent versions of Exchange - EWS is rather particular on how public folder and public folder item bindings can occur. EWS by design will not allow a cross-version public folder (or item) bind operation. Period. This means a session, for example on a mailbox on Exchange 2010 would not be able to bind to a public folder or its items on Exchange 2007, there would need to be a replica of the folder on Exchange 2010 for the bind operation to be successful. Further, continuing our example, even if the there is a replica on Exchange 2010, the bind operation would still fail if the user’s mailbox database’s “default public folder database” is set to a non-2010 public folder database (i.e. an Exchange 2007 database). The EWS session would kick back an error stating: ‘There are no public folder servers available’

With these guidelines in mind, we approached the script update to maximize the congruency potential between the local mailbox item and the public folder item. We only disable the direct booking settings in the local mailbox item if one of the following criteria is met regarding the Schedule+ item:

• We can successfully bind to the user’s Schedule+ item
  • There is a replica we can touch with the EWS session, and we found the item representing the user and we can therefore safely keep congruency between the local and the Schedule+ items.
• There is no replica present that would potentially contain an item representing the user
  • There is no replica in the org (any version of exchange) that would contain an item for the user so there is no potential for getting into an incongruent state between the local and the Schedule+ items.
• There is a replica of the Schedule+ folder on the same version of Exchange that the EWS session is connected to, AND the default public folder database of the user is likewise on the same version of Exchange.
  • We could not find a Schedule+ item for the user (if we did, we would have satisfied condition 1 above), but not because there was no replica containing the item (if we did, we would have satisfied condition 2 above), and not because we could not bind to the folder via the EWS limitations we outlined above. We can therefore state that congruency between the local and the Schedule+ items are not at risk and there is no Schedule+ item representing the user.

It should be noted that we will always take action to disable the Direct Booking settings from the Schedule+ item even if the local mailbox item does not have its Direct Booking settings enabled – this keeps us true to our “congruency” logic.

In closing, please remember that the script is a sample and does not cover every possible scenario out there – we made this update because the aforementioned issue reported is central to having the script produce the desired outcome of fully disabling Direct Booking. We are thankful for and welcome your continued feedback!

Dan Smith & Seth Brandes
Exchange PFEs

Exchange Server 2013 introduces a new feature called Managed Availability, which is a built-in monitoring system with self-recovery capabilities.

If you’re not familiar with Managed Availability, it’s a good idea to read these posts:

• Lessons from the Datacenter: Managed Availability
• What Did Managed Availability Just Do To This Service?

As described in the above posts, Managed Availability performs continuous probing to detect possible problems with Exchange components or their dependencies, and it performs recovery actions to make sure the end user experience is not impacted due to a problem with any of these components.

However, there may be scenarios where the out-of-box settings may not be suitable for your environment. This blog post guides you on how to examine the default settings and modify them to suit your environment.

Managed Availability Components

Let’s start by finding out which health sets are on an Exchange server:

Get-HealthReport -Identity Exch2

This produces the output similar to the following:

Next, use Get-MonitoringItemIdentity to list out the probes, monitors, and responders related to a health set. For example, the following command lists the probes, monitors, and responders included in the FrontendTransport health set:

Get-MonitoringItemIdentity -Identity FrontendTransport -Server exch1 | ft name,itemtype –AutoSize

This produces output similar to the following:

You might notice multiple probes with same name for some components. That’s because Managed Availability creates a probe for each resource. In following example, you can see that OutlookRpcSelfTestProbe is created multiple times (one for each mailbox database present on the server).

Use Get-MonitoringItemIdentity to list the monitoring Item Identities along with the resource for which they are created:

Get-MonitoringItemIdentity -Identity Outlook.Protocol -Server exch1 | ft name,itemtype,targetresource –AutoSize

Customize Managed Availability

Managed Availability components (probes, monitors and responders) can be customized by creating an override.

There are two types of override: local override and global override. As their names imply, a local override is available only on the server where it is created, and a global override is used to deploy an override across multiple servers.

Either override can be created for a specific duration or for a specific version of servers.

Local Overrides

Local overrides are managed with the *-ServerMonitoringOverride set of cmdlets. Local overrides are stored under following registry path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ActiveMonitoring\Overrides\

The Microsoft Exchange Health Management service reads this registry path every 10 minutes and loads configuration changes. Alternatively, you can restart the service to make the change effective immediately.

You would usually create a local override to:

• Customize a managed availability component that is server-specific and not available globally; or
• Customize a managed availability component on a specific server.

Global Overrides

Global overrides are managed with the *-GlobalMonitoringOverride set of cmdlets. Global overrides are stored in the following container in Active Directory:

CN=Overrides,CN=Monitoring Settings,CN=FM,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com

Get Configuration Details

The configuration details of most of probes, monitors, and responders are stored in the respective crimson channel event log for each monitoring item identity, you would examine these first before deciding to change.

In this example, we will explore properties of a probe named “OnPremisesInboundProxy”, which is part of the FrontendTransport Health Set. The following script lists detail of the OnPremisesInboundProxy probe:

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/ProbeDefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like "OnPremisesInboundProxy"}

You can also use Event Viewer to get the details of probe definition. The configuration details most of the Probes are stores in the ProbeDefinition channel:

1. Open Event Viewer, and then expand Applications and Services Logs\Microsoft\Exchange\ActiveMonitoring\ProbeDefinition.
2. Click on Find, and then enter OnPremisesInboundProxy.
3. The General tab does not show much detail, so click on the Details tab, it has the configuration details specific to this probe. Alternatively, you can copy the event details as text and paste it into Notepad or your favorite editor to see the details.

Override Scenarios

Let’s look at couple real-life scenarios and apply our learning so far to customize managed availability to our liking, starting with local overrides.

Creating a Local Override

In this example, an administrator has customized one of the Inbound Receive connectors by removing the binding of loopback IP address. Later, they discover that the FrontEndTransport health set is unhealthy. On further digging, they determine that the OnPremisesInboundProxy probe is failing.

To figure out why the probe is failing, you can first list the configuration details of OnPremisesInboundProxy probe.

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/ProbeDefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like "OnPremisesInboundProxy"}

Name : OnPremisesInboundProxy

ExtensionAttributes : <ExtensionAttributes><WorkContext><SmtpServer>127.0.0.1</SmtpServer><Port>25</Port><HeloDomain>InboundProxyProbe</HeloDomain><MailFrom Username="inboundproxy@contoso.com"/><MailTo Select="All" Username="HealthMailboxdd618748368a4935b278e884fb41fd8a@FM.com"/><Data AddAttributions="false">X-Exchange-Probe-Drop-Message:FrontEnd-CAT-250 Subject:Inbound proxy probe</Data><ExpectedConnectionLostPoint>None</ExpectedConnectionLostPoint></WorkContext></ExtensionAttributes>

The ExtentionAttributes property above shows that the probe is using 127.0.0.1 for connecting to port 25. As that is the loopback address, the administrator needs to change the SMTP server in ExtentionAttributes property to enable the probe to succeed.

You use following command to create a local override, and change the SMTP server to the hostname instead of loopback IP address.

Add-ServerMonitoringOverride -Server ServerName -Identity FrontEndTransport\OnPremisesInboundProxy -ItemType Probe -PropertyName ExtensionAttributes -PropertyValue '<ExtensionAttributes><WorkContext><SmtpServer>Exch1.contoso.com</SmtpServer><Port>25</Port><HeloDomain>InboundProxyProbe</HeloDomain><MailFrom Username="inboundproxy@contoso.com" /><MailTo Select="All" Username="HealthMailboxdd618748368a4935b278e884fb41fd8a@FM.com" /><Data AddAttributions="false">X-Exchange-Probe-Drop-Message:FrontEnd-CAT-250Subject:Inbound proxy probe</Data><ExpectedConnectionLostPoint>None</ExpectedConnectionLostPoint></WorkContext></ExtensionAttributes>' -Duration 45.00:00:00

The probe will be created on the specified server in following registry path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ActiveMonitoring\Overrides\Probe

You can use following command to verify if the probe is effective:

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/ProbeDefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like "OnPremisesInboundProxy"}

Creating a Global Override

In this example, the organization has an EWS application that is keeping the EWS app pools busy for complex queries. The administrator discovers that the EWS App pool is recycled during long running queries, and that the EWSProxyTestProbe probe is failing.

To find out the details of EWSProxyTestProbe, run the following:

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/ProbeDefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like "EWSProxyTestProbe"}

Next, change the timeout interval for EWSProxyTestProbe to 25 seconds on all servers running Exchange Server 2013 RTM CU2:

1. Use following command to get version information for Exchange 2013 RTM CU2 servers:
   

   Get-ExchangeServer | ft name,admindisplayversion

2. Use following command to create a new global override:
   

   Add-GlobalMonitoringOverride -Identity "EWS.Proxy\EWSProxyTestProbe" -ItemType Probe -PropertyName TimeoutSeconds -PropertyValue 25 –ApplyVersion “15.0.712.24”

Override Durations

Either of above mentioned overrides can be created for a specific Duration or for a specific Version of Exchange servers. The override created with Duration parameter will be effective only for the period mentioned. And maximum duration that can be specified is 60 days. For example, an override created with Duration 45.00:00:00 will be effective for 45 days since the time of creation.

The Version specific override will be effective as long as the Exchange server version matches the value specified. For example, an override created for Exchange 2013 CU1, with version “15.0.620.29” will be effective until the Exchange server version changes. The override will be ineffective if the Exchange server is upgraded to different version of Cumulative Update or Service Pack.

Hence, if you need an override in effect for longer period, create the override using ApplyVersion parameter.

Removing an Override

Finally, this last example shows how to remove the local override that was created for the OnPremisesInbounxProxy probe.

Remove-ServerMonitoringOverride -Server ServerName -Identity FrontEndTransport\OnPremisesInboundProxy -ItemType Probe -PropertyName ExtensionAttributes

Conclusion

Managed Availability performs gradual recovery actions to automatically recover from failure scenarios. The overrides help you customize the configuration of the Managed Availability components to suite to your environment. The steps mentioned in the document can be used to customize Monitors & Probes as required.

Special thanks to Abram Jackson, Scott Schnoll, Ben Winzenz, and Nino Bilic for reviewing this post.

Bhalchandra Atre

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

A user is out of office for some reason – on vacation, sick, on a sabbatical or extended leave of absence, or traveling to a remote location on business, and forgets to set an automatic reply, also known as an Out Of Office message or OOF in Exchange/Outlook lingo. As an Exchange administrator, you get an email from the user’s manager asking you to configure an OOF for the user.

In previous versions of Exchange, you would need to access the user’s mailbox to be able to do this. Out of Office messages are stored in the Non-IPM tree of a user’s mailbox along with other metadata. Without access to the mailbox, you can’t modify data in it. Two ways for an admin to access a mailbox:

1. Grant yourself Full Access mailbox permission to the user’s mailbox.
2. Change the user’s password and log in as user.

It is safe to say that either of these options is potentially dangerous. The first option grants the administrator access to all of the data in the user’s mailbox. The second option grants the administrator access to all of the data that the user account can access within your company and locks the user out of his own user account (as the user in question no longer knows the account password).

In Exchange 2010, you can configure auto-reply options for your users without using either of the above options. You must be a member of a role group that has either the Mail Recipients or User Options management roles.

Configure auto-reply options using the Exchange Control Panel

To configure an auto-reply using the ECP:

1. From Mail>Options, select Another User (default My Organization).
   
   Figure 1: Select Another User

2. Select the user you want to configure the auto-reply for

3. In the new window, ensure the user's name is displayed in the alert message, and then click Tell people you’re on vacation
   
   Figure 2: When managing another user in the ECP, an alert near the top of the page displays the name of the user you're managing

4. From the Automatic Replies tab, configure the auto-reply options for the user (see screenshot).

In Exchange 2007, we introduced the ability to create different Out of Office messages for external and internal recipients. You can also disable or enable Out of Office messages on a per-user basis and on a per-remote domain basis in Remote Domain settings. For details, see previous post Exchange Server 2007 Out of Office (OOF).

Configure auto-reply options using the Shell

This command schedules internal and external auto-replies from 9/8/2011 to 9/15/2011:

Set-MailboxAutoReplyConfiguration bsuneja@e14labs.com –AutoReplyState Scheduled –StartTime “9/8/2011” –EndTime “9/15/2011” –ExternalMessage “External OOF message here” –InternalMessage “Internal OOF message here”

To configure auto-replies to be sent until they're disabled (i.e. without a schedule), set the AutoReplyState parameter to Enabled and do not specify the StarTime and EndTime parameters. For detailed syntax and parameter descriptions, see Set-MailboxAutoReplyConfiguration.

This command retrieves auto-reply settings for a mailbox.

Get-MailboxAutoReplyConfiguration bsuneja@e14labs.com

This command disables auto-reply configured for a mailbox:

Set-MailboxAutoReplyConfiguration bsuneja@e14labs.com –AutoReplyState Disabled –ExternalMessage $null –InternalMessage $null

Bharat Suneja

Update 10/21/11: There is now a fix for this issue. Please go here to learn how to get it.

We wanted to write a blog post about an issue that some of you have reported to us, and has been discussed at some length in Exchange Forums also.

After you install Internet Explorer 9 on a computer that has Exchange 2010 or Exchange 2007 management tools installed, you might run into a situation where closing the Exchange Management Console (EMC) results in the following error:

You must close all dialog boxes before you can close Exchange Management Console

This might happen even if there are no property pages left opened that you can see. Please note here that not all of our customers who installed IE9 on a computer with Exchange management tools (server or workstation) have run into this problem.

Are there any workarounds?

As it stands right now, we are not aware of a reliable workaround for this problem. Terminating the EMC using the Task Manager (or possibly a command or script) does not have adverse effects on management tools functionality, but is clearly a non-optimal solution.

What are we doing to address this?

The EMC is implemented as a Microsoft Management Console snap-in. We are working closely with both MMC and Internet Explorer teams to find a solution to this problem. Due to the complex nature of several products involved and the interoperability between them, identifying the root cause was not simple; things are still in process and we do not have a firm solution or a date to share with you yet. We do, however, want to say that we are very aware of this issue and several teams are collaborating and working to get this addressed. Once more details are available, we will be sure to share them here.

Nino Bilic

Update 12/13/2011: Please note that starting with today, you do not need to call Microsoft Support to get the fix to resolve this issue. All that is required now is installation of December 13, 2011 IE security update, KB 2618444. The below blog post has been updated accordingly.

We are happy to report that a fix for the Exchange Management Console (EMC) issues when Internet Explorer 9 is installed is now available. To be specific, we have talked about this in a previous blog post:

Exchange 2007 or 2010 EMC might fail to close with "You must close all dialog boxes before you can close Exchange Management Console"

How does this fix need to be applied?

In order to install the fix, a released version of IE9 needs to be installed on the machine first. Then:

• MS11-099: Cumulative Security Update for Internet Explorer: December 13, 2011 needs to be installed. This fix is available publicly for everyone to download. The fix that resolves the incompatibility has been rolled into this security update.

The KB article talking about all this has also been updated: KB 2624899 FIX: You cannot close the EMC window on a computer that has Internet Explorer 9 installed

Finally, I would like to thank the Internet Explorer team for working with us on this interoperability issue and producing this hotfix.

Nino Bilic

Since its release in 2009, the interest in Exchange 2010 has been fantastic. While working with customers to educate them and prep them for moving to Exchange 2010, we've uncovered some common misconceptions. One trend has to do with misconceptions around the Client Access Server array object, or CAS array object for short. Technical Writer and frequent blogger Scott Schnoll suggested I put pen to paper… err… keys to keyboard (?) when I was commenting on this trend on an internal Microsoft distribution group, so here we are with this post.

I’m not going to go into all of the technical aspects of a CAS array object in this post. That's already been covered wonderfully by Nagesh Magadev in a prior post: Exploring Exchange 2010 RPC Client Access service.

The following list is a collection of truths many customers are not aware of when it comes to the CAS array object which I'll try to demystify. Part 1 will discuss the first three items and l'll cover the last three items in part 2.

1. A CAS array object does not load balance your traffic
2. A CAS array object does not service Autodiscover, OWA, ECP, EWS, IMAP, POP, or SMTP
3. A CAS array object's fqdndoes not need to be part of your SSL certificate
4. A CAS array object should not be resolvable via DNS by external clients
5. A CAS array object should not be configured or changed after creating Exchange 2010 mailbox databases and moving mailboxes into the databases
6. A CAS array object should be configured even if you only have one CAS or a single multi-role server.

Everyone confused? Nice. Let’s try to fix that as best we can by going through each of these one at a time. You'll see some server names throughout this article so why don’t I show you what I’m working with in my lab first?

OK, let's dig in!

1. A CAS array object does not load balance your traffic

A CAS array object performs no load balancing. It's an Active Directory object used to automate some functions within Exchange and that's all. Exchange 2010 documentation says all over the place that it's recommended to use load balancers (LB) to load balance CAS traffic. So what do I mean by saying the CAS array object performs no load balancing?

What you're actually doing with a load balancer is balancing traffic across a pool of CAS or perhaps you could call it an array of CAS - but not the CAS array object itself. The difference is subtle yet distinct; perhaps we didn’t make the names distinct enough to help prevent the confusion in the first place.

The primary reason, and perhaps the only reason, a CAS array object exists is to automatically populate the RpcClientAccessServer attribute of any new Exchange 2010 mailbox database created in the same Active Directory site (as the CAS array object).

The RpcClientAccessServer attribute is used to tell Outlook clients during the profile creation process what server name should be in the profile. That’s pretty much it folks, there's no more magic going on here and once you've created your CAS array object it's simply an object in Active Directory and there's zero load balancing going on at this point in time.

The rest is up to you at this point. It's up to you to:

• Create an ‘A’ record in DNS that'll allow the client machine to resolve the hostname to an IP address. This IP address will most likely be the virtual IP (VIP) of the LB reachable only by internal clients. This VIP is where Outlook or any other MAPI/RPC capable application will then connect to gain access to Exchange 2010 mailbox resources.
• Configure your load balancing solution to pass traffic to the pool of CAS servers by way of the VIP.

The CAS themselves have no idea there is any load balancing happening.

You may also be confused by what can be seen after creating a CAS array object using the New-ClientAccessArray cmdlet or viewing a pre-existing CAS array object using the Get-ClientAccessArray cmdlet.

Here I'm creating a new CAS array object in my lab with the Name CASArray-A, the FQDN of outlook.lab.local, and in the Active Directory site very aptly named Site-A.

Figure 1: Creating a Client Access array

First of all my FQDN and Name fields don’t match because the Name is a display name - it's purely cosmetic. It's whatever you want to name it so you know what that CAS array object is being used for. The FQDN is the record you must then create in DNS or else clients will never be able to resolve it to an IP address to connect to. At this point, I’ll remind you that there can be only one CAS array object per Active Directory site.

So why is the Members property populated with two CAS immediately after creation? Didn’t I tell you there's no load balancing going on at this point? It looks kind of like I lied to you doesn’t it?

To be honest, the Members property is a touch misleading. If you didn’t read up on the steps to create a CAS array object you may think you’re done at this stage. You created your CAS array object and you can see two CAS have automatically joined the array. By this time you may be off for a celebratory drink or going down cube-town hallway to steal some cookies from this guy. Not quite yet my friend!

Due to the fact that we associated the CAS array object to Active Directory site Site-A, the cmdlet simply goes and finds all Client Access servers registered as residing in Site-A and then lists them in the Members column. I like to tell customers to think of this column as the Potential Members column or as my colleague Kamal Abburi, another PFE here at Microsoft, suggests it's the Site CAS Members column. You can add these Client Access servers as nodes in your load balancing solution because they all reside in the same Active Directory site. But until the load balancer is configured we have no load balancing.

How did the cmdlets know what site the CAS are in? Well, I’m glad you asked because we get to break out everybody’s best friend AdsiEdit.msc and dig down into the Configuration partition of Active Directory to find the magic beans.

Figure 2: The msExchServerSite attribute of an Exchange 2010 server contains the Active Directory site the server resides in

Each Exchange server has an msExchServerSite attribute that contains the Active Directory site they currently reside in. In case you're wondering, yes it's dynamically updated if you move an Exchange server to a new site and the Microsoft Exchange Active Directory Topology service has a chance to run and update a few things. But the AutoDiscoverSiteScope attribute (Part of Get/Set-ClientAccessServer) will not be dynamically updated and you may have funky Autodiscover results until this is fixed – depending on your site, server, and client layout.

2. A CAS array object does not service OWA, ECP, EWS, Autodiscover, IMAP, SMTP, or POP

Let’s go back for a moment to what a CAS array object actually does. It populates the RpcClientAccessServer attribute of an Exchange 2010 mailbox database, which is then used to tell Outlook where it needs to connect when using RPC (over TCP). For Outlook Anywhere (HTTPS) clients, it indicates where the traffic that leaves the RPC-over-HTTP proxy needs to connect on the client’s behalf in order to reach their mailbox.

So what services does the Outlook client attempt to connect to when using RPC (over TCP)?

First Outlook connects to the CAS array object on TCP/135 to communicate with the RPC Endpoint Mapper in order to discover the TCP ports the following two services are listening on.

1. Microsoft Exchange RPC Client Access (aka MSExchangeRPC)
2. Microsoft Exchange Address Book (aka MSExchangeAB)

That’s it for RPC (over TCP) mode!

Outlook Anywhere (aka RPC over HTTP) clients connect to the RPC-over-HTTP proxy component on TCP/443 on a CAS by resolving the Outlook Anywhere external hostname, or what the Outlook profile calls the proxy server.

Interesting geeky side note for anyone interested, Outlook automagically and quietly adds /rpc/rpcproxy.dll to the server name specified, as that’s really what it needs to connect to, but if we asked people to type these names in, like we used to back in Outlook 2003 days, can you imagine how many would have missed it, or got it wrong?)

Figure 3: Specifying the RPC Proxy URL in Outlook 2003

Traffic is routed out of the RPC-over-HTTP proxy to the appropriate MAPI/RPC endpoint using a list of hard-coded, rather than dynamically assigned TCP ports, those being TCP 6001, TCP 6002, and TCP 6004. The Outlook Anywhere external hostname is purposefully not the same FQDN as the CAS array object and I’ll explain why later on.

A client may also make HTTPS connections to services such as Autodiscover, OAB downloads, EWS, POP, or IMAP, but these services are defined by entirely different methods such as virtual directory URLs or the AutoDiscoverServiceInternalUri value. None of these additional services are serviced by the CAS array object as none of them are using RPC, although it’s likely to be the same server they are connecting to. The CAS array object’s FQDN may share the same VIP as the other service’s URLs, but we strongly recommend the CAS array object FQDN not be the same as the other services’ URLs if split DNS is in use. More on that last recommendation later.

3. A CAS array object's FQDN does not need to be part of your SSL certificate name list

This is a very common misconception usually spawned due to the item directly above. SSL certificates in the realm of this article are only utilized when we want to do something like establish an SSL-protected HTTP session. Because RPC (over TCP) is not an HTTP session, it's not going to be protected with SSL and therefore, we don't need the CAS array object's FQDN to be included on the subject name list of the SSL certificate. Let's take a look at it.

Below is Outlook 2010 in MAPI/RPC mode connected to an Exchange 2010 CAS array object.

Figure 4: Outlook 2010 RPC (over TCP) connections to Exchange 2010 CAS

We can see it has made one directory and two mail connections. In the netstat output (overlayed above the screenshot) we see the machine has made one endpoint mapper connection (TCP 135) to the CAS array object as well as connections to TCP 59531 and TCP 59532 which represent the statically assigned TCP ports for the MSExchangRPC and MSExchangeAB services respectively in this lab.

From the server side we can see the services listening using the command netstat –n –b.

Figure 5: Services Outlook needs to connect to when using RPC (over TCP)

As expected, it shows that none of the services are being contacted over HTTP (to TCP 443). This is why you don't need the CAS array object FQDN on the SSL certificate.

Thinking you need the CAS array FQDN on the SSL certificate can sometimes be confused by the way Outlook displays connections while in HTTPS mode as seen below.

Figure 6:Outlook Anywhere connections

This time we see Outlook 2010 has made two mail connections and a Public Folder connection when the screen shot was taken and we can also see we are using HTTPS. From within Outlook it looks as if we are connected to outlook.lab.local and E2K10-MLT-01.lab.local, which we are sort of, but utilizing netstat once again we see we are actually connected to the RPC-over-HTTP proxy located at webmail.lab.local on TCP/443 (HTTPS). Outlook will always display what server is eventually connected to for data by itself or via RPC-over-HTTP proxy. If you're wondering why we see 6 connections via netstat instead of three, it's because HTTP is a half-duplex protocol and we therefore establish an RPC_DATA_IN and an RPC_DATA_OUT channel for each connection seen inside Outlook.

You may also be thinking, “Wait! Outlook 2007 and 2010 encrypt RPC sessions by default! We have to have the name on the cert!” Wrong-O my friends because the encryption setting you see below utilizes RPC encryption and has nothing to do with SSL. The communication is still happening over RPC and not over HTTPS.

Figure 7: When connecting using RPC (over TCP), Outlook uses RPC encryption

Simple isn’t it! If a CAS array object met a Certification Authority and the CA said: “Hey man you really need me! C’mon I’ll sell you a swanky wildcard cert on the cheap!” the CAS array object would simply reply “Honey badger don’t care!” and probably use the CA to crack open a pistachio. Now that's of course if you followed our recommendation to use a different FQDN for the CAS array object than you’re using for the other service FQDN(s). Yes, I’m getting to why…

I hope Part 1 of this article has been helpful to you so far in making sense of some common misunderstood issues with CAS array objects, and hope that you’ll tune in for Part 2 at a later time where we'll cover the remaining three common misconceptions about CAS array objects.

Brian Day
Premier Field Engineer, Messaging

Continue to Demystifying the CAS Array Object - Part 2.

Moving mailboxes is an important part of managing an email service. Check out the latest Geek Out with Perry blog and video to gain some deep insights on our approach to moving mailboxes with Mailbox Replication Service (MRS) and get Perry’s take on this topic and how it works. This technology is also incredibly important if you want to move mailboxes to the cloud on your terms with a hybrid deployment.

Want more details and info?

• Check out Ross’ past blog on mailbox moves and mailbox resiliency
• Read the TechNet info all about Understanding Move Requestswhich also includes information about the client experience during a move request.
• See Hybrid Deployments with the Hybrid Configuration Wizard on TechNet if you’d like to learn about setting up a hybrid deployment in order to move mailboxes to Exchange Online.

Need to Geek Out with Perry some more? Check out his blog and the playlist of videos on YouTube or from the MSN Video catalogue. He recently discussed immutability in Exchange which has been a really hot topic.

Keep on geeking out with us, send us your feedback and let us know if you have good questions for Perry to geek out on.

Ann Vu

This post describes an update to the Facebook provider for the Outlook Social Connector and the related policy settings that are available for Administrators.

Outlook 2010 includes a feature called the Outlook Social Connector which can show social updates for the people your users email with, directly in Outlook. Earlier this year, the Outlook team made an update to enable continued access to Facebook information as Facebook has moved to a new authentication model called OAuth. While making this change the transport has also been updated to use SSL to better secure the information transmitted between Facebook and Outlook.

Note: You do not need to enable the Outlook Social Connector to display GAL Photos in Outlook 2010. For more details, see GAL Photos in Exchange 2010 and Outlook 2010.

Starting on May 1st, 2012, users will see notifications in Outlook to update the Facebook provider for the Outlook Social Connector. If users have a previous version of the Facebook provider installed, the notification will lead the user to the updated version of the Facebook provider on Microsoft Download Center.

Current users of the Facebook provider must install the updated Microsoft Outlook Social Connector Provider for Facebook to avoid errors connecting to Facebook.

Users who don't have the Facebook provider installed but do have the Outlook Social Connector enabled will see a one-time notification that a new social network provider is available.

You can use Group Policy settings to control your user’s experience. For example, you can:

• block the notifications in the People Pane
• block a specific social network provider
• turn off the Outlook Social Connector entirely

To learn more about the available Group Policy settings, see KB 2020103: How to manage the Outlook Social Connector by using Group Policy.

Note: The Outlook Social Connector is also available as a separate download for Outlook 2007 and Outlook 2003. The same notifications and policy settings apply to OSC for Outlook 2007 or Outlook 2003.

The OSC team worked to help protect users' privacy. More details about how data is protected in Learn more about Outlook Social Connector and privacy.

The Outlook team also is blogging about this update. You can read their blog here.

Adam Glick

*But Were Afraid to Ask

This is a part 1 of a 3 part blog series. Please see this for Part 2 and this for Part 3.

If you find the inner workings of Exchange data backups using Volume Shadown Copy (VSS) a bit mystifying take comfort in not being alone. Administrators may ask, “What’s all the “freezing” and “thawing” I’m seeing in my event logs? What is the Exchange VSS Writer really, and what is it doing to my databases? How does it create a snapshot of a 135GB database in less than 60 seconds?”

If you ever asked these questions but only felt more confused with the answers, here’s a guide to clear some of that up. To understand how a VSS backup of Exchange works it’s critical to understand the basics of VSS itself. There is some excellent documentation on TechNet and MSDN on this, as well as the Windows Server Core Team blog, “Ask the Core Team.” My esteemed colleague Randy Monteleone sums up the basics of VSS very nicely early in his post, while also providing links (repeated here) to some good TechNet primers on VSS:

How To: VSS Tracing – Randy Monteleone
http://blogs.technet.com/b/askcore/archive/2012/04/29/how-to-vss-tracing.aspx

How Volume Shadow Copy Service Works
http://technet.microsoft.com/en-us/library/cc785914(WS.10).aspx

Volume Shadow Copy Service
http://technet.microsoft.com/en-us/library/ee923636.aspx

If you’re already familiar with at least the basics of VSS, then look forward to Part 2 in this series, where we will break down the events that occur in a VSS Exchange backup, and how Exchange logs them in the application event log.

If you need a quick primer or refresher on VSS basics and the Exchange Writer I’ve condensed them into some visual points below to complement the references above.

Snapshots

Bear in mind that VSS solutions for Exchange, and for all applications, vary greatly between different hardware and software configurations. There are clone and COW snapshots, hardware and software solutions, just a very wide variety of technologies based on the core VSS subsystem. For the purposes of understanding Exchange backups we’re only going to illustrate one specific type of solution out of the multitude. Detailed below is what’s called “copy-on-write”, or “COW” snapshots.

In a COW snapshot-based VSS backup of Exchange we have the creation of snapshots of the disks where Exchange data is hosted. No matter what is getting backed up, even if it’s a single database file and a few logs, VSS creates a snapshot of the entire disk where any data is stored. If the data resides across multiple disks, such as when an Exchange database is on one disk, and the logs are on another, VSS will create snapshots of any and all of those disks.

So what is a “snapshot”? A volume snapshot is an area of space inside what’s called “shadow storage”, which is itself a typically small area of space on the disk located in its System Volume Information folder.

After a disk snapshot is created a change to any data block from that time forward cannot get written until a copy of that block’s data before the change (as it was when the snapshot was created) gets written to the differencing area in shadow storage. In this way the data on the disk at the time the snapshot was created is preserved, block by block, in the shadow storage area. The snapshot data is then available either from the original disk, if the data blocks requested haven’t changed, or from the differencing area if they have. The fundamentals of this are illustrated below:

Disk E: has a snapshot created at 1PM:

A minute later one of the blocks gets written to, but not before the data as it was at 1PM gets preserved in the differencing area:

As the actual disk changes the data as it was at 1PM gets written into shadow storage, preserving a record of the disk as it was in that moment:

The following step:

In the figure above a backup server requests data from the snapshot of blocks 2 and 53. Block 53 from 1PM is preserved in the snapshot, so it’s copied directly from shadow storage. Block 2 is unchanged since 1PM, so it is copied via the VSS driver VOLSNAP.SYS, which operates much like a filter driver underneath the NTFS.SYS file system driver. By working in the IRP stack (the part of kernel memory that manages disk I/O) underneath the file system it can read blocks of data without NTFS objecting that a file is in use. VOLSNAP.SYS is also responsible for ensuring blocks are copied over to shadow storage if a write is requested to them, hence the name “Copy On Write”. Here is more about VOLSNAP.SYS from Tim McMichael:

Exchange / VSS / and differential block size…
http://blogs.technet.com/b/timmcmic/archive/2011/07/12/exchange-vss-and-differential-block-size.aspx

Now that we’ve got the basics of a COW snapshot down let’s look at how it works with Exchange, along with some other major concepts:

Microsoft Exchange Writer

So we know that any disk that stores Exchange data gets a snapshot created of it by VSS. How exactly, though, does a backup application find out which disks those are? Oftentimes an administrator selects databases for backup without specifying anything about what disks their data files are stored in. So something is required to provide the information about where the data files are, and therefore what disks VSS needs to create snapshots of. This information also tells a backup application, also known as a VSS requestor, what specific data files should be copied out of the snapshots for preservation on backup media, as we don’t want to copy out anything from the disk we don't need.

The mechanism at work here is the Microsoft Exchange VSS Writer. Like any application’s VSS writer (there are many, just run VSSADMIN LIST WRITERS to see them) its first job is to tell the backup application about the data needed for backup, especially the EDB file, logs, and checkpoint file for each database requested. The information about these specific Exchange data files is known as writer metadata.

(click thumbnail for full size version)

In the figure above we see the initial steps of an Exchange backup. The Exchange Writer tells the backup server (the requestor) that there is a database located in a folder on volume E:, and that transaction logs for that database are in a folder on D:. Based on that information the backup application will request snapshots of the D: and E: volumes when the job progresses.

The Exchange VSS Writer serves another critical role besides providing metadata to VSS requestors. It also has the job of stopping writes to the databases and logs on disk, or “freezing” them, for the time it takes to create the necessary snapshots. A COW snapshot typically takes a small amount of time to create, as all it consists of initially is the designation of an area in shadow storage for blocks to be preserved in when they change on the actual disk. Despite this relatively quick operation it can still take up to a minute, which is plenty of time for blocks of data to change on a disk between the start and the end of its snapshot creation process. If blocks of data change but don't have the originals preserved from the exact time the snapshot creation begins those blocks may become inconsistent with other snapshot data, especially between logs, database, and checkpoint files. Hence, the Exchange Writer prevents the Information Store Service, or the MS Exchange Replication Service, from writing what’s in RAM to the frozen database files. In the case of the Information Store Service, the current transaction log file (Exx.log) gets rolled and closed out before the Exchange Writer allows VSS to take the snapshot. This ensures nothing changes in the file data between the beginning of the snapshot and the completion, at which point the databases are “thawed”. When databases are thawed write I/O held in RAM is allowed to go to disk again.

Here's more information on how an application's VSS writer interacts with VSS with regards to freeze, thaws, and the time needed to get a snapshot completed:

CVssWriter::OnFreeze method
http://msdn.microsoft.com/en-us/library/windows/desktop/aa381563(v=vs.85).aspx

The last major responsibility of the Exchange Writer is to tell the Information Store Service (MS Exchange Replication Service in the case of a passive copy backup) that the backup was completed and, if applicable, carry out post-backup tasks like log truncation, marking the database as no longer with a backup in progress, etc.

In the part two and part three of this series we’ll look at a play-by-play breakdown of how the elements described above all come together in an Exchange backup, the application log events that get generated, and compare the process for a mounted database to that for a passive database copy.

Thanks go out for the collaboration on the content in these posts to Michael Blanton, Tim McMichael, Randy Monteleone, Dave Vespa, and Tom Kern.

Jesse Tedoff

* But Were Afraid to Ask

Part 2 of this series (Part 1 is here and Part 3 is here) breaks down the events that take place during the backup of a mounted and active replicated database in an Exchange 2010 Database Availability Group called, simply enough, “DAG”. In this example the backup server is asked to create a full backup of database DB1 on server ADA-MBX1, using non-persistent COW snapshots:

(please click thumbnails for full size version of graphics in this post)

Event 9606 indicates that the VSS requestor has engaged the Exchange writer, and reports the instance GUID for the backup job that is starting. In this case the instance is 830705de-32d9-4059-94ea-b9e9aad38615. This instance GUID persists throughout each job, and changes with each subsequent one. You can therefore use it to track the sequence of events for each individual job. At this time the Exchange Writer provides metadata about the databases and logs present to the backup application.

Events 2005 and 9811 indicate an instance number assignment for ESE. So along with the writer instance GUID from event 9606 we can also track a job’s progress using these ESE instance numbers which increment by one with each job. At this stage the database is marked with “backup in progress” in the Information Store Service's memory space.

Just after the backup application has determined which disks need snapshots created, based on the data locations provided by the Exchange Writer metadata, it goes ahead and requests those snapshots. As the snapshot requests arrive event 9608 gets generated, indicating the Exchange writer’s acknowledgment of what’s about to happen. It then must halt disk writes to the database(s) and logs, also known as a “freeze” for the duration of the snapshot generation process.

When event 2001 is generated the current transaction log is closed, and the freeze begins. Writes from STORE.exe to the disks are held in memory.

Once these events appear we know the snapshot(s) have been created, and writes are allowed to database data blocks again.

Once the snapshots are created the backup application can copy blocks of data from the VSS subsystem, getting blocks of data from shadow storage if they’ve been preserved due to a change, or from the actual disk volume if they haven’t. The Exchange Writer waits for the signal that the transfer of data is complete. This flow of data is represented by the purple arrows, which in this case indicates data getting copied out of the snapshots in storage, through I/O of the Exchange server, and on to the backup server.

Once the backup application finishes copying data it will signal VSS that it’s done. VSS in turn signals the Exchange writer, which then initiates post-backup steps, signified by the above events. Event 225 appears to state that log truncation won’t occur, but that event is misleading. For a standalone database, upon backup completion, ESE would go ahead and clear logs accordingly. However, when a DAG replicated database is involved a check of other database copies must be performed in coordination with the Exchange Replication Service to ensure log truncation can continue. Once that check is complete the logs eligible for truncation are deleted. The database header is marked with information about the backup and the backup in progress bit is switched off in memory. In this case the snapshots used for the job are destroyed as part of the completion. In other types of backups, such as incremental, the persistence of the snapshot varies, but in this case they are removed.

In the next post in this series we'll break down the backup of a passive DAG replicated database copy.

Jesse Tedoff

* But Were Afraid to Ask

In Part 1 and Part 2 of this series we looked at the fundamentals of Exchange backups using VSS, and the flow of an active DAG database backup.

In Part 3 we break down how a passive DAG database copy undergoes a full backup. The Exchange Writer responsible for passive copy backups doesn't run in the Information Store Service, but rather as part of the MS Exchange Replication Service. Among other functions, this service coordinates the backup process between the passive copy node and the active copy server. Similar to the backup of an active database described in Part 2, this post describes the backup of a passive database copy of DB1, hosted on server ADA-MBX1. The active mounted database copy is on ADA-MBX2, and again, a non-persistent copy-on-writer (COW) snapshot is utilized by the backup solution:

(please click thumbnails for full size version of graphics in this post)

The first steps to back up a passive database copy are about the same as for an active one. The backup application gets the metadata for DB1 from the Exchange Writer, but again, the writer is running in the MS Exchange Replication Service. A new writer instance GUID is generated which will persist throughout the job, as with an active database backup.

Event 2021 indicates that the backup application, or VSS requestor, has engaged the Exchange Writer. It will appear numerous times throughout the backup as different components are read from metadata, such as log and database file locations.

Events 2110 and 2023 indicate that the backup application has requested a particular set of components to back up, and the backup type.

The replication service for the passive copy’s server signals the active copy server that a backup is in progress. Events 910 and 210 on the active copy server, as well as 960 on the passive copy server, signify two things: First, they establish which server backing up a passive copy of the database; Second, the STORE service on the active copy server has marked the database with “backup in progress” in memory and acknowledges that the surrogate backup will proceed. Once this occurs it is not possible to backup the database again until either the current surrogate backup completes, or the “backup in progress” status is otherwise cleared.

Events 2025 and 2027 are generated when the replication writer prevents the replication service from writing logs copied from the active copy server to the local disk. Replay of logs also stops, thereby keeping the contents of the database files unchanged. At this point writes of data for the database getting backed up are “frozen”. VSS can now create the snapshots in shadow storage for each disk specified in the metadata.

VSS creates snapshots of disks D: and E:. Once these complete it signals the Exchange Writer, which in turns allows the replication service to resume log copy and replay. Events 2029 and 2035 are generated when the “thaw” is completed and normal disk writes are allowed to continue.

Once the snapshots are created the backup application can copy blocks of data through VSS, which transfers blocks of data from shadow storage if they’ve been preserved due to a change, or from the actual disk volume if they haven’t. The replication service writer waits for the signal that the transfer of data is complete. This flow of data is represented by the purple arrows, which in this case indicates data getting copied out of the snapshots in storage, through I/O of the Exchange server, and on to the backup server.

When the files necessary for backing up DB1 are safely copied to backup media, the backup application signals VSS that the job is complete. VSS in turn signals the replication writer, and Exchange generates events 963 and 2046 on the passive copy server. The replication service then signals the Information Store service on the active copy server that the job is done, and that log truncation can proceed if all necessary conditions are met. The active copy node generates events 913 and 213 signaling that the surrogate backup is done, and that the database header will be updated with the date and time of the backup.

Events 2033 and 2037 signal the end of the backup. The active copy node flushes and rolls the current transaction log containing database header updates. That log is then shipped and made eligible for replay according to schedule so that the passive database copy is marked with the new header information at the earliest available time. Log truncation also proceeds if possible. In this case the snapshots are destroyed, and normal operations continue.

For more on the subject of this series here are some more great references:

Volume Shadow Copy Service
http://technet.microsoft.com/en-us/library/ee923636(WS.10).aspx

Exchange VSS Writers
http://msdn.microsoft.com/en-us/library/bb204080.aspx

Overview of Processing a Backup Under VSS
http://msdn.microsoft.com/en-us/library/aa384589(VS.85).aspx

Backup Sequence Diagrams
http://msdn.microsoft.com/en-us/library/aa579076(v=exchg.140)

Troubleshooting the Volume Shadow Copy Service
http://technet.microsoft.com/en-us/library/ff597980(EXCHG.80).aspx

Jesse Tedoff

Last week, we announced The New Exchange. Today, we are excited to share its new, refreshed management experience.

For folks familiar with Exchange 2010, there are 3 ways to manage Exchange: the Exchange Management Console (EMC), the Exchange Control Panel (ECP), and the Exchange Management Shell (EMS).

As far as the GUI-based experience is concerned, customers are faced with an incongruous choice between EMC and ECP. While most of the management surface is exposed via EMC, some newer features such as Auditing, eDiscovery, RBAC management, Group naming policy, ActiveSync Quarantined Device management, etc., are only available in ECP. Since these features are applicable to both on-premises as well as online deployments, administrators are forced to learn multiple tools and juggle between them. Specifically for the MMC-based EMC, customers also have to bear IT overhead with respect to updates, patches and so on.

Wouldn’t it be pure bliss if you, the Exchange administrator (expert or novice), had just ONE seamless, integrated way to manage all of Exchange, be it on-premises, online, or even both?

Introducing the Exchange Administration Center (EAC)

With The New Exchange, we are proud to announce a brand new experience for the Exchange administrator: the Exchange Administration Center (EAC)! The EAC brings a completely refreshed, seamless, integrated and unified web-based experience.

(please click on thumbnails to see full size)

Figure 1: Introducing the new Exchange Administration Center (EAC).

EAC adopts some of the key tenets of the Windows 8 style. EAC is clean, light and open. While sporting a simplified look, rest assured that there is no sacrifice on functionality. Usability and visual design tests have driven best-fit functionality exposure. Frequently used elements are readily visible; everything else is available but just a little tucked away to reduce visual clutter. Significant attention has also been given to the Information Architecture model, ensuring that features are easily located across Exchange’s vast administrative surface (for instance, you won’t find oddities such as ActiveSync under Phone/Voice anymore). While designing EAC, we have constantly kept both the seasoned and the novice Exchange administrator in mind, and we believe that EAC scales well for both. Finally, the visual consistency across Office 2013, Windows 8 and Windows Phone is simply refreshing.

A quick tour

Let’s take a quick, whirlwind tour of the new EAC. Subsequent blogs will dig deeper into various key features.

To launch EAC, simply point your favorite browser to your new Exchange 2013 server. As soon as you login, the first thing you will notice is the immediate page load response – a stark difference from Exchange 2010’s EMC! Plus with EAC now relying on local PowerShell, MMC client requirements and annoying startup and WinRM issues are a thing of the past. (Note: The ToolBox still uses MMC).

EAC adopts a simple visual layout as described below:

Figure 2: Visual layout of EAC.

1. Hybrid navigation

This serves to rapidly navigate between on-premises and Office 365 Exchange deployments for customers that are running a Hybrid environment. With SSO in place, managing your complex, hybrid environment is a cinch – all it takes is a mouse-click to switch between your environments. You get the same, full-fidelity EAC experience across your entire deployment.

2. Notifications

Notifications are new in EAC. The infrastructure offers online (visual) as well as offline (email) notifications for any feature that is integrated with it. You no longer need to refresh the UI to be aware of updates. The infrastructure will notify you periodically as appropriate. Currently, the following features are plugged into the notification infrastructure, with more to come soon:

• Import and Export of PST
• Certificate expiration
• Mailbox migration

Figure 3: A closer look at Notifications in EAC.

Every Notification clearly identifies status, and offers contextual links to enable you to quickly navigate and take action as needed.

3. Me tile and Help

The Me tile indicates who’s currently logged in. It also offers an entry point for the Help Desk administrator to login on behalf of another user to troubleshoot his/her settings. The Help link here is the primary Help content entry point. Help, of course, is available throughout EAC, and is context-sensitive.

4. Feature panes

EAC employs an efficient Information Architecture model to surface Exchange’s administrative functions in an effective and meaningful manner. The model aims to collect related administrative features in a best-fit manner into each Feature pane or category. Currently, the Feature panes exposed are:

• Recipients – this covers all recipient management such as user, linked, room, equipment, shared mailboxes, distribution, security and dynamic groups, and mail user and contacts. The center also exposes a Migration entry point and dashboard to monitor all ongoing mailbox migrations in one place
• Permissions – this covers RBAC management functionality in addition to policies such as OWA policies
• Compliance Management – this covers various Compliance and eDiscovery related features such as In-place Discovery & Hold, Auditing, Data Loss Prevention (DLP), Retention Policies and Tags, and Journaling
• Organization – this covers Federation, Sharing, Apps (as described in the recent OWA blog article), and Address Lists
• Protection – this covers Anti-Malware/Anti-Spam
• Mail Flow – this covers Transport Rules, Delivery Reports, Accepted Domains, Email Address Policies, Receive and Send Connectors
• Mobile – this covers Mobile Device Access control and Policies
• Public Folders – this covers Public Folders and Public Folder Mailboxes
• Unified Messaging – this covers all UM administrative functionality such as Dial Plans, Policies, Gateways, etc.
• Servers – this covers Server configuration, High Availability (Databases, DAGs and DAG Networks), Virtual Directories and Certificates
• Hybrid – this covers Hybrid Setup (based on HCW) and Configuration

Note that EAC is fully RBAC-aware. This means that if a certain Feature pane is not applicable or unavailable due to underlying RBAC permissions, EAC will respect the same and not show the respective Feature panes. Additionally, EAC fully supports multiple forest topologies.

A quick glance at the above list should put both the seasoned and the budding Exchange administrator at ease. If you are coming from Exchange 2010, EAC offers the combined feature set of both EMC and ECP, and much more. For the novice Exchange administrator, by incorporating an effective Information Architecture, ensuring key data points/actions are easily available, and reducing visual clutter, we believe that EAC will be equally attractive.

5. Tabs

Tabs represent individual features in a given Feature pane. Each Tab goes deep to expose administrative functionality for a given feature.

Tabs are also RBAC-aware, and only show up depending on your permissions.

6. List view

This represents the core working area of EAC. While the List view may appear visually light, trust us when we say it is functionally rich. The List view has received extra attention to ensure that it performs well in large scale environments. Specifically for Recipient management, EAC’s list view offers asynchronous, background loading of large data sets, paging controls, and ensures that it does not impact your overall experience. The first page of data loads instantly, while the rest is being retrieved in the background. Also available on certain list views is the ability to export data to CSV format, and customizing the views by adding/removing columns. Bulk editing of objects is also available. Finally, with integrated Search experiences, the list view offers a quick, efficient way to work with large datasets.

Figure 4: EAC's new Search experience offers hints.

Figure 5: EAC's Bulk edit experience.

7. Details pane

The Details pane goes hand-in-hand with EAC’s list view. It serves as a context-sensitive work-area surfacing frequently viewed attributes and actions, with just one mouse-click. For example, to enable Archiving for a user, all you need to do is select that user, and click on the Enable link under “Archive” in the Details pane. Without the Details pane, you would need to bring up the user’s property page, navigate to the correct section, and then find the Archiving bit – cumbersome.

Figure 6: Configure Archiving and other common attributes for your users with just one click.

Interoperability

We realize that customers typically have complex, mixed version deployments, spanning multiple Exchange product versions. In line with our vision of a seamless, integrated and unified administrative experience, we have raised the bar on InterOp administration. EAC offers a much better and broader coverage across the board particularly around viewing/modifying lower-version Exchange objects. A subsequent article will dig deeper into this topic.

Accessibility

We have made great strides in making EAC accessible. We have ensured that EAC offers mouse-free, full-keyboard access across all of EAC. For keyboard access specifically, we have provided shortcut keys to work with navigation, forms and controls. Like the new OWA and other Office Web Apps, we also offer a navigation shortcut (CTRL+F6) to quickly navigate across EAC. We have tuned EAC to provide the best High-Contrast experience possible. Additionally, we are proud to say that we have adopted the Accessible Rich Internet Application (ARIA) industry standard to provide a great screen-reader experience for EAC, across Win8 Narrator and JAWS.

Platform support

We are aware that every user has his/her own favorite browser/OS combination, and we have worked hard to ensure that EAC works best across a broad set of popular platform combinations. We are happy to say that EAC works great on IE8, IE9, IE10, FireFox 13+ (Windows, Mac, Linux), Safari 5+ (Mac), and Chrome 20+ (Windows and Mac).

Additional reading

You can find EAC documentation here, and the EAC FAQ here.

Try EAC!

EAC is now available in the latest Exchange 2013 Preview download bits as well as via the Office 365 Customer Preview offering. We will be blogging more to drill-down on certain features. In the meantime, do try the new EAC, and give us your feedback!

The Exchange Manageability Team