Category Archives: Coexistence/Interoperability

Calls from Lync to Nortel CS1000 over ISDN don’t display caller ID on handset

During a recent Lync 2013 Enterprise Voice roll-out I was configuring interoperability with the legacy Nortel CS1000 PBX. For this, we’d deployed a pair of Sonus SBC 1000 gateways with 2x ISDN PRI ports each. In each gateway, one PRI port was connected to the PSTN and the other PRI port was connected to the CS1000, so these gateways were deployed in an upstream model in front of the PBX.

Calls to all destinations (Lync, the CS1000 and the PSTN) were connecting fine with no media problems, but we did observe that calls from Lync to legacy PBX phones were not displaying the calling number (or caller ID, or CLI, take your pick) on the handset. Tracing this using Sonus LX found that the gateway was configured to pass through the calling and called numbers correctly, so the problem wasn’t immediately apparent: Continue reading →

Exporting and importing contact lists in Lync Server 2010

37 Replies

I’ve been doing a fair bit of work around coexistence and migration lately and throwing contact lists around all over the place using dbimpexp. In light of this, I thought it’d be a good idea to do up a post to help you understand what dbimpexp.exe is as it’s a super useful bit of kit to have at your disposal during a Lync implementation/migration or during day-to-day operations.

If you’ve had experience backing up or restoring OCS 2007 R2 or Lync Server, chances are you’ll be familiar with dbimpexp. It’s very helpful for moving contact lists in a DR situation or between deployments in different domains. The only constant is that the SIP address must be the same when exporting or importing, so there’s no dependency on the AD domain that the contact lists have been exported from or are being imported into.

What is Dbimpexp?

Essentially (as per Microsoft), it’s a utility for exporting, managing and importing XML files containing homed resource data from a Microsoft Lync Server 2010 SQL database. When they say homed resource data, they mean user contact lists and conference directories. Dbimpexp allows you to import or export users’ contact lists either on a per user basis or a bulk pool-wide basis.

Using dbimpexp.exe

Dbimpexp.exe is located in C:\Program Files\Common Files\Microsoft Lync Server 2010\Support on a Lync Front End Server. You’ll be running it on one of your Enterprise Edition Front End servers or your Standard Edition server to export or import users’ contact lists.

The commands are slightly different for Standard and Enterprise Edition Front Ends, so I’ll cover both in the following sections.

Exporting Contact Lists

So the first thing we want to do is get those contact lists out of one server/pool so we can have them stored to restore in the event of failure, or so we can import them into a new server where the SIP domain is the same. We can export the contact list of an individual or the contact lists of all users on the server/pool.

Standard Edition

For Lync Server Standard Edition, we run the following commands to export users’ contact lists.

For a Single User

This will export out an XML file of the contact list for the single user you specify:

dbimpexp.exe /user:<sip address> /hrxmlfile:”<path that you want to write the xml file to>”

So an example of this would be:
dbimpexp.exe /user:jmorris@justin-morris.net /hrxmlfile:”C:\justin.xml”

For all users homed on the server

This will export out an XML files of all users’ contact lists on the server/pool:

dbimpexp.exe /hrxmlfile:”<path that you want to write the xml file to>”

An example of this would be:
dbimpexp.exe /hrxmlfile:”C:\allusers.xml”

Enterprise Edition

For Lync Server Enterprise Edition, we need to specify the backend SQL instance to connect to that the rtc database resides on. Run the following commands to export users’ contact lists from your Enterprise Edition Front End pool:

For a Single User

This will export out an XML file of the contact list for the single user you specify:

dbimpexp.exe /user:<sip address> /sqlserver:”<SQL Server FQDN\instance name>” /hrxmlfile:”<path that you want to write the xml file to>”

So an example of this would be:
dbimpexp.exe /user:justin@justin-morris.net /sqlserver:”SQL01.justin-morris.net\LYNC” /hrxmlfile:”C:\justin.xml”

For all users homed on the pool

This will export out an XML files of all users’ contact lists on the server/pool:

dbimpexp.exe /sqlserver:”<SQL Server FQDN\instance name>” /hrxmlfile:”<path that you want to write the xml file to>”

