Exchange Hybrid #550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

There might be cases where in Exchange hybrid deployments where Exchange Online and on-premises users have the same e-mail namespace (such as alias@domain.com), Office 365 users are unable to send e-mails to on-premises users and receive a nondelivery report (NDR) error message similar to:

 

#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

 

Amongst other possible reasons, this can be caused if the domain set up in the hybrid deployment is not configured as a shared domain in Office 365. To correct this problem, follow these steps using the Exchange Admin Center in the new Office 365:

1.       Sign in to the Office 365 portal as a global admin;

2.       In the header, click Admin, and then click Exchange;

3.       In the left navigation pane of the Exchange Admin Center, click mail flow and then click accepted domains;

4.       Select the domain that is set up for the hybrid deployment, and then click Details;

5.       Select Shared, and then click save.

 

The EAC the domains that you added to your account through the Microsoft Office 365 portal. It lets you manage how messages are delivered. In a hybrid scenario, Exchange Online must be set up correctly so that when a cloud-based user sends an e-mail to an on-premises user, Exchange Online routes the e-mail to the on-premises messaging environment.

Office 365 Service Comparison

The following page can be used to filter and compare features of Office 365 plans, Office 365 services and on-premises products, such as comparing every feature of Exchange Server 2013 on-premises vs. Exchange online: Office 365 service comparison.

This is extremely useful when exploring Exchange Online (or any Office 365 service for that matter) and trying to decide if Exchange Online meets all the organization’s requirements.

 

Exchange 2013 StalledDueToCI Error

When running some tests on Exchange 2013 Cumulative Update 1, namely migrating Public Folders from Exchange 2010 to 2013, I noticed the migration was taking too long. When querying more details regarding the migration request using the cmdlet Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport, I noticed the following error:

The job is currently stalled due to ‘Content Indexing’ lagging behind on resource ‘CiAgeOfLastNotification(Mailbox Database 1415171211)’

When checking the ContentIndexState for this database, it was in a FailedAndSuspended state...

It seems there is a bug in Exchange 2013 RTM and CU1 which causes Exchange to not setup all the groups necessary in Active Directory. Specifically for this case is the group “ContentSubmitters”. As such, if you are experiencing this problem, you need to:

    1. Manually create the group in AD under the existing exchange groups OU;

    2. Change the security on the group and allow Administrators and NetworkService accounts Full Control;

    3. Restart the Microsoft Exchange Search and the Microsoft Exchange Search Host Controller services on every Mailbox server.

Now, you should notice the mailbox databases content index status changing from Failed to Healthy, with the migrations starting to transfer at a much better speed.

Exchange 2013 DAG with Dynamic Quorum

Windows Server 2012 introduced a new quorum model called Failover Clustering Dynamic Quorum, which we can use with Exchange. When using Dynamic Quorum, the cluster dynamically manages the vote assignment to nodes based on the state of each node. When a node shuts down or crashes, it loses its quorum vote. When a node successfully re-joins the cluster, it regains its quorum vote. By dynamically adjusting the assignment of quorum votes, the cluster can increase or decrease the number of quorum votes that are required to keep it running. This enables the cluster to maintain availability during sequential node failures or shutdowns.

 

With a dynamic quorum, the cluster quorum majority is determined by the set of nodes that are active members of the cluster at any time. This is an important distinction from the cluster quorum in Windows Server 2008 R2 where the quorum majority is fixed, based on the initial cluster configuration.

 

The advantage this brings, is that it is now possible for a cluster to run even if the number of nodes remaining in the cluster is less than 50%! By dynamically adjusting the quorum majority requirement, the cluster can sustain sequential node shutdowns down to a single node and still keep running. It does not allow the cluster to sustain a simultaneous failure of a majority of voting members though. To continue running, the cluster must always have a quorum majority at the time of a node shutdown or failure.

 

 

The following picture shows a DAG still operational even though two out of three servers are offline:

 

 

To read more about this feature, including tests with an Exchange 2013 DAG, please check my Exchange 2013 DAGwith Dynamic Quorum article on MSExchange.org.

Last Logon Information in Exchange 2013

If we want to check when a user last logged on to their mailbox in Exchange 2007 and 2010 we have to use the Exchange Management Shell [EMS] and the following cmdlet:

Get-MailboxStatistics "User" | Select LastLoggedOnUserAccount, LastLogonTime

Note that the LastLoggedOnUserAccount property indicates the account last used to log on to the mailbox. This could be a user with FullAccess permissions to the mailbox, a delegate or even someone simply checking the user’s Calendar!

 

With Exchange 2013 part of this information is now available through the Exchange Administration Centre as well. If you:

    1.       Navigate to Recipients and then Mailboxes;

    2.       Double-click on the user you want to check this information for;

    3.       Select the Mailbox Usage tab and in there you will see the Last Logon date and time.

However, to check who actually logged on, we still need to use the EMS...