Compartir a través de

Haiku #59

  • Artículo

It's out with the old

And in with the New-CS

Static route commands.

With yesterday's posting, the daily Lync Server PowerShell haiku broke new ground: we told you all about the New-CsNetworkBWAlternatePath cmdlet, then told you not to even use the New-CsNetworkBWAlternatePath cmdlet. That's opened up a whole new world of possibilities for the authors of the Lync Server PowerShell blog; for example, we've now begun working on a cookbook filled with recipes you should never make; designing clothes that should never be worn; and trying to develop a TV show that no one should ever watch.

Note. Oops; forget about that last one. Looks like Two and Half Men got there first.

Of course, the overwhelming success of yesterday's haiku has also left us with a problem: what can we do for an encore? Well, here's our answer to that question: if you thought an article that recommended you not use one cmdlet was good, imagine how good an article that recommends that you not use seven cmdlets would be. In other words, here are seven more cmdlets that you will most likely not need to use:

· New-CsSipProxyCustom

· New-CsSipProxyRealm

· New-CsSipProxyTCP

· New-CsSipProxyTLS

· New-CsSipProxyTransport

· New-CsSipProxyUseDefault

· New-CsSipProxyUseDefaultCert

We told you this would be good, didn't we?

If you're wondering what the deal is with these cmdlets, and wondering why you shouldn't use them, well, here's the inside scoop. Back before most of you were born (well, assuming that most of you are less than a year and a half old) these cmdlets were used to create static routes for Lync Server. (Or, as it was known back in those days, Microsoft Communications Server "14". And yes, the quotations marks around the 14 were considered absolutely essential.) If you aren't sure what a static route is, here's a kind of, sort of definition copied from the Lync Server PowerShell help:

When you send a SIP message to someone that message might need to traverse multiple subnets and networks before it is delivered; the path traveled by the message is often referred to as a route. In networking, there are two types of routes: dynamic and static. With dynamic routing, servers use algorithms to determine the next location (the next hop) where the message should be forwarded. With static routing, message paths are predetermined by system administrators. When a message is received by a server, the server checks the message address and then forwards the message to the next hop server that has been preconfigured by an administrator. If configured correctly, static routes help ensure timely, and accurate, delivery of messages, and with minimal overhead placed on servers. The downside to static routes is that messages are not dynamically rerouted in the event of a network failure.

Now, back in the Communications Server 14 – uh, back in the Communications Server "14" days, you actually needed all of those cmdlets to create a static route. For example, if you wanted to create a route that used TLS, you might have to first use New-CsSipProxyUseDefaultCert to create a certificate object, which could then be used by the New-CsSipProxyTLS cmdlet to create a new TLS object, which could then be used by the New-CsSipProxyTransport cmdlet to create a new transport object, which could then be used by the – well, you can see where this is headed. The truth is, back in those days it was faster, and easier, to just type up all your messages and deliver them by hand than it was to create a static route.

But then a true miracle occurred: about the time Communications Server "14" went into beta, the New-CsStaticRoute cmdlet made its debut, and the old CsSipProxy cmdlets were no longer needed.

Good question: if that's the case, then why are these cmdlets still in the product? Well, due to some highly-obscure backward compatibility concerns, it was decided to keep these cmdlets around. However, you have a much better chance of being struck by lightning – twice – than you have of needing to ever use the old CsSipProxy cmdlets.

Note. In case you're wondering, you have (depending on whose estimate you read) a 1 in 750,000 chance of being struck by lightning in any given year. Over the course of your lifetime, you have a 1 in 9 million chance of being struck twice by lightning.

Well, depending, we suppose, on how powerful that first strike was. If you know what we mean.

So what's so great about the New-CsStaticRoute cmdlet? Well, for one thing, it's the only cmdlet you need: you don't have to use multiple cmdlets, and create multiple objects, in order to create a new static route. Remember all the rigmarole we had to go through to create a TLS route using the CsSipProxy cmdlets? Well, here's how you create the same TLS route using New-CsStaticRoute:

$x = New-CsStaticRoute -TLSRoute -Destination "atl-proxy-001.litwareinc.com" -Port 8025 -MatchUri "*.litwareinc.com" -UseDefaultCertificate $True

That's a little bit nicer, to say the least. Now we don't have to create separate objects for things like the route type (TLS) or the certificate being used. Instead, we can just use the parameters built right into New-CsStaticRoute.

Ah, another good question: why did we save the object created using New-CsStaticRoute to a variable named $x? Well, as it turns out, static routes are meaningless by themselves. Instead, any static route you create must immediately be added to a collection of static routing configuration settings. That means that any time you create a static route you then need to use New-CsStaticRoutingConfiguration or Set-CsStaticRoutingConfiguration to add that new route to a static routing configuration collection. In turn, that means you need two commands to create and implement a static route:

 $x = New-CsStaticRoute -TLSRoute -Destination "atl-proxy-001.litwareinc.com" -Port 8025 -MatchUri "*.litwareinc.com" -UseDefaultCertificate $True

  

 Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$x}

So, yes, two commands instead of just one. Which is still better than the 478,219 commands required in the pre-beta days.

We should also add that there is no Get-CsStaticRoute, Set-CsStaticRoute, or Remove-CsStaticRoute cmdlet. New-CsStaticRoute lets you create a static route. If you later want to view, modify, or delete that route, you'll need to use the appropriate CsStaticRoutingConfiguration cmdlet.

But that's another story for another day. In the meantime, we're going to see if we can come up with even more things that you should never do.

Note. Well, now that you mention it, "Paying attention to what the guys who write the Lync Server PowerShell blog say" probably should be on the list, shouldn't it? Thanks for the tip!

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    March 30, 2011
    how can you see the full details of the static routing config? It strips the end of the string, especially if multiple routes are in the config?