Everywhere must be

Somewhere. Or maybe nowhere.

CS Location.

 

Last week, the author of today's Lync Server PowerShell haiku opened up an email that asked the following:

 

I’m trying to understand the purpose of the Set-CsLisLocation cmdlet.

 

I understand it creates locations, but what purpose does a location provide on its own? Can I use this in some way to define locations and then associate them with a subnet (for example), rather than use the Set-CsLisSubnet cmdlet? If so, how would I go about that?

 

Seeing that a customer needed help, the author of today's haiku did exactly what you would expect him to do: he immediately forwarded that email to his colleague (the one who isn't the author of today's haiku) and asked her if she could answer this question.

 

Note. Shouldn't the author of today's haiku have tried to answer that question himself? Well, maybe. Except it's been his experience that people who write to Microsoft asking a question would prefer to get back an answer to that question rather than yet another haiku.

 

Hey, there's no accounting for taste, right?

 

As you might expect, his colleague not only could answer the question, she did answer the question:

 

You can use Set-CsLisLocation for a couple of things.

 

One is to simply add in all your addresses. The information you get back from Get-CsLisLocation is what goes to the E911 service to verify that the addresses are valid.

 

The other thing you can do with it is make global changes to addresses. For example, the city I live in has just been rezoned. Right now I live in Bothell, as of June 1 I’ll live in Kirkland, without ever moving. If a business had a bunch of subnets, ports, etc. with addresses with the City property set to Bothell they’d all need to be changed to Kirkland. By retrieving all locations where the City is Bothell and changing the City to Kirkland, you automatically change all the associated subnets, switches, etc.

 

$a = Get-CsLisLocation | Where-Object {$_.City –eq "Bothell"}

$a | Set-CsLisLocation –City Kirkland

 

Note. Seeing as how she knows what she's talking about, shouldn't the person who didn't write today's haiku have gone ahead and actually written today's haiku? Well, at first glance, you might think so. But the person who didn't write today's haiku is sort of like Yoda in Star Wars: she's the wise and powerful Jedi master who doesn't do mundane things (like work) but just waits for someone to approach her with a question that no one else can answer. After all, if Yoda doesn't have to write daily haikus how can we expect her to write haikus?

 

At any rate let's take a moment to delve a little deeper into the CsLisLocation cmdlets (Get-CsLisLocation, Remove-CsLisLocation, and Set-CsLisLocation). As you probably know, all the CsLis cmdlets (LIS being an acronym for Location Information Service) are associated with Lync Server's Enhanced 9-1-1 service (E9-1-1). This service (which wasn't available in Office Communications Server 2007 or 2007 R2) enables emergency responders (that is, people who answer a 9-1-1 call made from an Enterprise Voice device) to determine the caller’s geographic location without having to ask the caller for that information. In Lync Server 2010, locations are pinpointed by mapping the caller’s port, subnet, switch, or wireless access point to a physical location.

 

Because of that, there are cmdlets that map physical locations to ports, subnet, switches, and wireless access points. So then why do we have the CsLisLocation cmdlets, cmdlets that don't map a network item (such as a switch) to a physical location? Well, as noted above, one thing the CsLisLocation cmdlets do is let you make changes in bulk. For example, suppose the city of Redmond adds a new ZIP code – 99999 – and all of your physical locations in the city of Redmond are to be assigned this new ZIP code. That means that you're going to have to update the ZIP code of every port, subnet, switch and wireless access point in the city of Redmond.

 

Now, if you wanted to, you could use the Set-CsListPort cmdlet to update all your ports, and the Set-CsLisSwitch cmdlet to update all your switches, and …. But there's an easier way. You can use a single command to update everything:

 

Get-CsLisLocation | Where-Object {$_.City –eq "Redmond"} | Set-CsLisLocation –PostalCode "99999"

 

See what we've done here? The Get-CsLisLocation cmdlet returns all the locations that have been configured for the E9-1-1 service: that means ports, switches, subnets, whatever kind of location you can configure for the service. What we're doing here is using Get-CsLisLocation to return a collection of all our locations (regardless of location type), then piping that collection to the Where-Object cmdlet. We ask Where-Object to pick out only those locations where the City property is equal to (-eq) Redmond, and then pipe that sub-collection of items to Set-CsLisLocation. In turn, Set-CsLisLocation changes the PostalCode property to 99999 for each of those locations.

 

Way faster, and way easier, that updating ports, then updating switches, then – well, you get the idea.

 

And that's the answer to the question about what the Set-CsLisLocation cmdlet is for: it's primarily for making bulk changes to locations regardless of the type of location we're dealing with.

 

The author of today's haiku only wishes he'd been the one to come up with that answer.

 

And speaking of the CsLisLocation cmdlets, we might note that the Get-CsLisLocation cmdlet has a very useful function all its own. As we've seen, you can use Get-CsLisLocation to return all your E9-1-1 locations. That's extremely useful when you need to do bulk updates, such as changing a ZIP code. However, it's somewhat less-useful when simply wanting to review your location information; that's due to the fact that Get-CsLisLocation only returns the address of each location without telling you what kind of location you're dealing with. (That is, if you call Get-CsLisLocation you'll know that something is located at 712 Main Street; you just won't know if that something is a port, a switch, or whatever.)

 

But the cool thing about Get-CsLisLocation is the Unreferenced parameter. It's possible to create locations that aren’t associated with an actual thing; in other words, you can create a location for 712 Main Street without associating that location with a switch or port or whatever. Is that a particularly useful thing to do? As far as we know, not really: there's not much use for a location that isn’t associated with something.

 

And that's what’s so cool about the Unreferenced parameter: it lets you return all these "orphaned" locations. Want to see a list of all your locations that aren't associated with a switch or port or other real, live object? No problem:

 

Get-CsLisLocation –Unreferenced

 

And what if you'd just as soon delete all those unreferenced locations? Again, no problem; you just need to pipe those locations to Remove-CsLisLocation:

 

Get-CsLisLocation –Unreferenced | Remove-CsLisLocation

 

And there you have it. We admit that, at first glance, the CsLisLocation cmdlets might seem somewhat superfluous. As it turns out, however, they can be – and are – incredibly useful to anyone trying to set up and manage the E9-1-1 service.

 

Hey, would Yoda steer you wrong? Of course not.

 

See you tomorrow.