No one has responded to this discussion for at least a year, so this information may be out of date. If you're looking for information about this topic, please search for a more recent discussion or post a new question.

Odd dirsync behavior

  • 4 Replies |
  • This post has 0 verified answers |
Not Answered This question is not answered

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 instead of  When i checked the ADUC, the UPN was set correctly at  The user accounts reside in a subdomain, but all users have their UPN set to  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.

  • Post Points: 20
All Replies
  • Hello RreidAD,

    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.

    Thank you.

    Jack Sun

    • Top 50 Contributor
    • Post Points: 0
  • 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.  

    • Top 500 Contributor
    • Post Points: 0
  • Hello rreidAD,

    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?

    Thank you,
    Ken Berg
    O365 Support
    • Top 500 Contributor
    • Post Points: 0
  • Yes, that is exactly how i resolved the issue.  Still dont know why the UPN was wrong on O365 in the first place.

    • Top 500 Contributor
    • Post Points: 0
Page 1 of 1 (5 items)