Over the past couple of years since MS has introduced Office 365 to replace BPOS; there has been open issues about the exact behavior especially in regards to the sync of AD objects. There was of course this same issue with BPOS but this article is regarding Office 365 so we’ll keep it on Office 365.

Since, Office 365 I have over a period of time defined this behavior  (user sync) each time it changed from start to present. When I say define - I have tested it and documented &  detailed the behavior  & then contacted Microsoft and questioned them about the expected behavior. It appeared during the Alpha-Beta that my conclusions were eventually incorporated into some type of description provided by MS.  Whoever is the real source is of course up for discussion.

 

The  behavior of user objects in particular has been interesting and  in constant flux. The specific part that we’ll discuss here is in regards to the assigning of the default onmicrosoft.com -  MOERA ( Microsoft Online Email Routable Address).

 I have on numerous occasions documented  the changes in behavior – passed the information on to my customers and contacted Microsoft. One of the matter I am still awaiting is in regards to the special characters list :  http://technet.microsoft.com/en-us/library/hh852533.aspx . whether it has been my input or from somewhere else it had been updated at least a couple of times over the course but not completely. And this is related to the ‘mailNicknameattribute as this should be treated the same as the ‘sAMAccountName in all regards. Of course, the manner in which you have DirSync (MIIS – FIM) configured plays a role but in most cases ‘mailNicknameis generally mapped or synched as your  alias and defines the MOERA  & in its absence other factors come into place such as the relation of the sAMAccountName’. I will include some older scenarios at the bottom to give an overview.

 

But, now it appears that if everything  is in place  valid UPN (userPrincipalName), ‘mailnickname’ , ‘mail’ , ‘sAMAccountName attributes are all present & unique but the object (user) is void any ‘proxyAddresses’  then no MOERA will be assigned . Now this could be by design  to resolve of the issues pointed out with my scenarios below but then this will cause issues with certain type of migrations – where that MOERA is needed for routing from the previous mail environment. And if by default the user has no standard need for ‘proxyAddresses’   then the MOERA may not be available. When dealing with a small number of users this may not be an issue because you could perhaps do some work-arounds like  license the user & then pull the MOERA . But this could lead to some lost e-mails & in some cases I have seen that licensing doesn’t always guarantee the  MOERA nor does the use of a ‘targetAddress’ .

 

The last update from MS  was that this wasn’t an error – so is this by design , now?

One of the last times I opened a case with MS regarding the behavior where some of the scenarios listed below come from – I was initially told I was wrong  as the behavior I was describing wasn’t what was expected. So, my next question was what is the expected behavior ? We’ll get back to you.. No official documentation regarding the issue.

Eventually, even though I was initially told that the behavior I was describing wasn’t what was to be expected – the end result was that the behavior I was describing was now the expected behavior. Since, there is no Official documentation from MS I thought that maybe I would post some of my findings.

Some scenarios over time:

So, when an object is synchronized with a valid UPN – if it has a valid & ‘mailnickname’ & the ‘mail’ attribute equals the UPN, it appears to work this way:

UPN: john.doe@test.Company_Mail.com & ‘mailnickname’: jdoe

Then the object synchronizes as: john.doe@test.Company_Mail.com with the alias: jdoe@Company_Mail.onmicrosoft.com

a. Which will cause issues if there are more than one jdoe

2. If the same user as above has the same except for a ‘mailnickname’:

Then the object synchronizes as: john.doe@test.Company_Mail.com with the alias: john.doe@Company_Mail.onmicrosoft.com

a. Which can cause issues if there are more than two john.doe ‘s

3. So, when an object is synchronized without a valid UPN but it has a valid & unique ‘mailnickname’ & ‘mail’ it appears to work this way:

UPN: john.doe@local.local & ‘mailnickname’: jdoe

Then the object synchronizes as: jdoe@Company_Mail.onmicrosoft.com

a. Which will cause issues if there are more than one jdoe

4. So, when an object is synchronized without a valid UPN & no ‘mailnickname’ but a valid ‘mail’ attribute it appears to work this way:

UPN: john.doe@local.local & ‘mailnickname’: jdoe

Then the object synchronizes as: john.doe@Company_Mail.onmicrosoft.com

a. Which will cause issues if there are more than one john.doe

5. So, when an object is synchronized without a valid UPN & no ‘PrimarySMTP’, ‘mailnickname’ nor a ‘mail’ attribute it appears to work this way:

UPN: john.doe@local.local & ‘samAccountName’: jdoe

Then the object synchronizes as: jdoe@Company_Mail.onmicrosoft.com (UPN)

 

6. So, when an object is synchronized with a  valid UPN, ‘mailnickname’ , ‘mail’ attribute (all the general standard requirements) but  no ‘PrimarySMTP’  or other ‘proxyAddresses’ it appears to work this way:

UPN: john.doe@test.Company_Mail.com & ‘samAccountName’: jdoex  mailnickname: jdoex

 

Then the object synchronizes as: jdoe@test.Company_Mail.com but will be void its MOERA address



Back to Top