I gave you guys a heads up on this a few weeks ago that I’d looked into this in some fairly significant detail and found some interesting behaviour when you attempt to failover after deploying Lync Server 2010 backend and Group Chat databases using SQL Server Database Mirroring. Now that I’ve completed this work, I can share the results with you in a multi-part blog series.

Questions have always been asked over the years as to why organisations can’t use SQL Database Mirroring as a lower cost alternative to SQL Failover Clustering and the only advice we’ve been able to give is what TechNet documentation provides:  ”Lync Server 2010 does not support native database mirroring“.

Based on the work I’ve done, I can tell you what happens when you attempt to failover, what you have to do to actually get to a “recovered” situation and reasons why you won’t want to use SQL Database Mirroring with Lync.

The Supported Scenario Today

Why SQL Database Mirroring?

Database mirroring was a new feature delivered as part of SQL Server 2005. The data replication occurs at an individual database level rather than at an instance level in clustering, providing greater flexibility at the expense of a higher management/configuration overhead. Unlike clustering, the system databases e.g. master db cannot be replicated using Database Mirroring. This means that you need to recreate logins, security etc manually on the mirrored node.

The mirroring process transports logs over its own TCP/IP session on port 5022 and uses compression by default. An important point to note is that SQL Server Standard Edition is a single threaded operation whereas SQL Server Enterprise Edition is a multi-threaded mirroring process.

One of the greatest benefits of database mirroring is its flexibility. An example of this is that an administrator can effortlessly switch principal and mirror roles back and forth, failing over between the two nodes. Plus there is no dependency on identical/near-identical hardware, disk, heartbeat networks etc that make traditionally make clustering a hinderance. Think of it like SCR was to Exchange Server 2007.

Compelling Reasons for Database Mirroring

I can definitely see why an organisation would want to utilise mirroring rather than clustering, especially when attempting to design site resiliency. The top reasons being that it is:

• Cheaper.
• Represents less infrastructure complexity.
• Better for site resiliency as there are no tight network and storage requirements. <— No 1 reason.

Test Environment

As part of this investigation, I deployed the following machines to test this configuration:

• One Lync Server 2010 Enterprise Edition pool consisting of two Front End servers (named FE01 and FE02).
• Two Lync Server 2010 Group Chat servers (GC01 and GC02).
• Two SQL Server 2008 R2 servers fulfilling the principal (named SQL01) and mirror (named SQL02) roles for Database Mirroring.

Lync and SQL Configuration

After deploying my servers, I got them ready to define the topology and install Lync. I’m not going to go into loads of detail on the configuration of SQL Database Mirroring here because it’s well covered on TechNet and it’s all GUI driven. I completed the database parts in the following way:

1. Specified the location for the back end databases for the Front End pool as the principal SQL server (SQL01) in Topology Builder and published.
2. Setup my Group Chat database and permissions on SQL01 and specified this server in the Group Chat Installation Wizard.
3. Ensured the Lync backend databases were successfully deployed onto this server.
4. Verified all sign-in functionality with both the Lync and Group Chat clients.
5. Configured SQL Database Mirroring using the SQL Server 2008 R2 Management Studio GUI to mirror all databases to SQL02.
6. Verified that all databases were in a Principal, Synchronized status on SQL01 and Mirrored, Synchronizing on SQL02.

The Next Chapter

Once we’re at this stage, we’re good to start failing the databases over to the mirror node to see how Lync behaves.

Be sure to subscribe and come back for the next part where it gets interesting. Services started failing over the shop, TCP connections were being automagically redirected to the SQL mirror node and there’s lots of the Lync client being in “limited functionality mode”. Stay tuned.

This week I’ve chosen to interview Lync MVP, Adam Jacobs. Adam is my first English guest, and him and I run the Microsoft UC User Group London together along with Tom Arbuthnot and John Lamb.
Adam has a wealth of UC knowledge in areas such as business value, strategy and voice integration scenarios. He was one of the first people to get Skype to talk to OCS via Asterisk, so you can tell he likes to push the envelope to see what’s possible.
I first met him at the quarterly #ucomsldn drinks I run in London, so I decided it was time to see what his story is.

• What’s your technical background? How did you end up where you are today?
  It’s pretty much my dad’s fault. He’s a software developer and from a young age he and I tinkered with technology. I recall our first breakthrough, a custom built ZX Spectrum – it featured a whole 1K of RAM (this was cool back then) and a keyboard that was embedded into a plastic lunch box!

