I see loads of requests on the Microsoft TechNet forums from time to time asking whether Lync can be configured to automatically bring the conversation window forward when a new IM comes through. This is because the flashing icon in the Windows taskbar can be easy to miss if someone has IM’d you and you didn’t happen to be at your PC.

We sat down at Modality and thought about how we could solve this problem. I’m stoked to announce that Paul Nearney and his awesome development team have come up with a solution. Presenting SuperToast by Modality Systems:

SuperToast will bring your new IMs up in a notification window on your desktop so it’s totally obvious you’ve just been IM’d. No more missing critical messages because they’re sitting in your taskbar going unanswered.

SuperToast is a cinch to install and runs in the system tray. It can be configured to wait a certain period of time (default 30 seconds) before accepting the IM and presenting the notification.

Check out more info on Paul Nearney’s blog, Code Lync, about the this release, available free from Modality Systems.

Our October MUCUGL event was on on last Thursday night, which happened at the Polycom EBC in Old Broad St.

We had a modest turn out, which made for a more personal event giving everyone an opportunity to mingle and share war stories. Polycom came to the party in a big way, providing lots of refreshments and snacks. They also demonstrated all their Microsoft video integration scenarios along with the impressive Immersive Telepresence rooms.

Jeff Schertz delivered a great presentation on Audio/Video Conferencing with Lync and Polycom. He went into lots of detail on video components, the difference between QCIF, CIF, VGA and HD video resolutions and how this all relates to Lync.

I also gave my presentation on the new Lync for Mac 2011 client, where I talked about the Mac story so far and what the new client looks like. The slides are available for viewing below on Slide Share.

Tom also gave an update on the community as a whole and spoke about Skype, Windows Mobile and CEBP. All the other sets of slides can be viewed on the MUCUG London blog and you can check out the audience feedback we received.

An update for Lync for Mac

Last Friday an update was released by Microsoft to fix the Office 365 and certificate issues on OS X.  More info is available in the blog post from the Office for Mac team here. Technical info is in the Microsoft KB article here and this page includes a link to download if you’d rather not wait for Microsoft AutoUpdate to do its thing.

In the previous part of this series, I talked about how we fail over our databases. In this part, I’ll cover what happens to Lync after the failover.
The objective of this exercise was to attempt to get our Lync Enterprise Edition Pool to function when we took the primary SQL server offline and pointed Lync to the SQL mirror node where our back end databases had been mirrored to.

Trying to get it to work

I found that after failing over, the SQL Native Client on the Front End servers was Database Mirroring aware and had automatically redirected itself to the mirror node of SQL02. This was confirmed when I saw a successful automatic connection to SQL02 on port 1433 from the Front End server (FE03) that we’d failed over to.

However the Lync Server Front End service is not Database Mirroring aware, and we saw loads of errors and warnings in the Lync Server event log telling us that a connection to the SQL server could not be made as it was consistently attempting to connect to SQL01 (the failed server) that is defined in the Lync topology.

When I attempted to sign in using Lync, all we could get was the “Limited Functionality Mode” experience with no presence or contact list.

At this stage, I started to think about how we could get this to work, and changed the DNS record for SQL01 to resolve to the IP address of SQL02, which didn’t help. I even changed the IP address of SQL02 to that of SQL01, which still didn’t result in a successful connection. Everything I tried to get SQL02 to look like SQL01 wouldn’t work.

How to achieve basic client functionality

Now that we’ve discovered that Lync doesn’t support Database Mirroring natively nor do basic DNS changes help, I worked out that we needed to do to get the Lync FE services to start properly and to make a database connection to the SQL mirror node.

1. Delete the computer account of the principal SQL server (SQL01) from Active Directory.
2. Modify the hostname of the mirror SQL Server (SQL02) to that of the failed, principal SQL Server (SQL01).
3. Restart the mirror SQL server and verify that all SQL services are started.
4. Modify the DNS A record for the failed principal SQL server so that it resolves to the IP address of the mirror SQL server.
5. Restart the Lync Front End server and confirm that the Front End service is started.
6. Verify signing in with the Lync client and that you receive the full client experience and not “Limited Functionality Mode”.

As you can see, this is by no means a “High Availability” solution, as it means computer name and AD changes which rules this out as being an acceptable “quick failover” scenario and even rules it out as a Disaster Recovery solution.

Because Lync Server is inherently secure, it means we cannot connect an FE server to a back end SQL server that isn’t defined in the topology.

Why is it not supported?

One reason why it’s not supported is that there is a highly dependent and integrated relationship between the rtc andrtcdyn databases.

Each database refers to the other to maintain a consistent presence state to the user of their contacts, and of their presence to their contacts. The rtc database is mostly static, holding publications of users, contact lists, privacy relationships etc whereas the rtcdyn database is dynamic, holding state about which front end in the pool holds a SIP endpoint and what active subscriptions are bound to the endpoint.

