Office 365 Generic MX Records Deprecated

Microsoft has changed how e-mail is routed to Office 365 in order to provide continuing improvements in performance and reliability, and to make e-mail routing more efficient. Now, each custom domain in Office 365 has its own unique Mail Exchange (MX) record value.

Up until recently, MX records for custom domains were “generic”, meaning everyone would point the MX record for their particular domain(s) to a generic MX record such as mail.global.frontbridge.com or something similar, without any reference to the organization. These generic MX records were deprecated on 1 January 2013 and support for these records will end on 1 July 2013. As such, organizations need to update their MX records to domain-specific MX records before July.

Please note that this does not affect P1 user plans, but all E plans.

You can find the specific value(s) for your domain(s) in the domain administration section of your Office 365 tenant admin page. The values are also listed in an e-mail your organization’s technical contact should have received from Microsoft.

Login to the Office 365 portal as an administrator, click on Domains under Management on the left hand side:

Select the domain you want to update the MX records for and click on View DNS settings:

Click on View DNS records:

Scroll down until Exchange Online. In here, look for the Points to address field for MX: 

This should be in the format of “company-domain”.mail.eo.outlook.com.


If you do not update all your generic MX records by 1 July 2013, you may not receive a future update, resulting in a mail flow disruption from people outside your organization. Microsoft cannot predict when or if such an update will occur. Even though generic records will be unsupported after this date, Microsoft will e-mail customers if they know of such an update in advance.

Exchange 2013 Managed Availability

In Exchange 2013, native, built-in monitoring and recovery actions are included in a feature called Managed Availability. Managed Availability is the integration of built-in, active monitoring and the Exchange 2013 high availability platform, allowing Exchange to make a determination on when to fail over a database based on service health.

To view the health of a server, you use the cmdlets Get-ServerHealth to retrieve the raw health data and Get-HealthReport that operates on the raw health data and provides a snapshot of the health.

This example returns the server health for server MBX1:

Get-ServerHealth MBX1

The following examples return a report on the health of the server. The second cmdlet narrows this report to the Store process:

Get-ServerHealth | Get-HealthReport
Get-ServerHealth | Where {$_.HealthSetName -eq “Store”} | Get-HealthReport

Exchange Online Service Description Updated

Yesterday (April 17th) Microsoft updated the Exchange Online Service Description and added the following new items:

• New Storage and Recipient Limits topic
• New standalone Exchange Online Plan 1 & 2 feature sections in all topics

Additionally, the latest customer feedback has also been incorporated throughout all the service description topics.

Exchange 2013 Help Files Updated for CU1

The Exchange 2013 Help files (.chm) have been updated on April 4th with updates for Cumulative Update 1.

 

Here you can download the help files for both Exchange Server 2013 Hybrid and On-Premise deployments.

Exporting Queue Messages

When exporting messages from a Queue, you need to use the AssembleMessage script. For example, if you want to export the message with message ID 6789 from the letsexchange.com queue on server MBX1, you need to run the following cmdlet:

Export-Message MBX1\letsexchange.com\6789 | AssembleMessage -Path "D:\Messages\Message6789.eml"

To export all messages from a Queue into individual .eml files, use the following script (which you can convert to a one-liner):

Get-Message -Queue "MBX1\letsexchange.com" | ForEach {
  # Build message path and filename with the Internet Message ID as the file name
  $Temp = "D:\Messages\" + $_.InternetMessageID + ".eml"
  $Temp = $Temp.Replace("<", "_")
  $Temp = $Temp.Replace(">", "_")
  
  # Export the message using
  Export-Message $_.Identity | AssembleMessage -Path $Temp
}

Exchange Online Inactive Mailboxes

In Office 365 “Wave 14”, you could not discover content in disabled mailboxes (which were removed after 30 days). In order to keep content discoverable, you had to leave the mailboxes enabled, which meant they would take up licenses.

 

In the new Office 365 “Wave 15”, Microsoft introduced the concept of Inactive Mailboxes, which allows you to place a mailbox in In-Place Hold and then delete the corresponding Office 365 user account. This makes it possible to preserve the contents of deleted mailboxes indefinitely and still be able to search its content using eDiscovery!

 

The advantages/characteristics of inactive mailboxes are:

• Inactive mailboxes are not removed as long as they are placed on hold;