• Can you tell us what your position entails?
  I’m the Head of IT at a leading UK foreign exchange. My responsibilities are fairly broad, from in-house e-commerce development to capacity management within our three data centres.Strategically I have to ensure that I’m thinking ahead, especially in the current economic climate, where technology investments typically have a life expectancy of 5 years+. Fixed-line and mobile voice technology is definitely an area whereby intellectual investment can be made with big cost savings and increased business agility benefits.

• What first made you get into UC and working with Lync?
  Previously I worked for a company that specialised in B2C SIP-to-PSTN services, it was run extremely badly and it wasn’t the most pleasant of workplaces – but I learnt a lot there. I started looking at Open Source VoIP technology, specifically Asterisk and as a consequence I fell in love with the capability of voice-to-desktop integration – which we now all know as UC.When the opportunity arose to put this into practice at my present workplace we chose OCS. We’re a “Microsoft shop” and this solution ticked all our boxes – we even identified an integration path for our Nortel CS1000. Next steps for us are to rip-and-replace our existing PBX with Lync and, fingers crossed, we’re hoping to pull this off later this year.

• What’s your favourite thing about Lync?
  Probably the intuitive interface. Rolling out Lync (or OCS) has not only been huge hit within my workplace, but there has been little or no need for end user training. It’s the most successful technology implementation I have made to date. I recall one end-user saying, “Instant Messaging at work is great, I reckon you could use it for business use too!” – this made me chuckle

• If you could think of one feature you’d like included in the next version of Lync, what would it be?
  Call pickup, in the UK (and Europe for that matter) this is a commonly adopted piece of traditional telephony functionality – team call-group doesn’t quite tick the box for all scenarios.

• What do you feel is your area of expertise, where you’d consider yourself a bit of a rockstar?
  I’m not sure this makes me a “rockstar” as such, but here goes…I’d say I have both a strong technical background and grounded business acumen, this means I can engage in both areas. Often resulting in solutions that are not only cost efficient but also well aligned with the needs of the business.

• Your blog is known for taking a different look at OCS and Lync, providing some more flexible solutions in the past. When did you start it and what direction has it taken?
  I started “I’m a UC Blog” back in early 2009, it used to be a fairly broad Microsoft technology site until I made the decision to focus primarily on UC, since then I see an average of 700+ visitors daily. The most popular articles are focussed around interoperability – I even got a mention in the Microsoft Lync 2010 resource kit chapter on “Interoperability with Asterisk and Skype” J

• Whereabouts in the UK are you from and what do you think makes your hometown/city great?
  I’m from London and even withstanding the recent rioting and looting I still feel proud of my home town, especially when I commute in and around the City of London. The beauty and history can be quite breath-taking. As a Londoner, sometimes you just have to pause and be a tourist in your own city. That said, I love travelling (probably not as much as you Justin) and wouldn’t rule out re-locating if the right opportunity became available.

• When you’re not dishing out quality technical know-how, what do you do on weekends for fun?
  It’s not always “fun”, but probably being a father to twin boys – it has its moments I can tell you!

Thanks a lot for participating Adam, it’s great to hear from another UC Pro in London. Make sure you check out his blog here and follow him on Twitter.

Remote Call Control on Lync is still a bit of a dark area. Everything in the server product remains in terms of configuring RCC, but getting it going is a bit of a different story. There is very little PBX vendor advice around regarding support of RCC in Lync with their PBXs (although Cisco updated their interoperability statement recently).

Plus there are some shortcomings on the client side that will make or break your RCC deployment. One of the biggest pain points is the complete lack of any video capability when Remote Call Control is configured. This will cause dramas for lots of organisations looking to leverage the desktop video capabilities in Lync. More on this from Jason Sloan.

I’m going to dive straight into the thick of it here and concentrate on getting RCC working with a Mitel 3300 ICP PBX and what vendor specific things you need to do in Lync. I will touch on the PowerShell cmdlets to get RCC going in Lync, but for more generic details on how RCC is configured in Lync, check out these other blog posts.

Infrastructure Requirements

At a high level, here are the basic bits and pieces you’ll need to get this running.

1. Active Directory.
2. A functioning Lync Server 2010 Environment consisting of at least one Standard Edition Server or an Enterprise Edition Front End Pool and Lync clients.
3. A Mitel 3300 ICP (IP Communications Platform) and Mitel handsets.
4. A Mitel Live Business Gateway.

Configuring the Mitel Live Business Gateway

Now let’s take a look at the somewhat tricky part – configuring the LBG. Here’s where you’ll want to have your Mitel man at the ready to give you a hand, mainly in the configuration of the ICP side of things.

