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
This blog post is all about how to go about setting up a collocated Lync Server Mediation server with separate NIC’s for Primary (or Lync if you will) and PSTN traffic. I wrote it due to the fact that I find this setup poorly documented, and hopefully others will escape the pitfalls that I encountered by reading it.
If you stumbled upon this post directly you might also find the previous one describing the problem in more detail interesting. If not, or if you are more into just fixing problems, then please keep reading.
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.
I wrote up a post on this topic a few months ago, named “Lync 2013 Mobile Client deployment – field notes“.
This has somewhat proven to be one of the more popular posts on my blog, both regarding stats and comments/questions. I have promised to update it to reflect some more recent experience and knowledge on the subject, but haven’t had the time until now (vacation time) to do so. But finally, here goes.
Lync Phone Deployment is pretty straight forward, and the mystery of DHCP options is pretty well documented on both Technet article and in Jeff Schertz’s excellent blog post on the matter. I have done a few of them, and they have all gone smoothly. Yet, a recent deployment really had me “rolling up my sleeves” to get it working. Here are some of my experiences, and what to look out for when setting it up.
I was working on a Project With a customer where they are running a Lync pilot for about 150 out of 10,000 employees. Considering the size of the customer, along With the fact that they are very Security-minded, the infrastructure is quite complex. For instance, all the Lync related servers are placed in a separate VLAN/subnet With strict firewall Access lists governing traffic. I am no stranger to the comprehensive requirements for ports in a Lync topology, and thought I had it all covered. Continue reading
On a recent job, I was aiding a customer setting up a new Lync Server 2013 Edge. It was a mixed topology, with a Lync Server 2010 Front End still acting as Central Management Server, but all users moved to the Lync Server 2013 pool and the new Edge destined to handle external media relay.
Upon the install completion and successfully starting services we noticed that the edge server did not replicate with the CMS. Continue reading