|
|
|
|
|
New-CsStaticRoute
|
|
New-CsSimpleUrl
|
|
New-CsRgsCallAction
|
|
New-CsVoicePolicy
|
And here is our official answer: New-CsVoicePolicy. That cmdlet is not like the others.
Why not? Well, of the four cmdlets, New-CsVoicePolicy is the only one that can be used to create a real, live Lync Server: when you run New-CsVoicePolicy the immediate result is, well, a new voice policy. By contrast, the other three cmdlets create in-memory-only objects that must then be added to other objects. If you run New-CsStaticRoute, you'll end up with an object reference to a new static route. However, that route is meaningless until you add it to a static routing configuration. Likewise, the simple URLs created with New-CsSimpleUrl and the call actions created with New-CsRgsCallAction must be added to simple URL configurations and Response Group queues, respectively.
For example, this command calls the New-CsStaticRoute cmdlet:
$x = New-CsStaticRoute -TCPRoute -Destination "192.168.0.100" -Port 8025 -MatchUri "litwareinc.com"
So what does that give you? As far as Lync Server is concerned, that doesn't give you much of anything: all you have is a variable named $x that holds some routing information. To actually make use of that routing information, you need to add $x to a collection of static routing configuration settings, like so:
Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$x}
That's not how it works with New-CsVoicePolicy, however. To create a new voice policy all you have to do is, well, create a new voice policy:
New-CsVoicePolicy -Identity UserVoicePolicy1
It's that easy. Or, as Klaatu would say, " Klaatu barada nikto. "
And Now for the Good Part
OK, that's the way we solved the first challenge. Far more interesting (at least to us) is how you solved the first challenge. And while most of the people who submitted answers also thought New-CsVoicePolicy was the one thing that wasn't like the others, there were also a few alternate suggestions.
Note . And at least one alternate explanation: Thomas L. went for New-CsVoicePolicy, pointing out that it created an object that could be assigned to users, while the other cmdlets created objects that can't be assigned to users. Good point, Thomas, and one we didn't think of.
And yes, we usually do think of everything, don't we?
ewright19 opted for New-CsRgsCallAction, noting that this cmdlet runs as part of the Response Group application, which in turn runs under the Application Server service. By contrast, none of the other three cmdlets require the Application Server service. Nice call, ewright19; we have to give you credit for that one.
We also have to give credit to Patrik L. and Aleksandar N.: they also chose New-CsRgsCallAction, noting that this was the only one of the four cmdlets that can essentially be run by anyone. (The other three can only be run by users who are members of the RTCUniversalServerAdmins group.) That's another one we didn't even think about although, in all fairness, we should point out that Patrik and Aleksandar cheated a little: they both obviously read the Lync Server PowerShell help! Who the heck actually reads help these days? Extra points for reading the help, guys!
Note . Um, not really. We don't want to have to answer thousands of emails from people saying, "Hey, I read the help, too; how come I don't get extra points?"
Last, and surely not least, “thumper” picked New-CsSimpleUrl, and for two reasons: 1) unlike the other three cmdlets, it has nothing to do with Enterprise Voice; and, 2) simple URLs can affect external users as well as internal users, while the other three cmdlets only affect internal users. We'd tell you that we didn't think of that either but, let's face, we don't have time to list all the things we didn't think about.
Thanks to everyone for playing along, and remember, we have a brand-new challenge available right here .
