Monday, November 10, 2014

AADSync ProxyAddresses Not Synchronized to Office 365

If you have installed the first publicly available version of AADSync (v1.0.0419.0911), the eventual successor to DirSync, you might have noticed that the ProxyAddresses attribute will not get synchronized to Office 365. Unfortunately this means that all proxy addresses will be gone in Exchange Online!

It turns out this is not a configuration error, but a bug with this release... Microsoft statement is that “currently Proxyaddresses will not work with AADSYNC, and will be addressed in the next release”.

As such, you have two alternatives:
   1. Update to the latest version of AADSync, v1.0.0470.1023 (obviously recommended!);
   2. If, for some reason, you don’t want to upgrade, edit the existing rule to sync the proxyaddresses attribute.

Monday, November 3, 2014

Permissions lost after moving mailbox from Exchange 2003 to Exchange Online in hybrid environment

Consider the following scenario:
  • Your on-premises Exchange organization includes mailboxes that are hosted in Exchange 2003;
  • Your on-premises Exchange organization is set up for a hybrid deployment together with Exchange Online;
  • You move users or shared mailboxes from on-premises Exchange to Exchange Online.
 
After you move these mailboxes, you notice that the original mailbox permissions are not retained.

You might also notice that when you run the Add-MailboxPermission cmdlet in Exchange Online, you receive an error stating:
The ACL for the object “CN=user,CN=Users,DC=letsexchange,DC=com" is not in canonical order (Deny/Allow/Inherited) and will be ignored.

This is because Exchange 2003 uses a mailbox security descriptor system that is no longer used by Exchange Online. Because of this, when an Exchange 2003 mailbox is moved to Exchange Online, the original mailbox security descriptors are ignored and permissions are not kept.

To resolve this issue, run the FixMailboxSD command-line tool to correct the security descriptions on the on-premises Exchange 2003-based servers.

This is a small utility to fix mailbox security descriptors in Microsoft Exchange that have become non-canonical. It must be run on a machine with Exchange System Manager, as it relies on the interfaces exposed by CDOEXM, but it will work against mailboxes on 2003 or 2007 (not 2010 or 2013).

The tool uses CDOEXM from C# to read the MailboxRights object from the IExchangeMailbox interface. It then iterates through the DACL and puts all the ACEs in canonical order, and saves the changes.

The syntax of the tool is very straightforward:
FixMailboxSD “DN of mailbox”

For example:
FixMailboxSD “CN=nuno,CN=Users,DC=letsexchange,DC=com”

The tool will display a summary view of the current DiscretionaryAcl, and then show a summary view of the DACL after it has reordered it. It will then save the changes and return to a command prompt.
 

Wednesday, October 22, 2014

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.

Friday, October 3, 2014

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?
 
 
It also details how DirSync determines what is not synced (excluded) from the on-premises environment to Windows Azure AD.