msExchangeRecipientTypeDetails Active Directory Values

A while back, while performing a migration to Office 365, I had to convert a Distribution Group into a Room List. However, due to the nature of the migration, I didn’t have access to an on-premises Exchange to use the Shell and convert it, so I had to resort to using ADSIedit. So how do we do this using ADSIedit?

 

There is a reference field that specifies what a recipient type is, as far as on-premises AD/Exchange is concerned, Recipient Type Details = msExchRecipientTypeDetails.

 

As many other AD attributes, these are represented by an Integer value in AD. Here are all the possible values for Recipient Type Details:

Object Type	RecipientTypeDetails	Value Name
User Mailbox	1	UserMailbox
Linked Mailbox	2	LinkedMailbox
Shared Mailbox	4	SharedMailbox
Legacy Mailbox	8	LegacyMailbox
Room Mailbox	16	RoomMailbox
Equipment Mailbox	32	EquipmentMailbox
Mail Contact	64	MailContact
Mail User	128	MailUser
Mail-Enabled Universal Distribution Group	256	MailUniversalDistributionGroup
Mail-Enabled Non-Universal Distribution Group	512	MailNonUniversalGroup
Mail-Enabled Universal Security Group	1024	MailUniversalSecurityGroup
Dynamic Distribution Group	2048	DynamicDistributionGroup
Public Folder	4096	Public Folder
System Attendant Mailbox	8192	SystemAttendantMailbox
System Mailbox	16384	SystemMailbox
Cross-Forest Mail Contact	32768	MailForestContact
User	65536	User
Contact	131072	Contact
Universal Distribution Group	262144	UniversalDistributionGroup
Universal Security Group	524288	UniversalSecurityGroup
Non-Universal Group	1048576	NonUniversalGroup
Disabled User	2097152	DisabledUser
Microsoft Exchange	4194304	MicrosoftExchange
Arbitration Mailbox	8388608	ArbitrationMailbox
Mailbox Plan	16777216	MailboxPlan
Linked User	33554432	LinkedUser
Room List	268435456	RoomList
Discovery Mailbox	536870912	DiscoveryMailbox
Role Group	1073741824	RoleGroup
Remote Mailbox	2147483648	RemoteMailbox
Team Mailbox	137438953472	TeamMailbox

 

 

As such, all I had to do was locate the Distribution Group in AD, update its msExchRecipientTypeDetails attribute to 268435456 and wait for DirSync to replicate the change.

Exchange Mailbox ForwardingSMTPAddress setting not working

For a variety of different reasons, sometimes there is the necessity of users or administrators to automatically forward e-mails addressed to one mailbox to another mailbox. To achieve this there are several options such as Outlook Inbox Rules or Transport Rules. Another option is to configure the mailbox itself using the ForwardingAddress setting which can be configured using the Exchange Management Console/Exchange Admin Center.

However, in some cases the end recipient is a SMTP address external to the local Exchange environment. As ForwardingAddress only works with local recipients, we can create a contact for the target mailbox and then use ForwardingAddress with the contact.

But creating a contact might not be desirable, so a more “direct” way is to use the ForwardingSmtpAddress setting instead (which can only be configured through the Shell). As such, what most administrators do is something like this:

Set-Mailbox nuno -ForwardingSMTPAddress mota@somedomain.com -DeliverToMailboxAndForward $True

After doing this, the administrator notices that e-mails are still not being automatically forwarded... Let us see why.

Within Exchange and Office 365, administrators can create remote domains. By default, every Office 365 tenant leverages the “*” domain. When a specific remote domain does not exist, the “*” remote domain setting are applied to the message. However, this is not true for on-premises Exchange environments where, by default, there are no remote domains.

A property of a remote domain is the AutoForwardEnabled property, which allows administrators to define if auto-forwarding is allowed on e-mails destined to the domain specified. By default auto-forwarding in Office 365 is allowed to all domains, but not in on-premises environments.

This means that administrators need to create a remote domain for the forwarding addresse's domain (or a generic one), in my example, somedomain.com, and ensure AutoForwardEnabled is set to $True (which it is by default when creating a new remote domain):

