Before diving into the story, let’s cover some essential theory. The domain name is not just a formality; it’s a key element in forming User Principal Names (UPNs) and email addresses. If you’re not planning to use the default domain onmicrosoft.com, you must add your actual domain name in Entra ID (Azure AD). This step is crucial for proper user management and authentication.

However, a domain can only be part of one tenant at a time. If you need to move a DNS domain name between tenants, you must first delete the domain name from the source tenant. The most common reason for such a move is company reorganization, where some groups need to migrate data and resources to a new tenant, bringing their existing domain name with them.

I encountered a similar situation recently.

My Initial Setup

Here was our starting point:

• One Active Directory Forest where all users used domain.com as part of their UPN.
• Two Entra ID Connect servers were deployed, each syncing users to their respective tenants.
• Both tenants had the same list of users with slight differences.
  • The source tenant had domain.com registered, allowing users to authenticate with it.
  • The target tenant used a temporary domain, requiring users to authenticate with temp.com.

Migration Goals

The objectives were clear:

1. Migrate Intune Managed Devices
2. Migrate Enterprise Applications
3. Move licenses between tenants

Given that the customer had an Enterprise Agreement, we could move licenses between tenants. However, we needed licenses for both tenants simultaneously during the migration period. We purchased SCP licenses for the target tenant for one month, ensuring both tenants had identical license sets.

The Migration Plan

The plan for the migration day was as follows:

1. Disable Licenses and Remove Objects in the Source Tenant: This was necessary to delete the domain, as domains can only be removed if no objects are using them.
2. Add domain.com to the Target Tenant and Force Entra ID Connect Replication: Since domain.com was used on-premise, once it appeared in the target tenant, all UPNs would update, replacing temp.com with domain.com.

As a result, all users received the correct UPNs, licenses were adjusted, and Enterprise Applications could be used in the target tenant.

The Unexpected Challenge

Initial tests were successful: users could authenticate, licenses were applied, and Single Sign-On (SSO) for Enterprise Applications was available. Users then had to sign in to the Intune app with the correct UPN on managed devices, which proceeded smoothly.

However, disaster struck unexpectedly: Outlook for iOS stopped working.

Outlook for iOS – “mailbox cannot be added right now please try again later”

We spent two days troubleshooting, including wiping devices, comparing Intune settings, disabling conditional access policies, and more. Nothing seemed to work, except reverting the UPN to temp.com.

When we almost gave up, Outlook for iOS started to work without any changes. Two days have been since we changed UPN.

The Culprit: Caching Issues

We suspected caching issues, but after 24 hours, we doubted this theory. On the same day, we received a response from Microsoft Support, which confirmed our experience. They explained that Outlook and other Office 365 apps cache credentials and configuration details. When a UPN changes, these cached details can become outdated, causing issues like the configuration loop we experienced. It can take around 48 hours for the cache to refresh or expire and recognize the new UPN.

Lessons Learned

If you are planning to change your users’ UPN, anticipate a wait interval of at least 48 hours for the cache to update. This foresight could save you from a weekend of unexpected troubleshooting.

Good luck with your migrations!

Ilia Rud