Haiku #20

Can I use your phone?

Of course, but it's not my phone –

It's everyone's phone.

We have to admit that the developers responsible for putting together Microsoft Lync Server 2010 were pretty clever. Why do we say that? Well, for one reason, we get paid to say things like that. More importantly, however, those developers really were clever. For example, any sizable organization is bound to have common areas: kitchens, cafeterias building lobbies, conference rooms, etc., etc. (In other words, places where large and ever-changing groups of people are likely to congregate.) In addition, many of these common areas are likely to have phones; in this day and age, could you possibly have a conference room that didn't have a phone?

So what's wrong with that? Well, nothing … unless, of course, you'd like to exert some sort of administrative control over those common area phones. That's a problem in Lync Server, because phone management isn't typically carried out by managing hardware (that is, by managing the actual phone itself); instead, phone management is carried out by assigning policies and dial plans to users. For example, a user's dial plan specifies the normalization rules that take the number dialed and convert it to a phone number that Lync Server can work with: without the correct normalization rules, users aren't able to make a call. Likewise, the user's voice policy is used to enable or disable such things as call forwarding, call parking, and simultaneous ringing.

So what's wrong with that? Well, again, nothing … except for the fact that policies and dial plans can't be assigned to hardware; they can only be assigned to people. Phones aren't people, which means that phones can't be assigned policies and dial plans. That's not a problem for phones located in someone's office; those phones will simply be governed by the dial plan and policies assigned to the user who works in that office. But what do you do with a common area phone, a phone that doesn't belong to any one person, and which, over the course of a single day, might be used by scores of different people? In order to manage that phone, and provide all the users of that phone with a common experience, you need to be able to assign policies and dial plans to the phone. But you can't assign policies and dial plans to the phone, because it's, well, it's a phone.

Needless to say, it's a bit of a sticky wicket.

Note. In case you're just dying to know, the term "sticky wicket" comes from cricket, and refers to the erratic nature of the cricket field that can occur as the field begins to dry after a heavy rainfall. As the field (or "pitch") dries, a hard crust tends to form on top of the spongy ground underneath; in turn, that can cause balls to take unexpected bounces. Or, as we baseball players say, "nasty hops."

Good question: where would you learn about things like this if it wasn't for the Lync Server PowerShell blog?

So how did the Lync Server team unstick this wicket? With a surprisingly simple, but clever solution. After you've installed your common area phone, you use the New-CsCommonAreaPhone cmdlet to create a corresponding common area phone object. What's so clever about that? Well, what the New-CsCommonAreaPhone cmdlet does is create an Active Directory contact object that represents the phone you just installed. That's clever, because you can assign policies and dial plans to contacts. (And no, it doesn't matter that the contact doesn't represent a real person; Lync Server doesn't care about that.)

In other words, suppose you install a phone in one of your building lobbies. After you do that, you can then use a command similar to this to create a contact object representing that phone:

New-CsCommonAreaPhone -LineUri +14255556710 -RegistrarPool redmond-cs-001.litwareinc.com -DisplayName "Building 14 Lobby" -OU "ou=Telecommunications,dc=litwareinc,dc=com"

Big deal, you say? Believe it or not, it is a big deal. For example, suppose you don't want people to use call parking or to transfer calls from that lobby phone. That's fine. All you have to do is create a voice policy (which we'll call CommonAreaPhoneVoicePolicy) and then assign that policy to the common area phone. You know, like this:

Get-CsCommonAreaPhone -Filter {DisplayName -eq "Building 14 Lobby"} | Grant-CsVoicePolicy "CommonAreaPhoneVoicePolicy"

Just like that, you've managed your common area phone.

Thank you; you're too kind. But we really think that the development team deserves a bit more of the credit than we do.

Oh, and here's another cool thing you can do with common area phones. As it turns out, Lync Server's client policy (see New-CsClientPolicy for more information) includes two properties related to "hot desking," the process by which users can (or cannot) log on to a common area phone using their own credentials, and therefore have access to things like their own contacts.

Note. Don't worry: we know how anxious you are to hear an aside on the origin of the term "hot desking." Hot desking originally referred to users who shared a desk; for example, Ken Myer might use a desk during the day shift, and Pilar Ackerman might use that same desk during the night shift. The term itself likely derived from the Navy's practice of "hot racking," in which different sailors share the same bunk.

Uh, no, not at the same time. During different shifts.

At any rate, "hot desking" is now used in the telecommunications world to refer to users who share phones.

At any rate, the Lync Server client policies enable you to enable or disable hot desking on a common area phone (using the aptly-named EnableHotdesking parameter) and to specify how long a user can remain logged-on with their own credentials (the equally well-named HotdeskingTimeout parameter). When the timeout period expires, the user will automatically be logged off, regardless of whether or not they are currently using the phone. This helps prevent a single user from hogging the common area phone, and also offers some protection for users who log on to a common area phone and then forget to log off.

Which, come to think of it, is also pretty clever. Boy, those Lync Server guys thought of everything, didn't they?