I don’t think it is any secret that almost any* administration that happens in Lync happens via PowerShell. The obvious use of this is by opening the Lync Server Management Shell and typing in some PowerShell commands. The slightly less obvious version of this is using the graphical Lync Server Control Panel. Something I’ve always wanted the Control Panel to do is to show me the PowerShell commands it was about to run in the same vein as in the Exchange Management Console.
Today I stumbled across a way to do this. It isn’t nearly as easy to see as in Exchange but with a little bit of work you can see the “hidden” cmdlets that the Control Panel is running. In order to see these commands, you will need to use the Lync Server 2013 Logging Tool (aka OCSLogger). If you have already downloaded the Lync 2013 Debugging Tools, you will find the Lync Server 2013 Logging Tool in this path: C:Program FilesMicrosoft Lync Server 2013Debugging ToolsOCSLogger.exe. Start the Tool and find the AdminUI option in the left hand column.
Check the AdminUI Component and be sure that every other component is unchecked. Depending on your environment, having any other components checked could lead to a very large log file and finding the area we are looking for would be pretty difficult. You can keep the rest of the settings at their default values. Here is what my level and Flags sections look like (which I think are the default values):
At this point, if you haven’t yet, open the Lync Control Panel and add something but don’t hit the “commit” option just yet. In this example, I am going to add a new Dial In Access Number. After adding the values (and before hitting commit), start the Lync Server 2013 Logging Tool.
At this point you can hit the Commit button in Lync Server Control Panel. After clicking it, flip back to the Logging Tool and click Stop Logging.
Now that you have captured the command that the Control Panel ran, we need to view it. To do this click the Analyze Log Files button.
This brings up a new window. It provides a few options but none of them are relevant. Simply click the Analyze Button and after a brief pause the Snooper log viewer will open.
Finally we can drill down and see the commands that were run. If you are experienced with Snooper your first inclination is to click the “Messages” tab. However, this capture is not in a format that Messages can handle so we need to stay in the default Trace tab. In the Trace window you should see a few lines of captured entries. There shouldn’t be too many here so feel free to click on each one.
Look for a row that has “TF_Component” in the Flag column. There should be two of them. The first one is the PowerShell command that was actually run. The second one is almost the exact same thing except that there is a result code added to the end. Hopefully it simply says “Result:Success”. In the screen shot above, you can see that the actual PowerShell command that was run is the following:
New-CSDialInConferencingAccessNumber -PrimaryUri “sip:+email@example.com” -DisplayNumber “123-4567” -DisplayName “Conference Number” -LineUri “tel:+1234567” -Pool “lyncpool.flinchbot.com” -PrimaryLanguage “en-US” -SecondaryLanguages “System.Collections.Generic.List`1[System.Object]” -Regions “System.Collections.Generic.List`1[System.Object]”
That is quite some command! Note that the commands used in the Control Panel won’t necessarily translate to a Lync Management Shell Session. In the command above, the “System.Collections.Generic.List`1[System.Object]” garbage is not something you could use in the Lync Management Shell as that is a reference to a field within the Lync Server Control Panel GUI. So you would still have to translate that to a value that Lync Management Shell could use. In my case, the first would be $Null (or I could simply omit it) and the second would be “United States”.
Now that you know which command was actually run, you could use it as a basis of a PowerShell script. Alternately, if you’ve been banging your head to figure out the right syntax for a PowerShell script and just can’t seem to get a command right, you could “snoop” the command this way to get the proper syntax.
* As best I know, Topology Builder doesn’t use PowerShell.