Tag Archives: Microsoft

Special characters in Active Directory and Exchange Online

During migrations to Exchange Online I get the question regarding special characters in the User Principal Name (UPN) and e-mail address. Every time I have to check this again and again, so it’s time to do a write-up.

The UserPrincipalName (UPN)

The UserPrincipalName (UPN)

The UPN is the user’s identifier in Active Directory, and it is formatted like j.wesselius@exchangelabs.nl. It is a Microsoft recommendation to keep the user’s email address and UPN identical, but that’s not a hard requirement.

The UserPrincipalName attribute has the following characteristics and/or requirements:

  • The @ character is required.
  • The @ character cannot be the first or the last character of a UPN.
  • The total length cannot exceed the 113 characters limit. 64 characters in front of the @ character (i.e. username) and 48 characters after the @ character (i.e. domain name).
  • Allowed characters are A – Z, a – z, 0 – 9, ‘ . – _ ! # ^ ~
  • Invalid characters are \ % & * + / = ? { } | < > ( ) ; : , [ ] “
  • An Umlaut, tilde and accents are also invalid characters.
  • The UPN cannot end with a dot.
  • The UPN cannot contain spaces.
  • With directory synchronization in mind:
    • a routable domain must be used for the UPN (for a stand-alone AD this is not the case).
    • UPN must be unique and cannot contain any duplicated value in the directory (like UPN of user A is the same as e-mail address of user B).

The last bullet is something I see a lot in hybrid scenarios. In Exchange 2019 it is possible to have a user with a UPN like J.Doe@exchangelabs.nl, and another user with an identical email address J.Doe@exchangelabs.nl. Although it is confusing, it is possible on-premises.

In Exchange Online this is not possible, and when you have Entra ID in place, it will generate error messages, and strip the email address from the second user. Needless to say, you must fix this inconsistency (which can be problematic since you must remove an email address from a mailbox).

A little bit related is the samAccountName attribute of a user. This has the following limitations:

  • The maximum length is 20 characters.
  • It must be unique in the entire organization.
  • The following characters are invalid: [ ] \ | / , : < > + = ; ? * ‘ and the double quoute character “

Email Addresses

In Exchange and Exchange Online there are four e-mail address related attributes:

  • The mail attribute. The mail attribute of a recipient must be unique in the entire organization.
  • mailNickName (or alias). Must be unique in the entire organization and it cannot start with a period.
  • ProxyAddresses. This is a multi-valued attribute and has the following restrictions:
    • The maximum length of an entry is 256 characters.
    • It cannot contain a space character.
    • It must be unique in the entire organization.
    • It cannot contain any of the following characters: < > ( ) ; , [ ] and a double quote character “. The colon character : is allowed, but only after an identifier like SMTP: or X500:
    • Special characters with an umlaut, accent or tilde are invalid.
    • TargetAddress. This is used for forwarding email messages, in a hybrid environment this is the remote routing address. It is a singe value attribute, and has the same limitations as the proxyAddresses attribute.

Most likely there are more related attributes that need attention, but these are the most interesting I see when working with customers.

Exchange 2010 End of Life extended to October 2020

If you are still running Exchange 2010 you are most likely aware that the end-of-life of Exchange 2010 is in January 2020 when extended support will end.

Because of the size of customer still running on Exchange 2010 and the amount of work it takes, especially for large enterprise customers, to move to newer platforms, Microsoft has extended the extended support to October 2010.

After October 2020, Microsoft no longer support Exchange 2010. This means no bugfixes, no security fixes, no hotfixes, nothing. The product won’t stop working of course, but no fixes will be released by Microsoft, and especially no security fixes can be dangerous.

Note. The support for Office 2010 and SharePoint 2010 is also extended to October 2020, so these are aligned now.

If you are still running Exchange 2010, it is recommended to move to Office 365 or to Exchange 2013 or Exchange 2016. Please note that there’s no direct upgrade path to Exchange 2019, so you have to move to Exchange 2013 or Exchange 2016 (preferred) first before moving to Exchange 2019.

A lot of my customers are moving to Office 365, and I have written two blog posts on this. These are based on Exchange 2010 hybrid, without the hassle of installing Exchange 2016 first into the existing Exchange 2010 organization:

https://jaapwesselius.com/2017/05/15/moving-from-exchange-2010-to-office-365/

https://jaapwesselius.com/2017/05/16/moving-from-exchange-2010-to-office-365-part-ii/

I am not sure, but when support for Exchange 2010 stops in October 2020 support for Exchange 2010 hybrid stops as well and I wouldn’t be surprised that Exchange 2010 hybrid will stop working anytime soon after this date.

If you are still running on Exchange 2010, or working on an upgrade to Exchange 2016 or Office 365, you have some more time to finish these projects, but please don’t slow down at the moment and continue your projects.

You can find the official Microsoft announcement here: https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Microsoft-Extending-End-of-Support-for-Exchange-Server-2010-to/ba-p/753591