I somehow end up with all types of odd scenarios through my daily work. One baffling scenario showed up a couple of weeks ago. One of our latest customers requested that all of their Office 365 accounts have the same logon name as their email address.
**Wait, What...?**
Yes. This customer migrated to Office 365 and Azure with another consulting company and was told all of their logon names had to be the same. So they created a unique UPN within Active Directory and set all accounts to use it when logging in to O365. No big deal in most cases but in this case they were mislead.
This customer has three branches of their company, each with their own email suffix. We started with the first branch. We will call this @Arrow-Sales.com. Josh@arrowcompany.com is going to change his UPN to josh@arrow-sales.com. We changed the UPN and did a delta sync with AAD Connect. Waited about 30 minutes for everything to populate through the system. We were able to logon to portal.office.com, portal.azure.com, but were unable to send or receive email.
What gives....?
We tried to logon to outlook.office365.com and received an error that the account does not exists. That's odd... So I reverted the change and started again. After all was done, I received the same error. Again, odd...!! I decided to move on to the next account. This time we were changing Rusty@arrowcompany.com to Rusty@arrow-operations.com. I followed the same steps, did a delta sync with AAD Connect, and waited 30 minutes. This time everything worked flawlessly.
Why does one UPN work and the other doesn't? Good question. I looked through the domains section of Office 365 and everything was fine. I checked, double checked and triple checked the account to make sure all attributes updated. To make a long story a little shorter I decided to check Azure one last time. There is a blade under Azure Active Directory named "custom domain names". This is where you can see all of your domains and if they are Federated or not. I found that arrowcompany.com and arrow-operations.com are not federated. However, arrow-sales.com is federated.
After a lot of digging we found that no one knew why it was federated but hypothesized that there was a previous tenant that no longer exists. We were able to remove the federation with the powershell command below:
Convert-MsolDomainToStandard -PasswordFile C:\temp\pwd.txt -SkipUserConversion $False -DomainName arrow-sales.com
When the script ran it threw an error stating that the domain does not exist or cannot be contacted. Good sign...
I checked my password file (C:\temp\pwd.txt) and noticed that there were no UPNs and Passwords. If you do have something in your file, don't fret, on your next AAD Connect cycle your passwords will sync. After the domain was converted we were able to change the accounts to use arrow-sales.com. We could also see that the check mark by arrow-sales.com was removed.