New-RemoteDomain -Name ExternalDomain -DomainName somedomain.com
Get-RemoteDomain ExternalDomain | Select DomainName, AutoDorwardEnabled

Note that using ForwardingAddress is a way for an administrator to bypass forwarding settings on remote domains, meaning it is not necessary to create a remote domain for the forwarding to work.

Bottom line: if you want to use the ForwardingSmtpAddress setting, make sure you have a remote domain for that SMTP addresse's domain with AutoForwardEnabled set to $True.

DirSync Attributes Synced

Have you ever wondered exactly which Active Directory (AD) attributes are synced from the on-premises AD to Windows Azure AD and/or which AD attributes are written back to the on-premises AD from Azure AD in an Exchange hybrid deployment scenario?

 

If yes, then the following Wiki has the answer: DirSync: List of Attributes that are Synced by the Windows Azure Active Directory Sync Tool.

 

It also details how DirSync determines what is not synced (excluded) from the on-premises environment to Windows Azure AD.

Exchange 2013 Edge IP Block List BypassedRecipients

On Edge Transport servers, IP Block list providers are used by the Connection Filtering agent, which acts on the IP address of the incoming SMTP connection to determine what action, if any, to take on an incoming message.

The Get-IPBlockListProvidersConfig cmdlet is used to view the settings that affect all IP Block list providers that are configured on an Edge Transport server. When running this cmdlet, there is a property called BypassedRecipients:

The BypassedRecipients parameter specifies the e-mail addresses of internal recipients that are exempted from filtering by IP Block list providers.

If we want to configure connection filtering to bypass filtering for e-mails sent to nuno@letsexchange.com, we run the following cmdlet:

Set-IPBlockListProvidersConfig -BypassedRecipients nuno@letsexchange.com

We can easily add multiple values and overwrite any existing entries by using the following syntax: "email1","email2",...

To add or remove one or more values without affecting any existing entries, we can use the following syntax:

Set-IPBlockListProvidersConfig -BypassedRecipients @{Add=”email1”,”email2”; Remove=”email3”}

Exchange 2013 Servicing Model - Support for CU’s & SP’s

In the Servicing Exchange 2013 article there is the following Q&A regarding the support for Cumulative Updates (CUs):

 

Q: How long is a CU supported?

A: A CU will be supported for a period of three (3) months after the release date of the next CU. For example, if CU1 is released on 3/1 and CU2 is released on 6/1, CU1 support will end on 9/1.

As we know, a Service Pack (SP) is typically supported for 12 months after the next SP is released. However, since SP1 is CU4, what does this mean in terms of support for SP1? Will SP1 no longer be supported once CU6 gets released? No, not at all!

Lifecycle Support is the reason why CU4 is officially branded SP1 and not a CU, although technically it is. If we check the lifecycle for Exchange 2013, SP1 is explicitly mentioned and it is stated that its “support ends 12 months after the next service pack released”:

 

Which confirms the assumption: servicing model for CU’s, LifeCycle model for SP’s.

 

This also addresses the needs of Microsoft partners who want to certify their products against a release running at a slower cadence. SP1 will be supported according to the LifeCycle policy already mentioned (until 12 months after the release of a subsequent SP) but will only receive security updates. Customers who raise escalations requesting fixes or who want the benefits of the latest set of fixes will have to move to the appropriate CU to receive non security related fixes.

Managed Availability Failed by Design Error

If you navigate to the Exchange’s ProbeResult Crimson Channel under ActiveMonitoring, you will likely find the following error event logged:

EventID: 2
Channel: Microsoft-Exchange-ActiveMonitoring/ProbeResult
ResultId: 479968430
ServiceName: Monitoring
ResultName: HealthManagerHeartbeatProbe
Error:  Failed by design.
Exception: System.Exception: Failed by design. at Microsoft.Office.Datacenter.ActiveMonitoring.TestActiveMonitoringProbe.DoWork(CancellationToken cancellationToken) at Microsoft.Office.Datacenter.WorkerTaskFramework.WorkItem.Execute(CancellationToken joinedToken) at Microsoft.Office.Datacenter.WorkerTaskFramework.WorkItem. c__DisplayClass2.startexecuting b__0() at System.Threading.Tasks.Task.Execute()

