Forum Discussion

C_the_S's avatar
C_the_S
Bronze Contributor
Apr 19, 2017

Changing UPNs / Domains

We are going to be changing our company name, so this requires a new domain. The new domain has been added to On-Prem AD and Office365.   On a test user we have changed the UPN to the new domain a...
office 365
C_the_S's avatar
C_the_S
Bronze Contributor
Apr 19, 2017

I've attempted to reply to this thread twice already but neither has shown up.

Want to thank you for the link as I modified their script and it worked.

 

And no VasilMichev, it did not require a password change for it to work. It just required running the proper PowerShell script which the Support document obviously doesn't have.

  • Justin Baker's avatar
    Justin Baker
    Copper Contributor
    Apr 27, 2017

    I ran into the same issue and this exchange helped me, but I'd like to add that to me the big difference between the MSOL cmdlets and the Azure AD (new) cmdlets is that the MSOL cmdlet will generate a password for your profile when running it and the AzureAD cmdlets do not. 

     

    In order to fix this issue you first have to change your UPN to match the default domain - for example @tenant.microsoft.com which is a MS domain and since that domain is not a federated one, the user account needs a password.

     

    When setting the UPN to match the default domain using the MSOL cmdlets, I didn't get an error about password profile being empty which was great. The cmdlet worked, however, it returned a random 8 character alphanumeric word each time I executed it when the default domain (@tenant.microsoft.com) was part of the UPN.  This leads me to believe the cmdlet is generating a password and setting it as part of its process for setting the UPN when no password exists in the profile and getting around the error that the Set-AzureADUser cmdlet throws when no password is set in the profile.

     

    When you run the cmdlet the 2nd time and set it to the federated domain name (its a 2 step process to fix this issue), the random alphanumeric 8 character word is not generated which makes sense as the domain the UPN is using is now a federated one and the user will authenticate against your on-premise ADFS instance not against an Azure owned domain (aka default domain).

     

     

     

    • C_the_S's avatar
      C_the_S
      Bronze Contributor
      Apr 27, 2017

      Thanks, but I ran the script on two test users to change their UPNs, and at no time did I or the scripts change their passwords. It finished successfully both times.

      Maybe that isn't how it is supposed to work, but that is how it worked for us.

      • Justin Baker's avatar
        Justin Baker
        Copper Contributor
        Apr 28, 2017

        The command finished successfully for me as well, but whenever I changed the UPN to the default domain (Microsoft's domain) using the MSOL cmdlet it would return at 8 character alphanumber upon completion, but only when I chose Microsoft's domain as the one for the UPN and not my federated one.  

         

        Are you saying if you change your user from the federated domain to the Microsoft default domain that the cmdlet does not return that for you?

         

        Example:

         

        Set-MsolUserPrincipalName -UserPrincipalName justin@mydomain.net -NewUserPrincipalName justin@tenant.microsoft.com

         

        Then I'd see something like the below output to my shell

        Bota2317

         

        I'm using powershell verion 5.1 on Windows 10 to run the cmdlet.