One of These Things is Not Like the Others: Challenge 11: Answer

With last week’s Challenge we decided to get a little sneaky. (Probably not a good idea, but we did it anyway.) As you might recall, last week we presented you with the following four Lync Server PowerShell commands and asked you which command was not like the others:



Get-CsUser -Identity “”

Get-CsUser -Identity “”

Get-CsUser -Identity “Ken Myer*”

Get-CsUser -Identity “litwareinckenmyer”



What’s so sneaky about that? Well, if you set out to find the command that didn’t work, you had a long, hard slog ahead of you: all of the commands do work. (With one somewhat-rare exception that we’ll discuss in a minute.) The first command uses the Get-CsUser cmdlet to return a user with a SIP address. Command 2 tries to do the same thing based on the user principal name (UPN). Command 3 retrieves information using the Active Directory display name, and command 4 uses the format domain_nameuser_name in order to return information.


So which of these commands is not like the others? This one:


Get-CsUser -Identity “Ken Myer*”


And what makes this command so special? It’s the wildcard character (the *) tacked on to the end of the name Ken Myer. This wildcard tells Get-CsUser to look for any (and all) user accounts that have a display name that begins with the string value Ken Myer. That’s important for two reasons:


·         Active Directory display names are not necessarily unique; it’s possible to have 2 or more users who have the display name Ken Myer. If you do have multiple Ken Myers, then this command is going to return information about each of those users.

·         The wildcard characters looks for users who have a display name that starts with the string value Ken Myer. That means that the command will return information about Ken Myer; it also means that the command will return information about Ken Myers, Ken Myerson,  Ken Myerdahl, Ken Myer Johnson, etc. Again, this single command could return multiple users.


And that’s the difference: this command could, in theory at least, return multiple user accounts:


Get-CsUser -Identity “Ken Myer*”


The other three commands will only return, at most, a single user account.


We should probably point out something else: if you include a wildcard in the Identity then Get-CsUser will only look at the display name attribute. For example, suppose you’re interested in finding all your users who have a SIP address in the domain. You might think that this command will find those users for you:


Get-CsUser -Identity “sip:*”


It won’t. Instead, Get-CsUser will look for all the users who have a display name that starts with sip: and then ends with (We expect that there won’t be very many of those.) To find the users who have a SIP address in the domain your best bet is to retrieve all the user accounts and then pipe that data to the Where-Object cmdlet:


Get-CsUser | Where-Object {$_.SIPAddress –like “sip:*”}


Or you could do this, provided you leave off the sip: prefix:


Get-CsUser -Filter {SIPAddress –like “*”}

Pretty much everyone who submitted an entry to last week’s Challenge came up with the same answer (and the same reasoning) that we did. One exception was the entrant who said he tried this command and it didn’t work:


Get-CsUser -Identity “”


We don’t know exactly how his Active Directory is set up, but it is possible to configure a user account so that it doesn’t have a UPN; if you’ve done that then the preceding command won’t work. That’s not a problem with the domain_nameuser_name format or with the SIP address: if you don’t have those attributes then you can’t be enabled for Lync Server anyway. And because you can also have a Lync-enabled user who doesn’t have a display name, well, that would make the UPN command unique. So we’ll give you credit for that one.


Incidentally, when we first posted last week’s Challenge we apparently had a typo in one of the commands; we didn’t put a space between Get-User and –Identity:


Get-CsUser-Identity “litwareinckenmyer”


Someone asked us if that was intentional. The answer to that is no, it was not intentional. After all, we make plenty of mistakes as it is. We rarely need to go out and purposely make a mistake.


Don’t forget, there’s a new Challenge this week. See you next week.


Challenge Home


Skip to main content