In my previous job as a hired consultant I generally wanted the Lync/Skype for Business servers to have certificates lasting beyond the two year default validity period. Why? Because I, along with the customer, would consider a Lync or Skype for Business solution to have a horizon stretching beyond two years – and therefore issuing a certificate that would expire only after two years would be meaningless.
In a recent project I have been working on voice VLAN implementation and 802.1x (or dot1x) authentication in our Cisco switching infrastructure. There was little to nothing on the subject to be found online, so I thought I would share my experiences.
When upgrading our Lync infrastructure from 2010 to 2013 I encountered some errors upon the first time I would publish the Lync Server 2013 Enterprise pool, consisting of three Front End servers and a fresh SQL server instance.
Diving into the resulting log file can quickly lead you to think that almost everything failed, as every parent category of the action point that actually went wrong will also be labeled “Completed with errors” or “Failed”. Therefore it is important that you (for your own mental well-being) filter out those things and drill down to the action point that is causing the problem, often with the “Execution result” column simply indicating “Error”.
Both SIP and ISDN trunk providers will often bill you based on the number of simultaneous calls/channels they provide (as well as minute charges). As a result you may end up scaling your capacity above what your real needs might be, just to be on the safe side.
With Lync there is no available tool to monitor this, neither real-time nor historically. There used to be a cool script available by Tom Pacyk to do this, but the times this need has arisen over the last year I have only been faced by an error message stating that the resource is not available.
The call performance counters reside on the Mediation server and are by no means a secret, but I haven’t seen anyone else (beside Tom) provide something to output them.
That aside; I decided to make my own PowerShell script to this.
It is still maturing, but for now it will give you
- Console output with the current total of inbound, outbound and concurrent calls (sampled every 15 seconds)
- CSV file output with hourly peak and average (per 15 seconds) statistics on the same counters
I will continue to develop it into a more complete solution, as I see fit. If you have suggestions or comments on the topic they are more than welcome! Although, I have to admit that my PowerShell skills are not unlimited, I promise to give it my best effort!
DISCLAIMER: As I just began working for a new employer where I have not yet got the chance to upgrade our Lync platform to server 2013, I can only vouch for it working on Lync Server 2010 – but I cannot see any reason why it should not run on the 2013 version (the counters would be identical, I think). In any case it will have to be run on the server hosting the Mediation role.
Download the latest version of the script from here.
April 15 2014 – v0.5 – first basic version, dumping hourly statistics to CSV file (max/avg in/out/concurrent calls)
April 16 2014 – v0.8 – added console output with current counters, added keyboard input to exit script
I recently installed Lync Server 2013 on a Windows Server 2012R2 for the first time.
Although everything worked just as before I noticed that Lync Server Management Shell would not start – it would just hang with a blank window without the prompt. No error or indication as to what might be the problem.
To get around it I simply launched the “regular” PowerShell and ran a
import-module lync cmdlet. After this “Lync PowerShell” can be used just like before.
First of all apologies for the rather long title, but I felt the need to state the full scenario in one sentence.
I have been struggling a little with this scenario for a while, and although it is briefly described as a supported and “no-brainer” setup in the TechNet documentation you come across it proved much harder than I first anticipated when recommending this design for a small sized customer. It also struck me, in regards to the previous reference to TechNet, how poorly documented this actually is – and inspired me to shed a little light to this dark corner of Lync Server installation.
As this post, as usual, turned out to be longer than I wanted it to be I decided to break it into two: This one being sort of the background or explanation, the next one will elaborate on the how-to’s.
Here’s another post in my “revisited” series. This time I am revisiting my previous post about how to use the Forefront UAG as a Reverse Proxy for Lync. At the time I wrote that post (Dec 2012) the Lync server UCWA and Lync 2013 mobile client had not yet been released, and the Modern UI/MX Lync App was not that much applied either. My later experience with these applications have been incompatible with the use of UAG like I described it, and when a colleague contacted me the other day on how to go about using the UAG I decided to do a little follow-up on this.