Microsoft Copilot is all around...

  As the debut of Microsoft 365 Copilot approaches, there are a lot of Copilot features set to be introduced across the Microsoft 365 ecosystem. Here are a few noteworthy additions: Microsoft has unveiled a series of innovative features in the upcoming releases of Windows 11, some of them are already released, and some are currently available in preview builds. The Windows 11 Copilot, conveniently located in the taskbar, eliminates the need to open your Edge browser. It is seamlessly integrated with Bing Enterprise Chat (BEC) and ChatGPT, making it really easy to get started on your creative journey. Included in Windows 11 is the new co-creator feature in Paint. This feature, also in preview, is integrated with DALL-E and provides a swift and straightforward method for creating illustrations and images. If you possess a knack for crafting descriptions, you can generate quite impressive imagery. Another AI-powered feature is image creation directly from BEC. This feature, also integrate

Lync in coexistence with CUCM part 3 (pro's and con's)

Now then, after looking at two ways of integrating CUCM and Lync, let's discuss some of the alternatives I have not covered, the different scenarios and some pro's and con's of the implementations.

There are of course other ways to create an integration between CUCM and Lync. One of them is to install a CUPS (Cisco Unified Presence Server) in the CUCM environment, and set up a federation. This however; Can not be done if and when the CUCM has an integration with AD (same ad as Lync), or if they share the same domain name space. Also bear in mind, you still need an enterprise voice solution for those users residing on Lync. Having two different presence systems might also be an administrative burden, and quite difficult to maintain.

Another way to do an integration, is to use the application component of Lync, and create a "SIP Trunk" to a CUPC (Using what some call "Simple SIP"). I consider this as a kind of federation (though not going through the Edge server). But if I have understood our partner contacts correctly this is probably not a solution Cisco (nor Microsoft) will put much development efforts into in the future.

What about the options I highlighted in part 1 and part 2? Which solution is the best? Well, there is no black or white answer to that question. If there had been, I would have left the other one out. What You as a technician/consultant have to focus on, is this: What suits your organization best? Where do you see the company in few years time? Are you (or your customer) going to stay with the CUCM as your primary PBX, or will you switch to Lync down the road?

In my mind, if you are not planning on switching to Lync, the Lync plug-in described in part 1 is probably the best solution. It will give you presence information in every scenario to both platforms. You have only one PBX, and there are very few sources for complex errors. And it is probably the "only" really supported solution from Cisco (to the best of my knowledge at this point).
The only real big drawback with this solution, is the lack of built-in remote capabilities. This could probably be remedied by using some kind of VPN or direct access. I know there is a remote capability in CUCM now (including the use of a Cisco ASA) for hardphones, but I have not seen it put to use for the plug-in yet. Nor do I know if it's going to be possible.
But since you're not enabling enterprise voice you might be missing out on some great features in Lync. I'm not saying you can not implement all of these capabilities in Cisco's world. But for now, I consider Lync the fastest (and easiest?) all-in-one box you're going to get. Some might consider it a shame, not to make the best of it ;)

The solution in part 2 is much more flexible when you have to take travelling employees into account. And since you do enable enterprise voice in Lync, you will be able to use every feature available to you. The major drawback in this scenario is the lack of presence information shared between the systems.
These are my findings so far:
- If a call is made from PSTN to a subscriber, and it is answered in/by a CUCM device (or vice versa): There will be no presence update to Lync.
- If a call is made from PSTN to a subscriber, and it is answered in/by a Lync device: There will be a presence update to both systems (*1).
- If a call is made from Lync to the PSTN: Presence is set on Lync, but not visable to CUCM.
- If a call is made from Lync to a CUCM device: The CUCM will recognize the Lync as a "local" device (since the extension is registered as a destination), and the CUCM device will see this as a local call (as if it was a CUCM to CUCM call). Presence is set on both systems for the calling device, but only on CUCM for the called device.

Again, I really can't tell you which solution is the best for you. And who knows, maybe you end up implementing both solutions into your environment. Giving different groups of subscribers different options. I know I do all the time :)

Hope this post answers some of the questions I've seen regarding these posts.

Happy labbing!

(*1) By presence on CUCM, I am really talking about "busy line" status. Which in it's own way is a presence status.

See the other posts in this series for more info on CUCM and Lync:



Like this post

Comments

Anonymous said…
Great Post!! Well done man, this is quite explanatory.

I'm looking to deploy this and I'm still not sure which deployment model would be the best, either the solution described in Part 1 or part 2.

The customer is running CME in about 15 remote sites and they have Lync 2010. They're now however looking to deploy CUCM in the main office and conver the remote sites to SRST.

Since they're already using Lync quite well, I guess it would be important to have a discussion with them to ensure they don't lose any existing functionality they have in Lync that thy're already used to.

I guess I'll be back here to ask you some questions.
us vpn said…
I sure that a VPN or direct access would fix that problem also.
vpn service said…
Amazing post. Thank you for sharing.