Exchange 2013 Alerts


I’ve been critical about the features that have been dropped from the new browser-based Exchange Administration Center (EAC) console in Exchange 2013 when compared to its Exchange Management Console (EMC) predecessor as used by Exchange 2007 and Exchange 2010.  I’ve also pointed out some areas where EAC needs refinement (or simply to have some bugs fixed) To be fair, along with its ability to support a large number of different types of device from PCs to smartphones and its coverage of on-premises, hybrid, and cloud deployments, EAC introduces some new and very useful features, among which are event notifications or alerts.

Any component is able to create an alert by writing it into the “Federated email” arbitration mailbox (the one that looks like FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042  – you can see the set of arbitration mailboxes in an organization by running the Get-Mailbox -Arbitration command).

The idea is that alerts bring issues to the attention of administrators that they might otherwise overlook and it is expected that other Exchange components will add their own alerts over time. The Mailbox Replication Service (MRS) issues alerts for mailbox migration, import, export and restore operations to EAC. The alerts notify administrators when operations start, finish, and if any problems occur. Apart from MRS, the only other Exchange component that currently signals alerts to EAC is a scan for expired certificates that is performed every 24 hours or any time that the Exchange Service host Service restarts. I expect that other Exchange components will add their own alerts over time as developers realize the value of these notifications and get the time to add alerts to their code.

Components control how they write alert information into the arbitration mailbox. Some information is written immediately an operation starts, as in the case when a migration batch or PST import begins, and is updated as the operation progress. For instance, if you start off a migration batch, MRS marks it as “InProgress”. When the batch finishes, MRS updates its notification to “Complete”. Others take a more leisurely approach because their information is not quite so time critical, which is the reason why the scan for expired certificates occurs daily.

EAC checks the arbitration mailbox for alerts that it should signal every 30 seconds. When an alert is discovered, EAC signals it to the administration. In the screen shot we can see that EAC has discovered the presence of an expired certificate. If the administrator clicks the “View Details” link, EAC brings them to the Certificates section (under Servers) to allow the administrator to deal with the problematic certificate. On the other hand, clicking the link will do nothing if you run EAC using an account that does not hold an RBAC role that allows access to certificates.

Two alerts can be seen. One for an expired certificate, the other to say that a migration batch has started

Two alerts can be seen. One for an expired certificate, the other to say that a migration batch has started

You do not have the ability to create new types of alerts, but you can fetch information about alerts or create a request for Exchange to notify specific recipients by email when a task is complete. The Get-Notification command reads information from the arbitration mailbox and provides an insight into the information available to EAC. You can compare the output shown below to the alerts displayed in the screen shot:

Get-Notification

Display Name              Type       Status      StartedBy          StartTime
------------              ----       ------      ---------          ---------
January 16 Batch (to VIP) Migration  Queued      Redmond, Tony (IT) 16/01/2013 12:23:00
Exchange 2013 Test        CertExpiry CertExpired Microsoft Outlook  14/01/2013 13:46:02

The Set-Notification command creates a request to be notified when a task is complete. For example, this command instructs Exchange that we want email sent to two users when migration batches are complete.

Set-Notification –NotificationEmails “TRedmond”, “JSmith” –ProcessType Migration

Notifications remain in the arbitration mailbox until they are removed or expire. It is the responsibility of the component that creates a notification to remove it and this is usually done when the associated task is complete. For instance, if you remove a migration batch, the notification for that batch is deleted from the arbitration mailbox. If notification items are left in the arbitration mailbox, they will be removed by the Managed Folder Assistant after 30 days because they are stamped with the AsyncOperationNotification system retention tag.

Although EAC has a bad name in some quarters, new features like alerts prove that the transition to the new console brings benefits. Once Microsoft gets around to fixing the bugs that are in EAC and adding back some of the missing functionality, EAC will be an advance over EMC. For now, well, you have to make your own mind up…

Follow Tony @12Knocksinna

About these ads

About Tony Redmond

Exchange MVP, author, and rugby referee
This entry was posted in Exchange 2013 and tagged , , , , , , . Bookmark the permalink.

4 Responses to Exchange 2013 Alerts

  1. Is it possible to create custom alerts from scripts which may be expected to be long-running?

  2. Pingback: Exchange 2013 EAC Alerts « SME IT guy

  3. Pingback: Exchange 2013 Database Removal Error: "This mailbox database contains one or more mailboxes"

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s