Sign up for Office 365
Learn more about Office 365
During an ongoing Office 365 deployment, we identified an issue with Office 365 customers not being able to change a user’s UPN if both UPN’s are in federated domains. We have identified and validated a work-around, please see the guidance below. Thanks to Marcus Hass and Dmitry Kazantsev for the write-up.
Therefore for us to provide customers with UPN rename functionality we will have to engineer some sort of the provisioning process that will provide two-step rename via a standard (non-federated domain). The steps below illustrate such process with a use-case scenario with the fictitious company Contoso. We will assume that Contoso has a default standard (non-federated) domain of contoso.onmicrosoft.com and contoso1.com and contoso2.com both of which are federated domains, and that Contoso is running Directory Sync:
1 out of 1 people found this post helpful.
So, I've run into a similar situation and now we're a bit stuck. For some background, we configured ADFS and ran Directory Sync with all users on the domain1.com UPN Suffix. It was later determined that all Office 365 users will login with domain2.com UPN Suffix. We converted domain1.com from federated back to a standard domain. We added the domain2.com UPN Suffix to AD. We converted domain2.com from a standard domain to federated. We then changed a few users' UPN Suffix to domain2.com (most users were not modified). Ran DirSync, and nothing happened. None of the users accounts have updated to the new UPN Suffix of domain2.com after multiple syncs. The DirSync reports show an unknown error updating these user objects.
So knowing that domain1.com WAS federated but is no longer, and domain2.com is the new federated domain. How do we get usernames to change from the domain1.com UPN Suffix to the domain2.com UPN Suffix?
Update the article there were a couple of extra spaces. Also customers should review this article (community.office365.com/.../support-for-multiple-top-level-domains.aspx) around support for multiple domains with a single AD FS 2.0 server.
Ross Adams MSFT
Quick note: the parameter-new UserPrincipalName is incorrect, the parameter is -newUserPrincipalName (without a space)
I want to know following about this article.
- “3. Directory Sync cannot be used to rename a UPN...” is correctness?
- Or my understanding about "3." is mistake?
- If my understanding is mistake, I want to know difference in “standard (non-federated) domain” and “federated domain” and “managed domain”.
1. We cannot rename the UPN of a user when user account is moving from one federated domain to another (such as email@example.com to firstname.lastname@example.org)
2. We can rename UPN of a user when user account is moving from one federated domain to a standard (non-federated) domain (such as email@example.com to firstname.lastname@example.org)
From results of the validation, I think this is correct content.
3. Directory Sync cannot be used to rename a UPN from a federated domain to a managed domain because of a defect. A fix is in the works but not yet available.
But, I think this is incorrect content.
Because I can rename a UPN from a federated domain to a managed domain by using DirSync or Set-MsolUserPrincipalName cmdlet.
And I think the content of “3” is inconsistent with the contents of “2”. Don't you think?
Thanks for posting this! I'm following this process for a customer but I get an error when I execute the set-msoluserprincipalname cmdlet to move the user into the federated domain.
Since the user is moving into a federated domain, help for set-msoluserprincipalname states that providing the immutableID value is required but I get an error when I include that parameter.
The o365 domain is configured for directory synchronization and that is running fine.
If I run this cmdlet *WITHOUT* the -immutableID parameter, the UPN change takes place but then the user then can't log in to O365 through ADFS because the ImmutableID values don't match. Doh! Any ideas?
PS v3.0 > Set-MsolUserPrincipalName -UserPrincipalName email@example.com -NewUserPrincipalName firstname.lastname@example.org -ImmutableId <immutableIDvalue>
Set-MsolUserPrincipalName : Unable to update parameter. Parameter name: SourceAnchor.
At line:1 char:1
+ Set-MsolUserPrincipalName -UserPrincipalName email@example.com ...
+ CategoryInfo : OperationStopped: (:) [Set-MsolUserPrincipalName], MicrosoftOnlineException
+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.PropertyNotSettableException,Microsoft.Online
I have the same issue but i have user UPN and verified domain are same., when user login it gives below error
Your organization could not sign you in to this service.
There may be a system error. Please contact administrator at your organization if this problem persists.
Now i reverted the user account setting back to previous state, but still same error