Freigeben über


Haiku #144

It's almost July

Fourth, and that means fireworks and

CS server apps!

 

Today is July 1st, which, at first glance, might not seem all that exciting to you. However, if you do the math, and you do the math correctly, you'll realize that Monday is July 4th, a national holiday in the US of A. And if you do even more math, you'll realize that this upcoming weekend is a three-day weekend. And that is exciting, to say the least.

 

Note. In all fairness, the author of today's haiku should point out that it's very possible that he did not do the math correctly. After all, it's nearly 9:00 this morning, and his building is totally empty: he has yet to see a single person, or to even hear a single person. Maybe this was supposed to be a four-day weekend, but he got his calculations wrong.

 

July 4th, of course, is Independence Day in the US: the day that the American colonies declared their independence from Great Britain. Of course, in typical American fashion, July 4th actually isn't the day that the American colonies declared their independence from Great Britain; that actually occurred on July 2, 1776. July 4, 1776 was simply the day that the Declaration of Independence was adopted. But then again, history – like math – has never been our strong suit here in the US.

 

At any rate, the Fourth of July has always been a pretty festive occasion here in the US, a day typically marked by picnics, barbecues, parades, and fireworks. And, of course, American ingenuity occasionally comes into play as well. For example, a few years ago, some local neighbors celebrated the Fourth of July by burning down the house belonging to the author of today's haiku. Now that was a memorable Fourth of July!

 

OK, so technically, they didn't actually burn down the house, although they did torch his garage pretty good. And, technically, the fire inspector didn't put the blame on the neighbors, saying that it was possible that the fire was the result of an electrical malfunction. "But it's the Fourth of July, and your neighbors shot off fireworks for 8 straights hours," he said. "I look around the neighborhood and I see firework debris everywhere. And then, that night, something smolders and your house catches on fire. You tell me what that sounds like."

 

"Sounds like an electrical malfunction to me."

 

Note. But after burning down someone's house, did the neighbors learn their lesson about the dangers of fireworks? You bet they did. Come the next Fourth of July, they only shot off fireworks for 7 straight hours.

 

Hey, you can never be too careful, right?

 

Another traditional way to celebrate the Fourth of July is to run one or more of the CsServerApplication cmdlets: Get-CsServerApplication, New-CsServerApplication, Remove-CsServerApplication, and Set-CsServerApplication. Server applications are individual applications that run as part of Microsoft Lync Server 2010. Give you an example of a server application? We'll do better than that; we'll give you a command that returns information about all your server applications:

 

Get-CsServerApplication

 

Or, if you'd rather just see the names of your server applications, run this command instead:

 

Get-CsServerApplication | Select-Object Name

 

On our test computers, that command returns the following server applications:

 

ClientVersionFilter

TranslationServer

IncomingFederation

UserServices

InterClusterRouting

IIMFilter

UserPinService

QoEAgent

DefaultRouting

ExumRouting

OutboundRouting

OutgoingFederation

AcpRouting

IIMFilter

OptionsHandler

 

In other words, all the fun and excitement of fireworks, but less likely to burn down your house.

 

Admittedly, most of the time you run a CsServerApplication cmdlet you'll probably be running Get-CsServerApplication. Why? Two reasons. First, you can't just configure any old application as a server application; someone (i.e., a developer) has to write an application specifically designed to run under Lync Server. You say that someone did write an application specifically designed to run under Lync Server? That's fine; in that case, you can use the New-CsServerApplication cmdlet to register that application with the system:

 

New-CsServerApplication -Identity "EdgeServer:atl-edge-001.litwareinc.com/EdgeMonitor" -Uri https://www.litwareinc.com/edgemonitor -Critical $False

 

Likewise, you could then use the Set-CsServerApplication cmdlet to modify that new application. For example, in the command shown above we set the value of the Critical property to False. The Critical property determines what Lync Server will do if the server application cannot be started. In our example, we decided that Lync Server should start even if our server application can't be started; therefore, we set the Critical property to False. But suppose we decided that this new application was so important that, if the application can't be started, then we don't want to run Lync Server at all. In that case, we could simply set the Critical property to True:

 

Set-CsServerApplication -Identity "EdgeServer:atl-edge-001.litwareinc.com/EdgeMonitor" -Critical $True

 

And if we decide that we never should have registered this application in the first place, well, we can rectify matters by using Remove-CsServerApplication to unregister the thing:

 

Remove-CsServerApplication -Identity "EdgeServer:atl-edge-001.litwareinc.com/EdgeMonitor"

 

 

Of course, you aren't limited to modifying custom applications; can also use these commands to modify the server applications that ship with Lync Server. Do we recommend that you just start willy-nilly modifying and deleting the built-in server applications? Not exactly, no. We have no idea what will happen if you start changing the built-in server applications, but we don't expect it would be good; in fact, we wouldn't be surprised if your house caught on fire.

 

Well, OK, we'd be a little surprised. But you probably shouldn't mess around with the built-in server applications unless some sort of official Microsoft support person specifically tells you to mess around with them.

 

But, as we noted earlier, what you can do is get information about those applications. For example, this command returns the names of all your critical server applications:

 

Get-CsServerApplication | Where-Object {$_.Critical -eq $True} | Select-Object Name

 

And this one returns information about all the registered server applications that are currently disabled:

 

Get-CsServerApplication | Where-Object {$_.Enabled -eq $False} | Select-Object Name

 

And, last but surely not least, this command returns the names and priorities of your server applications, sorted in priority order:

 

 Get-CsServerApplication | Sort-Object Priority | Format-Table Priority, Name -AutoSize

 

Note. What's the priority order all about? Well, the priority order specifies the order of execution for server applications. The application with priority 0 is started first; the application with priority 1 is started second; and so on. If you'd like to know more about priority orders, and how to work with them, well, do we have the perfect article for you or what?

 

That's all we have for today. Enjoy the Fourth of July, and try not to burn down anyone's house.

 

Or at least not the house belonging to the author of today's haiku, OK? After all, for him that's one of those "been there, done that" sort of things