I see that CBT Nuggets have just announced the release of their video training course Microsoft Lync Server 2013 70-337.
This course covers all the key parts of the syllabus for the 79-337 exam along with some exam preparation tips and a case study to help you further prepare.
I've not yet looked at the videos in the course, but CBT Nuggets material is usually of a good standard. I'd be interested in any feedback.
Ever since Microsoft introduced Live Communications Server, customers have been asking how they can virtualize the product. During the OCS years, I constantly heard requests for support for Virtualisation. But the answer remained: no support. Eventually Microsoft did the work necessary to validate fully the product in a virtual environment. The result is that, today, you can fully virtualize both the Lync server and the Lync client product. But it’s not all that simple – virtualization just adds more opportunity for problems.
While many workloads are a great fit for virtualization, Lync is a real real-time application. As such, there can be performance related issues that are not even noticeable with other workloads. These issues manifest as poor audio and video resulting in a poor service to the user.
In a recently published White Paper, Lync Server 2013 Virtualization White Paper Microsoft provides full guidance for planning a Lync Server deployment in a virtual environment. The white paper descries how to configure Lync Server 2013 in a virtual environment, including both the host and the guest VMs. Also included are the most important Key Health Indicators (KHIs) that you should watch both when performing a capacity test prior to deploying, and later during deployment.
If you are planning a Lync deployment in a virtual environment or if you want to consider virtualizing part of your existing Lync infrastructure, you really should read this paper.
One of the major changes between Lync 2010 and Lync 2013 is the integration of Lync with Windows Fabric. Windows Fabric is described as ‘a Microsoft technology used for creating highly reliable, distributable an scalable applications’. Windows Fabric is designed to enable replication of application related data across multiple application servers. These application servers work in parallel to provide fault tolerance and scalability. Windows Fabric ensures the information needed for these applications is delivered reliably to each of the necessary servers.
Lync uses Windows Fabric to move information previously held in a back end database (and hence a bottleneck) to the front end servers. This eliminates the need for each Lync Front End server to use network resources to obtain application information – it’s available locally.
In the case of Lync, this change enables better scaling as well as providing resilience (a front end server can continue to work in the case of errors elsewhere in your network). While pretty much all of the complex stuff, with respect to Windows Fabric, is done auto-magically for you, it is important to understand what it’s doing, why and some of the issues arising.
One of key issues that arises from the integration of Windows Fabric and Lync is the recommendation of always having at least three ES servers in an ES pool. See http://technet.microsoft.com/en-us/library/gg412996.aspx for the details of this limitation.
For more information on the integration of Lync 2013 and Windows Fabric, see Richard Brynsteson’s post on the Mastering Lync blog.
Lync joins other Microsoft products in the billion dollar club! With the release of the Q4 earnings, Microsoft has disclosed that is now taking in over one billion US$ and revenue grew 30% This is fantastic news to those of us watching in the Lync space.
As part of the earnings call, Microsoft also divulged that Skype delivered 162 billion call minutes this quarter. My wife calls her dad every day and they chat for an hour – so I know where a few hundred of those minutes come from – but 162 billion is a lot of call time. I suspect many telcos would love to have that call volume (well that volume in PAID calls anyway!).
Tom Arbuthnot has a few more comments about this over on his blog. It makes interesting reading.
One of the big changes with Lync has been Microsoft’s approach of investing in a particular product for a particular function/feature and then have other products leverage that investment. This really makes sense on two levels. First, product groups are not each re-inventing the same wheel. Second, it really makes the ‘better together’ argument more real and less hype.
For example, with Lync 2013, all contact information is in a single Unified Contact Store which is maintained by Exchange 2013. The architecture for that looks like this:
Microsoft has just published an awesome set of posters that illustrate all the current sets of feature integration along with loads of links and more information. I find this a fantastic Lync resource (if only the Microsoft Learning courses were as well described!
You can download these posters (it’s a 9 page PDF) from http://go.microsoft.com/fwlink/p/?LinkId=311975
I have setup a Paper.Li weekly newsletter of news on UC and in particular Lync. You can see it: here. You can also subscribe (free) and get an abbreviated version in your mail box every Monday Morning. The mail can be clicked to get to the full content. The language is set to English, with coverage from around the globe.
In Lync, and indeed with almost any VOIP product, call quality can vary. This variation can be caused by a number of factors, including network delay, jitter, packet loss, and under powered PCs. Diagnosing the causes is difficult if you don’t have all the facts.
Microsoft has issues a pair of new tools< PreCall Diagnostics Tool, that run on Win 7 (desktop) and Win 8 (as a metro/modern app). You can get the Desktop application here, and the modern app here.
To understand more about the tool(s) and what the out means, take a look at an excellent blog article by Byron Spurlock.
Microsoft’s Lync server has a great feature called E911 – Emergency calling mainly for the UK and Canada. I teach Lync and find this topic to be of only minor interest in the UK and Europe mainly because we do not have E911 service over here (yet, anyway!).
Gary Williams has just published a great blog article entitled Is it OK to Place a Test Call to Emergency Services. His answer is Yes and he goes about telling how to do it. I have to say, I’ve always been quite nervous about testing out calls to 999 – and have only twice every had to call it for real.
But Gary’s article makes it clear that yes you can do this and also makes the good point that not testing it can be life threatening if it doesn’t work. He sets out how to do it in the article and it’s pretty simple. Gary also notes another potential gotcha – Lync will add a leading “+” to the number (e.g. if you dial 999, Lync ‘dials’ +999). Thus it’s vital that you have your routes are set up expecting this.
I just love how the market is creating little useful add-ins to increases the functionality and value of Lync. The most recent one I’ve found is a product called SuperToast. It’s made by Modality Systems and you can read about it over on Modality’s web site.
SuperToast is a Lync application that notifies a Lync user of any missed instant messages and telephone or video calls. If an instant message is not acknowledged within a certain timeframe, or a call goes unanswered, SuperToast pops up a window in the centre of your screen, notifying you of any missed items. It stays there until you click it away and add any subsequent missed IM’s or calls to the list.
The value here should be obvious. For all too many IT Pros, and Information Workers, it is all too easy to miss an incoming instant message or call from a colleague, partner or even a customer. Combine that with the difficulty of being able to see when or what IM’s and calls you have missed. SuperToast avoids important queries going unnoticed.
The Lync team at Microsoft publish a comprehensive guide to network planning, monitoring and troubleshooting of Lync.
This guide consists of a large (146 page document) , 2 spreadsheets, 2 PowerShell scripts and a collection of SQL T-SQL scripts – not to mention a README file:
If you are implementing Lync, this material can be invaluable. especially if you are planning using Enterprise voice. If you used earlier version of the guide, then you would be well advised to download the latest version for the updated spread sheets and the T-SQL scripts. If you have not yet used the guide, or are early on in the planning stages of your deployment, make sure you read and work through document as you deploy.
I was somewhat (pleasantly) surprised to see on my Windows Phone that there was an updated Lync 2013 client. The client does not change much, but there are two nice new features added. One nice new feature is the ability to view a PowerPoint presentation during a Lync meeting. The update also enables you to use your voice to control Lync 2012 client.
For me, the ability to see a PowerPoint presentation on my phone is of pretty minimal value. That’s mainly for two reasons: first my phone (I have a Nokia 820) is just too small to do much more than listen to the audio. I’d rather be somewhere that I can watch the presentation on a decent screen (i.e. my laptop or desktop). But having said that, it would make great sense on a larger form factor device (phablet’s here we come). So while I won’t be using this feature much, I am sure glad I can!
Microsoft publishes lots of information about sizing and even has a neat free capacity calculator you can download (Did I mention it was free!). But knowing where to start and what to look out for is harder especially for those who don’t do a lot of sizing work.
In browsing around, I found an interesting post that looks at a proposed sizing for 1500 users, consisting if three Front End servers, plus more. The author was asking for advice and the rest of the post is just that advice.
If you are planning on deploying Lync, this might make good reading and is certainly good food for thought.
In the original voice design for OCS, all traffic bound for the PSTN had to transit a mediation server. The mediation server provided three key features: it removed the encryption of SIP packets that go to the gateway (and added it for signaling traffic received form the Media gateway), it similarly managed the encryption of the RTP packets sent to and from the PSTN and finally transcoded the media traffic between Microsoft’s Real Time Audio codec and G.711 (used on the PSTN).
In the early days of OCS, this made sense as the then-available gateways could not really handle the encryption and de-encryption and the early clients did not natively send/receive using G711. The downside to this design was the need for extra servers (and associated OS/Software licenses) and the processing delay encountered particularly when transcoding RTP traffic (i.e. the actual audio). And since transcoding was never going to be perfect, there was also a bit of a reduction in call quality.
Lync introduced an excellent new feature, Media bypass, which enables the client to send all media traffic directly to the media gateway thus removing most of the traffic through the mediation server. This was possible only with new gateways that supported Media Bypass. With Media Bypass, the call setup (signaled by SIP traffic sent from the client) was done as in OCS, but all the media traffic could a) be initially encoded using G.711 and b) sent directly to the Media gateway. This approach delivers several benefits: first, it reduces significantly the traffic traversing the Mediation Server allowing that role to co-exist on a front end server. Since the RTP traffic never transits the mediation server, RTT times and other factors are improved. And finally, since the client natively encodes audio into G.711, fidelity is at least as good and probably better than with OCS. Assuming your gateways were up to the job, media bypass represents a big reduction in the number of servers needed to support PSTN interconnection.
While Media Bypass is designed mainly for use in PSTN-interconnection scenarios, it can also be used if you are routing calls to an internal IP-PBX (assuming of course that that IP-PBX supports media bypass) and can be used with connecting to some SIP Providers.
In a great article on Windows IT Pro’s site, Lync super-star Byron Spurlock explains how media bypass works and shows how relatively simple it is to turn on. Byron makes the point that while Media Bypass is not quite out of the box, it’s fairly simple to configure assuming your infrastructure is capable of handling it.
One nice feature of Lync (and OCS before that) is the Server’s ability to provide clients with details of errors that occurred whilst the server was attempting to process a SIP command sent from the client. This is done by extending SIP to enable both client and server to report errors to each other. A new SIP header, Diagnostics, is used to report errors The idea is that if the server has an error, the client can get more information and possibly provide better information both to the end user and to any help desk support engineer.
This extension, snappily known as MS-OCER, an hot it is used is defined in the Client Error Reporting Protocol document you can download from Microsoft at: http://download.microsoft.com/download/1/6/F/16F4E321-AA6B-4FA3-8AD3-E94C895A3C97/%5bMS-OCER%5d.pdf
The PDF file, which runs to just under 200 pages, describes The details of the protocol plus full details of every Error ID including the reason for the error, are included in this document. This is a document that is likely to be of great value when you are troubleshooting!
Interestingly, although the document was last updated last November, there appear to be no Lync 2013 specific messages – only those for Lync 2010 and earlier. I assume that the Lync 2013 errors are the same as for Lync 2010, but there’s nothing I can see in the document to confirm that.
I just found an interesting white paper, produced by Mindlink Software. It’s entailed The value of Persistent Chat in Incident Management, Support and Business Continuity. The paper, which is short, starts form the premises that a) the workplace is changing and b) email is not a panacea in this new world. In areas such as incident management, business continuity and support – the ability to share knowledge quickly and communicate efficiently is vital. With geographically dispersed teams, increasing mobility and the constant challenge to do more with less. The paper concludes with some great use cases for PC and a more in-depth case study. Sadly, there is no economic justifications presented – these would have been very useful in helping readers to gauge likely ROI.
If you are planning on deploying Lync, or considering upgrading to the latest version, you should consider adding in Persistent Chat into the mix. With Lync 2013, you no longer need loads of extra servers to support PC – you can co-locate the PC servers on your front ends and utilise existing SQL Server for the databases needed by PC.
With Lync (as with OCS), your client is partly configured, in band, from the server and partly based on locally set registry keys. Things such as your contact list are obtained from the server once you are fully registered. Other things, such as whether to check spelling as you type, are set via registry settings. In a number of cases, these registry settings can be overridden by client policy settings. For example, you could set the registry to show emoticons, but disable it via client policy.
Richard Brynsteon has written two excellent blog posts that map every client setting to the registry entry that controls that setting. As well, Richard shows where the registry setting can be overridden by a suitable client policy.
Part one, which sets out information on the General and Personal tabs can be found: Here. Part 2 sets out information on the Contacts List and Status tab can be found: Here.
As much as we’d all like utterly reliable software – history suggests it’s not likely to happen at least in my lifetime. Read Fred Brookes book Mythical Man Month: http://en.wikipedia.org/wiki/The_Mythical_Man-Month – while it describes things Brookes saw during his time at IBM working on OS/360 (in the 1960s), the book continues to be highly relevant. Brookes observes that in any complex system there are a certain irreducible number of errors – as true today as in the era Brookes writes about. Worse, all attempts to fix the observed errors tends to result in the introduction of other, new, errors. So we live with the reality that all complex software will have bugs and that at some point we may be impacted.
For Windows IT Pros, one great source of information on bugs and solutions is Microsoft’s Top Support Solutions pages (see: http://blogs.technet.com/b/topsupportsolutions/) over on the TechNet site. For Lync administrators, the URL is: http://blogs.technet.com/b/topsupportsolutions/archive/tags/lync/ which sets out top solutions for Lync which was last updated late November 2013, so is relatively up to date.
If you are having problems with Lync, consult these references to see if your problem is one of the well known variety with an equally well known solution.
Some 5 years ago, Microsoft bought a third party company (Parlano) and acquired their highly regarded group chat product, which was a feature missing from OCS. Group Chat was eventually “added” into OCS and Lync 2010 although as more of a bolt on than a full citizen in the Lync product. Group chat in those days was essentially a separate stand-alone application that required separate servers for both the GC feature and for its databases. The actual installation was also challenging and highly error prone.
With Lync 2013, Microsoft did a lot of simplification work integrating it into the overall Lync topology. Microsoft also changed the name of this feature to Persistent Chat. With PC in Lync 2013, you can co-locate the GC service on the Front End servers, and you can co-locate the PC databases on SQL servers used for other UC databases.
Like all of the Lync 2012 components, PC is supported by the underlying Lync Architecture, including the high availability features. Like all Lync features, availability requirements tend to be pretty high, as companies begin to depend on things like PC.
In a complex blog post over on TechNet, Richard Schwendiman (an MS Exchange/Lync PFE) presents a deep dive into PC’s High Availability and Disaster Recovery features. Richard starts off by looking at how you can engineer HA in a single data centre. This architecture enables a single PC server to fail and for the client to be re-connected to another PC server. The blog post then goes on to look at disaster recovery – or engineering against the failure of an entire Lync Site, in particular using stretched sites for PC.
This blog post is worth reading if you are going to be implementing Persistent Chat either as part of an initial Lync deployment or as a later phase. TechNet has a good article that provides more information on how Persistent Chat works. You can find more details on HA and DR in Lync Server 2013 here (a blog article by Thomas Binder). And for more information on capacity planning for PC, see the TechNet article at Http://technet.microsoft.com/en-us/library/gg615006.aspx.
In mid-December, Microsoft issued a Lync Software Defined Network API and related documentation to enable you and your applications to interface with Lync. This API can enable 3rd party applications to monitor, isolate and correct issues in a network that impact on Lync’s overall quality of experience.
There are three files included (you can download some or all of them!) :
The idea behind the API set is fairly straightforward. Lync deployments can end up with user experience impacted by overall network performance. This can in turn lead to both calls being dropped (or not even connected), as well as jittery audio. This API is designed to enable network management applications to all the relevant Lync network diagnostic data, including Lync Quality Of Experience information.
So while this API can’t be used directly to improve performance, what it does do is to provide network management vendors and other third parties with the ability to develop rich diagnostic tools to assist you in deploying Lync.
I can’t wait to see vendors taking advantage of this API!
