Our onboarding process is taking too long because Windows sign-in is still handled by an on-premises domain, while Microsoft 365 belongs to a separate parent tenant. The parent organization also provisions devices through Intune, but users still have to sign in to each Microsoft application after their Windows profile is created.
The biggest challenge is Outlook. The sign-in prompt seems to change depending on the setup, and I'm not sure when users should enter their actual tenant username versus an email alias. I'd like to document a reliable process, automate whatever possible, and train others to handle onboarding consistently.
Has anyone found a tried-and-true way to avoid Outlook automatically using the on-premises Windows username, and to streamline the sequence of sign-ins when the local domain and Microsoft 365 identities are different?
3 Answers
If the parent organization controls Intune, ask whether they can enable automatic sign-in for Microsoft 365 applications during provisioning. With the right configuration, the basic workflow can be domain-joining the device, signing in the user once, forcing a sync, and letting Intune provision the applications.
There is also an Office policy commonly described as “Automatically configure profile based on Active Directory SMTP address.” If the on-premises AD mail or SMTP attributes contain the correct primary address, Outlook and the other Office applications can often provision themselves without repeatedly asking the user for credentials.
Automate as much of the process as possible. If the environment uses Entra Connect, check whether automatic sign-in or seamless single sign-on can be enabled. Group Policy can also configure some Outlook behavior, but it won’t fully solve mismatched identities by itself.
The Outlook behavior is usually an identity and UPN issue rather than an Outlook issue. Outlook generally wants the user principal name, so if the on-premises UPN differs from the Microsoft 365 sign-in name, it will keep suggesting the wrong account. A non-routable suffix such as .local commonly causes this.
A durable fix is to add the organization’s routable domain as an on-premises UPN suffix and set each user’s UPN to match their primary Microsoft 365 sign-in address before synchronization. The primary SMTP address should be used for authentication; aliases can remain as additional email addresses but generally should not be used to sign in.
Because Windows and Microsoft 365 are currently separate identities, users will still have two sign-in experiences unless the parent organization enables something such as password hash synchronization, seamless sign-on, or another supported single sign-on configuration. Confirm which tenant owns the mailbox before changing anything, since that affects the available options.
You don’t need to rename the entire local domain. You can add another UPN suffix and apply it to users, preferably with PowerShell if there are many accounts. However, coordinate with the tenant owner and verify synchronization rules before making the change.
So if the local domain is something like contusion.local and the tenant sign-in is [email protected], would adding @ad.com as an on-premises UPN suffix and changing the local UPN make Outlook sign-in behave normally? Would the tenant owner need to approve that change first?