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.

Thursday, January 30, 2014

That very nice man Lee Holmes has done something really nice – in support of the current PowerShell games, he’s made access to his Cookbook web site unlimited for all. See http://www.powershellcookbook.com/ and have at it.

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:

The document looks at the aspects of planning, monitoring and troubleshooting Lync 2013 and describes these processes in some detail.

The spreadsheets enable you to look at various aspect of your Lync architecture and compare your environment with best practices – for example looking at the CPU utilisation on all your servers and ensuring that they are all less than 80%. These were updated in the latest drop of the guide

The PowerShell scripts enable you to obtain the key health indicators in your infrastructure that can then be used within the spreadsheets.

The SQL scripts are queries that help you leverage the data contained on your QOA/CDR databases.These were updated in the latest drop of the guide

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.

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!

Tuesday, January 28, 2014

I’m not alone in talking about SIP Trunking and SIP Trunking providers, as it turns out. SIP Trunks, as I discussed in this blog post, can provide a lot of benefits, not the least of which is cost reduction. The more you look at Sip Trunk Providers, though, the more you realise that not all providers are equal.

Microsoft has done a good job in qualifying Sip Trunk Providers and publishes a list of such providers at: http://technet.microsoft.com/en-us/lync/fp179863.aspx. This page lists the various qualified carriers and their service name. By ‘qualified’, each of the listed providers has been independently reviewed and their product is seen to support all the necessary Unified Communications Open Interoperability Program (UCOIP) requirements. You can read more about these requirements here.

In his blog, Jonathan Steeman looks at some of the differences between SIP providers in terms of the functions and features they provide. The more I read this post, the more it is clear that there really is a great deal of difference between the qualified trunk providers. If you are considering a SIP trunk, then you should take a close look at this blog entry and work out which of the mentioned features are important to you.

I’d love to hear of any experiences, good or bad, you are having with any of these named providers.

Monday, January 27, 2014

The other day, a student asked me how he could display a message box as part of a script. There is no, out of the box, cmdlet that does this, she pointed out. What she wanted to do was to display a window, with a window title and some contents, like this:

Now if you are a .NET programmer, this is pretty much a no brainer – just call the Windows.Forms.Messagebox’s Show method, and provide the text and the heading. Easy – but what if you are using PowerShell? As a Lync Admin – you might have a script that, say, provisioned users and you want to display a nice friendly message box to tell the user some bit of information such as how many users were provisioned. So how do you do that?

PowerShell, as you all know (or probably should know) is based on .NET – many cmdlets are just a PowerShell wrapper around an existing .NET Class/method. For example, Get-Process just invokes the System.Diagnostic.Process class’s GetProcesses() method. Now the cmdlet does a little more than just a GetProcess call, such as processing wild cards, enabling the cmdlet to run against a different machine, etc. But essentially, the base cmdlets just enable IT Pros simple access into .NET functions and Features. Application specific cmdlets, such as those supported by Lync, provide access into application specific functions, which are implemented as .NET Classes too. You can think of the application specific classes as just an extension to .NET.

The .NET Framework, and the Application specific ‘extensions’, are vast. There are a very large number of classes in total, and many of them have no relevance at all to the tasks that Lync admins carry out. To load all the relevant classes at runtime each time you open PowerShell would be very wasteful – both in terms of how long it would take to load them all, plus the runtime overhead (i.e. memory) wasted on classes never used. Thus, PowerShell only loads a core set of classes by default. But there is nothing stopping you from first loading the using any other .NET class.

This load the DLL from .NET’s global assembly cache and it remains loaded in the current PowerShell window and memory space till you close that instance of PowerShell. If you have other assemblies either part of the .NET Framework (e.g. System.Numerics) or a privately developed assembly, you can load them in a similar fashion.

