By: Matthew McGillen
Posted:
December 13, 2011 at 11:58 AM
Sunday night at about 7pm Chicago time, I downloaded and installed the Lync Mobile client for Windows Phone 7. In a sad reflection on what passes for excitement in my life, I had been checking about a few times an hour Saturday and Sunday; I probably hit the App Marketplace 50 times on Sunday before striking gold.
I quickly sent a message to the rest of the PointBridge UC team and a bunch of us began fiddling around with the new client.
First I should mention: you need to read and follow the Lync Server Mobility guide exactly to the letter. You cannot just install the Lync client – you need to have patched the Lync servers, added the mobility and autodiscover services, re-configured your Lync cert & created a new ISA/TMG rule. There are a lot of instructions and you really can't afford to skim. More about this later.
I've had a full day use the client and test things out. Here's what I've gleaned so far:
Aesthetics
- The interface is nice. It's a good looking client that has a consistent look carried over from the desktop client.
- I like the integration with the mobile OS – especially the "live tile" concept. I have the Lync client pinned to the main screen on my phone. When I have a new IM sent to me, the tile shows the number of new notifications / missed notifications
- The threaded IM view is nice. The conversations are easy to read and easy to follow.
- Using groups (and, my favorite, e-mail distribution groups") provides for a nice way to easily view contacts. Having one giant list of 400 people is not conducive to mobile usage.
- The pivot, or "swipe", to see all current conversations is fantastic. This solves an age-old problem of how to organize many conversations with limited real estate.
- People's pictures don't appear in the client – unless the pictures have been uploaded to AD. For me this means 99% of the pictures don't appear.
It's obvious a lot of time and effort went into the UI. This is a nice Windows Phone 7 app that feels "right".
Features
- IM & Presence works well, as expected
- 1-touch joining conference calls also works well
- Managing a roster for
- "Call from work" is nice – calls from your mobile
- No VOIP
- No Video
- No desktop sharing
This is the area where I was hoping for more. The IM and Presence is great & I am happy to have the one-touch join. The lack of voice and video was expected, but nonetheless too bad. There is a "workaround" in that I can call a contact from my Lync Mobile client, but it really just initiates a call from Lync server to my cell and bridges me in with my contact. This is ok, but not VoIP.
Performance
- The client itself is responsive, the interface is pretty snappy.
- I ran the client for about 24 hours straight. After regular usage (listened to a podcast, replied to several e-mails, web browsing, a couple phone calls) on both Wi-Fi and cellular networks for 23 hours, I finally ran out of battery. This is a huge improvement over the old mobile client.
- The client does run in the background & doesn't seem to be draining the battery much if at all. I'm sure I'll have more info after a full week, but so far so good. I am attributing this to the brand-new support of push notifications.
Performance is where the Lync Mobile client has made the biggest improvements. While the features have not advanced much, this is a VERY usable client. It is reliable, easy to use, and it won't kill your battery.
Conclusions
The new Lync Mobile client is an uber-awesome IM platform. You can really keep this service running on your phone at all times – which makes it different from almost any other IM-like application we'd seen to date. Status updates happen quickly, threads are easy to follow. This is EXACTLY what a mobile IM client should be & goes some distance towards making text messaging in the enterprise irrelevant.
However – I truly was hoping that it would go beyond that and be what a mobile UC client should be. Not just mobile IM. I sent a request to a couple folks in Redmond to see if they could provide some insight here. The features of the new client are exactly like the features of the old OCS mobile client. Many of the people I've talked to at various customers / Microsoft Partners feel the same way. It's been a year in development, and the end-user functionality doesn't seem any different than what we had for all those years with OCS. I haven't had a chance to converse with any of the Redmond folks to go over this in detail yet, but I would like to better understand what the thinking is. I hope to talk with them soon and blog about some of their insights. Until then you are stuck with my conjecture:
Why did it take a year to essentially provide the same features of the old client? I can think of a three important factors
- Microsoft has re-written the mobile underpinnings of Lync, which is no small feat. The new mobile client uses web calls rather than emulate the Lync fat client. This has obvious benefits for scalability and performance. I can see this is laying the foundation for future, proper mobile infrastructure. Xync is a much more feature-rich client – but it's a mobile port of the Lync fat client. This may not hold up under the stress of 10,000 users with mobile devices.
- Microsoft wrote not just a Windows Phone 7 client, but an iPhone, Android, and Symbian client. This is another huge departure from the old way of doing things. This wasn't just a dev effort for Windows phones.
- Most importantly: Xync or other rich 3rd party clients require a LOT of smarts in the mobile client itself. The MS Lync client is probably pretty dumb and lightweight, relying on the server to do the heavy lifting. The future of mobility is having thin, light clients (almost "wrapper-like") that are easy to make for all the mobile platforms & leave all the hard core development to the web service. HTML5 wrappers may well kill the app – according to this publication from AT Kearney.
I really did want to see more feature parity with the desktop client; the mobile world is a demanding world. But I think if given the choice between throwing out a feature-rich mobile client and properly laying the groundwork for a real mobile strategy, Microsoft probably made the right decision. This goes a long way to explaining why organizations had to patch Lync servers, add new services, update certs, update publishing rules etc. This wasn't just about getting a client out, it was about adjusting the Lync architecture to account for mobility – both now and in the future.
By: Matthew McGillen
Posted:
October 18, 2011 at 11:15 AMAs most people will have heard, Microsoft officially acquired Skype last week. There are precious few details about what the end-state is going to look like with Lync and Skype integrated; or even what Microsoft really plans to do with Skype. With so little information available directly from either party, I decided to read between the lines and try to draw some conclusions on my own.
Microsoft's Strategic Direction
With an $8.5 billion dollar price tag, Skype was the largest acquisitions ever made by Microsoft. Ultimately Microsoft is going to want to make their money back on this purchase of Skype, that's a given. But the question is how will they do it? One thing we know is that it won't do it by becoming a "PBX vendor". I can deduce this because, according to a Wall Street Journal article, the communications giant, Avaya, is valued at around $5 billion. By my reckoning, for almost half the price of Skype, Microsoft could have tried to acquire the second-leading PBX market share leader (Avaya) instead of Skype. Or heck, MS could have picked up all of Nortel for a scant $900 Million back when they were on the auction block. Oh, and in case you were wondering: Cisco's valuation of $94 billion dollars probably disqualified them from Mr. Ballmer's shopping list!
This should tell you about Microsoft's strategic direction; they aren't interested in just making and reselling phones or phone systems. Microsoft is betting on the future. This wasn't a short-term decision. It may not have even turned out to be a medium-term decision. But you have to believe that the folks in Redmond saw something special in Skype's future that justified the price. What was it that MS saw? They seem to think that the future involves a global application for voice, video, and data sharing. How does Microsoft deliver on this promise? Looking into any cheap crystal ball will give you the answer: it's cloudy.
Software-Powered Cloud Services
Two of the biggest buzzes in all of technology right now are "The Cloud" and "Consumerization of IT". I think Skype hits both of these; today Skype is nothing more than a voice/video cloud service for consumers.
Microsoft's stated vision is to deliver software via cloud, and they have been doing so for a few years with Office 365 and its predecessors. But one of the major gaps yet to be bridged by Office 365 is giving customers a cloud-based equivalent of Lync's voice and video capabilities. In many respects, Skype is already doing this, and doing it well. Perhaps with a little tweaking, Microsoft will be able to leverage the strengths of both Office 365 and Skype. The well managed infrastructure comes from Office 365, the seamless delivery of voice and video comes from Skype. Everyone lives happily ever after.
The other major achievement of Skype's is to have successfully "consumerized" UC. Skype is designed to please consumers. It's easy to use, intuitive, cheap, and effective. Think about the Skype business model: No phone system, no handset, no expensive video units, a free client, BYOD (bring your own device), no boring classroom training. Skype just sells you the service – and you do the rest. People seem to like this and perhaps are starting to think it's odd that they have better communications tools available at home than they do in the workplace. This plays right into Microsoft's strengths of focusing on end-user software and services and letting someone else worry about the hardware.
With Skype potentially integrated with the enterprise-grade service of Office 365, we could see a cloud-based unified communications experience for home and business users alike. Given the ubiquity of Skype and Microsoft together, this could get interesting.
UC-topian Vision of the Future
Imagine for a minute that Lync and Skype are integrated seamlessly… businesses using Lync for communications, consumers using Skype. In this utopian vision, users of either system could contact each other with voice, video, IM and desktop sharing and all calls between services would be free. Skype/Lync clients are available on any computer, mobile device, or tablet. Anyone could communicate with anyone else in the world using just about any modality. VoIP calls from mobile devices connect to friends, family, and co-workers on which ever device is handy to them.
In this scenario – would you ever pick up a phone and dial a phone number again? Assuming calls between Lync and Skype clients remain free, the answer is a resounding "Heck, No!" You would use your work PC at work, your home computer at home, and your mobile device for everything in between. You would use ZERO minutes on your cell phone and ZERO minutes on your home phone.
But could you really connect with everyone in your life? According to the official MS press release, Skype is aiming to have 1 billion users: "By bringing together the best of Microsoft and the best of Skype, we are committed to empowering consumers and businesses around the globe to connect in new ways," Bates said. "Together, we will be able to accelerate Skype's goal to reach 1 billion users daily," (emphasis mine). Factor in the Skype/Facebook agreement and a billion users seems pretty reachable.
In 2010, MS's Windows Live Messenger boasted 300 Million users. I don't believe MS publishes data on Lync/OCS users, but you get the picture quickly when you start adding Skype users + MS users. Maybe a quarter of the world as of right now? Maybe total world domination by 2020? (evil laugh mine).
Reality Check and Conclusion
It's not unrealistic to imagine Microsoft/Skype ushering in a new universal way to communicate globally that connects literally everyone. Like I said before, I have to believe that Microsoft is looking to make their money back and then some on this Skype deal. Relegating the traditional phone networks to the dustbin – now that should be worth at least $8.5 billion.
But I do think it is useful to connect the dots of Microsoft's stated vision ("to the cloud!") and their decision to shell out record-breaking cash for Skype. We'll soon hear more about what is really going on. But for now, reading between the lines leads me to believe that the possibilities are nothing short of world-changing.
But in reality, I know it's way too early to declare the PSTN dead. Heck, Lync and Skype don't even talk to each other today. We could be looking at many, many years before we see the true potential realized. I also realize that I'm open to the criticism that I may be over-eager to see something that justifies my existence. A friend of mine chided me when I shared my crazy future vision with him. He told me, "Yeah, and I was just as sure in 1999 that SIP trunking would end the PSTN, too." OK, message received. But it is fun to speculate.
By: Matthew McGillen
Posted:
May 13, 2011 at 3:03 PMExchange 2010 Unified Messaging is a great voicemail solution, especially for anyone with SIP-compliant PBX like Cisco or Avaya. At PointBridge we've had good success migrating people off Cisco Unity in particular. In fact, we recently migrated a 2000-user customer from Unity to Exchange UM, cutting everyone over in a single night. The project was a huge success, but along the way we ran into something interesting with Exchange UM and the G729 codec: Microsoft doesn't support it.
Background
Exchange UM integrates with Cisco Call Manager using SIP trunking. The SIP trunking provides the signaling for calls that are routed from the Cisco phone system into Exchange UM servers. This SIP signaling goes directly between the Cisco Call Manager servers and the Exchange UM servers. It's also possible to configure the voice traffic to also go through the Call Manager and go directly to the Exchange UM server. But this only works if you are using G711 as your voice codec. Because…. Exchange 2010 UM only supports the G711 codec. If you are using G729 Exchange UM will not answer your calls, you will get fast busy. Doh.
If this is the case for you, you have 2 real options, detailed in the sections below:
1 - Just Use G711 between all remote sites and Exchange UM
You can just configure a new region in CCM for your Exchange UM SIP trunk. Then you make sure that all calls from any other remote site regions to the Exchange 2010 SIP trunk uses G711. In this case:
- Call comes in to the remote site
- Gateway strips the number down to the CCM extension
- CCM sets up a SIP call between Exchange UM and CCM
- Voice traffic passes from the Gateway to the CCM, then to the Exchange UM server. G711 across the board.
Pros:
- No hardware transcoding required
- Simple setup
Con:
- G711 uses up more bandwidth – you may oversubscribe your remote site links
Don't underestimate the con, even though it's only a single con. Let's say you have a 356k link (yeah – they still exist!). And let's say you have a CCM "location" configured that allows half of the available bandwidth (180k) for voice calls. With G729, that gets you 6 calls (roughly 30k per call). But if you are using G711 (roughly 80k per call) for voicemail between that site and Exchange UM, and you have 2 people checking their Voicemail at once: no more calls will be allowed between that site and anywhere in the network. So it is a pretty big deal.
2 - Use G729 for calls, but transcode calls to Exchange UM
In many Cisco IPT deployments with several remote locations, calls are often made using the lower-bandwidth G729 codec. As I mentioned earlier: Exchange UM will not be able to handle these calls; they must be first transcoded from G729 to G711. To add to your misery, Cisco Call Manager servers are not capable of transcoding; only hardware-based resources can transcode. DSP (Digital Signal Processing) modules in a Cisco router are the most common transcoding resources.
This will work well – but you will be limited by the amount of DSP resources you have to transcode the calls. If you have enough resources to transcode 12 calls, then you can only have 12 simultaneous calls from CCM into Exchange UM.
To get this to work, you need to make sure you have plenty of DSPs to as transcoding resources. Then you assign those to your SIP Trunk's Media Resource Group. Once you've done this, the call flow looks like this:
- Call comes in to the remote site
- Gateway strips the number down to the CCM extension
- CCM sets up a SIP call between Exchange UM and CCM
- Voice traffic passes from the Remote gateway to the gateway in the datacenter, which transcodes from G729 to G711 for the leg to the Exchange UM server
This assumes that you have a Cisco gateway with spare DSPs in your datacenter. If you don't have extra DSPs, you are going to need to buy additional modules to use for transcoding.
Pro:
- You can use your low-bandwidth codec everywhere.
Con:
- You may need to buy additional DSP resources to allow for session transcoding.
(Non) Option 3 – use DSP resources in remote site routers
You may be thinking to yourself: "ha! There's another option you've overlooked; use more DSPs in your remote site routers". Well, I've tried this one too. And it kinda sorta works. You can get more calls through to Exchange UM if you allocate DSP transcoding resources from remote site routers. I tried it and it works. But here's the issue. Let's say you have 10 remote sites and you allocate 12 DSPs from each site. You have to stick them all in the same media resource group. Meaning you don't have any way to assign "Chicago DSPs" to just Chicago VM calls. You could end up with a call coming in the Chicago gateway & routing to voicemail, but getting transcoded by the Detroit router. That means the call goes from Chicago to Detroit then down to your datacenter and into Exchange.
In short: you generally want to keep your DSPs close to your Exchange UM servers to avoid burning bandwidth between sites. So this is an option, but it's highly not recommended.
Real life experience
With the 2000 user Unity to Exchange UM migration I mentioned at the beginning, we saw this happen. They had a single Cisco voice gateway in their main datacenter where Exchange was located. It only had enough transcoding resources to allow about 20 phone calls through to Exchange UM. We ended up stuffing a bunch of spare DSP modules they had into another router in the data center. We assigned all those DSP transcoding resources to the Media Resource Group for our Exchange UM SIP trunk. This increased capacity to over 100 calls, which is what we wanted.
The 20 calls would have most likely satisfy the day-to-day requirements of the busy organization. However, it did not account for periods of high usage. For example: a company-wide voicemail being accessed and retrieved by many users at once would have likely overloaded the router's capacity. To ensure the system had all required capacity, we added additional transcoding resources to convert an additional 96 calls from G729 to G711.
It is worth noting that the reason for the diminished capacity was solely due to the widespread use of G729 in the environment combined with Exchange 2010's lack of native support for G729. If G711 were used throughout the network, no transcoding resources would be required. In that case, capacity would have been limited only by the Exchange UM servers themselves: approximately 200 calls.
By: Matthew McGillen
Posted:
May 10, 2011 at 1:36 PM
One of the very useful new features of Lync 2010 Phone Edition is support for LLDP (Link Layer Discovery Protocol) to allow phones to receive configuration information from the switches they plug into. If you have any experience with Cisco IP Telephony, you know that Cisco Discovery Protocol (CDP) is used for similar purposes to assign voice traffic to a separate VLAN. This works great, but really only with devices (like Cisco phones) that speak CDP.
LLDP is an open standard that's been evolving over the years. I'm glad that Microsoft has chosen to comply with it for Lync Phone edition. Eventually LLDP will be used by the Lync soft clients on PCs – however thanks to a bug or some other limitation, LLDP doesn't quite work in that regard yet. Nonetheless, I have found LLDP to work pretty well with the Lync Phone edition and Cisco switches.
However – I have identified a bug, confirmed by Microsoft: you can't use LLDP to set a VLAN higher than 512 with Lync Phone Edition.
When you use LLDP to assign a voice VLAN to phones, you set the configuration on the switch itself. Below is what you configure on a Cisco switch:
(Global command)
LLDP run
(interface-specific command)
interface FastEthernet1/0/1
switchport access vlan 600
switchport mode access
switchport voice vlan 700
That's it. When an LLDP-compliant device plugs in, the Cisco switch will tell it to use VLAN ID 700. However the Lync Phone edition, while it processes the VLAN 700 tag, it just won't assign it to the phone. VLANs 1-512: fine. VLANs 513 and up: no go.
Doing some reading on the LLDP spec, the VLAN ID is a 2-octet field. 2 octets should yield a max of 65,000+ for the VLAN ID. Even if it were only 12 useable bits to account for padding, that would still get us to 4096 as the max. The limit of 512 only makes sense if it were only using 9 bits total. So there's the issue, we need Lync Phone edition to use more than 9 bits for VLAN ID.
As I mentioned, this is a confirmed bug and should be addressed soon with a Cumulative Update.
By: Matthew McGillen
Posted:
March 4, 2011 at 10:51 AMI recently visited a client who was having a miserable time getting the Lync Central Management Store database created during the Topology publishing process. They kept seeing errors similar to below:
Error: Script failed (code "ERROR_CREATE_DB") when installing "CentralMgmtStore" on "lyncserver.company.com". For details, see the following log file: "C:\Users\adminacct\AppData\Local\Temp\Create-CentralMgmtStore-lyncserver.company.com-[2011_01_03][10_32_38].log" 1/3/2011 10:32:38 AM Error
Error: An error occurred: "Microsoft.Rtc.Common.Data.SqlConnectionException" "Cannot open database "xds" requested by the login. The login failed.
Login failed for user 'DOMAIN\adminacct'."
There are LOTS of similar errors out there that people have encountered, unfortunately none applied to me. But I thought I'd put this handy little checklist together for anyone else who runs into this:
- Checked to make sure the account had correct permission on the SQL server (technet)
- Made sure that port 1433 was reachable on the SQL server (kb article)
- Tried removing and re-installing Lync components on the front end (Mike Stacy)
- Didn't see errors related to packets on the SQL server (Terrence Luk)
- Made sure that SQL was the right version (OCSPedia)
As it turned out, it was none of the above. But it was a good exercise going through and double-checking everything. My issue was more obscure: the default size of the model DB in SQL was set to 25 MB. Which seemed reasonable enough to me. However, the Lync DB Create process tries to create the CMS database with a size of 8 MB. And if the default size in the model DB is greater than 8 MB… you lose!
I found this kb article and followed the instructions to shrink the model DB size down to 2MB. It worked & saved the day.
|
|
|
|
 |
|
|
|
Practice Manager - Unified CommunicationsMatt McGillen is the practice manager for Unified Communications at PointBridge. He has over 10 years of IT consulting experience, focusing mainly on the government, legal, financial and health care s... [more]
|
|
|
|
|
|