This weekend I finally got to upgrade our Lync 2013 servers to Skype for Business. The delay has been intentional as we have awaited at least the first cumulative update to be announced. We rely heavily on Lync/Skype for Business in our daily operations (1,362 A/V conferences over the last week and more than 103,113 participant conference minutes in our 250 pax company), both for telephony and collaboration, so any service disruption is poorly welcomed. As we are running an Enterprise pool with three Front Ends and the Lync 2013->Skype for Business requires an In-place upgrade this means quite some downtime as well as the added complexity of an Enterprise solution.
In the upgrade process I experienced several things that others might benefit from – so I thought I’d share some thoughts here. Continue reading
Keeping your servers up to date is essential, and not only the application server parts but the OS and others as well. The other day I went with a Windows Update that also included a Lync Server security update. After a short while I would get feedback from users no longer being able to use the mobile client, and later I also got reports on the Web App not working. Continue reading
Chromecast is an interesting product even for businesses, especially it’s screen casting function (although still listed as experimental) can be utilized to present your PC to an external monitor – reducing the need for the right cables or adapters in between.
In an enterprise environment, however, it can prove difficult to connect a device like the Chromecast to WiFi networks that require features like dot1x authentication. This was the case in my company and searching for answers led me to a deployment guide from Cisco, the vendor we use our wireless solution. Although relevant it did not completely solve my issue, so if you are struggling with the same problem just keep on reading.
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.
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.
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.