• After a mailbox is made inactive (by placing it on hold and then removing it), you can search content in the mailbox using In-Place eDiscovery;

• Inactive mailboxes do not require a license;

• Inactive mailboxes cannot send/receive messages and will not show up in GAL;

• They do show up in In-Place Hold and In-Place eDiscovery interfaces.

 

Important: If a hold isn't placed on a mailbox before it's deleted, the contents of the mailbox will not be preserved or discoverable. The mailbox can be recovered within 30 days of deletion, but the mailbox and its contents will be permanently deleted after 30 days if it isn't recovered.

“Creating” an Inactive Mailbox

As mentioned before, creating an inactive mailbox involves two steps: first placing the mailbox on In-Place Hold and then deleting the mailbox or corresponding Office 365 user account. After the inactive mailbox is created, its contents are preserved until the In-Place Hold is removed.

Place a mailbox on In-Place Hold

Placing a mailbox on In-Place Hold preserves all contents that were in the mailbox before it was deleted. You can place the mailbox on indefinite hold or on a time-based hold.

In an indefinite hold, the inactive mailbox and all its contents will be preserved until the hold is removed. After the hold is removed (assuming that the mailbox was deleted more than 30 days ago), the inactive mailbox will be permanently deleted and the contents of the mailbox will no longer be preserved or discoverable.

In a time-based hold, you specify the duration of the hold. This duration is on a per-item basis and is calculated from the date a mailbox item was received or created. After the hold expires for a mailbox item, the item is permanently deleted from the inactive mailbox.

To use the Shell to put a mailbox on In-Place Hold, you can use the following cmdlet:

New-MailboxSearch “Hold-Nuno” -SourceMailboxes “nuno@letsexchange.com” -InPlaceHoldEnabled $True

If you don’t specify additional search parameters for an In-Place Hold, all items in the specified source mailboxes are placed on hold. If you don’t specify the ItemHoldPeriod parameter, items are placed on hold indefinitely or until the mailbox is either removed from hold or the hold is deleted.

Delete the mailbox

After the mailbox is placed on In-Place Hold to preserve its contents, it can be deleted. The best way to delete a mailbox is to delete the corresponding Office 365 user account in the Office 365 admin center. You can also delete the mailbox by using the Remove-Mailbox cmdlet through the Shell.

Access the contents of an inactive mailbox

After you enable an inactive mailbox by placing the mailbox on In-Place Hold and then deleting the corresponding Office 365 user account, you can access the contents of the inactive mailbox by using In-Place eDiscovery in the Exchange admin center (EAC). When you search an inactive mailbox, you can create a keyword search query to search for specific items or you can return the entire contents of the inactive mailbox. You can preview the search results, copy the search results to a discovery mailbox, or export the search results to an Outlook Data (PST) file. For step-by-step procedures for searching mailboxes, see Create an In-Place eDiscovery Search.

To run an eDiscovery search you can use the EAC, the SharePoint eDiscovery Center or the Shell. This example creates an In-Place eDiscovery search called “Discovery-Nuno” for items containing the keywords LetsExchange and ProjectX that also meet the following criteria:

• Start date: 1/1/2010

• End date: 12/31/2012

• Source mailbox: Nuno

• Target mailbox: Discovery Search Mailbox

• Message types: Email

• Log level: Full

New-MailboxSearch "Discovery-Nuno" -StartDate "1/1/2010" -EndDate "12/31/2012" -SourceMailboxes "Nuno" -TargetMailbox "Discovery Search Mailbox" -SearchQuery '"LetsExchange" AND "Project X"' -MessageTypes Email -IncludeUnsearchableItems -LogLevel Full

Important: If you don’t specify additional search parameters when running an In-Place eDiscovery search, all items in the specified source mailboxes are returned in the results. If you don’t specify mailboxes to search, all mailboxes are searched.

Permanently delete an inactive mailbox

If you no longer need to preserve the contents of an inactive mailbox, you can permanently delete the inactive mailbox by removing the In-Place Hold. If the mailbox was deleted more than 30 days ago, the mailbox will be permanently deleted after you remove the In-Place Hold, and mailbox items will become non-recoverable. If the mailbox was deleted within the last 30 days, you can still restore the mailbox after removing the hold.