So why is something failing by design?! Basically this probe is testing the Managed Availability framework, including that it can run responders. More specifically, a probe that will test that monitors can become unhealthy and execute null responders.

Bottom line, nothing to worry about :)

Clean-MailboxDatabase in Exchange 2013

In Exchange 2007 and 2010 we had the Clean-MailboxDatabase cmdlet to get disconnected mailboxes visible in the GUI without having to wait for the maintenance schedule.

However, in Exchange 2013 this cmdlet no longer exists but the same problem persists: disconnected mailboxes are not visible immediately after being removed or disabled.... Clean-MailboxDatabase has been replaced by Update-StoreMailboxState, which forces the mailbox store state in the Exchange store to be synchronized with Active Directory.

Its syntax is as follows:

Update-StoreMailboxState -Database “DatabaseIdParameter” -Identity “StoreMailboxIdParameter” [-Confirm [SwitchParameter]] [-WhatIf [SwitchParameter]]

Both the –Database and –Identity parameters are required, meaning we need to know the identity of the mailbox (mailbox GUID) that we want to update the store state for. To do so, we can run the following cmdlet for example:

Get-MailboxDatabase | Get-MailboxStatistics | Format-List DisplayName, MailboxGuid, Database, DisconnectReason, DisconnectDate

Once we know the mailbox’s GUID and in which database it was located, we can update its mailbox state by running:

Update-StoreMailboxState -Database “db_name” -Identity “mailbox_guid”

If we want to update the mailbox state for all mailboxes on a particular database, we can adapt the cmdlet to:

Get-MailboxStatistics -Database “db_name” | ForEach {Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$False}

Finally, if we want to just update the mailbox state for all disconnected mailboxes on a particular database:

Get-MailboxStatistics -Database “db_name” | Where {$_.DisconnectReason -ne $null } | ForEach {Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$False}

To be honest, I am not sure why this change from Clean-MailboxDatabase to Update-StoreMailboxState. The only reason I can think of is to give administrators the possibility to just update the state of a single mailbox instead of having to update an entire database.

Get-LogonStatistics in Exchange 2013

The Get-LogonStatistics cmdlet is used to retrieve logon statistics about currently active sessions such as user name, logon time, last access time and client version for example.

 

As you can see from the next screenshot, the Get-LogonStatistics cmdlet is still present in Exchange 2013 all the way to the latest CU5:

 

However, if you actually try to use it, you will get an error similar to the following:

 

 

The specified mailbox "DB01" doesn't exist.
  + CategoryInfo          : NotSpecified: (:) [Get-LogonStatistics], ManagementObjectNotFoundException
  + FullyQualifiedErrorId : [Server=EXAIO,RequestId=361f29b3-6474-4aad-a43e-111fe3af86b2,TimeStamp=07/08/2014 14:42:08] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 83C28CB1,Microsoft.Exchange.Management.MapiTasks.GetLogonStatistics
  + PSComputerName        : exaio.letsexchange.com



Cannot find LogonStatistics objects from the root 'DB01'. Please make sure that you specified the correct search root and that you have the correct permissions to perform the search.
  + CategoryInfo          : NotSpecified: (:) [Get-LogonStatistics], MapiOperationException
  + FullyQualifiedErrorId : [Server=EXAIO,RequestId=ebda72ad-ce19-443e-95bf-6b417cd14d7e,TimeStamp=07/08/2014 14:42:18] [FailureCategory=Cmdlet-MapiOperationException] 3962F04B,Microsoft.Exchange.Management.MapiTasks.GetLogonStatistics
  + PSComputerName        : exaio.letsexchange.com

