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