Why Are Display Names Allowed as User Identities?


Why Are Display Names Allowed as User Identities? After all, display names do not have to be unique in a forest.

 

Okay, so here’s the whole question: Display names do not have to be unique, which means I can have several users with the display name Ken Myer. If I try to enable one of those users by using the display name I get an error message and the user won’t be enabled for Lync Server. Why, then, are display names allowed as Identities?

 

You know, when we first started working with the Lync Server implementation of Windows PowerShell we were told that, with the user management cmdlets, there were four ways to specify a user’s Identity:

 

·         Using his or her Active Directory display name.

·         Using his or her SIP address.

·         Using his or her User Principal Name (UPN).

·         Using his or her email address.

 

“Can you also use the SamAccountName,” we asked, referring to the Active Directory attribute that is, more or less, a user’s logon name.

 

“No, you can’t,” was the reply. “That’s because SamAccountNames are not necessarily unique in the forest.”

 

And that’s true: SamAccountNames are not necessarily unique in the forest. And so we proceeded on our merry way, telling people that you can’t use SamAccountNames because those names aren’t unique in a forest. Or at least it was a merry way until TechReady 11, when someone asked us this question: “But display names aren’t necessarily unique in the forest. So why can you use display names when specifying a user’s Identity but not SamAccountNames?”

 

To which we replied: Eep.

 

Which is typically how we reply to questions we can’t answer.

 

But let’s see if we can answer that question anyway. (Although, truthfully, there is no answer other than “That’s just the way it works.”) To begin with, it’s definitely true that display names do not have to be unique in a forest; in fact, they don’t even have to be unique in a domain. Instead, display names only have to be unique in a container. For example, suppose you have three OUs in Active Directory:

 

·         OU_1

·         OU_2

·         OU_3

 

How many Ken Myers can you have in that domain? You got: you can have 3 Ken Myers, one in each OU. Each of these Ken Myers has to have a unique SamAccountName (unique in the domain, that is) , each has to have a unique UPN, and each has to have a unique email address, but they can all have the same display name. In fact, try running this command in a domain with multiple Ken Myers:

 

Get-CsAdUser –Identity “Ken Myer”

 

If you have three Ken Myers in your domain, all three are going to be returned when you run that command.

 

One for all, and all for one, if you know what we mean.

 

The fact that Get-CsAdUser and Get-CsUser return more than one Ken Myer probably doesn’t pose much of a problem. What definitely can be a problem is that neither Disable-CsUser nor Enable-CsUser can handle multiple Ken Myers. Suppose you have three Ken Myers and you try to run this command:

 

Enable-CsUser –Identity “Ken Myer” –RegistrarPool atl-cs-001.litwareinc.com –SipAddressType SamAccountName –SipDomain litwareinc.com

 

Are all the Ken Myers going to be enabled for Lync Server by using this single command? Nope; as it turns out, none of the Ken Myers are going to be enabled for Lync Server by using this single command. Instead, you’re going to get this error message:

 

Enable-CsUser : Multiple management objects were found for identity “Ken Myer”.

 

That’s the situation we’re talking about. Now let’s see if we can come up with an explanation.

 

To begin with, we should note that properties like display name and SIP address don’t represent the real Identity of a user account; instead, they just represent different ways to access a particular user account. As it turns out, the actual Identity for a user account is the user’s Active Directory distinguished name, something that looks like this:

 

cn=Ken Myer,ou=Finance,dc=litwareinc,dc=com

 

How do we know that this is the Identity for a user account? Because that’s what comes back when we run the following command, which requests the Identity for the Ken Myer user account:

 

Get-CsAdUser –Identity “Ken Myer” | Select-Object Identity

 

Admittedly, this is a little confusing. But think of display names as being like nicknames. Your real name might be Kenneth J. Myer, but most likely people won’t call you that; instead you might answer to everything from Ken to Kenny to The Big K. Technically speaking, your name is not “Ken”. But your nickname will suffice, at least until your company hires Ken Circeo, Ken Kwok, Ken Malcomson, and Ken Mallit. At that point, you need to be a little more specific; you can’t just ask for Ken and expect to get the right person.

 

We have the same issue with Lync Server. Technically, your Identity is your Active Directory distinguished name; for example, this command retrieves user account information for Ken Myer:

 

Get-CsAdUser –Identity “cn=Ken Myer,ou=Finance,dc=litwareinc,dc=com”

 

That’s great, but it’s also a lot to remember, and a lot to type in. Consequently, it’s easier to use a command like this one, as long as you only have one Ken Myer:

 

Get-CsAdUser –Identity “Ken Myer”

 

Which, of course, brings us back to the question “But what happens if you have more than one Ken Myer?”

 

There’s actually an easy way to work around this issue: if you have more than one user with the display name Ken Myer then don’t use the display name as the Identity; instead, use the UPN, the SIP address, the email address or – if all else fails – use the Active Directory distinguished name. Yes, that might be a little more cumbersome and a little more work, but it’s foolproof: UPNs, SIP addresses, email addresses, and distinguished names absolutely must be unique. Display names, as we’ve already discovered, don’t have to be.

 

In addition, you can also use the LdapFilter and Filter parameters to help pinpoint a particular user. You say you know that the Ken Myer you want is the only Ken Myer who works in the Accounting department? Then use a command like this:

 

Get-CsAdUser –LdapFilter “&(DisplayName=Ken Myer)(Department=Accounting)”

 

Note. If the preceding command looks like gobbledygook to you, take a peek at our article on writing filters for use with the user management cmdlets.

 

And remember, you can always use Get-CsAdUser (or Get-CsUser) to grab a specific user account and then pipe that account to either Enable-CsUser or Disable-CsUser:

 

Get-CsAdUser –LdapFilter “&(DisplayName=Ken Myer)(Department=Accounting)” | Enable-CsUser –RegistrarPool atl-cs-001.litwareinc.com –SipAddressType SamAccountName –SipDomain litwareinc.com

 

As long as we’re on the subject, here’s a handy little command that can tell you if you do have any duplicate display names in Active Directory:

 

Get-CsAdUser | Select-Object DisplayName | Group-Object –Property DisplayName | Where-Object {$_.Count –gt 1}

 

Note that we don’t recommend you try running this command if you have 500,000 users in your Active Directory; it’ll work, eventually, but it might take a while to complete. But if you have no more than a few thousand users in your domain it shouldn’t cause any problems.

 

Oh, right: what about our original question, the one that asked why you can use display names as identities but you can’t use SamAccountNames? Well, as we noted, that’s just the way things work. However, it turns out that you can use SamAccountNames as long as you include the user’s domain name as well. To see what we mean, try running this command:

 

Get-CsUser “litwareinckenmyer”

 

That command should work just fine.

This question is one of many asked during a session on managing Lync Server 2010 with Windows PowerShell at the TechReady 11 conference. For more questions and answers asked during that session, take a look at the Questions and Answers from TechReady 11.

Comments (1)
  1. Wilson says:

    You rocks, man! it confused me too and it now works as you instructed for to use domain + samaccountname. Great thanks!

Comments are closed.

Skip to main content