Exchange 2013 default OWA apps do not work

When you install Exchange Server 2013 on a Window Server 2012 R2-based computer, default apps (such as Bing map and Action item) in Outlook Web App do not work depending on the version of Exchange installed.

 

This issue occurs because the logic to load app resources is broken in Windows Server 2012 R2. To resolve this issue, install Cumulative Update 5 for Exchange Server 2013.

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.