Developers and PowerShell Gurus will probably point out that the LoadWithPartialName method has been deprecated. This is true but the recommended approach is more complex. Whatever, it remains the case that the LoadWithPartialName method works, and is likely to continue to work for some time! You can read a good explanation of this in Lee Home’s blog (http://www.leeholmes.com/blog/2006/01/17/how-do-i-easily-load-assemblies-when-loadwithpartialname-has-been-deprecated/) although you should note that that article was written in the Monad days, and is just slightly out of date (e.g. it uses .MSH as an extension). But for now, using this deprecated method does work and as I say, is likely to continue to work for a while!

So once you have the DLL loaded, you can just use the normal .NET calling feature to invoke a method in a .NET class directly. The core PowerShell line of code to do this is:

Ok, so it’s three lines long but it is quite simple. But rather than have to load an assembly and call that nasty looking method, you can wrap all of this inside a simple Advanced Function, and load that in your Profile or as part of a script or suite of scripts. I’ve written a simple script that implements a Show-Message function that displays a message box as you see above – see my PowerShell scripts blog for the script.
The bottom line is that you can easily display a message box from your script if and where you need. Just leverage my script as part of your profile, a personal module or directly inside a longer script and go for it.

Friday, January 24, 2014

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.

Thursday, January 23, 2014

I’ve been a LotMeIn user for some time. I find it very useful when I’m on the road and discover I’ve left an important file at home, or I want to use my home systems to demo something. The Free version of LogMeIn Suited me perfectly.

Then, thanks to reports over on Spiceworks, I discover today that this wonderful free version is being removed and users are being asked to start paying. Worse, existing fees have been dramatically increased all with no notice – some users say they only discovered the price hike when they got their CC bill. Others make the point that with no notice, getting budget approval in these tight times, is going to be next to impossible.

The message here to LogMeIn (and others considering the same thing) is simple: by all means raise your prices, but do so in a more transparent way and giving notice to loyal users (in our case formerly loyal soon to be ex-users). Other wise you are going to lose customers – and what’s worse lose good will.

Given this move, I’m moving off of LogMeIn – I hope to remove it all in the next day or two and replace it with a competitor. I suspect LogMeIn is going to see it’s competitors benefit from this move.

Wednesday, January 22, 2014

On Monday, I posted an article regarding an upcoming SIP Trunking webcast. In that article, I suggested that you can implement a Sip Trunk without a PSTN gateway. For the most part this is the case, but as one reader, Andy McAllister, pointed out, you probably are going to want a Session Boarder Controller to terminate the VPN between you and the SIP Provider. So the rosy picture painted in the earlier article is not altogether correct. Having said that, SIP Trunks typically offer lower cost telephony as well as increased flexibility in provisioning and de-provisioning.

Tuesday, January 21, 2014

Lync Server’s Enterprise Voice feature aims to enable you to replace your PBX. Enterprise voice helps you to get your users to use either a soft phone, the Lync client, or replace their existing desk phone with a Lync Phone.

Lync Phones are full IP phones – they contain some sort of computer and OS that either runs the Lync Phone Edition client or runs a compatible client. Both modes enable the phone to participate fully in your Lync environment.

One of the bigger players in the VOIP and Lync market is snom, and they’ve just produced a simple free eBook entitled: Using Microsoft Lync with Voice and snom Lync Qualified Phones. This is a 4 chapter book that covers an overview of Lync Phones, how to provision and customise Lync phones and how to integrate PC/Phone and Lync.

I just noticed that Ed Wilson, aka The Scripting Guy (at Microsoft), has another book out. Entitled Windows PowerShell Best Practices, it's a book that provides great examples on how to get the most out of PowerShell.

Monday, January 20, 2014

A SIP Trunk is a connection from your telephony solution to the PSTN via a SIP Provider. For Lync, this means the route to the PSTN is via the SIP provider, with all the signaling traffic being SIP and the audio being sent via RTP. This avoids having to have a local gateway to convert the signaling and audio into what the PSTN interface requires. SIP providers can be a cheaper PSTN Interconnection alternative to going direct to your local PSTN (e.g. British Telecom).

This means the PSTN connection is at level 3 in the ISO stack, not level 2 (which the normal PSTN connection uses). Someday, in the not overly far future I suggest that all PSTN connections will be via direct SIP, although it may take a few decades to get there.

Sip Trunks can provide many advantages. They can often be a cheaper PSTN Interconnection alternative to going direct to your local PSTN (e.g. British Telecom). They are also are a lot easier and faster to provision than traditional Level 2 connections. And, in many cases, you can create a short term trunk (e.g. for some event) more cost effectively than a traditional PSTN line.

With Lync 2013, SIP Trunks are very easy to integrate into your environment and can provide great cost savings – if nothing else, you don’t need separate PSTN gateways! If you are planning on deploying Lync Enterprise Voice, SIP trunks are something worth looking at.

Enterprise Connect Webinars are holding a 1-hour webcast on Jan 29th at 19:00 GMT – sadly late in the day for the UK, but mid afternoon EST and late morning on USA’s west coast. This web cast will describe the opportunities and challenges of SIP Trunking and will feature a detailed case study. You can signup for the webinar on line: Here.

Before you go rushing off to download – this is a big download. The pdf file itself is 110.9 MB. And definitely think hard before rushing off to print it out – it runs to 7970 pages. That’s around 8 reams of paper (or around 2 boxes). Not to mention the cost in toner!

Despite the size, this is a great document to have. I’ve loaded it onto my laptop and my Surface devices.

Lazar focused on four primary technologies that stood out on 2013: Cloud, Lync, UC Mobility and Video. The cloud continues to receive a huge amount of attention from a variety of vendors not least Microsoft. Lazar believes that the Cloud will only grow more important over the coming year.

As for Lync, Lazar notes that Microsoft is making inroads into the IP Telephony market, with 13% market share, which Avaya is tied at 13%, but Cisco continues to lead with 32% market share. Lazar predicts that Microsoft will continue to make waves and will aggressively target it’s competition, although at present Lazar claims Lync is significantly more expensive to operate than some of the competition – something no doubt that Microsoft will address in the next version of Lync.

Mobility is also a feature that was being adopted widely during 2013, a trend that Lazar predicts will grow significantly in 2014. Lazar expects that percentage of employees using tablets as their primary work device to climb to over 20% in 2014. Video too is likely to go ballistic as it becomes ever easier to record video which translates to a demand for Enterprise style YouTube capabilities.

An interesting paper, and certainly it ties in with the kinds of questions and issues I’m seeing in the forums and in my courses. And if you take the time to read his article, make sure you look at the comments – some interesting observations there!

Thursday, January 16, 2014

I just stumbled upon poshlinks.com, a PowerShell link list – a page full of links to more information about PowerShell and other stuff. At present there are over 1100 separate links to a variety of PowerShell related content. You can find links on fundamentals such as objects and modules, links related to using PowerShell with applications such as Lync, and a whole lot more.

So far, I’m not clear on how to add more to this list, but if/when I find out, I’ll blog it. I the meantime, this is a great resource and I’m going to be busy checking out all the links!

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.

Wednesday, January 15, 2014

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.

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.

Tuesday, January 14, 2014

If you are an organisation with any Internet facing resources, it’s important for you to ensure that all the supporting infrastructure is alive, well, and functioning as it should be. For large institutions, you probably already have all sorts of monitoring in place that can tell you of any problems in near-real time. You do, don’t you?
If you don’t (or you want to augment your existing services) there are number of sites on the Internet that will do that for you and provide you with the results. One site, Pingdom.com provides both a free and a pay service.
The pay service is aimed at monitoring the uptime and performance of you servers, including not only your corporate web server, but others too such as your Lync Edge server. The Pingdom service provides real-time monitoring service that can alert you is something interesting happens. You can get alerts ins SMS, Twitter and E-mail. The service also keeps records of the tests performed and the results which enable you to keep track of the performance of your key web sites. You can even get alerts on your mobile phone (Android and IOS it looks like – no Windows phone).
And there’s even a REST-based API for you to use! The API produces JSON encoded output. Invoking the API and interpreting the JDON responses were features added to PowerShell V3 – thus with the pay-service APIs, you could write PowerShell scripts to manage your Pingdom service!
If you are a Lync Admin, and are providing either remote access (i.e. to your users who are coming in via the Internet) or are providing federation to customers and clients, you have a significant challenge to setup your external infrastructure and ensuring it continues to function. The pay service can provide you with a useful set of eyes/ears on the internet, ensuring that all the infrastructure aspects of your Lync Internet features are working as they should – and will inform you when that stops.
Pingdom also offers three sets of free tests for you to use:

Ping/Traceroute – provides basic ping and traceroute to your site from Pingdom’s site. This provides a useful point of view in terms of your infrastructure’s availability/reachability across the Internet. The ping comes from one of the many probe servers used by Pingdom - there are over 60!

DNS Health – this page checks to see if external Internet DNS is setup correctly. DNS setup is critical to ensure your site is reachable but is also easy to misconfigure. This page tests your infrastructure, and provides details as to what it finds: good or bad. There’s also a troubleshooting guide to help you to understand the errors that the checker might find and how to resolve them. See here to see what precisely the DNS test is doing for you.

Full Page Test – this page tests the performance of a web page on your site and returns a wealth information. The waterfall view shows all the files that downloaded and how long each download takes. The Performance Grade view shows you how your page performs against a benchmark set of metrics. The Page Analysis view analyses the download, providing details of the server response code, how the page loaded, what sorts of documents are being downloaded, etc.

Here’s an example of using the Full Page Test against my Office 365 site, Reskit.Net:
This site is a fairly simple SharePoint site – and you can see each of the individual files downloaded to make up the page and what’s happening during the downloading of each file. You can use this waterfall graph to possibly optimise the page for faster downloads (and less bandwidth used).
And speaking of Free, Pingdom also provides a free check of a single site. This is the same check you could perform using their paid service, but free. The pay service allows you to check more than one site/page, and other services (see https://my.pingdom.com/account/subscription for details of the pay version).
All in all these free tools are pretty good – and I discovered a small DNS configuration issue I need to resolve! Nice catch Pingdom. And the pay tools look like being useful as well.

Monday, January 13, 2014

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.

Friday, January 10, 2014

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.

Thursday, January 09, 2014

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.

Wednesday, January 08, 2014

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.

Tuesday, January 07, 2014

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!) :

LyncSDNAPI.msi – this is a 1.6 MB MSI that installs the necessary APIs onto your machine.

LyncSdnApiData.zip – this is a 287 KB zip file that contains a compiled HTML help file documenting and describing the API elements

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.

Monday, January 06, 2014

The use of automation to deploy and manage complex TCP/IP networks is of prime importance to just about any IT Pro these days. It’s hard to think of how some businesses would function without a working network, including Internet and IP phone access. Even mid-size companies can find their networks are becoming more complex with each passing year as requirements grow for network services – and Lync can certainly provide the need for those services!

In terms of managing your TCP/IP network, PowerShell and the PowerShell modules released with the latest versions of Windows are slowly slowly replacing tools that have been in use since Windows NT launched over 20 years ago and before then on Unix (e.g. IPConfig, Ping) and well as somewhat more modern ones such as NetSH.

For the Lync Admin, these tools and the PowerShell cmdlets replacing those older tools both enable you to perform the same operations (e.g. check that the SRV record for your pool is correctly registered). You’re just using different tools (and with some judicious cmdlet aliasing, can be more efficient that the older tools!). This is the first of a number of articles I’m going to write this year focusing on managing networks using PowerShell V3 and Windows 8.

In writing scripts to configure any aspect of a Lync network (IP address, DNS settings, routing information, etc., etc.) you need to be able to enumerate and then select specific network objects (NIC, Route Table Entry, DNS Cache objects). To simplify the management of these objects, you need a simple and consistent object naming convention and the ability to name specific objects based on this naming convention. This involves writing some simple configuration scripts.

One challenge to doing this has been the default naming convention used before Windows 8. But with Windows 8 and beyond it’s much simpler. If you just one NIC, it is named either Ethernet or WiFi. If you have a second, or third NIC, it would just have an integer appended to the name, e.g. Ethernet 2, Ethernet 3 etc. A nice special case is the pseudo NIC added to the Hyper-V host representing a Hyper-V Switch. These are named vEthernet (<switch name>).

My Hyper-V host looks like this (and apologies for the rendering here in the blog):

This naming convention is provided for you when you install Windows and add NICs (virtual or otherwise) and gives you a great starting point. Most IT Pros will want to name individual NICs with a more task oriented name (e.g. VPN1, SIP-PROV-GC-<city>-<linkid>, etc). Your PowerShell script to name these NICs might look like this: