Sign up for Office 365
Learn more about Office 365
We have had the same bizarre behavior happen with two different users over the last week. We have a valid dirsync config set up that has been running for a few months without problems. Recently, two users were unable to log into Lync on two different days. When troubleshooting the issue, i found that the user record in O365 had the user UPN set to firstname.lastname@example.org instead of email@example.com. When i checked the ADUC, the UPN was set correctly at firstname.lastname@example.org. The user accounts reside in a subdomain, but all users have their UPN set to email@example.com. For the second user, i received a Directory Sync error of 'Unable to update this object in Microsoft Online Services, because the attribute UserPrincipalName is not valid. Update the value in your local Active Directory'
To correct the issues, i had to set the UPN in ADUC to an alternate UPN, force dirsync, change the UPN back to the correct UPN, force another sync. And then check to make sure the UPN was correct in O365.
What would cause this behavior? If the UPN is set correctly in AD, how would the alternate UPN get set in O365.
Thank you for your post.
Based on my experience, the following error can occur if the UPN of user account has been changed by some 3rd party application with an invalid value.
"Unable to update this object in Microsoft Online Services, because the attribute UserPrincipalName is not valid. Update the value in your local Active Directory"
To resolve this problem, you can correct the attribute value manually.
Troubleshoot directory synchronization
By the way, if you want to trace the root cause of this problem, you may configure audit settings on the user account which encounter problem to check if any application/process try to modify these user attribute in your local AD.
1 out of 1 people found this post helpful.
I am not sure what third party app would have done that on two different users, and only to the O365 record. I thought that record was not editiable since the AD record is definative. Neither user has anything installed (that i am aware of) that would alter the UPN in AD. My concern is that the UPN in active directory was correct, and the UPN in the O365 record was not. And a forced sync from our on site sync server did not resolve the issue until i changed the UPN in AD (to something else) forced sync, then changed the UPN back (to what it was originally) and then forced sync again.
Am I understanding correctly that you were able to resolve the issue by changing the UPN, forcing a sync, and then changing it back and forcing a sync again?
Yes, that is exactly how i resolved the issue. Still dont know why the UPN was wrong on O365 in the first place.