Because database mirroring is configured and managed at an individual database level, in the event of failure OCS/Lync cannot guarantee both databases are in the consistent state required to maintain the required quality user experience.

Summary

To summarise, when the failover process is executed, the following behaviour was observed:

• Initially, the Lync client signs in but is in “limited functionality mode”. This is because the Lync Front End service cannot communicate with the back-end database.
• Front End Service starts but events are logged advising that a back-end database connection cannot be made.
• It was concluded that due to inherent product design, the Lync Front End service will not connect to a SQL server that is not defined in the Lync Topology.
• It was only after we deleted the computer account for the failed principal SQL server from Active Directory and renamed the mirror SQL server did errors stop appearing in the Application Log and the Lync client function properly.

What about Group Chat?

In the next instalment, I’ll talk more about what happens to Group Chat when we failover the databases to the SQL mirror node. Make sure you subscribe to get updated!

I observed this problem recently on my own Mac, where Lync would crash with the latest patch applied (10.7.2) and it had me stumped. I’d updated to take advantage of iCloud with iOS5 on my iPhone, and it killed Lync on me.

Fortunately, Apple man of wizardry Mark Coughlan has posted an awesome fix for this problem over on his tech blog, which turns out to be caused by some certificate keychain in OSX. Check it out here.

Update: I’ve sheathed my sword a bit and toned down parts of this post because I was a bit of a fire breathing dragon.

Chris Norman has written a fantastic post over on his blog titled Lync Native Features Versus Plugins: Where Does The Real Complexity Reside?. It’s squarely aimed at third-party Lync call control applications like Cisco’s CUCI-Lync (Cisco Unified Communications integration for Lync) and Avaya’s Microsoft add-in built on their ACE (Agile Communication Environment) development platform that take away out-of-the-box voice and video functions from Lync and cripple the product.

Having deployed CUCiMOC first hand and seen it and CUCI-Lync in action, I can say that this type of integration scenario causes infrastructure and client management problems not to mention user experience issues.
I’m going to focus on the Cisco integration in this post, I’m going to pull a few references out of my Cisco Integration Scenarios document I wrote earlier this year here to wax lyrical about this for a bit.

Why would I want to deploy CUCI-Lync?

I’ve done the due diligence and cost/benefit analysis before, and I do appreciate why you’d want to use a PBX vendor provided client side integration scenario. Here’s a few reasons:

• Utilise your existing investment in Cisco Unified Communications Manager, not to mention the large estate of Cisco handsets you probably own.
• CUCI-Lync provides remote call control of Cisco handsets without Cisco Unified Presence Server (CUPS) – a typically difficult piece of kit for even a seasoned Cisco Voice professional to deploy.
• Utilises Instant Messaging and Presence functionality provided by Microsoft Lync Server 2010.
• Doesn’t require Lync Plus CALs for voice functionality.
• Gives the end user the option whether to use a soft phone (Cisco IP Communicator – part of CUCI-Lync) or their Cisco desk phone to make and receive calls.

Adding Unnecessary Complexity

Everything in that bulleted list looks like awesome, low hanging fruit doesn’t it? Get all the cheap benefits of Lync and still use Cisco for voice. Thumbs up right, game on?

No.

The reality here is that there are a bunch of sacrifices you need to make to achieve this. Like these:

• No native remote user access capability – CUCi-Lync requires VPN connectivity to log in and cannot leverage the Lync 2010 Edge Server to allow for remote voice use.
• Adds an additional application to your desktop image to maintain and contributes to the suite of applications your helpdesk team must support.
• No central management methodology – settings for CUCI-Lync are configured client side manually via the Windows registry or using Group Policy.
• Cannot federate media with external organisations. Federation is only available with IM/Presence via the Lync Edge Server.
• If you want audio/video/web conferencing, you need Cisco Meeting Place for this (another licensing cost).
• Finally, the user experience is confusing.

Luis Ramos has another good review here of CUCI-Lync from his lab. From what I’ve seen and from what you can tell from the screenshots, the plugin looks and feels buggy, and doesn’t respond as snappily as Lync does.

The User Experience is Paramount

Weighing up everything that the PBX vendors harp on about not having to pay for Lync Enterprise and Plus CALs, utilising your existing PBX investment etc.. at the end of the day the key to the success of your UC deployment is the satisfaction of your users.

You’re deploying Lync to receive the benefits of a robust, clean and functional UC solution. If you introduce an additional user experience layer on top of that that requires users to learn slightly different ways to achieve different things, written by different companies, you will encounter significant resistance.

And what do we know about user experience? If it’s terrible, users will throw your solution back in your face. Which means your project has been a failure. That money you saved not buying Lync Enterprise or Plus CALs doesn’t matter now.