Set-MailboxSearch "Hold-Nuno" -InPlaceHoldEnabled $false

Remove-MailboxSearch "Hold-Nuno"

What about On-Prem?

Well, if you think about it, licensing and costs is what mainly drove this change. With Exchange on-premise you are not paying a monthly subscription cost so this is not as relevant. If a user leaves, you can easily disable the AD account, hide the mailbox from the GAL, stop mailflow, etc., and basically get the same behavior.

To keep its content discoverable, all you need to do is keep the mailbox. As long as the mailbox is not accessed by the user, you do not require a license for it (just like resource, shared and journaling mailboxes).

Also, note that in on-premises you cannot remove mailboxes that are placed on hold.

Mailbox Documents Not Indexed

Ever wanted to check which documents Exchange Search couldn’t index? The Get-FailedContentIndexDocuments cmdlet gives you exactly this information: it will return a list of documents that couldn't be indexed including an error code and the reason for failure.

The most common cause for this is the lack of an available filter for that document type. For example, if the PDF filter is not available (which is not by default) and if an e-mail contains a PDF document, the document is marked as failed content indexing as Exchange can’t index it.

After a new filter is installed, only new messages with attachments of the type for which the filter is installed are indexed. If you want to index older messages for that document type, the mailbox has to be moved, which triggers Exchange to re-index the whole mailbox content.

Some examples of reasons for failure are:

• “The document format is not recognised by the filter”;

• “This is an encrypted document”;

• “Filter not found”.

To retrieve a list of items that couldn't be indexed by Exchange Search from the mailbox of user Nuno:

Get-FailedContentIndexDocuments Nuno

To retrieve a list of items that couldn't be indexed by Exchange Search from the mailbox database DB01:

Get-FailedContentIndexDocuments -MailboxDatabase DB01

Hope this helps!

Exchange Server Jetstress 2013 Tool

Exchange JetStress 2013 has just been released and is available for download here! The changes are listed below, but the main ones include improved reports with Lost Flush* detection (an ESE improvement made in Exchange 2010 was the introduction of the Lost Flush detection mechanism which takes care of logical corruption) and a new option to allow JetStress to continue running even if a disk fails (obviously assuming there are other disks which JetStress is using) in order to support the “Storage Burn-in” scenario.

 

Overview

“Use Jetstress to verify the performance and stability of a disk subsystem prior to putting an Exchange server into production. Jetstress helps verify disk performance by simulating Exchange disk Input/Output (I/O) load. Specifically, Jetstress simulates the Exchange database and log file loads produced by a specific number of users. You use Performance Monitor, Event Viewer, and ESEUTIL in conjunction with Jetstress to verify that your disk subsystem meets or exceeds the performance criteria you establish. After a successful completion of the Jetstress Disk Performance and Stress Tests in a non-production environment, you will have ensured that your Exchange disk subsystem is adequately sized (in terms of performance criteria you establish) for the user count and user profiles you have established. It is highly recommended that the Jetstress user read through the tool documentation before using the tool.”

Improvements

• “Event log is captured and logged to the test log. Shows up on the Jetstress UI as the test is progressing;
• The error is counted against the volume it occurred on. The final report shows the counts in a new sub-section;
• A single IO error anywhere will fail the test. In case of CRC errors, they might be remapped. A re-run of Jetstress should verify that they indeed were remapped;
• Detects -1018, 1019, -1021, -1022, -1119, hung IO, DbtimeTooNew, DbtimeTooOld;
• Threads which generate IO are now controlled at a global level. Instead of specifying Threads/DB, you now specify a global thread count which work against all databases. This improves the granularity of thread tuning and enables automatic tuning to work more effectively;
• Jetstress config files generated from an older version of Jetstress are no longer allowed.”

Requirements

• .NET Framework 4.5
• Exchange 2013 binaries: ESE.DLL, ESEPerf.dll, ESEPerf.ini, ESEPerf.hxx
• VC11 runtime (I believe this is installed automatically, haven’t had the chance to test it)

Exchange 2013 Maintenance Mode

UPDATE (11/03/2013): change made to the process of emptying the queues (please see below)

