The Lync Mobility Planning, Deploying and Monitoring documentation and associated autodiscover service are now online. Get the documentation here and the server bits here. The Windows Mobile 7 client will be available on Monday, December 12. The iOS and Android clients should be available sometime that same week (pending the appropriate market approvals).
The documentation surrounding this is quite complex. This is not a simple setup. Already, people are finding out what happens when you try to blindly run setup for the autodisover service (see http://ariprotheroe.wordpress.com/2011/12/09/how-not-to-install-the-lync-2010-mobility-and-autodiscover-services/). It pays to read the documentation carefully before running setup.
One thing that I find disappointing is the requirement for a new DNS namespace (lyncdiscover and lyncdiscoverinternal). When I was at the Exchange 15 summit last August, they made a big deal about reducing the number of namespaces required for a functional Exchange deployment. I hope there's a good reason why the Lync team has decided to increase the namespace requirements for Lync. Why not use the existing SRV-based infrastructure to publish the required information?
There's a Microsoft conference this afternoon about the Lync mobility service. Hopefully there will be an explanation about this. I will update this post with more information as I get it.
Friday, December 9, 2011
Friday, November 18, 2011
Lync and 3rd Party PBX Integration
I've been reading the comments over at VOIPNorm's blog post about Avaya ACE. There's a lot to wade through there, but it got me thinking about customer expectations around unified communications. I've got this one particular customer who's got Cisco phones deployed everywhere. They've also got Lync everywhere and people love it. They recognize that Lync has nailed the user experience, encompassing a full featureset along with an easy-to-use interface. Naturally, this customer doesn't want to toss out their significant investment in Cisco hardware, and they want Cisco and Lync to work together. They want Lync to work with their existing phone system with little fuss, and still maintain the rich UI experience of Lync.
What I want to tell them is that you will NEVER have a truly seamless easy-to-use experience when you try to join two competitors' UC products together. To paraphrase one of the commentors at VOIPNorm's blog: when you mix a nice red wine with a nice white wine, the end result isn't a great rosé.
At this client, we attempted to go down the integration path with OCS and a third-party product that promised seamless remote call control with Cisco. They were looking at a 3rd party for RCC rather than Cisco's Unified Presence Server (CUPS), because of apparent scalability issues with CUPS. From an administrative standpoint, the 3rd party product was an absolute nightmare to configure and troubleshoot. Once we did get it working, it did provide remote call control, but there were significant usability issues. The product worked fine when the user was in the office. Users could make or take calls on their deskphone using Lync to control it. However, when the user went home they got frustrated when they couldn't answer incoming calls they could see on their Communicator client because it would answer it on the deskphone back in the office.
We tried giving them the best of both worlds by enabling them for Enterprise Voice, but that became a support nightmare when they got confused about which way to answer the phone or to make calls. If they were set to answer via Communicator, they were confused why their deskphone didn't go off-hook. If they made a call from home and they were set to RCC mode, then they didn't understand what was going on when they dialed a number and they couldn't hear anything (because the call was going out via the deskphone at the office). Not only that, but we now had two separate phone systems to manage.
We tried CuciMOC and CuciLync as well. I remember saying that if CuciMOC could deliver on even half of what they were promising, then our integration problems would be solved. Unfortunately, the end-user experience was so lacking that the project never went beyond the IT pilot phase. Not only that, but the administrative burden involved in configuring and maintaining it was not something that the IT group wanted to deal with on a large scale.
Both projects died a well-deserved death, but the CIO has been demanding seamless connectivity between Cisco and OCS/Lync ever since. It's interesting that people expect so much more from Microsoft than any other vendor. I don't think I've ever heard anyone demanding that Cisco and Avaya integrate with each other. Why should Microsoft get such different treatment?
Unfortunately, when we are dealing with two COMPETING vendors like Cisco and Microsoft, there will never be the sort of tight integration that will allow companies to both leverage their existing investment AND take full advantage of the UC capabilities of Lync. Each vendor has their own very good reasons to push the benefits of their own particular solution. Companies need to stop trying to get the best of both worlds and fully invest in either one or the other solution, not both.
I truly believe that Lync is the best and most cost-effective unified communications solution out there. No other vendor has the same level of product functionality built into the base product as Lync. Companies can get IM, presence, video/audio conferencing, whiteboarding, application/desktop sharing and Enterprise Voice with as little as ONE server. Of course, high availability requirements and larger deployments do require more servers, but it does serve to illustrate what is possible with just one server. Add ONE more server for seamless external connectivity with other companies and remote users. Lync can provide companies with the sort of unified communications their users desire, but sadly even with my best pre-sales pitch, I can't convince everyone.
We are in the early days of a true revolution in communications. Its natural to be resistant to the big changes necessary to put the pieces in place. However, once the switch is made, it will pay dividends in terms of ease-of-communications, cost and flexibility.
What I want to tell them is that you will NEVER have a truly seamless easy-to-use experience when you try to join two competitors' UC products together. To paraphrase one of the commentors at VOIPNorm's blog: when you mix a nice red wine with a nice white wine, the end result isn't a great rosé.
At this client, we attempted to go down the integration path with OCS and a third-party product that promised seamless remote call control with Cisco. They were looking at a 3rd party for RCC rather than Cisco's Unified Presence Server (CUPS), because of apparent scalability issues with CUPS. From an administrative standpoint, the 3rd party product was an absolute nightmare to configure and troubleshoot. Once we did get it working, it did provide remote call control, but there were significant usability issues. The product worked fine when the user was in the office. Users could make or take calls on their deskphone using Lync to control it. However, when the user went home they got frustrated when they couldn't answer incoming calls they could see on their Communicator client because it would answer it on the deskphone back in the office.
We tried giving them the best of both worlds by enabling them for Enterprise Voice, but that became a support nightmare when they got confused about which way to answer the phone or to make calls. If they were set to answer via Communicator, they were confused why their deskphone didn't go off-hook. If they made a call from home and they were set to RCC mode, then they didn't understand what was going on when they dialed a number and they couldn't hear anything (because the call was going out via the deskphone at the office). Not only that, but we now had two separate phone systems to manage.
We tried CuciMOC and CuciLync as well. I remember saying that if CuciMOC could deliver on even half of what they were promising, then our integration problems would be solved. Unfortunately, the end-user experience was so lacking that the project never went beyond the IT pilot phase. Not only that, but the administrative burden involved in configuring and maintaining it was not something that the IT group wanted to deal with on a large scale.
Both projects died a well-deserved death, but the CIO has been demanding seamless connectivity between Cisco and OCS/Lync ever since. It's interesting that people expect so much more from Microsoft than any other vendor. I don't think I've ever heard anyone demanding that Cisco and Avaya integrate with each other. Why should Microsoft get such different treatment?
Unfortunately, when we are dealing with two COMPETING vendors like Cisco and Microsoft, there will never be the sort of tight integration that will allow companies to both leverage their existing investment AND take full advantage of the UC capabilities of Lync. Each vendor has their own very good reasons to push the benefits of their own particular solution. Companies need to stop trying to get the best of both worlds and fully invest in either one or the other solution, not both.
I truly believe that Lync is the best and most cost-effective unified communications solution out there. No other vendor has the same level of product functionality built into the base product as Lync. Companies can get IM, presence, video/audio conferencing, whiteboarding, application/desktop sharing and Enterprise Voice with as little as ONE server. Of course, high availability requirements and larger deployments do require more servers, but it does serve to illustrate what is possible with just one server. Add ONE more server for seamless external connectivity with other companies and remote users. Lync can provide companies with the sort of unified communications their users desire, but sadly even with my best pre-sales pitch, I can't convince everyone.
We are in the early days of a true revolution in communications. Its natural to be resistant to the big changes necessary to put the pieces in place. However, once the switch is made, it will pay dividends in terms of ease-of-communications, cost and flexibility.
Wednesday, November 9, 2011
Dialing Rule Optimizer Now Does Extensions
I've been keeping myself busy lately with updates to the Lync Dialing Rule Optimizer. If you've been keeping track, you may have noticed the numerous improvements lately, including new options for adding Call Park and Premium Number Blocking.
There have also been numerous little changes to the website over the past few months, like:
I am now proud to unveil the latest iteration of the Lync Dialing Rule Optimizer (v7.0). You now have the option to include dialing rules for local extensions. This is useful for companies that connect Lync to an existing PBX and want to maintain extension dialing for their Lync users. It can also be used to allow Lync users in a purely Lync environment to dial each other by extension number, which is especially useful to help users transition from a legacy PBX environment where they were used to dialing each other by their extension.
The new option is visible for Lync users in all countries, as shown below:
When you select the checkbox, it will show an Edit Extensions button. Clicking it will bring up the Extension Entry screen...
Add up to 10 extension ranges and the associated PBX main office number, in e.164 format. The program will create normalization rules, routes and outbound translation rules to make sure that when a Lync user dials an extension, it will route to the PBX.
I've also cleaned up the .PS1 script so that when you run it, it will provide concise and useful information about what it's doing, rather than the flying stream of output it used to do. It will also prompt for an application pool to apply call park/block rules, if it detects more than one in a site.
Try it out, and as always, be careful when applying to an existing Lync site. The script is designed to work in a new, blank site.
If you find issues or have ideas for improvement, please let me know.
There have also been numerous little changes to the website over the past few months, like:
- Minor change to the Lync rule naming convention to include the NPA/NXX for companies that have multiple Lync sites in the same city. So, instead of rules like NA-ON-Toronto-National, you get NA-ON-Toronto-416555-National.
- Website interface change to include warning if Javascript isn't enabled. The webpage relies on Javascript for proper functionality, but users might not notice when creating basic rules. This can lead to all sorts of weird behaviour, so I added a big WARNING: JAVASCRIPT NOT DETECTED! right in the middle of the screen when it doesn't detect Javascript.
- Detailed help for every option
- Rule tweaks to fix some recently found issues
I am now proud to unveil the latest iteration of the Lync Dialing Rule Optimizer (v7.0). You now have the option to include dialing rules for local extensions. This is useful for companies that connect Lync to an existing PBX and want to maintain extension dialing for their Lync users. It can also be used to allow Lync users in a purely Lync environment to dial each other by extension number, which is especially useful to help users transition from a legacy PBX environment where they were used to dialing each other by their extension.
The new option is visible for Lync users in all countries, as shown below:
When you select the checkbox, it will show an Edit Extensions button. Clicking it will bring up the Extension Entry screen...
Add up to 10 extension ranges and the associated PBX main office number, in e.164 format. The program will create normalization rules, routes and outbound translation rules to make sure that when a Lync user dials an extension, it will route to the PBX.
I've also cleaned up the .PS1 script so that when you run it, it will provide concise and useful information about what it's doing, rather than the flying stream of output it used to do. It will also prompt for an application pool to apply call park/block rules, if it detects more than one in a site.
Try it out, and as always, be careful when applying to an existing Lync site. The script is designed to work in a new, blank site.
If you find issues or have ideas for improvement, please let me know.
Monday, November 7, 2011
Migrating PBX Users to Lync Enterprise Voice
In all my previous blog entries about Lync Enterprise Voice Best Practices, I've assumed that the Lync deployments described are pure Lync. There is no mention about connecting to legacy PBXs and how to best setup Lync to integrate with them. Well, today is the day that we deal with that thorny issue.
Typically, there are two types of PBXs. The oldest style are purely analog devices and are known in the industry as TDM PBXs. TDM is short for Time Division Multiplexing - the old analog way of slicing up a telephony pipe to allow multiple calls. Since Lync is not an analog phone system, you require an IP-PSTN gateway to communicate with TDM PBXs. There are several gateway vendors out there that provide Lync-compatible gateways. Some of my favourites include Audiocodes, Dialogic and NET.
The other type of PBX is called an IP-PBX, which is digital in nature and uses TCP/IP for its voice backbone. Pretty much every PBX sold today is IP-based. An IP-PBX may use SIP or other proprietary protocol for communications. If the IP-PBX uses SIP, then there is a fairly good chance it can communicate directly with Lync over TCP/IP. This is by no means a sure thing, because every vendor interprets the SIP standard differently, and this often means that two different SIP-based telephony systems can't communicate with each other. In that case, you'll need to use an IP-PSTN gateway to bridge the two. Even if you can get Lync to talk to the PBX for basic calls, you may encounter issues with transferring or forwarding, which is again due to the different ways that vendors interpret the SIP standard.
Connecting a PBX to Lync
There are two ways to connect an IP-PSTN gateway to a PBX. The most obvious way is to put the gateway behind the PBX (as shown below) connected via a T1 crossover cable. This is the lowest impact solution for the PBX side of things, but it can make routing calls to Lync difficult, because you will be relying on the capabilities of the PBX for such decisions. If you are not well-versed in the operation of the PBX, this will usually require the services of a PBX technician, which can cost both money and time. If you are working with a TDM-PBX, then you are also relying on the availability of a spare PRI card on the PBX. This may not be available due to limited expansion capabilities or availability of hardware.
This may be the only workable solution if your users are assigned extensions, rather than direct numbers (DIDs), because the gateway will always just see the main office number on inbound calls, and won't be able to tell if the call should go to Lync or the PBX. Also, if you rely on an autoattendant for routing calls, you will need to route all calls to the PBX until you've migrated all users to Lync.
If your users all have DIDs or your PBX doesn't have any expansion slots available for an additional PRI card, then the more preferred solution is to place the IP-PSTN gateway in front of the PBX. This requires 2 PRI interfaces on the gateway (or more if you have multiple lines coming in to the PBX). Most gateways allow you to set the interfaces in pass-through mode, so that a failure in the gateway will just pass all calls through as if it weren't even there.
Now inbound routing logic is controlled by the gateway, which is much easier to manage than most PBXs. Usually, you set a default rule for calls bound to the PBX, and insert rules to forward calls to Lync users as you see fit. Many gateways provides Active Directory-based routing that can detect if the user is enabled in Lync and route calls accordingly.
Outbound routing from the PBX should be relatively easy as well. In some cases, you would create a default rule that would route any extension that doesn't have an internal match out of the PBX, and the gateway will route the call to Lync. Other cases may involve setting up forwarding on the internal extension to a pre-defined extension range, that then gets transferred to the gateway and on to Lync.
Setting Up Lync to Route Calls to a PBX
Once you've got the hardware setup, you need to connect Lync to the PBX or gateway. This guide won't get into the details of setting up a specific gateway to work with an given PBX. There are lots of those out there. Once you've got a working connection, you need to define the IP address of the gateway in your Lync topology document. You define the gateway under the PSTN gateways node of your Lync site. A PSTN gateway needs to connect to a mediation pool, which is often collocated with the front-end Lync server role.
As followers of this blog may know, I am a big proponent of e.164 formatting for phone numbers. Ideally, all the phone numbers you define for Lync use - from the actual number assigned to an Enterprise Voice enabled user to the phone numbers listed in Active Directory - should be formatted in e.164 format. If your users have DIDs, then this should be straightforward. For users that only have extensions, you should use the format +<countrycode><officenumber>;ext=<extension>as explained in my blog post on Internal Extensions. Resist the temptation to use only the extension as the user's phone number.
As you transition to Lync, you should allow your Lync users to dial others using the methods they are familiar with. For most, this means dialing by extension. You will want to allow extension dialing in Lync with the least amount of administrative overhead as you migrate users from the legacy system to Lync.
You achieve this by creating normalization rules that translate extensions to full e.164 phone numbers and outbound translation rules that turn e.164 phone numbers BACK into extensions. An example with a company whose main number is +1 (212) 555-1111 that uses 3-digit extensions starting with 2 is below:
Normalization Rule: ^(2\d{2})$ --> +12125551111;ext=$1
Outbound Translation Rule: ^\+12125551111;ext=(2\d{2})$ --> $1
Sample scenario:
Dial 234 --> normalize to +12125551111;ext=234 --> strip to 234 --> send to PBX
You may wonder why go through the trouble of normalizing 3-digit extensions to e.164 when we just strip it back down to 3-digits at the gateway. A long time ago, I evangelized the reasons why you should use e.164 formatting for your user phone numbers. I won't rehash what was said there, but it suffices to say that e.164 formatting is the way to go in almost every situation. So, using the above example with +1 (212) 555-1111 as the main office number, assign phone numbers to your Lync users like this: tel:+12125551111;ext=201. If a Lync user dials 201, it will normalize to the full e.164 format, find a match in its database and ring the user.
If someone dials an extension that doesn't yet exist in Lync, say 299, it will normalize to e.164, fail to find a match in its database, and then route it out to the PBX after stripping it back down to 3-digits.
The Lync Dialing Rule Optimizer can help ease the workload involved in setting up this routing logic. Simply select the Use Extensions checkbox (coming soon), and enter up to 10 extension ranges. The Optimizer will take care of the rest, including proper ordering and placement of rules.
Migrating PBX Users to Lync
Following this generalized plan makes migrating users to Lync very simple:
Links to my other posts in my Enterprise Voice Best Practices series:
E.164 Formatting
Normalization
Usages and Routes
Extensions
Typically, there are two types of PBXs. The oldest style are purely analog devices and are known in the industry as TDM PBXs. TDM is short for Time Division Multiplexing - the old analog way of slicing up a telephony pipe to allow multiple calls. Since Lync is not an analog phone system, you require an IP-PSTN gateway to communicate with TDM PBXs. There are several gateway vendors out there that provide Lync-compatible gateways. Some of my favourites include Audiocodes, Dialogic and NET.
The other type of PBX is called an IP-PBX, which is digital in nature and uses TCP/IP for its voice backbone. Pretty much every PBX sold today is IP-based. An IP-PBX may use SIP or other proprietary protocol for communications. If the IP-PBX uses SIP, then there is a fairly good chance it can communicate directly with Lync over TCP/IP. This is by no means a sure thing, because every vendor interprets the SIP standard differently, and this often means that two different SIP-based telephony systems can't communicate with each other. In that case, you'll need to use an IP-PSTN gateway to bridge the two. Even if you can get Lync to talk to the PBX for basic calls, you may encounter issues with transferring or forwarding, which is again due to the different ways that vendors interpret the SIP standard.
Connecting a PBX to Lync
There are two ways to connect an IP-PSTN gateway to a PBX. The most obvious way is to put the gateway behind the PBX (as shown below) connected via a T1 crossover cable. This is the lowest impact solution for the PBX side of things, but it can make routing calls to Lync difficult, because you will be relying on the capabilities of the PBX for such decisions. If you are not well-versed in the operation of the PBX, this will usually require the services of a PBX technician, which can cost both money and time. If you are working with a TDM-PBX, then you are also relying on the availability of a spare PRI card on the PBX. This may not be available due to limited expansion capabilities or availability of hardware.
This may be the only workable solution if your users are assigned extensions, rather than direct numbers (DIDs), because the gateway will always just see the main office number on inbound calls, and won't be able to tell if the call should go to Lync or the PBX. Also, if you rely on an autoattendant for routing calls, you will need to route all calls to the PBX until you've migrated all users to Lync.
If your users all have DIDs or your PBX doesn't have any expansion slots available for an additional PRI card, then the more preferred solution is to place the IP-PSTN gateway in front of the PBX. This requires 2 PRI interfaces on the gateway (or more if you have multiple lines coming in to the PBX). Most gateways allow you to set the interfaces in pass-through mode, so that a failure in the gateway will just pass all calls through as if it weren't even there.
Now inbound routing logic is controlled by the gateway, which is much easier to manage than most PBXs. Usually, you set a default rule for calls bound to the PBX, and insert rules to forward calls to Lync users as you see fit. Many gateways provides Active Directory-based routing that can detect if the user is enabled in Lync and route calls accordingly.
Outbound routing from the PBX should be relatively easy as well. In some cases, you would create a default rule that would route any extension that doesn't have an internal match out of the PBX, and the gateway will route the call to Lync. Other cases may involve setting up forwarding on the internal extension to a pre-defined extension range, that then gets transferred to the gateway and on to Lync.
Setting Up Lync to Route Calls to a PBX
Once you've got the hardware setup, you need to connect Lync to the PBX or gateway. This guide won't get into the details of setting up a specific gateway to work with an given PBX. There are lots of those out there. Once you've got a working connection, you need to define the IP address of the gateway in your Lync topology document. You define the gateway under the PSTN gateways node of your Lync site. A PSTN gateway needs to connect to a mediation pool, which is often collocated with the front-end Lync server role.
As followers of this blog may know, I am a big proponent of e.164 formatting for phone numbers. Ideally, all the phone numbers you define for Lync use - from the actual number assigned to an Enterprise Voice enabled user to the phone numbers listed in Active Directory - should be formatted in e.164 format. If your users have DIDs, then this should be straightforward. For users that only have extensions, you should use the format +<countrycode><officenumber>;ext=<extension>as explained in my blog post on Internal Extensions. Resist the temptation to use only the extension as the user's phone number.
As you transition to Lync, you should allow your Lync users to dial others using the methods they are familiar with. For most, this means dialing by extension. You will want to allow extension dialing in Lync with the least amount of administrative overhead as you migrate users from the legacy system to Lync.
You achieve this by creating normalization rules that translate extensions to full e.164 phone numbers and outbound translation rules that turn e.164 phone numbers BACK into extensions. An example with a company whose main number is +1 (212) 555-1111 that uses 3-digit extensions starting with 2 is below:
Normalization Rule: ^(2\d{2})$ --> +12125551111;ext=$1
Outbound Translation Rule: ^\+12125551111;ext=(2\d{2})$ --> $1
Sample scenario:
Dial 234 --> normalize to +12125551111;ext=234 --> strip to 234 --> send to PBX
You may wonder why go through the trouble of normalizing 3-digit extensions to e.164 when we just strip it back down to 3-digits at the gateway. A long time ago, I evangelized the reasons why you should use e.164 formatting for your user phone numbers. I won't rehash what was said there, but it suffices to say that e.164 formatting is the way to go in almost every situation. So, using the above example with +1 (212) 555-1111 as the main office number, assign phone numbers to your Lync users like this: tel:+12125551111;ext=201. If a Lync user dials 201, it will normalize to the full e.164 format, find a match in its database and ring the user.
If someone dials an extension that doesn't yet exist in Lync, say 299, it will normalize to e.164, fail to find a match in its database, and then route it out to the PBX after stripping it back down to 3-digits.
The Lync Dialing Rule Optimizer can help ease the workload involved in setting up this routing logic. Simply select the Use Extensions checkbox (coming soon), and enter up to 10 extension ranges. The Optimizer will take care of the rest, including proper ordering and placement of rules.
Migrating PBX Users to Lync
Following this generalized plan makes migrating users to Lync very simple:
- Enable user in Lync with the proper e.164 phone number. Lync-initiated calls to their extension should now be intercepted by Lync.
- Depending on the layout of your legacy PBX, you may just need to simply delete the users extension, and PBX-initiated calls to that number should default to routing out to the gateway. Other PBXs may require additional work to ensure calls to that specific user route to the gateway.
- Depending on the gateway, you may need to modify your PSTN-inbound rule to route inbound PSTN calls for that user to Lync. As mentioned earlier, some gateways can detect the user is enabled on Lync and route the call accordingly.
Links to my other posts in my Enterprise Voice Best Practices series:
E.164 Formatting
Normalization
Usages and Routes
Extensions
Friday, October 21, 2011
Lync Loses Connection Every 8min 28sec
If you enjoy CSI-like detective stories (and by CSI, I mean cheesy quips as he puts on his sunglasses, NOT this) centered around isoteric computer issues involving Lync, then you'll love this post. For the other 6.99999 billion people in the world, move along....nothing to see here.
Late last week, my Lync client on my main work desktop started acting oddly. Every so often, it would spontaneously lose its connection, log out, and re-login again - all within about 5-10 seconds. At first, I suspected a network problem. Running a steady ping against the Lync edge server showed a constant connection. I looked at the Lync servers for any potential issue, thinking it was something that could be affecting everybody, but all seemed well. It was late in the day on Friday, so I dealt with it like I deal with all my problems.....ignore it and hope it just goes away.
Monday morning - same thing. It was starting to get annoying. I'd be in the middle of an IM conversation, and BAM, log out and back in again. Audio calls were unaffected, except for the message about limited connectivity popping up. Weirdly enough, when I logged on via my laptop, the issue never came up, which lead me to believe it was a problem with my desktop computer. Even more weird was that if I logged onto another Lync account on the same pool via my desktop, the problem never came up.
The first thing I tried was to restart my computer. Didn't fix it. Then I exited Lync and deleted all my settings in my %userprofile%\AppData\Local\Microsoft\Communicator folder. No change in behaviour.
There were no relevant messages in the Event Log, even though Event Log logging was turned on. I decided to turn on detailed logging via Options - General - Turn on logging in Lync. You should only turn on this option when troubleshooting an issue, because it can take up a lot of disk space. Logs are stored in the %userprofile%\Tracing folder. The Communicator-uccapi-0.uccapilog is the log file to look at. This file will grow to about 50 MB before it rolls over into Communicator-uccapi-1.uccapilog and so on. It's Notepad-friendly.
Digging through the log, I focussed on the time where the issue arose. I started to notice a pattern. My client would lose its connection EXACTLY every 8 minutes 28 seconds. I racked my mind to think of what would be happening every 8:28, but nothing came to mind. I ripped out all the log data surrounding that time to try to find a pattern. This is the sequence that repeated every 8:28:
10/18/2011|12:23:30.119 1674:2350 INFO :: UCCP:ClientAllowedAuthProts0x10004
10/18/2011|12:23:30.120 1674:2350 INFO :: SIP_REGISTER::RefreshRegistration force(1),refreshSA(1),refreshRoute(0),state(2)
10/18/2011|12:23:30.120 1674:2350 INFO :: SIP_REGISTER:State (2) => (4)
10/18/2011|12:23:30.120 1674:2350 INFO :: SA(b0b8c38) Dropped
10/18/2011|12:23:30.120 1674:2350 INFO :: Out trxn corr-id (0CE823A8)
10/18/2011|12:23:30.127 1674:2350 INFO :: SignMsg:NoSA for request(ce823a8)
10/18/2011|12:23:30.127 1674:2350 INFO :: SignMsg: send request without signature for trans(ce823a8)
10/18/2011|12:23:30.127 1674:2350 INFO :: Trxn corr-id (0CE823A8), SIP msg corr-id (7aa8ef7f)
10/18/2011|12:23:30.127 1674:2350 INFO :: Sending Packet - 209.xx.xxx.xxx:443 (From Local Address: 10.0.0.2:55072) 793 bytes:
10/18/2011|12:23:30.127 1674:2350 INFO :: REGISTER sip:contoso.com SIP/2.0
Via: SIP/2.0/TLS 10.0.0.2:55072
The client would then try re-registering itself multiple times (about 10) for about 3-5 seconds, which would generate a SIP/2.0 401 Unauthorized from the server. Then, it would just log back in as if nothing ever happened.
It looked to me like the line that had SIP_REGISTER::RefreshRegistration force(1),refreshSA(1),refreshRoute(0),state(2) was the likely culprit, but I still had no idea why it was happening. I ran log captures on working machines and never saw that line appear anywhere else. Internet searches came up blank. I even ran traces from the front-end Lync server, which only showed me the multiple 401 Unauthorized messages it was returning to the client. No indication why it was not allowing me in.
I tried uninstalling and reinstalling Lync. Nope. I tried uninstalling and searching and deleting any trace of Lync in folders and the registry. I deleted any cached credentials in Windows via Credential Manager. Nope. In frustration, I even deleted my Lync account and re-created it. Nope.....Chuck Testa.
Then I tried creating a new local account on my desktop and logged into Lync. Great success!!! The problem was gone. However, I wasn't all that thrilled because I didn't want to go through the pain of moving all my profile data to a new account. Plus, it felt like giving up....kind of like when you re-install the OS to deal with an issue.
So, I reasoned that there must be something about my profile that was causing the issue. So, I logged back into my main account, deleted all the temp files in %userprofile%\TEMP, cleaned out my browser history and cache, and restarted. Amazingly, the problem was gone. It's been 3 days and my client has been working normally.
I'm not sure if it was cleaning out the TEMP folder or the IE cache that fixed the problem. Ideally, I should have tried one or the other first, but I was getting tired of troubleshooting by this point. If anybody has any insight as to what was really going on, please drop me a line.
Late last week, my Lync client on my main work desktop started acting oddly. Every so often, it would spontaneously lose its connection, log out, and re-login again - all within about 5-10 seconds. At first, I suspected a network problem. Running a steady ping against the Lync edge server showed a constant connection. I looked at the Lync servers for any potential issue, thinking it was something that could be affecting everybody, but all seemed well. It was late in the day on Friday, so I dealt with it like I deal with all my problems.....ignore it and hope it just goes away.
Monday morning - same thing. It was starting to get annoying. I'd be in the middle of an IM conversation, and BAM, log out and back in again. Audio calls were unaffected, except for the message about limited connectivity popping up. Weirdly enough, when I logged on via my laptop, the issue never came up, which lead me to believe it was a problem with my desktop computer. Even more weird was that if I logged onto another Lync account on the same pool via my desktop, the problem never came up.
The first thing I tried was to restart my computer. Didn't fix it. Then I exited Lync and deleted all my settings in my %userprofile%\AppData\Local\Microsoft\Communicator folder. No change in behaviour.
There were no relevant messages in the Event Log, even though Event Log logging was turned on. I decided to turn on detailed logging via Options - General - Turn on logging in Lync. You should only turn on this option when troubleshooting an issue, because it can take up a lot of disk space. Logs are stored in the %userprofile%\Tracing folder. The Communicator-uccapi-0.uccapilog is the log file to look at. This file will grow to about 50 MB before it rolls over into Communicator-uccapi-1.uccapilog and so on. It's Notepad-friendly.
Digging through the log, I focussed on the time where the issue arose. I started to notice a pattern. My client would lose its connection EXACTLY every 8 minutes 28 seconds. I racked my mind to think of what would be happening every 8:28, but nothing came to mind. I ripped out all the log data surrounding that time to try to find a pattern. This is the sequence that repeated every 8:28:
10/18/2011|12:23:30.119 1674:2350 INFO :: UCCP:ClientAllowedAuthProts0x10004
10/18/2011|12:23:30.120 1674:2350 INFO :: SIP_REGISTER::RefreshRegistration force(1),refreshSA(1),refreshRoute(0),state(2)
10/18/2011|12:23:30.120 1674:2350 INFO :: SIP_REGISTER:State (2) => (4)
10/18/2011|12:23:30.120 1674:2350 INFO :: SA(b0b8c38) Dropped
10/18/2011|12:23:30.120 1674:2350 INFO :: Out trxn corr-id (0CE823A8)
10/18/2011|12:23:30.127 1674:2350 INFO :: SignMsg:NoSA for request(ce823a8)
10/18/2011|12:23:30.127 1674:2350 INFO :: SignMsg: send request without signature for trans(ce823a8)
10/18/2011|12:23:30.127 1674:2350 INFO :: Trxn corr-id (0CE823A8), SIP msg corr-id (7aa8ef7f)
10/18/2011|12:23:30.127 1674:2350 INFO :: Sending Packet - 209.xx.xxx.xxx:443 (From Local Address: 10.0.0.2:55072) 793 bytes:
10/18/2011|12:23:30.127 1674:2350 INFO :: REGISTER sip:contoso.com SIP/2.0
Via: SIP/2.0/TLS 10.0.0.2:55072
The client would then try re-registering itself multiple times (about 10) for about 3-5 seconds, which would generate a SIP/2.0 401 Unauthorized from the server. Then, it would just log back in as if nothing ever happened.
It looked to me like the line that had SIP_REGISTER::RefreshRegistration force(1),refreshSA(1),refreshRoute(0),state(2) was the likely culprit, but I still had no idea why it was happening. I ran log captures on working machines and never saw that line appear anywhere else. Internet searches came up blank. I even ran traces from the front-end Lync server, which only showed me the multiple 401 Unauthorized messages it was returning to the client. No indication why it was not allowing me in.
I tried uninstalling and reinstalling Lync. Nope. I tried uninstalling and searching and deleting any trace of Lync in folders and the registry. I deleted any cached credentials in Windows via Credential Manager. Nope. In frustration, I even deleted my Lync account and re-created it. Nope.....Chuck Testa.
Then I tried creating a new local account on my desktop and logged into Lync. Great success!!! The problem was gone. However, I wasn't all that thrilled because I didn't want to go through the pain of moving all my profile data to a new account. Plus, it felt like giving up....kind of like when you re-install the OS to deal with an issue.
So, I reasoned that there must be something about my profile that was causing the issue. So, I logged back into my main account, deleted all the temp files in %userprofile%\TEMP, cleaned out my browser history and cache, and restarted. Amazingly, the problem was gone. It's been 3 days and my client has been working normally.
I'm not sure if it was cleaning out the TEMP folder or the IE cache that fixed the problem. Ideally, I should have tried one or the other first, but I was getting tired of troubleshooting by this point. If anybody has any insight as to what was really going on, please drop me a line.
Monday, October 17, 2011
Lync and Skype: What's Next?
As posted in many places on the net, Microsoft's acquisition of Skype is complete. There has been a lot of speculation as to what this means for Lync. I'm going to add my 2-cents worth, just to see if we can get some discussion going.
In the short term, I don't think you're going to see much difference in the way either platform is marketed. Skype already has a huge user base, and people are likely nervous about what MS will do. I'll bet that you will still be able to download Skype and use it as you always did. On the Lync side, I think you will see an option to add Skype as a 3rd party public provider, just like you can already with MSN/Yahoo!/AOL. This might arrive with the rumoured Lync service pack. If it doesn't come with Lync SP1, then we'll probably have to wait until the next release of Lync.
I think you'll see the biggest Skype-Lync integration will come with Lync "15", but not with the on-premises version. The on-premises version will likely keep Skype as an optional public provider, which will allow Lync to integrate with not only Skype, but by extension, other platforms that has Skype connectors. This could be the universal connector that current IP-PBXs can use to connect to Lync and other disparate phone systems. This could help companies save money, by providing a communications channel that doesn't rely on the PSTN.
I predict that you won't see Skype integration at the Lync "15" Online level at all. I think Skype will melt into the background as the base provider for Lync Online's worldwide PSTN telephony integration. The current version of Lync Online does not support PSTN connectivity as of yet. For Microsoft to provide the centralized support for PSTN connectivity it needs to do for a worldwide user base, Skype is an obvious choice. Skype already has a worldwide presence for users to obtain local PSTN phone numbers. If Lync Online can integrate Skype in this manner, then it will vault Microsoft well ahead of the competition to provide corporations worldwide with a secure, easy-to-use and scalable online solution for all their telephony needs.
Companies will be able to sign on with Lync Online and be able to provision users with PSTN numbers almost anywhere in the world. Lync will be a better choice for corporations, because it can be centrally controlled, managed, and users will be able to use their existing corporate credentials. This is a much more palatable solution than Skype, which is geared more towards the end-user or SMB, and isn't controllable by corporate IT.
Microsoft will also benefit financially by siphoning off those corporate users who currently use Skype because there's no suitable corporate alternative. By bringing them into the Lync Online fold (hopefully with as little migration pain as possible), Microsoft will be able to realize a much higher revenue stream per user, compared to Skype.
What do you think? Any other thoughts on the matter? Drop a comment.
In the short term, I don't think you're going to see much difference in the way either platform is marketed. Skype already has a huge user base, and people are likely nervous about what MS will do. I'll bet that you will still be able to download Skype and use it as you always did. On the Lync side, I think you will see an option to add Skype as a 3rd party public provider, just like you can already with MSN/Yahoo!/AOL. This might arrive with the rumoured Lync service pack. If it doesn't come with Lync SP1, then we'll probably have to wait until the next release of Lync.
I think you'll see the biggest Skype-Lync integration will come with Lync "15", but not with the on-premises version. The on-premises version will likely keep Skype as an optional public provider, which will allow Lync to integrate with not only Skype, but by extension, other platforms that has Skype connectors. This could be the universal connector that current IP-PBXs can use to connect to Lync and other disparate phone systems. This could help companies save money, by providing a communications channel that doesn't rely on the PSTN.
I predict that you won't see Skype integration at the Lync "15" Online level at all. I think Skype will melt into the background as the base provider for Lync Online's worldwide PSTN telephony integration. The current version of Lync Online does not support PSTN connectivity as of yet. For Microsoft to provide the centralized support for PSTN connectivity it needs to do for a worldwide user base, Skype is an obvious choice. Skype already has a worldwide presence for users to obtain local PSTN phone numbers. If Lync Online can integrate Skype in this manner, then it will vault Microsoft well ahead of the competition to provide corporations worldwide with a secure, easy-to-use and scalable online solution for all their telephony needs.
Companies will be able to sign on with Lync Online and be able to provision users with PSTN numbers almost anywhere in the world. Lync will be a better choice for corporations, because it can be centrally controlled, managed, and users will be able to use their existing corporate credentials. This is a much more palatable solution than Skype, which is geared more towards the end-user or SMB, and isn't controllable by corporate IT.
Microsoft will also benefit financially by siphoning off those corporate users who currently use Skype because there's no suitable corporate alternative. By bringing them into the Lync Online fold (hopefully with as little migration pain as possible), Microsoft will be able to realize a much higher revenue stream per user, compared to Skype.
What do you think? Any other thoughts on the matter? Drop a comment.
Friday, October 14, 2011
IETF RFCs Supported by Lync
I was responding to an RFP, and one of the questions was a list of the IETF RFCs that Lync supported. There didn't seem to be a central list anywhere, so I compiled a list myself. If you're in a similar situation where you need this kind of info, hopefully this will help! Much of this was taken from Microsoft's official protocol documentation at http://msdn.microsoft.com/en-us/library/cc307282(v=office.12).aspx. If the RFC was listed in the Normative References section, I added it here. The RFC may not be followed to the letter, and may have been added on to as well.
Any additions or corrections would be greatly appreciated.
Any additions or corrections would be greatly appreciated.
| RFC # | Description | Relates To | Link |
| RFC 1321 | The MD5 Message-Digest Algorithm | Security | http://tools.ietf.org/html/rfc1321 |
| RFC 2045 | Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies | Conferencing | http://tools.ietf.org/html/rfc2045 |
| RFC 2104 | HMAC: Keyed-Hashing for Message Authentication | Security | http://tools.ietf.org/html/rfc2104 |
| RFC 2111 | Content-ID and Message-ID Uniform Resource Locators | Telephony | http://tools.ietf.org/html/rfc2111 |
| RFC 2118 | Microsoft Point-To-Point Compression (MPPC) Protocol | Base | http://tools.ietf.org/html/rfc2118 |
| RFC 2132 | DHCP Options and BOOTP Vendor Extensions | Base | http://tools.ietf.org/html/rfc2132 |
| RFC 2141 | URN Syntax | Base | http://tools.ietf.org/html/rfc2141 |
| RFC 2190 | RTP Payload Format for H.263 Video Streams | Media | http://tools.ietf.org/html/rfc2190 |
| RFC 2198 | RTP Payload for Redundant Audio Data | Media | http://tools.ietf.org/html/rfc2198 |
| RFC 2246 | The TLS Protocol Version 1.0 | Security | http://tools.ietf.org/html/rfc2246 |
| RFC 2315 | PKCS #7: Cryptographic Message Syntax Version 1.5 | Security | http://tools.ietf.org/html/rfc2315 |
| RFC 2459 | Internet X.509 Public Key Infrastructure Certificate and CRL Profile | Security | http://tools.ietf.org/html/rfc2459 |
| RFC 2474 | QoS Differentiated Services | Network | http://tools.ietf.org/html/rfc2474 |
| RFC 2716 | PPP EAP TLS Authentication Protocol | Security | http://tools.ietf.org/html/rfc2716 |
| RFC 2743 | Generic Security Service Application Program Interface v2, Update 1 | Security | http://tools.ietf.org/html/rfc2743 |
| RFC 2782 | A DNS RR for specifying the location of services (DNS SRV) | Base | http://tools.ietf.org/html/rfc2782 |
| RFC 2818 | HTTP Over TLS | Base | http://tools.ietf.org/html/rfc2818 |
| RFC 2976 | SIP INFO Method | Base | http://tools.ietf.org/html/rfc2976 |
| RFC 2986 | PKCS#10: Certificate Request Syntax Specification | Security | http://tools.ietf.org/html/rfc2986 |
| RFC 3261 | Session Initiation Protocol (SIP) | Base | http://tools.ietf.org/html/rfc3261 |
| RFC 3262 | Reliability of Provisional Responses in SIP | Base | http://tools.ietf.org/html/rfc3262 |
| RFC 3264 | An Offer/Answer Model with the Session Description Protocol (SDP) | Conferencing | http://tools.ietf.org/html/rfc3264 |
| RFC 3265 | SIP-Specific Event Notification | Base | http://tools.ietf.org/html/rfc3265 |
| RFC 3311 | SIP UPDATE Method | Base | http://tools.ietf.org/html/rfc3311 |
| RFC 3323 | A Privacy Mechanism for the Session Initiation Protocol (SIP) | Base | http://tools.ietf.org/html/rfc3323 |
| RFC 3325 | Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks | Telephony | http://tools.ietf.org/html/rfc3325 |
| RFC 3326 | The REASON Header Field for SIP | Base | http://tools.ietf.org/html/rfc3326 |
| RFC 3327 | SIP Extension Header Field for Registering Non-Adjacent Contacts | Base | http://tools.ietf.org/html/rfc3327 |
| RFC 3350 | Real-time protocol for media | Media | http://tools.ietf.org/html/rfc3350 |
| RFC 3361 | DHCP option for SIP servers | Telephony | http://tools.ietf.org/html/rfc3361 |
| RFC 3389 | Real-Time Transport Protocol (RTP) Payload for Comfort Noise (CN) | Telephony | http://tools.ietf.org/html/rfc3389 |
| RFC 3420 | Internet Media Type message/sipfrag | Media | http://tools.ietf.org/html/rfc3420 |
| RFC 3428 | Session Initiation Protocol (SIP) Extension for Instant Messaging | Base | http://tools.ietf.org/html/rfc3428 |
| RFC 3515 | SIP REFER Method | Base | http://tools.ietf.org/html/rfc3515 |
| RFC 3550 | RTP: A Transport Protocol for Real-Time Applications | Media | http://tools.ietf.org/html/rfc3550 |
| RFC 3551 | RTP Profile for Audio and Video Conferences with Minimal Control | Media | http://tools.ietf.org/html/rfc3551 |
| RFC 3581 | SIP Symmetric Response Routing | Base | http://tools.ietf.org/html/rfc3581 |
| RFC 3605 | Real Time Control Protocol (RTCP) Attribute in Session Description Protocol (SDP) | Media | http://tools.ietf.org/html/rfc3605 |
| RFC 3611 | RTP Control Protocol Extended Reports (RTCP XR) | Media | http://tools.ietf.org/html/rfc3611 |
| RFC 3629 | UTF-8, A Transformation Format of ISO 10646 | Conferencing | http://tools.ietf.org/html/rfc3629 |
| RFC 3711 | Secure real-time protocol for media | Media | http://tools.ietf.org/html/rfc3711 |
| RFC 3761 | Telephone Number Mapping (ENUM) | Telephony | http://tools.ietf.org/html/rfc3761 |
| RFC 3840 | Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) | Base | http://tools.ietf.org/html/rfc3840 |
| RFC 3842 | A Message Summary and Message Waiting Indication Event | Telephony | http://tools.ietf.org/html/rfc3842 |
| RFC 3852 | Cryptographic Message Syntax (CMS) | Security | http://tools.ietf.org/html/rfc3852 |
| RFC 3863 | Presence Information Data Format (PIDF) | Base | http://tools.ietf.org/html/rfc3863 |
| RFC 3891 | SIP REPLACES Header | Telephony | http://tools.ietf.org/html/rfc3891 |
| RFC 3892 | SIP Referred-by Mechanism | Telephony | http://tools.ietf.org/html/rfc3892 |
| RFC 3960 | Early Media and Ringing Tone Generation for SIP | Telephony | http://tools.ietf.org/html/rfc3960 |
| RFC 3966 | Tel URI for Telephone Numbers | Telephony | http://tools.ietf.org/html/rfc3966 |
| RFC 3986 | Uniform Resource Identifier (URI): Generic Syntax | Base | http://tools.ietf.org/html/rfc3986 |
| RFC 4028 | Session Timers in the Session Initiation Protocol | Conferencing | http://tools.ietf.org/html/rfc4028 |
| RFC 4119 | A Presence-based GEOPRIV Location Object Format | e911 | http://tools.ietf.org/html/rfc4119 |
| RFC 4120 | The Kerberos Network Authentication Service (V5) | Security | http://tools.ietf.org/html/rfc4120 |
| RFC 4121 | The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2 | Security | http://tools.ietf.org/html/rfc4121 |
| RFC 4122 | A Universally Unique Identifier (UUID) URN Namespace | Base | http://tools.ietf.org/html/rfc4122 |
| RFC 4145 | TCP-Based Media Transport in the Session Description Protocol (SDP) | Media | http://tools.ietf.org/html/rfc4145 |
| RFC 4235 | An INVITE-Initiated Dialog Event Package for SIP | Base | http://tools.ietf.org/html/rfc4235 |
| RFC 4244 | An Extension to SIP for Request History Information | Base | http://tools.ietf.org/html/rfc4244 |
| RFC 4353 | A Framework for Conferencing with the Session Initiation Protocol (SIP) | Conferencing | http://tools.ietf.org/html/rfc4353 |
| RFC 4480 | RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) | Base | http://tools.ietf.org/html/rfc4480 |
| RFC 4559 | SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows | Security | http://tools.ietf.org/html/rfc4559 |
| RFC 4566 | SDP: Session Description Protocol | Media | http://tools.ietf.org/html/rfc4566 |
| RFC 4568 | Session Description Protocol (SDP) Security Descriptions for Media Streams | Media | http://tools.ietf.org/html/rfc4568 |
| RFC 4571 | Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport | Media | http://tools.ietf.org/html/rfc4571 |
| RFC 4574 | The Session Description Protocol (SDP) Label Attribute | Conferencing | http://tools.ietf.org/html/rfc4574 |
| RFC 4575 | A Session Initiation Protocol (SIP) Event Package for Conference State | Conferencing | http://tools.ietf.org/html/rfc4575 |
| RFC 4733 | RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals | Telephony | http://tools.ietf.org/html/rfc4733 |
| RFC 5139 | Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO) | e911 | http://tools.ietf.org/html/rfc5139 |
| RFC 5245 | Interactive Connectivity Establishment (ICE) | Media | http://tools.ietf.org/html/rfc5245 |
| RFC 5280 | Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile | Security | http://tools.ietf.org/html/rfc5280 |
| RFC 5389 | Session Traversal Utilities for NAT (STUN) | Media | http://tools.ietf.org/html/rfc5389 |
| RFC 5652 | Cryptographic Message Syntax (CMS) | Security | http://tools.ietf.org/html/rfc5652 |
| RFC 5766 | Traversal Using Relays around NAT (TURN) | Media | http://tools.ietf.org/html/rfc5766 |
| RFC 6797 | HTTP Strict Transport Security (HSTS) | Security | http://tools.ietf.org/html/rfc6797 |
Subscribe to:
Posts (Atom)