Firstly, open up Mitel Business Gateway from Control Panel. This tab will display the IP address of the machine and the SIP port the LBG will use. Unless you have a strict business requirement to encrypt internal communications, don’t select TLS (this is a big headache, involves lots of stress with certificate, something I’ll cover in another post).

Next, click the ICP tab. Here’s where you specify the Mitel 3300 PBX nodes (aka ICPs) that the LBG will talk to.

Specify the IP address of the ICP and the Remote CC URI (this is what will become your Line Server URI in Lync – should be something like lbg@hostname.domain.com) to use. Next, specify the username and password to connect to the Mitel 3300 and hit Add.

Next click the Licensing tab. Here you need to put in your Service Link ID from Mitel to license your users for RCC using the LBG.

Now click the Active Directory tab. You need to configure the LBG to talk to AD so it can check if users are setup with phone numbers that they are attempting to remotely control with Lync.

Specify the FQDN of a domain controller, then the username you want to use to query AD and the password and click Add To List. You can add additional DCs for redundancy.

Under the ODM and IDM tabs, you can configure how numbers are modified on outbound and inbound calls (so you can normalise incoming numbers from, for example only 4 digit extensions to full E.164 so they match to AD user accounts).

Finally, on the Log tab, you can setup the log level that will be captured for diagnosis purposes.

Once you’re all done, return to the Live Business Gateway tab and click the button at the button labelled Start.

Configure Lync Server for Remote Call Control

As I mentioned above, configuring the Lync server infrastructure for RCC is a bit different from previous versions. Everything is done in Powershell now, so those familiar with Routing and Authorised Hosts tabs in the OCS 2007 R2 GUI will need to pay attention here.

Setting up routes and trusted applications

To configure remote call control with Mitel, the following Powershell cmdlets will be run using Lync Server Management Shell on the Lync Front End server. Replace server FQDNs and IP addresses with your own.

1. Create a new Trusted Application Pool for the Mitel LBG.
   New-CsTrustedApplicationPool -Identity mitel-lbg.justin-morris.net -Registrar lyncfe.justin-morris.net -Site 1 -TreatAsAuthenticated $true -ThrottleAsServer $true -RequiresReplication $false
2. Create a new Trusted Application which is bound to the Application Pool created in the previous step.
   New-CsTrustedApplication -ApplicationId RCC -TrustedApplicationPoolFqdn mitel-lbg.justin-morris.net -Port 5060 –EnableTcp
3. Create a variable called $tcpRoute that defines the static route to the IP address of the Mitel LBG when the Server URI is matched.
   $tcpRoute = New-CsStaticRoute -TCPRoute -Destination 10.1.10.50 -Port 5060 -MatchUri mitel-lbg.justin-morris.net
4. Configure the Lync Static Routing Configuration with the new route specified in the previous step.
   Set-CsStaticRoutingConfiguration -Route @{Add=$tcpRoute}
5. Enable the modified Lync Server Topology.
   Enable-CsTopology
6. The topology will then need to be exported to XML and a manual workaround applied specific to integration with Mitel. Note that this is NOT RECOMMENDED by Microsoft to EVER manually modify the topology document, but it is required to get RCC working with Mitel in Lync. Test this in an isolated environment before making changes to your production environment.
   Run the following command to export the topology to XML:
   Get-CsTopology -AsXml | Out-File c:\rcc.xml
7. Open the rcc.xml document and find the line that refers to the Mitel LBG e.g.
   <Cluster Fqdn=”mitel-lbg.justin-morris.net” RequiresReplication=”false” RequiresSetup=”true”>
   <ClusterId SiteId=”1″ Number=”3″ /> <Machine OrdinalInCluster=”1″ Fqdn=”mitel-lbg.justin-morris.net”>
   <NetInterface InterfaceSide=”Primary” InterfaceNumber=”1″ IPAddress=”0.0.0.0” />
   </Machine> </Cluster>
8. Modify the IPAddress field from 0.0.0.0 to the actual IP address of the Mitel LBG e.g. 10.1.10.50.
9. Save the file and exit.
10. Next, publish the modified Lync Server Topology to the CMS.
    Publish-CsTopology -FileName c:\rcc.xml

User Configuration

For each user you want to setup for RCC, go into their account details in the Lync Server Control Panel. From the Telephony drop-down menu, select Remote Call Control.

Configure them with a LineURI that looks like this:
tel:+441632456765;ext=6765

And a Line Server URI that looks like this:
sip:lbg@mitel-lbg.justin-morris.net

So in the GUI, it should look like this once configured:

Once you’ve filled this in, hit Commit.