With Exchange 2013, Microsoft introduced many new features to further improve Database Availability Groups, or DAGs. One of these new features is called Maintenance Mode and it enables administrators to designate a server as in-service or out-of-service by using the Set-ServerComponentState cmdlet. With Exchange 2010, administrators had to use the StartDagServerMaintenance.ps1 script or manually prepare a DAG member for maintenance.

 

As with the script, Maintenance Mode is used to tell Exchange that a particular server should not be available to service clients. In a mailbox server, an administrator will typically perform a switchover to another server (if the server to be put in maintenance mode is hosting active database copies) and then use the Set-MailboxServer and Set-ServerComponentState cmdlet to put it into maintenance mode, preventing the active copies from being activated and disabling the Transport services.

 

Enabling Maintenance Mode on a Mailbox server role is straightforward. Let’s consider mailbox server MBX1. Before you can disable the Transport service, all active queues need to be drained first:

Set-ServerComponentState MBX1 -Component HubTransport -State Draining -Requester Maintenance

If the server is part of a DAG, you must run these cmdlets to switchover any active databases currently mounted on the server and prevent those copies from being activated:

Suspend-ClusterNode MBX1

Set-MailboxServer MBX1 -DatabaseCopyActivationDisabledAndMoveNow $True

Set-MailboxServer MBX1 -DatabaseCopyAutoActivationPolicy Blocked

Once the queues are empty, you can disable all components on the server:

Set-ServerComponentState MBX1 -Component ServerWideOffline -State Inactive -Requester Maintenance

UPDATE: if you script the process and use the Get-Queue cmdlet to check how many messages are still in all the queues of the server you are placing in maintenance mode, the script might take a long time to pass this stage because of the Poison and Shadow Redundancy queues... There are two alternatives. One is to update the Get-Queue cmdlet to exclude these queues from your script:

Get-Queue -Server MBX1 | ? {$_.Identity -notmatch "Poison" -AND $_.Identity -notmatch "Shadow"}

The other option is to use the Redirect-Message cmdlet to drain active messages from all the delivery queues on the server and transfer those messages to another Mailbox server:

Redirect-Message -Server MBX1 -Target MBX2

When a message queue is drained, the active messages in the queues on the source Mailbox server are routed to the target Mailbox server. After the messages are received and queued by the target Mailbox server, the messages are made redundant. Please also note that:

• Only active messages are drained. Shadow queues aren't drained;

• Messages in the poison message queue aren't drained;

• The source server won't accept new messages while the queues are drained.

 

To take MBX1 out of Maintenance Mode all you have to do is reverse these actions. First, reactive all components:

Set-ServerComponentState MBX1 -Component ServerWideOffline -State Active -Requester Maintenance

If the server is part of a DAG, resume the cluster node and remove the restriction on the database copies:

Resume-ClusterNode MBX1

Set-MailboxServer MBX1 -DatabaseCopyActivationDisabledAndMoveNow $False

Set-MailboxServer MBX1 -DatabaseCopyAutoActivationPolicy Unrestricted

And finally resume the transport queues:

Set-ServerComponentState MBX1 -Component HubTransport -State Active -Requester Maintenance

Sources: Brian Reid | C7 Solutions and Michael Van Horenbeeck

Creating a Custom Receive Connector in Exchange 2013

Receive Connectors are used to control the flow of inbound messages into Exchange. With Exchange 2013 they are configured on servers with the Transport service (all mailbox servers) or with the Front End Transport service (all Client Access servers).

This means we can configure a Receive Connector in two different places... However, the big difference is that the Front End Transport service does not queue any messages locally while the Transport service does! Therefore, if you want Exchange to queue e-mails received by a custom Receive Connector (for example, in case of a problem with the recipient’s mailbox) you have to create it on your Mailbox servers.

Obviously, all the Receive Connectors required for internal mail flow are automatically created when a Client Access server or Mailbox server is installed. While Exchange 2007/2010 Hub Transport servers were not configured out of the box to accept e-mails from the internet, the new Client Access server comes with a Receive Connector named “Default Frontend server_name” already configured to allow “Anonymous Users” to connect to it to allow inbound flow from the Internet.

But sometimes custom Receive Connectors are required for various reasons: to control which servers receive messages from a particular IP address; to configure special connector properties for messages received from a particular IP address such as allowing larger messages or more recipients per messages; or to allow servers, applications or devices such as printers to establish unauthenticated SMTP connections to Exchange in order to send e-mails.