Has anyone actually heard of this being deployed in production at a company? Let me know in the comments.

Time for us all to get together again in London for MUCUGL, talk about Lync Server and have a few beers after. Following up from a successful first event, this time we’ve got the Polycom guys onboard to talk video interoperability with Lync.

Taking place on the 20th October at the Polycom EBC and kicking off at 6pm sharp, the night will start off with Polycom Customer Experience Manager Mike Adams showing us a demo of the Lync and Polycom VC integration experience. After a break and some networking, Lync MVPs Jeff Schertz and Mike Stacey will follow up the tech content by talking about audio/video conferencing and Lync integration at a deeper level.

To finish up, Adam, Tom and I will be covering all the latest Lync news and updates to bring you up to speed with what’s happened in the last 3 months. Then, it’ll be time for beer.

Location:

Polycom Executive Briefing Centre
69 Old Broad St
Dashwood House (16th Floor), Broadgate
EC2 London

For more more info and the registration link, jump over to the MUCUGL blog here.

In the first part of this series covering SQL Database Mirroring and Lync Server 2010, I covered a lot of the prerequisites required to establish this deployment scenario. I also ran through getting the Database Mirroring side of things setup.

In this next part, I’ll cover actually simulating a failure of our SQL Server. There are a few T-SQL queries we need to run first, followed by actually failing over the SQL database server node and verifying that the failover was successful.

Failing over to another SQL Server

The failover process was scoped so that it simulated a production data centre failure as close as possible. The process consisted of the following steps for each database mirroring scenario.

Prerequisites to Failover

1. First, open a Command Prompt and navigate to C:\Program Files\Common Files\Microsoft Lync Server 2010\Support. Run the following command to backup all user data (e.g. contact lists, privacy relationships, conference directories) using dbimpexp.exe:dbimpexp.exe /export /hrxmlfile:location of backup file /sqlserver:name of SQL server /restype:all.
2. Next, ensure the mirroring status is healthy and that the Principal server node (SQL01) reports each database as Principal, Synchronized:
   
    and that the mirror server node (SQL02) reports each database as Mirrored, Synchronizing:
3. To track synchronous replication, timestamp tables should be created in each database using the following Transact SQL commands.

CREATE TABLE dbname1.dbo.tblDate (dtDate datetime)
CREATE TABLE dbname2.dbo.tblDate (dtDate datetime)
CREATE TABLE dbname3.dbo.tblDate (dtDate datetime)
CREATE TABLE dbname4.dbo.tblDate (dtDate datetime)
CREATE TABLE dbname5.dbo.tblDate (dtDate datetime)
CREATE TABLE dbname6.dbo.tblDate (dtDate datetime)

4. Next, run the following command to insert timestamp data into the table every second so replication can be tracked:

SET NOCOUNT ON
WHILE 1 <> 2
BEGIN
INSERT INTO dbname1.dbo.tblDate (dtDate) (select GETDATE())
INSERT INTO dbname2.dbo.tblDate (dtDate) (select GETDATE())
INSERT INTO dbname3.dbo.tblDate (dtDate) (select GETDATE())
INSERT INTO dbname4.dbo.tblDate (dtDate) (select GETDATE())
INSERT INTO dbname5.dbo.tblDate (dtDate) (select GETDATE())
INSERT INTO dbname6.dbo.tblDate (dtDate) (select GETDATE())
WAITFOR DELAY ‘00:00:01‘
END

In each T-SQL command, replace the field dbname1 with the name of the database you wish to run the command against. Now we’re ready to failover the databases.

Simulating a Server Failure and Failing Over the Databases

You can do this in two ways – either using the Failover button in the Database Mirroring GUI or use the following method to simulate a complete server failure:

1. Force-power off the Lync Front End and back-end SQL servers, or verify that these servers have failed.
2. After the decision has been made to activate the disaster recovery process, log onto the SQL Server mirror node (SQL02) and run the following SQL queries to force failover of databases.
1. Check that the database is in synchronous mirroring mode:
   ALTER DATABASE dbname SET SAFETY FULL;
   GO
2. Failover the database (this is an unplanned database failover, performed when the Principal is offline, which may result in data loss, hence the command name):
   ALTER DATABASE dbname SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS;
   GO

Replace the field dbname with the name of each database.

3. After failing over the database, verify that the Lync databases are in “Principal, Synchronized” mode on the mirror node (SQL02).

At this point, we can check the Front End (FE) service on our Front End servers and test signing in with the Lync client.

How Lync Server Behaves

In the next instalment, I’ll talk more about what weird behaviour was observed and how I tried to get Lync to use the SQL mirror node. I encountered loads of problems, but eventually got the Lync Front End service to use the SQL server we’d failed the databases over to. Make sure you subscribe to get updated!