Lync Mobility – Understanding SIP Sign-in Address vs. User Principle Name (UPN)

With the recent release of the Lync Mobile client for Windows Phone 7, Android, and iPhone, I’ve seen numerous companies thrilled about the opportunity to extend Lync further within the enterprise! For companies interested in deploying Lync Mobility, the Lync Server Cumulative Update 4 is required. For deployment steps, I highly recommend reading the Microsoft Lync Server 2010 Mobility Guide and Jeff Schertz’s blog.
After working with various customers to deploy the new Mobility service, occasionally I get asked “Why do I have to enter my username to sign into my Lync mobile client?”
I’ve read articles that mentioned if the SIP address username differs from the AD username, than the user would have to manually populate the User Name field to authenticate successfully. For example:

• SIP Sign-in Address: jdoe@contoso.com
• AD Username: john.doe

The mismatch between SIP sign-in address and AD username made sense to me, but for my customers their usernames matched. For example, the SIP address username matched their AD username:

• SIP Sign-in Address: jdoe@contoso.com
• AD Username: jdoe

Fast forwarding, Microsoft has published a mobility troubleshooting guide (KB2636318) which outlines various troubleshooting techniques. The article makes reference to the SIP sign-in address vs. UPN, but does not go into great detail. Below are two scenarios that highlight the difference between SIP sign-in address vs. User Principle Name (UPN) and the expected Lync mobile client behavior.
Scenario 1: Matching SIP Sign-in Address & User Principle Name (UPN)

• To validate the UPN of a user, first launch ADSI Edit
  • Connect to the Default Naming Context
  • Expand the domain structure and locate the user account object
  • Right-click the user account object and click Properties
  • Scroll down to the field named userPrincipalName
• In the screenshot below, the UPN (kcrockett@pbtest.com) is provisioned in the same format as my SIP domain (kcrockett@pbtest.com)

• Switch over to the Lync Mobile client and populate the Sign-In Address and Password field
  • In this scenario, the User Name field is left blank
• Once the information has been entered, click the Sign In button

• As indicated in the screenshot below, the Lync Mobile client automatically signs in. Hurray!!!

Scenario 2: Mismatch between the SIP Sign-in Address & User Principle Name (UPN)

• To validate the UPN of a user, first launch ADSI Edit
  • Connect to the Default Naming Context
  • Expand the domain structure and locate the user account object
  • Right-click the user account object and click Properties
  • Scroll down to the field named userPrincipalName
• In the screenshot below, the UPN (kcrockett@pbtest.local) is provisioned in a different format as my SIP domain (kcrockett@pbtest.com)

• Switch over to the Lync Mobile client and populate the Sign-In Address and Password field once again
  • To demonstrate, the User Name field is left blank
• Once the information has been entered, click the Sign In button

• Unfortunately, since I left the User Name field blank, I received the warning “Can’t sign in. Please check your account information and try again.“
• In the Lync Mobile client tracing log, the following error should also be reported:
  • 401 – Unauthorized: Access is denied due to invalid credentials. You do not have permission to view this directory or page using the credentials that you supplied.

• Switch back to the Lync Mobile client and repopulate the Sign-In Address and Password field, if necessary
• Populate the Username field using the format domainusername (e.g. pbtestkcrockett)
• Once the information has been entered, click the Sign In button

• As indicated in the screenshot below, the Lync Mobile client signs in. Success!

Comments welcomed!