To create Receive Connectors in Exchange 2013 we can use the Exchange Administration Center [EAC] or the Exchange Management Shell [EMS]. In this tip, we will be using the Shell to create a Receive Connector that:
• Is associated with the Mailbox server called MBX1;
• Listens for incoming SMTP connections on the IP address 10.10.1.1 and port 25;
• Accepts incoming SMTP connections only from the IP range of 192.168.1.1 to 192.168.1.10;
• Accepts e-mails of a size up to 50MB;

New-ReceiveConnector -Name “Application 1” –Server MBX1 -Usage Custom -Bindings 10.10.1.1:25 -RemoteIPRanges 192.168.1.1-192.168.1.10 -MaxMessageSize 50MB

But what if a server is multi-role and has the Client Access and Mailbox server roles? How does Exchange know which role to associate the Receive Connector with? For these situations we have the TransportRole parameter exactly to designate the server role associated with this connector. The valid types are FrontendTransport and HubTransport.

So our example would become:

New-ReceiveConnector -Name “Application 1” –Server MBX1 -Usage Custom -Bindings 10.10.1.1:25 -RemoteIPRanges 192.168.1.1-192.168.1.10 -MaxMessageSize 50MB –TransportRole HubTransport

Office 365 Wave 15 Release Date

It’s official! According to several Microsoft sources at the Exchange Ignite, the new version of Office 365 commonly known as “wave 15” will be released in a couple of weeks in February 27th! :)

This coincides with the release of Exchange 2013 CU1 as well.

So stay tuned in the Office 365 Blog!

Exchange Server 2010 SP3 Released

Finally the much anticipated SP3 for Exchange 2010 has just been released! It brings the features and capabilities:

• Support for installing and deploying Exchange 2010 on Windows Server 2012;
• Support for Internet Explorer 10 to connect to Exchange 2010;
• Fixes;
• Coexistence with Exchange 2013.

 

Important: Exchange 2010 SP3 allows Exchange 2010 servers to coexist with Exchange 2013 CU1, which is scheduled to be released in February 27th.

 

Please also note that this Service Pack requires schema updates.

 

DOWNLOAD it here.

Moving the Primary Active Manager

If, for some reason, the server currently hosting the Active Manager role of Primary Active Manager [PAM] fails, this role should automatically move to a surviving server of the Database Availability Group [DAG] which then takes ownership of the cluster quorum resource.

However, you might face a (rare) scenario where this doesn’t happen and you end up with a failed server and with Exchange still thinking that server is the PAM. Among other things, you will not be able to add/remove members to/from the DAG...

PAM decides which database copies will be active and passive, is responsible for getting topology change notifications and reacting to server failures. The DAG member that holds the PAM role is always the member that currently owns the cluster quorum resource (default cluster group).

So how do we move the PAM to one of the surviving servers? To achieve this, we need to use the command line and use the following Windows Clustering command to move the cluster quorum resource:

cluster.exe “DAG Name” /MoveTo:NewDAG

where “DAG Name” is your DAG Cluster Name and NewDAG is the node where you want to move the PAM to.

Exchange 2013 Automatic Reseed

Microsoft has made great improvements in Exchange 2013, some of these around Database Availability Groups [DAGs]. For example, it is now possible to reseed a database from multiple sources, greatly reducing the overall time this operation usually takes. Another improvement, in this case a new feature, is called Automatic Reseed, or simply AutoReseed.

With Exchange 2010, if you lose the disk where your database is (either active or passive), Exchange will failover that database to another server (assuming it is part of a DAG with multiple copies). After that, an administrator will typically replace the faulted disk and reseed the database back to that server. This, of course, in scenarios where resilience through RAID or enterprise-level storage is not provided, which would cater for disk failures.

The purpose of AutoReseed is to overcome this situation and automatically restore database redundancy by using spare disks provisioned specifically for this. All it involves is pre-mapping volumes and databases using mount points that will be used for the databases and the reseed operation. In a simplistic way:

1. Mount all volumes (used for databases and as spares) under a single mount point, C:\ExchangeVolumes for example;
2. Mount the root directory of mailbox databases as another mount point under C:\ExchangeDatabases for example. Next, create two directories for each database: one for the database itself and another for the log files;
3. Finally create the database(s).

 

Here is AutoReseed process flow:

1. The Exchange Replication service periodically scans for database copies that have a status of FailedAndSuspended;
2. If one is found, it does pre-requisite checks like checking if spare drives are available and ensuring nothing might prevent Exchange from automatic reseeding the database;
3. If all the checks pass, the Replication service allocates and remaps a spare drive;
4. Seeding is performed;
5. Once seeding is complete, the Replication service checks if the seeded copy is healthy.

All an administrator needs to do now is simply replace the faulty disk and reconfigure it as a spare for the DAG!

To read all about this new feature and how to implement it, please check the article at MSExchange.org.

 

Exchange Server 2013 Help Files Updated

The Exchange 2013 Help files (.chm) have been updated on January 18.

 

Here you can download the help files for both Exchange Server 2013 Hybrid and On-Premise deployments.

E-mail Recipient Number Distribution

Have you ever wondered what the distribution of the number of recipients per e-mail in your organization is?
 

The following script will go through every e-mail received by Exchange and group the results by the number of recipients.

Get-TransportServer | Get-MessageTrackingLog -ResultSize Unlimited -EventID RECEIVE -Start "07/05/2012 16:40" | ? {$_.Source -eq "STOREDRIVER"} | Select RecipientCount | Group RecipientCount | Select @{Name="Recipients"; Expression={[Int] $_.Name}}, Count | Sort Recipients

Alternatively, you can group them in batches depending on which format you want the output.

[Int] $1 = $2 = $5 = $10 = $30 = $50 = $75 = $100 = $150 = $200 = $250 = $big = 0

Get-TransportServer | Get-MessageTrackingLog -ResultSize Unlimited -EventID RECEIVE -Start "07/05/2012" | ? {$_.Source -eq "STOREDRIVER"} | Select RecipientCount | ForEach {
    If ($_.RecipientCount -eq 1) { $1++ }
    If ($_.RecipientCount -eq 2) { $2++ }
    If ($_.RecipientCount -gt 2   -and $_.RecipientCount -le 5)    { $5++ }
    If ($_.RecipientCount -gt 5   -and $_.RecipientCount -le 10)   { $10++ }
    If ($_.RecipientCount -gt 10  -and $_.RecipientCount -le 30)   { $30++ }
    If ($_.RecipientCount -gt 30  -and $_.RecipientCount -le 50)   { $50++ }
    If ($_.RecipientCount -gt 50  -and $_.RecipientCount -le 75)   { $75++ }
    If ($_.RecipientCount -gt 75  -and $_.RecipientCount -le 100)  { $100++ }
    If ($_.RecipientCount -gt 100 -and $_.RecipientCount -le 150)  { $150++ }
    If ($_.RecipientCount -gt 150 -and $_.RecipientCount -le 200)  { $200++ }
    If ($_.RecipientCount -gt 200 -and $_.RecipientCount -le 250)  { $250++ }
    If ($_.RecipientCount -gt 250 -and $_.RecipientCount -le 300)  { $300++ }
    If ($_.RecipientCount -gt 300) { $big++ }
}

Write-Host "1,                     $1"
Write-Host "2,                     $2"
Write-Host "Between 3 and 5,       $5"
Write-Host "Between 6 and 10,      $10"
Write-Host "Between 11 and 30,     $30"
Write-Host "Between 31 and 50,     $50"
Write-Host "Between 51 and 75,     $75"
Write-Host "Between 76 and 100,    $100"
Write-Host "Between 101 and 150,   $150"
Write-Host "Between 151 and 200,   $200"
Write-Host "Between 201 and 250,   $250"
Write-Host "Between 251 and 300,   $300"
Write-Host "More than 300,         $big"

Exchange 2013 Database Mount Limit

A change introduced in Exchange 2013 that many administrators are not aware is the fact that with the Enterprise Edition of Exchange, you can now only mount up to 50 mailbox databases per server, a reduction in 50% from the 100 with Exchange 2010! The limit of the Standard Edition remains at 5 databases.

Highly available and resilient environments might have some problems when migrating from Exchange 2010 if they have servers with more than 50 databases (in big environments with 3 or 4 copies of each database it is not that uncommon). Therefore, a complete review of the current database layout might have to happen.

But why this change?! Basically it was introduced in order to ensure a good performance from the mailbox servers. Some of the reasons behind this change are the improvements made in some areas, which mean the mailbox servers consume more memory now... For example, Exchange 2013 uses Search Foundation instead of MSSearch in order to be consistent with SharePoint and to allow discovery searches across e-mail and documents. Search Foundation uses more memory and it seems it can take between 10 to 15% of available memory on a mailbox server.

Another change is the move of protocol handling from the Client Access Server [CAS] to the Mailbox server. It helps make the CAS more stateless and not so dependent on a particular mailbox server but it also increases the memory use on the mailbox server...

Note: the limit of 16 mailbox servers per DAG remains in Exchange 2013.

Dynamic Distribution Groups with MultiValued Attribute

Ever wondered how to use the Multi-Valued Attributes in Exchange 2010 SP2 (or above) with Dynamic Distribution Groups? The following example shows you how to do this:

First we use 3 users and set their ExtensionCustomAttribute1 attribute to something we want to use:

Set-Mailbox User1 -ExtensionCustomAttribute1 Area1,Area2,Area3
Set-Mailbox User2 -ExtensionCustomAttribute1 Area2,Area3,Area4
Set-Mailbox User3 -ExtensionCustomAttribute1 Area3,Area4,Area5

Now we create our dynamic groups based on the information we want to “filter”:

New-DynamicDistributionGroup -Name Area1 -RecipientFilter {ExtensionCustomAttribute1 -eq “Area1”}
New-DynamicDistributionGroup -Name Area2 -RecipientFilter {ExtensionCustomAttribute1 -eq “Area2”}
New-DynamicDistributionGroup -Name Area3 -RecipientFilter {ExtensionCustomAttribute1 -eq “Area3”}

If we want to make sure they are working as expected, we can easily return each group’s members:

$Group = Get-DynamicDistributionGroup Area1
Get-Recipient -RecipientPreviewFilter $Group.RecipientFilter

In the example above the group:

• Area1 will have User1;

• Area2 will have User1 and User2;

• Area3 will have User1, User2 and User3.

Check DAG Status

With Exchange 2010 and Database Availability Groups [DAGs], Microsoft greatly increases high availability and resilience in Exchange. But now, it is not only important to make sure your active mailbox databases are healthy and working fine, but it is also crucial to ensure your passive databases are healthy and ready to be mounted in case of necessity.

Microsoft System Center Operations Manager does a great job monitoring Exchange, but if you simply like to check for yourself, there are many cmdlets available. Two of the most important ones and most frequently used, in my opinion are the Get-MailboxDatabaseCopyStatus and Test-ReplicationHealth cmdlets.

Get-MailboxDatabaseCopyStatus will show status information about your databases that are part of a DAG. Using the following cmdlet, you can check all the databases in all the DAGs present in your environment:

(Get-DatabaseAvailabilityGroup) | ForEach {$_.Servers | ForEach {Get-MailboxDatabaseCopyStatus -Server $_}}

Using the Test-ReplicationHealth cmdlet will allow you to check all aspects of the replication and replay status, providing you with a complete overview of a Mailbox server in a DAG. This way, administrators can proactively monitor the continuous replication and the continuous replication pipeline, the availability of the Active Manager and the health and status of the underlying cluster service, quorum and network components.

(Get-DatabaseAvailabilityGroup) | ForEach {$_.Servers | ForEach {Test-ReplicationHealth -Server $_}}

Exchange Server Vulnerability Could Allow Remote Code Execution

Unfortunately, there seems to be another vulnerability in Exchange Server WebReady Document Viewing feature, this time with the third-party code Oracle Outside In libraries.

This security update resolves publicly disclosed vulnerabilities and one privately reported vulnerability in Microsoft Exchange Server.

The most severe vulnerabilities are in Microsoft Exchange Server WebReady Document Viewing and could allow remote code execution in the security context of the transcoding service on the Exchange server if a user previews a specially crafted file using Outlook Web App.

The transcoding service in Exchange that is used for WebReady Document Viewing is running in the LocalService account. The LocalService account has minimum privileges on the local computer and presents anonymous credentials on the network.

This security update is rated Critical for all supported editions of Exchange Server 2007 and 2010!

For more information and to download the update, please see Microsoft Security Bulletin MS12-080 - Critical