The reason for this error is that this cmdlet has been deprecated in Exchange 2013 since RTM! According to Microsoft, “Get-LogonStatistics is no longer supported by Exchange 2013. The cmdlet and documentation will eventually be removed.”

 

The documentation mentioned above refers to a couple of TechNet articles that still mentioned the cmdlet. However, these now seem to have been removed.

Exchange 2013 Loose Truncation

Loose Truncation is a new feature that was introduced in Exchange 2013 Service Pack 1. Its purpose is to prevent possible disk space issues that can occur in environments with DAGs when one or more copies of a database is offline for an extended period of time. When enabled, loose truncation changes the “normal” truncation behavior. Each database copy tracks its own free disk space and starts to truncate transaction log files independently if the available disk space falls behind a set threshold configurable by the administrator.

To continue reading, please check the full Exchange 2013 Loose Truncation article at MSExchange.org.

How to manually force a Directory Synchronization with the new DirSync tool

In the latest release of the Windows Azure Directory Synchronization tool (aka DirSync), the way we manually force a directory synchronization has changed.

In previous versions, we had to navigate to the location where DirSync was installed, launch DirSyncConfigShell.psc1 (PowerShell Console) and then run the Start-OnlineCoexistenceSync cmdlet:

 

 

However, in this latest version this console file does not exist anymore:

 

 

So how do we manually force a directory synchronization now?! Well, DirSync cmdlets are now part of a PowerShell module named DirSync. As such, simply lunch a PowerShell console with administrative rights, import this module and run the usual Start-OnlineCoexistenceSync cmdlet. Simple as that!

 

This change, however, will obviously break any scripts you might have developed, but it shouldn’t be hard to update them.

As expected, if you try to import this module in an older version of DirSync, you will get the following error as the module does not exist:

 

 

If we try to list all the cmdlets available in this module, we actually don’t receive anything back:

 

 

So where are all the DirSync PowerShell cmdlets we had in previous versions?! Not to worry. The DirSync module is actually just a wrapper which calls “%programfiles% \Windows Azure Active Directory Sync\DirSync\DirSync.psd1”. As such, if we want to list all the cmdlets, we have to check the Microsoft.Online.Coexistence.PS.Config module instead:

 

 

Unfortunately not all of these cmdlets are fully documented yet, but we can guess what most of them do based on their name anyway.

 

 

In my opinion, this change is more than welcomed as it makes life a lot easier!

Exchange 2013 with Rights Management Connector

Windows Rights Management Services (also known as Rights Management Services, Active Directory Rights Management Services or simply RMS) is a form of Information Rights Management used on Microsoft Windows that uses encryption and a form of selective functionality denial in order to limit access to information, such as e-mails or Word documents for example, and enforce what operations authorized users can perform on them.

Users can use this technology to encrypt information stored in such document formats, and through policies embedded in these, prevent the protected content from being decrypted except by specified people or groups, under certain conditions, and even for certain periods of time. Specific operations such as printing, copying, editing, forwarding and deleting can be allowed or disallowed by the author.

 

Rights Management Server first debuted in 2005 as an add-on to Windows Server 2003, with client API libraries made available for Windows XP and Windows 2000. With Windows Server 2008, it was renamed to Active Directory Rights Management Services [ADRMS], reflecting its higher level of integration with AD.

The next big “upgrade” was in July 2013 when Microsoft released a preview of Azure Rights Management which allows organizations to protect their data in Office 365. Azure RMS is included with E3, E4, A3 and A4 plans at no additional cost, or it can be purchased as a standalone subscription.

 

For organizations that are in the process of migrating to Office 365 there is a feature called RMS Connector that enables protected content to work with an organization’s online services as well as on-premises servers.

 

RMS connector lets administrators enable existing on-premises servers, such as Exchange, SharePoint or even file servers running Windows Server to use their Information Rights Management [IRM] functionality with the cloud-based RMS. With this functionality, IT and users can easily protect information both inside and outside the organization, without having to install additional infrastructure or establish trust relationships with other organizations.