Additionally, each user needs to have the extension field (e.g. 6765) somewhere in their AD account (in a Telephone field for example) so the Mitel LBG can see that the users is setup for that phone number.

Configuring each Lync Front End Server to listen on Port 5060

Finally, we need to configure our Lync Front End Server to listen on port 5060 for SIP TCP so it can receive traffic from the Mitel LBG. We do this by running the following cmdlet from Lync Server Management Shell:

Set-CsRegistrar “Registrar:lyncfe.justin-morris.net” -SipServerTcpPort 5060

Hat tip to Tom Pacyk’s blog post for this one (again, the guy comes up with the goods).

Troubleshooting connectivity on the LBG

If RCC doesn’t work straight off the bat for you, you can troubleshoot connectivity by opening the Log Viewer application on the LBG. Navigate to C:\Program Files (x86)\Mitel Networks\Live Business Gateway\Tools and open MSPlogs.exe

First, click File then click Connect to MSPLog File…

Next, navigate to the Logs directory under …\Mitel Networks\Live Business Gateway\Logs and select appgw.log and click Open.

All logs of connections to the LBG are now available for viewing. Interpreting what they mean is a topic for a whole other blog post.

Conclusion

Obviously this is a pretty full-on piece of integration, and this goes into a bit of detail but doesn’t cover everything. You’ll see less and less support of RCC these days and not as many people deploying it, but hopefully this helps those of you out there still wanting to get RCC going with your Mitel 3300 and Lync Server 2010.

This has come up a few times in different engagements in the past, and I decided it would be worth publishing some guidance around how to set this up.

Why would I want to hide users?

Perhaps you have members of the organisation that you don’t want contacted by everybody else. Say if you have a strict communications policy that the CEO shouldn’t be directly contactable, you could hide them from appearing in the address book.

Another example is if you have resource accounts setup that are enabled for Lync whose purposes is for only making calls, there’s no need for these to be discoverable in the address book. Or perhaps you don’t want them searchable because they are private numbers or are in private areas, you would hide these from the Lync Address Book.

How it’s done

First, on one of your Lync Front End servers, install the Lync Server 2010 Resource Kit. You can download it here.

Next, on the server using Windows Explorer, browse to C:\Program Files\Microsoft Lync Server 2010\ResKit and double click the application named ABSConfig. You’ll be presented with the UI below.

Firstly, you’ll see a list of AD Attribute Names. To achieve this, we need to create a new one and specify the AD Attribute we want to use to filter accounts. Here I’ve specified the AD Attribute comment, but you can use whatever takes your fancy.

Next, you need to specify where it says Which users do you want to include in the ABS files? whether you want to:

1. Only include users that have a value for the AD attribute you specify or;
2. Exclude all users who have a value for the AD attribute you specify.

For this blog post, we’re going to select Exclude all users who have a value for this AD attribute. In the field next to this, we’re going to type the name of the AD attribute (comment) that we specified above. In each user account we want to hide, we will use this AD attribute to populate with a data value.

Once you’re done, hit Apply changes and you’re good to go. Changes will take affect next time the Address Book processes do their thing (by default, this happens at 1:30am each night).

Now, whenever the Lync User Replicator process sees a user with a value for the attribute you specified, it will exclude it from the Address Book and that user will not appear when you search for them in the Lync client.

So the last few weeks I’ve been nutting out what happens when you deploy the backend Lync and Group Chat SQL databases onto a SQL Server 2008 R2 mirror pair for site resilience purposes. This is an unsupported scenario, so needless to say the results were quite fascinating.

I saw some very interesting behaviour when you simulated a failure of the primary SQL node and activated the standby node in another site. I also had to hack at it like crazy to try and get Lync to connect to the mirror node, both for the regular backend databases and for the Group Chat database.

Let me just whet your appetite by saying, some things work well, other things don’t work at all.
Database Mirroring in SQL I’ve learnt is actually a very robust and flexible HA solution for databases, but there are only some ways it could potentially be useful for Lync.

Standby for a full write up in the near future.

After a few months of preparation, working out what we were going to present, where we were going to have it and when, we pulled it off and ran our first Microsoft UC User Group London event last Thursday!

I’m really happy with the response and feedback we received on the night and I think all the content we presented went down well. It was also great having a chat to people about Microsoft UC after at the pub over a few pints and to share some war stories.

Adam has uploaded all the slidedecks to slideshare for us, here’s my one on Voice Resiliency in Lync Server 2010.

The rest of the presentations are available here. More info including snippets of feedback from attendees is available here on the MUCUG London blog also. Look forward to seeing you at the next one!