So an example of this would be:
dbimpexp.exe /sqlserver:”SQL01.justin-morris.net\LYNC” /hrxmlfile:”C:\justin.xml”

Importing Contact Lists

So now that we’ve exported our contact lists from the source server/pool, we can take the XML files that dbimpexp has created and import the contact lists into the target server/pool.

The only difference between the export and import commands is that to import users, you need to specify the /import switch and the restore type switch of /restype:user (which is different from /restype:all which will attempt to import the conference directories also).

Standard Edition

For Lync Server Standard Edition, we run the following commands to import users’ contact lists.

For a Single User

This will import the contact list from the XML file for the single user you specify:

dbimpexp.exe /import /user:<sip address> /hrxmlfile:”<path where the xml file resides>” /restype:user

So an example of this would be:
dbimpexp.exe /import /user:jmorris@justin-morris.net /hrxmlfile:”C:\justin.xml” /restype:user

For all users homed on the server

This will import all users’ contact lists on the server/pool from the XML file you specify:

dbimpexp.exe /import /hrxmlfile:”<path where the xml file resides>” /restype:user

An example of this would be:
dbimpexp.exe /import /hrxmlfile:”C:\allusers.xml” /restype:user

Enterprise Edition

For Lync Server Enterprise Edition, we run the following commands to import users’ contact lists.

For a Single User

This will import the contact list from the XML file for the single user you specify:

dbimpexp.exe /import /user:<sip address> /sqlserver:”<SQL Server FQDN\instance name>” /hrxmlfile:”<path where the xml file resides>” /restype:user

So an example of this would be:
dbimpexp.exe /import /user:justin@justin-morris.net /sqlserver:”SQL01.justin-morris.net\LYNC” /hrxmlfile:”C:\justin.xml” /restype:user

For all users homed on the pool

This will import all users’ contact lists on the server/pool from the XML file you specify:

dbimpexp.exe /import /sqlserver:”<SQL Server FQDN\instance name>” /hrxmlfile:”<path where the xml file resides>” /restype:user

So an example of this would be:
dbimpexp.exe /sqlserver:”SQL01.justin-morris.net\LYNC” /hrxmlfile:”C:\allusers.xml” /restype:user

Conclusion

So as you can see, it’s a really good tool to have up your sleeve. It’s great for restoring data after you’ve had to do a force move of users or have just rebuilt a new server and have a working Front End ready to go.

If you’ve got any questions about how it works or when you’d need to use it, drop me a comment below.

CUCI-Lync and why you should think twice

37 Replies

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.

Configuring Lync Server 2010 for Remote Call Control with Mitel 3300

47 Replies

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.

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

When approaching this kind of integration, you should have an engineer on hand familiar with the Mitel PBX so they can configure the 3300 ICP to work with the LBG and outbound/inbound digit modification on the LBG.

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.

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
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
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
Configure the Lync Static Routing Configuration with the new route specified in the previous step.
Set-CsStaticRoutingConfiguration -Route @{Add=$tcpRoute}
Enable the modified Lync Server Topology.
Enable-CsTopology
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
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>
Modify the IPAddress field from 0.0.0.0 to the actual IP address of the Mitel LBG e.g. 10.1.10.50.
Save the file and exit.
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.

My take on Microsoft’s purchase of Skype

2 Replies

So, today it all went down. There were rumours floating around since Sunday that either Facebook, Google or Microsoft were going to snap up Skype. Commence a flurry of observations and comments as to why one or the other would/should buy Skype.

Fast forward to Tuesday and it’s all a done deal. Microsoft have purchased Skype for some $8 billion in cash. A hefty sum to pay, considering eBay sold Skype to a bunch of investors for only $2 billion only 2 years ago. They have had some awesome growth since then however, and have delivered new functionality to the market like video calling from the desktop to the mobile.

There were blog posts and news articles everywhere saying it was soon to come and each was speculating on why this is strategic for Microsoft, how it will affect consumers and what will happen to Skype when they become part of Redmond. This all cumulated in a press release and live conference this afternoon (London time) that announced a few things:

