One of These Things is Not Like the Others: Challenge 13: Answer
If we were to show you all the weekly Lync Server PowerShell challenges and asked you, "Which of these challenges is not like the others?" there would be one obviously correct answer: Challenge No. 13. Why? Well, in each of the first 12 challenges, we had a definite answer in mind. That didn't mean that it ours was the only possible answer, but – at least to us – there was always one answer that stood out among all the other possible answers.
Well, like we said, at least to us that was the case.
However, last week's challenge, Challenge 13, was different. Did we have an answer in mind for Challenge 13? Yes, we did. On the other hand, we're the first to admit that our answer was perhaps a little obscure, and that there were a whole bunch of other possible answers that were equally good (and possibly quite a bit better). And that was the whole idea of issuing a challenge like that: we were really curious to see the different answers that people came up with as well as the reasoning that caused them to come up with those answers. To us, that sounded incredibly fun, and incredibly interesting.
Well, like we said, at least to us it sounded incredibly fun, and incredibly interesting.
So was Challenge 13 incredibly fun and incredibly interesting? We’ll let you be the judge of that. First, let's quickly review the challenge itself. Last week we presented you with the following four Lync Server PowerShell cmdlets and asked you to tell us which of these cmdlets was not like the others:
Stop-CsWindowsService |
Get-CsAdUser |
Set-CsUserAcp |
New-CsServerApplication |
And here are some of the answers that you came up with:
Get-CsAdUser. Remember how we said that there was no obvious answer to Challenge 13? Well, we might have been wrong about that: most people who submitted an answer to this challenge suggested that the oddball in the group was Get-CsAdUser. Why? Primarily because Get-CsAdUser only returns data; it doesn't actually do something that changes the system in any way. Stop-CsWindowsService lets you stop a Lync Server service; that's a change. Set-CsUserAcp lets you change the audio conferencing provider settings for a user; that's a change. New-CsServerApplication lets you create a new server application; that's – well, you get the idea. But Get-CsAdUser? It just returns data; it doesn't change a thing.
Note. So being the so-called Lync Server PowerShell "experts," is this the answer we were thinking of? No. But we wish we had thought of it. This was a pretty good answer.
Johann D. also pointed out that Get-CsAdUser doesn't have a WhatIf parameter. That's a good point: although there might be an exception or two, none of out Get-Cs cmdlets should have a WhatIf parameter. Why not? Well, the WhatIf parameter is designed to tell you what would happen if you ran a cmdlet: it tells you exactly what would happen (for example, it might tell you which objects would be deleted in you ran the command) without actually carrying out that command (e.g., without actually deleting those objects). If a Get-Cs cmdlet had a WhatIf parameter it would tell you, "If you ran this command you would get back the following objects." Which, of course, is the exact same information you would get if you ran the command without using the WhatIf parameter. That's a bit silly, so the Get-Cs cmdlets aren't supposed to have a WhatIf parameter.
New-CsServerApplication. Kudos to Aleksandar N. for coming up with this answer: as he noted, New-CsServerApplication is the only one of the four cmdlets that does not accept pipelined input. We kind of wish we'd thought of that answer, too.
Set-CsUserAcp. Several people chose Set-CsUserAcp, noting that this cmdlet is really designed for Lync Online and not for the on-premises version of Lync Server. And that's true: the CsUserAcp cmdlets are kind of useful for the on-premises version of Lync Server, but are really geared for use with Lync Online.
Yet another good answer that we never even considered.
Stop-CsWindowsService. Thomas L. wondered if we were trying to trick him with this question. The answer to that is no, we weren't. The truth is, we're far more likely to trick ourselves than to trick anyone else.
Be that as it may, Thomas L. chose Stop-CsWindowsService because it's the one cmdlet in the group that does not return an object. As he pointed out, Set-CsUserAcp typically doesn't return an object, either, but you can coerce it into doing so by tacking on the PassThru parameter. Is that the answer we came up with? Do you even have to ask?
The truth is, we had a much more mundane solution in mind: Get-CsAdUser, because it does not support the Name parameter. That one stuck out to us simply because, ideally, none of the Lync Server PowerShell cmdlets is supposed to have a Name parameter. If all things went as planned, you would be able to refer to an object by its Identity and not by its Name. As you can see, however, all things didn't go as planned, and for many reasons, including backward compatibility and a better mesh with the Lync Server Control Panel, several cmdlets ended up with a Name parameter after all.
Well, hey, it seemed like a good answer at the time.
At any rate, thanks once again for playing along: we really did find last week's challenge to be fun and interesting. Will this week's challenge be more of the same? Well, there's only one way to find out ….