Collaborate without boundaries
Table of Contents
Options
Page Details
Connect with us
Office 365   Wikis   Directory integration services   Office 365 DirSync Content Map   Renaming a UPN to another federated domain

Renaming a UPN to another federated domain

  • Advanced

Renaming a UPN to another federated domain

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.

UPN Rename to another federated domain

  1. We cannot rename the UPN of a user when user account is moving from one federated domain to another (such as john@contoso1.com to john@contoso2.com)
  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 john@contoso1.com to john@contosofoo.com)
  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.
  4. The Office 365 Portal GUI cannot be used to rename a UPN from a federated domain to a managed domain because the object is DirSync’d and the GUI will not allow you to modify DirSync’d objects.  Microsoft Online Services Module for Windows Powershell can be used to rename a user’s UPN in Office 365.

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. John, who is working in Contoso’s Subsidiary, Contoso1, currently has his UPN set to John@contoso1.com.  Contoso1.com is a Federated domain.
  2. John is moving into his new role in Contoso’s Subsidiary, Contoso2; therefore his UPN should be changed to John@contoso2.com.  Contoso2.com is a Federated domain.
  3. We will rename John’s Office 365 UPN to a federated domain via Microsoft Online Services Module for Windows PowerShell  using the command:  set-MsolUserPrincipalName -UserPrincipalName john@contoso1.com -new UserPrincipalName john@contoso.onmicrosoft.com  
  4. John’s mailbox will be preserved, but a new password for John’s managed account needs to be established if they need to access the resources immediately, if not this can be skipped.
  5. The on-premises AD administrator will now need to modify John’s account with the new john@contoso2.com UPN.
  6. Force Directory Sync to propagate the change to Office 365 (or wait up to 3 hours). 
    1. Directory Sync will update the value into the cloud and successfully move John’s account back to federated account, from the contoso.onmicrosoft.com standard domain.  John’s mailbox is again preserved and John will be able to access his mailbox with new UPN and AD password.

 

1 out of 1 people found this post helpful.

, , , ,
Sort by: Published Date | Most Recent | Most Useful
Comments

  • 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?

    Thanks,

    Jason Thrasher

  • 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.

    Regards

    Ross Adams MSFT

  • Quick note: the parameter-new UserPrincipalName is incorrect, the parameter is -newUserPrincipalName (without a space)

  • Hi

    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 john@contoso1.com to john@contoso2.com)

    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 john@contoso1.com to john@contosofoo.com)

    -----------------------------------------

    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 testuser@domainname.onmicrosoft.com -NewUserPrincipalName testuser@domainname.com -ImmutableId <immutableIDvalue>

    Set-MsolUserPrincipalName : Unable to update parameter. Parameter name: SourceAnchor.

    At line:1 char:1

    + Set-MsolUserPrincipalName -UserPrincipalName testuser@domainname.onmicrosoft.com ...

    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

       + CategoryInfo          : OperationStopped: (:) [Set-MsolUserPrincipalName], MicrosoftOnlineException

       + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.PropertyNotSettableException,Microsoft.Online

      .Administration.Automation.SetUserPrincipalName

  • 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

Page 1 of 1 (6 items)