Skype will connect users with Lync, Office 365, Outlook (does this mean a Skype Outlook add-in?) Windows Live and Xbox Kinect.
Enhance Lync for our enterprise customers (interoperate with Skype).
Continued commitment to non-Microsoft platforms for Skype.
An entirely new business division will be created under the current Skype CEO’s (Tony Bates) leadership “Microsoft Skype Division” and Bates will become the President of this division, reporting directly to Steve Ballmer.

Here’s an interesting question, what will happen to David Gurle the current head of Skype’s Business division? He’s a previous Microsoft employee, and he used to head up the LCS team in Microsoft. Will he want to stick around and bring some value or will he jump ship quick smart?

Also, what will the Lync interoperability look like? Will it be via the Edge Server? That’s the obvious integration point really. They need to deliver every communications modality, not just IM and audio/video. What about archiving and compliance? Security? I can only see this interoperability being delivered in a new version of Lync.

With 600 million users registered and 30 million online at any one time, that’s a huge population of users to connect the existing business communications (running Lync) world to.
It means that any seat in any business and any home can connect to each other using IM, audio/video or collaboration. Not to mention people running Xbox Live with Kinect. Now that’s a pretty exciting nirvana to look forward to.

How can I integrate Cisco UCM with OCS 2007 R2 or Lync?

1 Reply

Recently I completed a white paper that details a lot of information regarding the many ways you can integrate OCS 2007 R2/Lync Server with Cisco Unified Communications Manager. This covers Remote Call Control, CUCiMOC and Simultaneous Ringing (a flavour of Enterprise Voice) and includes loads of screenshots to actually give you a visual idea of what the user experience looks like.

It’s up over on the Modality Systems blog, and you can check it out here.

Office Communicator 2005 and Lync 2010 Client Coexistence

3 Replies

What if you have a supported back-end server version (e.g. OCS 2007 R1) to coexist with Lync, but you’re running Office Communicator 2005 out on the desktop? What happens when you want to migrate?
It’s going to be pretty rare that you might encounter this kind of scenario, but I did recently and it’s worth documenting the behaviour we observed.
Unfortunately there’s no pretty screenshots in this post, so use your imagination. 🙂

The Environment

The situation I encountered was an OCS 2007 R1 backend with all clients running Office Communicator 2005. We deployed a new Lync 2010 Front End pool in the same forest and the two pools happily talked to each other (as OCS 2007 R1 and Lync Server 2010 coexistence is supported).
It was only until we begin running client testing that we started to notice weird things happening.

The Behaviour

If you have one user using Office Communicator 2005 and another user using Lync 2010, you will see strange behaviour if the session is initiated from the Lync user to the OC 2005 user.
If the Lync 2010 user polls for presence of the OC 2005 user in any way, whether this is by searching the address book for a user, expanding a distribution group or exposing their name in Outlook, the OC 2005 user will get a Add to Contact List notification. This detracts from the way things usually work, where you can get presence of a user without first adding them to your contact list.
When I tested this same scenario using OC 2007 R1 and Lync 2010, I couldn’t reproduce the issue.

My only guess is that there is a difference between the SIP INFO packets Lync 2010 and OC 2007 R1/R2 send to get presence information, and the way OC 2005 interprets them.

Obviously this is not ideal, and will most likely pose an unacceptable issue during a period of coexistence whilst migrations are occurring. Given that hundreds of these interactions could occur a day per user in a large environment, this presents a massive support issue for your internal IT helpdesk.

The Solution

In the end, you have two options depending on how long your period of coexistence will be and how complicated/large your environment is. These are:

Migrate from OC 2005 to OC 2007 R1 on your existing OCS 2007 R1 backend, then migrate your users to the Lync 2010 backend and upgrade your clients to Lync 2010.
Migrate your users to the Lync 2010 backend and upgrade your clients to Lync 2010 all in one go, effectively having no period of coexistence.

In conclusion, TechNet documentation defines that this kind of coexistence is “only supported if Communicator 2005 is on a federated network” and now we know why. I’d say this has something to do with what the Edge Server does to the SIP packets on their way in and out of the network.