Solution to office 365 assigning onmicrosoft.com addresses when used with AAD Connect.

Annoyingly, Office 365 when coupled with AAD Connect assigns the login name as the AD UPN, but it won’t assign that same UPN as the default email address – instead using user@domain.onmicrosoft.com .This is generally when the ProxyAddresses attribute in AD isn’t populated.

In certain situations it’s not desirable to populate this manually, or to mess with the existing settings.

AAD Connect to the rescue. With AAD Connect we can transform the ProxyAddresses attribute from an existing AD field – the UPN would seem the most sensible.

In Synchronization rules editor, switch the direction tabs to outbound rules.

There is a rule called “UserExchangeOnline”, hit edit and accept the option to disable and clone the rule (this saves it being overwritten at a later date)

Change the precedence to 50 and go to transformations.

Scroll down till you find the Target Attribute of ProxyAddresses.

Change the FlowType to Expressions and enter the following in the source:

“SMTP:”&[userPrincipalName]

And save the rule.

Now on the next sync, the Azure directory will have it’s ProxyAddresses attributes replaced with SMTP:user@domain.com (assuming your UPN is the desired email address)

14 thoughts on “Solution to office 365 assigning onmicrosoft.com addresses when used with AAD Connect.

  1. Hi,

    This seems to be a very nice solution, but I am unable to complete your tutorial. I can’t seem to find this “In Synchronization rules editor, switch the direction tabs to outbound rules.”

    What tool do I have to use? Where is this Synchronization Rules Editor and where are the mentioned direction tabs?

    I tried to find those in: “Synchronization Service Manager” and “Azure AD Connect”, but I can’t find it.
    Regards,

    Erik

    • Hi Erik it should be at –
      Start>all programs>Azure ADConnect>synchronization rules editor.
      Once you’ve got it started there a drop down at the top left for ‘direction’ – inbound or outbound.
      Cheers R.

  2. indeed I do, I’ve spent way too long fiddling with this:
    Basically you form a text string using the expressions listed here:
    https://docs.microsoft.com/en-us/azure/active-directory/active-directory-aadconnectsync-understanding-declarative-provisioning-expressions

    But I can save you some time:

    “SMTP:” & [givenName] & “.” & [sn] & “@domain.com”

    Then if you find later on you need to add in secondary proxy addresses you need to split that string into a multi-string format using the split command, something like:

    Split (“SMTP:” & [givenName] & “.” & [sn] & “@domain1.com*” & “smtp:” & [givenName] & “.” & [sn] & “@domain2.co.uk”,”*”)

    I’m not even going to say how long it took me to figure that one out!

    • Thanks a million! This works very nice (after a forced full sync, delta sync doesn’t work as nothing actually changed on the AD user object).
      Saves me a lot of time! Thanks again!

  3. Bear in mind you’ll probably want to translate both the UPN and the primary email to match, just keeps things easier for users to remember to login with a single id.

  4. Cool glad it worked for you. iirc correctly you can just do the export on the Azure connector to update after making changes to expressions.

  5. Hi Richard,

    Thanks for this information, however when I click save after entering “SMTP:”&[userPrincipalName] I get Invalid Character ” encountered in expression any ideas?

    James

  6. Hi James
    There’s something odd going on there – I replicated your problem when copying and pasting that expression from this article, which I assume you did too.

    Typing it in directly fixed it…. Please give that a try. I think it may have something to do with wordpress encoding the characters in some way. Remember the userPrincipalName is case sensitive.

  7. Hey,
    Setting this up this way is cool and works great but I noticed it would overwrite my existing proxy address settings thus I was not getting all my proxy addresses for certain users, just the one created from the UPN. Is there a way to achieve both of these things?

  8. I’m sure there is.. though it would probably take a couple of hours of fiddling, it’s not something I could reel off the top of my head I’m afraid –

    I think you’d need to put together an expression that loops for existing proxyaddresses, then uses the split statement to put both the existing proxyaddresses and the newly created ones into the Azure proxy addresses attributes.

    There’s a link in a previous comment for the syntax allowed, where they have some good examples. TBH that looks like a fair bit of fiddling to me, I’d probably try and standardise by creating them all in aadconnect (though I appreciate that the job requirements we’re given aren’t always what we want to do!)

  9. Richard, thank you for the useful guide! I tested this successfully by copying another AD user and NOT specifying the proxyAddresses attribute. After dirsync ran a delta, the email address in 365 matched their UPN (@companyname.org). The one thing I noticed was the alias for “.onmicrosoft.com” was missing from the 365 user. As I understand, that’s still needed for internal Exchange routing. Is this expected behavior, and would the solution be to add an additional expression so that the “.onmicrosoft.com” alias is present as well?

  10. Hi Ernst, unfortunately I am not seeing the same thing – we’ve applied this on a couple of places and all users still have the @company.onmicrosoft.com listed under their aliases (both in the 365 user bit & ECP).

    Sorry your reply had got stuck in the spam filter – are you still seeing the issue or did it sort itself out?

  11. Richard,

    This is a great write up. However its not working for me. I’ve double (Triple or Quadruple maybe) checked my configuration and I cannot get this to update my accounts. I’ve disabled the rule for now as, I didn’t want to cause problems with a busted rule somewhere, but I’m uncertain what I’m missing.

    Any ideas?

Leave a Reply

Your email address will not be published. Required fields are marked *