Haiku #170
Uphill both ways? Not
With the Set Application
Server cmdlet.
Last night the author of today's haiku saw that not only was there a new Conan the Barbarian movie coming up, but this fall there will also be a remake of Charlie's Angels to be aired on ABC. All he can say about that is: hey, what took them so long?
But we digress. After all, you didn't come to the Lync Server PowerShell daily haiku to hear about remakes of clunky old movies and even-clunkier old TV shows. Instead, you came here for one reason and one reason only: to hear how the author's first bike ride in Park City, UT went.
Surprisingly, it went pretty darn well. We say "surprisingly" simply because all sorts of surprises occurred along the way. For one thing, the 5-mile ride into town turned out to be nearly a 10-mile ride into town. Surprise! For another, the bike trail that everyone told the author and his wife would take them directly into town ended after about a mile. Surprise! They ended up having to duck into a nearby visitors' information center, and got different directions that involved crossing the freeway, crossing back under the freeway, riding on every trail except the one they were originally told they would be riding on, and then flying a hot air balloon across the Atlantic Ocean. But, eventually, they made it to Park City, safe and sound.
On the bright side, the day did include one pleasant surprise. When they picked up their trail map (which has all sorts of trails marked on it; it just doesn't seem to have any real trails marked on it), the guy at the bike store said, "Yeah, you can ride all the way into Park City. It can be a difficult ride, though: a lot of people say it's uphill in both directions. You guys OK with that?"
Are we OK with that? Of course not; who wants to ride uphill in both directions? But you can't tell the guy at the bike store that you're a wimp. And so we just chuckled and said, "Yeah, we're OK with that," and immediately began praying for rain. Or maybe snow, just to be on the safe side.
But, as it turned out, it was only uphill in one direction. (Imagine that.) And while it was a bit of a climb to get up to Park City (although, really, it wasn't bad at all), coming home from Park City was a blast: it was downhill all the way.
Just like some of our careers.
While we were in Park City, our first stop – the same as any other tourist's first stop – was at the Park City Museum of Lync Server PowerShell Cmdlets. All the exhibits there were truly fascinating, but the one that really caught our attention was the Set-CsApplicationServer cmdlet. (Which, according to the museum, was discovered in an otherwise-abandoned silver mine just outside of Park City way back in 1847.)
As you history buffs know, the Application service hosts a number of Microsoft Lync Server 2010 programs that are not part of the core server components; that includes everything from the Response Group application to the Conferencing Attendant application to the Conferencing Announcement application. The job of the Application service (and the Application server) is to grabs these programs and fully integrate them into the Lync Server environment. You say you can't see any difference between, say, the Response Group application and any other Lync Server component? Well, you can thank the Application server for that.
But suppose you don't just want to thank the Application server; suppose you actually want to make a few modifications to the Application server. That's where Set-CsApplicationServer enters the picture. Set-CsApplicationServer is used primarily to modify the various ports used by the Application service. (With one exception: you can also use the cmdlet to change the path to the Application database.) You say you'd like things better if the Conferencing Announcement application used port 5074? Then it's Set-CsApplicationServer to the rescue:
Set-CsApplicationServer -Identity "ApplicationServer:atl-cs-001.litwareinc.com" -CasSipPort 5074
But wait: maybe you meant to use port 5074 for Response Group SIP traffic. What do you do in that case? You got it:
Set-CsApplicationServer -Identity "ApplicationServer:atl-cs-001.litwareinc.com" -RgsSipPort 5074
Now here's a fancy one. Audio, video, and application sharing can use a range of ports; for example, maybe you want audio traffic to use ports 60000 through 60199. (That's a grand total of 200 ports.) How do you configure something like that? Believe it or not, it's easy: you just have to specify the first port in the range (60000) and the total number of ports in the range (200). In other words:
Set-CsApplicationServer -Identity "ApplicationServer:atl-cs-001.litwareinc.com" -AudioPortStart 60000 -AudioPortCount 200
See how easy that is? The only catch is that all the ports must come one right after another. For example, you can assign ports 60000 through 60005. But can you assign port 60001 and port 60003 and port 60005? Nope; that won't work.
Considering the fact that the cmdlet dates back to 1849, it might come as no surprise that Set-CsApplicationServer does have at least one limitation: the cmdlet can't accept pipelined input. Does that even matter? Well, it might. For example, suppose you want to take all your Application servers and set the Conferencing Announcement port to 5074. Logically, you would expect this command to work:
Get-CsService -ApplicationServer | Set-CsApplicationServer -Identity $_.Identity -CasSipPort 5074
But sometimes logic can be overrated: logically, you wouldn't think there would be anyone dumb enough to write a daily haiku about Lync Server PowerShell. However, because you can't pipe data directly to Set-CsApplicationServer the preceding command is doomed to fail. If you want to modify all your Application servers with a single command, you have to pipe the data to the ForEach-Object cmdlet and then let ForEach-Object call Set-CsApplicationServer.
You say that doesn't make any sense? Maybe this will help:
Get-CsService -ApplicationServer | ForEach-Object {Set-CsApplicationServer -Identity $_.Identity -CasSipPort 5074}
And yes, as the preceding command implies, you do need to use Get-CsService and the ApplicationServer parameter in order to return information about your Application servers. Like many of Lync Server's server/service cmdlets, there is no Get-CsApplicationServer cmdlet. Instead, you need to rely on Get-CsService, the Swiss Army knife of Lync Server PowerShell cmdlets.
And there you have it: the fascinating story of the Set-CsApplicationServer cmdlet. Unfortunately, we won't have time to take questions from the audience: the author of today’s haiku has to decide whether he's going to go on another bike ride, going for a hike, or maybe going to try his hand at kayaking. Shouldn't he spend the day working instead? Hey, you're not the boss of me!
Oh, turns out you are the boss of me. Hi, boss. Just trying to decide whether to get an early start on tomorrow's haiku or work on something else for the rest of this gorgeous sunny day.
See you all tomorrow.