The RMS connector is a small-footprint service that is installed on-premises on servers that run Windows Server 2008 R2, 2012 or 2012 R2. After installed and configured, it acts as a communications interface (a relay) between the on-premises IRM-enabled servers and the cloud service.

To read the entire article, please check Exchange 2013 with Rights Management Connector on MSExchange.org.

 

 

AssociatedItemCount versus ItemCount in Exchange

When running the Get-MailboxStatistics cmdlet, two of the attributes returned are AssociatedItemCount and ItemCount. But what exactly are the differences between the two?!

 

As one would expect, ItemCount is the total number of e-mails, contacts, etc. items available and visible to the end-user on the mailbox. Basically, everything the users sees.

 

On the other hand, AssociatedItemCount are special messages in the Associated Table of a folder. They are most often rules and other special messages like the MRM FAI message. Basically, things that are “associated” with a folder, usually other file-like objects not visible to users such as IPM.Configuration.RssRule, IPM.Configuration.AutoComplete, Outlook Rules Organizer or IPM.Microsoft.MigrationStatus.

 

These are not visible to the user, only through MFCMapi for example (right-click a folder and select Open Associated Contents table).

 

Folder Associated Information (FAI) is a collection of message objects that are stored in a folder object and are typically hidden from view by e-mail applications. An FAI Message object is used to store a variety of settings and auxiliary data, including forms, views, calendar options, favorites and category lists.

Database Availability Group Failover during a Mailbox Move

During a mailbox move operation if the active database becomes unavailable then the Mailbox Replication Service [MRS] contacts the active manager to see which copy will take over. MRS then logs on to the mailbox on the new database and continues with the move process from where it left off. This as long as the DataMoveReplicationConstraint setting for the database is set to something else other than None and as long as the database was not down for longer than 30 minutes (or there is another copy satisfying the constraint).

 

Let us assume the database has 3 copies. It is entirely possible that MRS will just continue working after a failover even if the original server is down.

 

If DataMoveReplicationConstraint is set to None then MRS will try to connect to the same database every 30 seconds for the next 30 minutes. The 30 minute is from the maximum retry of 60 times every 30 seconds. This value can be changed in the in the msExchMailboxReplication.exe.config file.

 

The DataMoveReplicationConstraint parameter specifies the throttling behavior for high availability mailbox moves. The possible values are:

• None: moves should not be throttled to ensure high availability. Use this setting if the database is not part of a DAG;
• SecondCopy (default): at least one passive mailbox database copy must have the most recent changes synchronized. Use this setting to indicate that the database is replicated to one or more mailbox database copies;
• SecondDatacenter: at least one passive mailbox database copy in another AD site must have the most recent changes replicated. Use this setting to indicate that the database is replicated to database copies in multiple AD sites;
• AllDatacenters: at least one passive mailbox database copy in each AD site must have the most recent changes replicated. Use this setting to indicate that the database is replicated to database copies in multiple AD sites;
• AllCopies: all copies of the database must have the most recent changes replicated. Use this setting to indicate that the database is replicated to one or more mailbox database copies.

 Note: any value other than None enables MRS to coordinate with Active Manager.

Exchange server has failed to heartbeat error after uninstalling Exchange

When you uninstall Exchange 2013, you might encounter the following error in the Event Log regarding the Managed Availability’s monitoring agent complaining that the server you uninstalled is not available:

Log Name: Microsoft-Exchange-ManagedAvailability/Monitoring
Source: Microsoft-Exchange-ManagedAvailability
Event ID: 4
Task Category: Monitoring
Level: Error
Description: Machine “uninstalled_server” has failed to heartbeat since “unistalled_date_and_time”, as observed by machine “some_other_server”. Restarting the Exchange Health Manager service did not fix the problem.

The problem is that the old server continues to be present under the following registry key for all other Exchange Servers:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ActiveMonitoring\Subjects

This causes the error above in the Event Log or SCOM alerts. If this happens, the workaround is to simply delete the old server(s) from the registry key mentioned above on the remaining servers.

Microsoft says that this bug was previously closed as Won’t Fix but that they have re-opened it for re-triage.