DirSync Error Resolution Part 3 – Invalid User Principal Name

The next type of DirSync errors generated by the organization in Part 1 were objects with invalid User Principal Names. Using some of the error messages sent in the Directory Synchronization error report email, I will examine why these errors occurred and how we fixed them.

Blank User Principal Name

ASPNET@contoso.onmicrosoft.com

Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [UserPrincipalName ASPNET@contoso.onmicrosoft.com;]. Correct or remove the duplicate values in your local directory. Please refer to http://support.microsoft.com/kb/2647098 for more information on identifying objects with duplicate attribute values.

 
 

Although the error states the UPN was a duplicate, I included it with the Invalid UPNs rather than the duplicate values in Part 2 because of the reason the UPNs were duplicated. The ASPNET accounts had blank UPNs, thus when they were replicated they were each given the default UPN suffix of @contoso.onmicrosoft.com. Blank User Principal Names or missing UPN suffixes can occur when the account was created by a program, through software installations, a script or other user provisioning system outside of Active Directory Users and Computers. ADUC will include the AD domain name as the UPN suffix by default, while other account creation methods may leave the UPN or suffix blank. Changing the UPN to match the Primary SMTP Address will fix these problems unless, like these accounts, they do not have a mailbox. The ASPNET account was present in the parent and all child domains, causing multiple dirsync errors but only one error message in the error report.

 

Resolution:

  1. Update the account UPNs in each domain with a federated domain as the UPN suffix.
  2. Dirsync will update the objects at the next synchronization cycle.

 

Change UPN to Different Federated Domain

 

BJones@ContosoOhio.com

Unable to update this object in Windows Azure Active Directory, because the attribute [FederatedUser.UserPrincipalName], is not valid. Update the value in your local directory services.

 
 

Bob moved from an office in Iowa to an office in Ohio. His primary SMTP address was changed from @ContosoMW.com to @ContosoOhio.com to reflect his new location and his UPN was changed to match. It is not possible to change from one federated domain to another just by updating the UPN on the on-premise account. The user object must be updated in the portal when the UPN suffix changes between federated domains.

 

Resolution:

  1. Launch the Azure AD PowerShell Module from an admin workstation.

  2. Run the Connect-msolservice cmdlet from the PowerShell window.
  3. Log in with an Office 365 account that has rights to manage users.
  4. Change the cloud UPN from the old federated domain to the default domain on Office 365.
    1. Set-MsolUserPrincipalName -UserPrincipalName BJones@ContosoMW.com -NewUserPrincipalName BJones@contoso.onmicrosoft.com

  5. This change requires 2 Dirsync cycles to replicate the changes in both directions.
  6. The Cloud Account will be updated with the correct on-prem UPN when the dirsync cycles complete.

 

Invalid Characters in User Principal Name

 

CHI-PTO/VacCalendar@contosomw.com

Unable to update this object in Windows Azure Active Directory, because the attribute [Username], is not valid. Update the value in your local directory services.

 
 

Tech Use@contososouth.com

Unable to update this object in Windows Azure Active Directory, because the attribute [Username], is not valid. Update the value in your local directory services.

 
 

Both of these accounts have invalid characters in their User Principal Names. These errors are discovered during the initial readiness assessment or roadmap when AD is examined for accounts that will cause directory synchronization errors. However, these accounts were created after the assessments were run at the beginning of the project so they showed up in the dirsync error report. Changing the UPN to match the primary SMTP address would have resolved these errors.

 

Resolution:

  1. Remove the / from UPN, Display Name, alias, and first name in the Vacation Calendar shared mailbox user account.
  2. Remove the space from the Tech Use UPN.
  3. Dirsync will update the objects at the next synchronization cycle.

The majority of Invalid UPN errors can be resolved by changing the UPN to match the email address. Accounts that lacked email addresses or moved between federated domains required manual intervention, but the resolution is still straightforward. In Part 4 I will examine the strange errors that do not fit in the other two dirsync error categories.

 

 

 

Edit – In an earlier version I used the word internvention instead of intervention. Neither the standard Office dictionary nor my editor consider internvention a real word, however I believe it should be.

 

In-tern-ven-tion. Noun. The act or fact of assigning the repetitive menial tasks required to solve a problem to an unpaid subordinate.

 

Manually editing UPNs to fix dirsync errors is a prime example of a task that requires an internvention. English is a living language. If enough people start using it, we can make internvention a real word.

One Response

  1. Thierry KOCIEMSKI December 8, 2014

Leave a Reply