Enabling a user for Microsoft Lync Server 2010 throws the error: “ConstraintViolationStringDoesNotMatchRegularExpression(Pattern that specifies a valid UserPrincipalName, someUserName)”

I’ve been meaning to blog this when I encountered it a few months ago but never got the chance so when I ran into this again today, I made sure I took some screenshots of it so I can write a post as soon as I got home (and before I have to go out and work again tonight).

Problem

You’re enabling a user for Microsoft Lync Server 2010 but notice that the control panel throws the following error message:

ConstraintViolationStringDoesNotMatchRegularExpression(Pattern that specifies a valid UserPrincipalName, someUserName)

Solution

I recall not being able to find anything via searching Google and since the most obvious hint from the error message was the reference to the UserPrincipalName attribute, I went ahead and opened up the problematic account’s object and another object that did not have this problem in Active Directory Users and Computers which showed the following:

The above screenshot shows the problematic account’s domain field as blank so I then went ahead and opened ADSIEdit to have a look at the user’s value for that attribute and this was what I saw:

userPrincipalName   JohnB

This immediately told me that Lync probably didn’t like the invalid UPN format because as most of us know, UPN is formatted to something similar as such:

username@someDomain.com

Opening up another user account’s object and comparing it side by side shows exactly what’s wrong:

To rectify this problem, all we need to do is open up the attribute and correct the format so in this case for JohnB, changing it to JohnB@domain.com allowed us to enable the account for Lync.

So what causes this?  The environment I encountered this issue in was a domain that was around since the NT days and this user account belongs to an employee who’s been around since those days.  My guess is that the upgrades and applications ran against accounts in this domain probably changed the UPN to this format at some point.