November 19th, 2014 | Tags:

The Lync Room System folks have been busy as of late and a load of updates have been delivered over the last week (in time for Thanksgiving :)), first of all the 15.12 update.

This update includes a number of enhancements, notably:

  • Adds functionality to make public switch telephone network (PSTN) calls and adds a Find a contact button in the In-meeting dial pad.
  • Adds functionality to the “Where is my join button” feature so that users can create a meeting by using the existing meeting information from the console.
  • Adds functionality to reduce the number of Lync Room System restarts for future device updates that are later than the November 2014 update (version 15.12.0). Future updates will be cumulative.
  • Adds functionality Lync Room Systems can be monitored by System Center Operations Manager when LRS is not joined to a domain (Workgroup mode).
  • Improvement to the UI colors on the console and front of room screens. Previously the UI colors for some buttons appear dimmed and disabled even though they are active.

There’s also an update to the Lync Room System Deployment Guide, some new items in here include:

  • LRS Appliance Security Information
  • PowerShell Setup Scripts

Finally there’s also an update to the Lync Room System Portal here

Update: Overview of the new “Where is my join button” functionality.

One interesting new feature within the 15.12 update is a solution to the scenario whereby the organizer forgets to Lync-enable a meeting, previously I mentioned the conference policy update that an IT Admin can apply to prompt for Lync blobs (specifically whereby an LRS system is invited into the meeting) – see here. But this new feature in 15.12 will also go a step further to mitigate scenarios whereby the invite has already been sent, instead of the previous behavior when the calendar entry would say “Where is my join button”, a single click will prompt the end-user to send a new (this time Lync-enabled) invite from the LRS system itself. See picture below:

Once sent the meeting with start and other participant will get a new invite that they can click and join the meeting with. Note: This will not mitigate the need to update TNEF settings in Exchange, blobs would still be removed when the new invite is sent between Exchange Servers that do not have this setting specified correctly.

LRS-WhereIsMyJoinButton

 

September 16th, 2014 | Tags:

When scheduling a Lync meeting it’s important that you add your Lync meeting credentials to the Outlook invitation, this is a fairly obvious requirement and in the case whereby this isn’t added you could of course create an ad-hoc or “Meet Now” conference.

However when you’re using a Lync Room System forgetting to add these “blobs” to your invitation results in the lack of single click-to-join, therefore slowing down the time in which it takes to start the call. One thing however that I hadn’t noticed is that in CU2 for Lync Server 2013 Microsoft added a new conferencing policy setting that corrects the problem whereby an LRS resource is added to an invite but the “Create a new Lync meeting” button is omitted.

The setting is:

Set-CsConferencingPolicy -Identity Global -EnableOnlineMeetingPromptForLyncResources $true

By default this is set to false and needs to be enabled. Once enabled users will be prompted to add the Lync conference detail prior to sending the invitation (see below)

EnableOnlineMeetingPromptForLyncResources

 

Hope this helps!

 

August 11th, 2014 | Tags:

Back at Lync Conference 2014 Dustin Hannifin and I co-presented on the various video interoperability options available for Lync 2013.

I’m specifically calling out Lync 2013 as the video enhancements, specifically the addition of H.264 SVC, created challenges when integrating existing Lync 2010 video solutions. For those that want to know more on this subject I covered this in detail during our presentation – long story short whilst existing support for the RTVideo codec is still included various signaling changes require vendor specific updates.

Of the solutions available today there is an emphasis on all conferences taking place on a 3rd party MCU or bridge. Microsoft’s Video Interoperability Server (VIS) will bring some relief in this area, but in some cases this may not address all scenarios.

Many are already familiar with the Polycom RMX portfolio (don’t be deterred by cost at this point either, the entirety of this platform can now be virtualized and is also available in software), which previously was also limited to the same “meet on the bridge” scenario. But with the recent update a new capability (referred to as “RealConnect for Microsoft Lync” – don’t shoot the messenger I don’t work in marketing ;-) ) is made available. With this feature Lync clients continue to join the Lync Server (or AVMCU) and traditional video VTCs (not specific to Polycom), with an emphasis being on Cisco including their non-standard based “TelePresence Interoperability Protocol” (TIP), LifeSize and any other standards-based system) join the Polycom MCU. Both worlds are then cascaded or barbelled and Microsoft’s SVC is leveraged resulting in up to 5 of the active video participants being composed within the Polycom MCU layout, referred to as “Continuous Presence”.

RealConnect for Lync 2013 Overview

First up you’ll need to schedule the conference call, this achieved in the same way any other Lync conference is scheduled, specifically via a Lync Online Meeting invite – there’s one important attribute within the invitation and that’s the dial-in conferencing ID. This ID is leveraged by the VTC as a way of dialing into the call, so for those who haven’t deployed dial-in conferencing it’s a pre-requisite. Note for those that don’t already have this deployed or have the notion of enabling PSTN dial-in conferencing capabilities – that’s okay – a dummy number can be added, we’ll cover this later.

RealConnect_01

With the invitations sent to all those that are required to join the call, let’s go through the join process and UX. The animation below (credit to Jeff Schertz) illustrates the following steps:

RealConnect_02

 

We see the Lync clients (top right) joining the Lync conference (as per the usual process), resulting in an AVMCU call – with that Lync clients are now presented with “Gallery View” video (bottom right).

  1. Next up (the order of this isn’t important) the VTC(s) join by dialing the meeting’s respective Lync dial-in conference ID (top left).
  2. The Polycom RealPresence Platform components (specifically RMX and DMA, which are already integrated to Lync), perform a process whereby the Lync conference SIP URI is obtained and an ad-hoc Virtual Meeting Room (VMR) is created, this VMR is assigned the same number as the Lync conference ID and automatically dials into the Lync conference – as though it were another Lync client.
  3. Once the call is cascaded the VTC is seen as an additional participant within the Lync conference (bottom right) and the existing Lync participants (and their respective video streams, up to 5 of the active) are composed within the RMX layout (bottom left).
  4. As additional VTCs join the RMX layout increases by one and the existing VMR within the Lync Gallery switches based upon the active VTC speaker.

Deployment Overview

The solution is comprised of two mandatory Polycom infrastructure components:

  1. DMA (6.1), which handles signaling, Lync conference URI lookup and VMR creation
  2. RMX (8.4), performs the media handling and connects into the Lync conference

Note: an additional software component is required for deployments where Lync to traditional VTC (and vice-versa) content is required.

I won’t cover the base Polycom RealPresence Platform steps, this is already well documented and this picks up from the point whereby both the DMA and RMX are already deployed and integrated via the Trusted Application process – one difference worth noting here is that creating a “Static Route” is no longer a requirement unless Lync to VMR calling is still a requirement.

Steps:

  1. Deploy Lync Dial-in Conferencing (if not done so already)
  2. Customize the Lync meeting invitation, add H.323/SIP dialing instructions
  3. Configure DMA (SIP Peer)
  4. Create a RealPresence Platform Lync account
  5. Configure and enable the DMA Lync conference dial rule
  6. (Optional if not already configured) Ensure ICE is enabled on your RMX

The following content is an abridged version of the Polycom UC Deployment Guide for Microsoft Environments, this content was created by yours truly and edited by James Hill – the complete guide can be downloaded here.

Step 1. Enable Dial-in Conferencing:

1. Install the dial-in (PSTN) conferencing component for the Lync Front End server or Pool in the Lync 2013 Topology builder by going to Edit Properties > General > Features and Functionality.

RealConnect_03

2. Check Dial-in (PSTN) conferencing and click OK.

3. Publish the topology by right-clicking the central site name and clicking Publish Topology > Next > Finish.

RealConnect_04

 

Once published, the output displays as shown next.

RealConnect_05

After you change the topology, deploy the application on the Lync Server by running the Lync 2013 ‘bootstrapper’ process.

To deploy the application:

1. Open the command prompt on your Lync Front End server and execute the command:

%ProgramFiles%\Microsoft Lync Server 2013\Deployment\Bootstrapper.exe

RealConnect_06

2. Install the associated service by opening the Lync Server Management Shell and executing Start-CSWindowsService.

Next, ensure that a dial-in conferencing region is configured. Typically, you need to configure multiple regions and assign local access numbers. In the following example, we add a default region in order to generate an H.323 or standard SIP number that users can dial into from any standards-based room system. The naming convention is not important but you must populate the dial-in conferencing region to complete the configuration.

To populate the dial-in conferencing region:

1. Open the Lync 2013 Server Control Panel and go to Voice Routing > Edit the Global Dial Plan > Dial-in conferencing region.

RealConnect_07

2. Specify a dial-in access number by going to Lync 2013 Server Control Panel > Conferencing > Dial-in Access Number > New and completing the following fields:

  • Display number  This field permits alpha numeric entry. This is typically the dial-in access number. This example uses the VMR or Conference ID and is labelled here as ‘VMR-Number’.
  • Display name Choose a display name. Typically, this name matches the region.
  • Line URI The line URI will not be used as the actual dial-in conference is not being used. This example uses a dummy number ‘tel+111’.
  • SIP URI This field allocates a SIP address to the conference number. Though this field is not used for RealConnect, you must enter a SIP URI.
  • Pool Enter the pool you are enabling for dial-in conferencing.
  • Primary language This field is not used for RealConnect.
  • Associated Regions Add the region you created in step 1.

RealConnect_08

Step 2. Customize the Lync meeting invitation, add H.323/SIP dialing instructions:

If you want to customize the meeting invitation, you can add custom footer text to allow meeting participants to join a meeting using a standards-based video endpoint.

    1. In the Lync 2013 Control Panel, go to Conferencing > Meeting Configuration.
    2. Edit the default global template as shown next.

RealConnect_09

This example shows external addresses. If you want to show external addresses, you need to enable standards-based video Firewall traversal using, for example, a Polycom RealPresence Access Director.

Your Lync environment now includes Conference IDs in Lync-enabled meeting invitations.

Step 3. Configure DMA (SIP Peer):

Next, complete the Lync 2013 and DMA integration. Configure DMA network settings to match the Lync Server, specifically, Time and Domain. You need to configure the domain to match the extension you gave to the DMA DNS name.

Next, specify domain and time on the DMA system.

To specify domain and time on the DMA system:

1. In the DMA administrator screen go to Local Cluster > Network Settings > General System Network Settings.

RealConnect_10

2. Configure the time to synchronize with the same source as the Lync Server, typically one of your domain controllers, by going to Local Cluster > Time Settings. Specify an IP address for your time server as well as a time zone.

RealConnect_11

Next, add the Lync Server as an external SIP peer. To add the Lync 2013 Server as a SIP Peer:

3. In the DMA administrator console go to Network > External SIP Peers > Add. Complete the following fields:

  • Name Enter the name you gave to this Lync Front End Server or Pool.
  • Description Enter a description for Name field.
  • Type Choose Microsoft.
  • Next hop address Enter the fully qualified domain name for your Lync Front End Server or Pool.
  • Destination network Enter the Active Directory domain for your Lync Front End Server or your Pool. Do not enter your SIP domain.
  • Port Enter 5061.
  • Transport type Enter TLS

You can leave the remaining fields blank.

RealConnect_12

4. In the left window, click Lync Integration.

RealConnect_13

5. In Maximum Polycom conference contacts to publish, enter the maximum number of VMRs you are publishing presence for. This field is not required for RealConnect. This example sets the maximum at 25,000, the recommended number.

6. Check Enable combined RealPresence-Lync scheduled conferences.

Step 4. Create a RealPresence Platform Lync account:

Next, assign a Lync account. This can be an existing account. However, Polycom recommends creating a dedicated Lync account that can be used to perform Conference ID to Lync Conference SIP URI resolution. In this case, the account can be a Lync account enabled for PC-to-PC telephony, as illustrated next.

Edit Lync Server User – RealPresence Platform Service Account

RealConnect_14

Step 5. Configure and enable the DMA Lync conference dial rule:

Next, create a conference template that is assigned to RealConnect Lync conferences.

To create a conference template:

1. Conference mode Set to AVC only. Mixed mode is not supported.

2. Enable the dial rule on DMA by going to the DMA administrator screen > Call Server > Dial Rules.

The Description field displays Dial by Lync conference ID.

RealConnect_15

3. Highlight the Dial by Lync conference ID and select Edit.

4. Check Enabled to enable the rule and the Conference template created in the previous step.

The available SIP peer(s) you assigned displays in Selected SIP peers.

5. Click OK.

Your RealConnect for Lync deployment is now complete!

Step 6. (Optional if not already configured) Ensure ICE is enabled on your RMX:

This configuration isn’t specific to RealConnect, however RMX 8.4 introduces a mandatory requirement, specifically where ICE needs to be enabled in all types of Lync deployment scenarios (with or without Edge deployed).

There are two supported methods, either user-based or a new method introduced in RMX 8.4 that leverages a UCMA option, with this we’re able to scale greater than 12 connections for remote worker/Federated scenarios. In the configuration example below we’re going to use the new approach which is now recommended.

To perform this configuration please refer to the new Trusted Application configuration within the sub-chapter Configure Lync Server for use with a Polycom RealPresence Collaboration Server System on page 61 of the Polycom UC Deployment Guide for Microsoft Environments here

 

 

March 3rd, 2014 | Tags:

Last year at Lync Conference 2013 Microsoft announced that they were going to introduce a new video interoperability component to Lync vNext, namely the “Video Interoperability Server” or (VIS). During the conference Mike Stacy, Jeff Schertz and I presented a session on Lync 2013 video interoperability, during the session we covered off these three pillars

  1. Lync 2013 new video functionality
  2. Microsoft’s SVC implementation
  3. Modes leveraged for interop, specifically (Gateways vs. MCU vs. native integration)

At this year’s Lync Conference the keynote again visited the VIS component and Microsoft provided a public demo.

LyncConf14VISDemo

During the demo we can see a traditional room system (in this case a Tandberg/Cisco EX60) being added to a Lync multi-party conference and presence being reflected within the Lync client.

So architecturally how does this work and how does this fit into the overall Lync video interop landscape, the biggest question I hear is “does this replace the needs for Gateways, MCUs and the need for native Lync support?”

These are good questions and as much as I’d love to give you a one size fits all answer, I can’t – ultimately this is going to be based on how you use Lync, your investment in video endpoints, the dependencies you have on H.323 and standard SIP calling, the architecture of your environment, size and geographic location of your end-users. Dustin Hannifin and I re-visited Lync 2013 video interoperability at this year’s Lync Conference, we both re-visited the pillars above and included VIS as one of those options. I’m going to go over here what was discussed at that session (in finer detail), cognizant that VIS is still under wraps and some lower level detail is still yet to be disclosed by Microsoft.

First let’s start with the problem, when Lync 2013 was announced so was support for H.264 SVC, which led to some confusion, specifically “so now all my traditional video just works with Lync?” Of course this isn’t the case, whilst the H.264 SVC codec has far closer alignment with traditional video systems from a media perspective there’s still some outstanding work required to make things work on the signaling side.

Now we know that there’s not really such a thing as “standard SIP”, all UC call control platforms have their own flavors and SIP extensions, so with this in mind Microsoft’s SVC implementation follows suit.
Jeff Schertz wrote an article on Lync 2013 video interoperability that explains this is greater detail, but for those that have either not read this (or don’t have a few hours set aside :-)) the conclusion is that Microsoft’s implementation of H.264 SVC isn’t interoperable with AVC VTCs without the following:

a) Re-packetization of media – Microsoft’s SVC is Mode 1 (Temporal Scalability with Hierarchical P i.e. a single video stream is sent for each requested resolution that could be comprised of different frame rates, typically a stream with two layers is sent (one layer @ 15fps and another @ 15fps, this in turn would be capable of facilitating either 15fps or a cumulative 30fps).

However traditional video systems utilize H.264 AVC is Mode 0. Folks will argue that Mode 1 contains streams that are AVC compliant, but a non-SVC or AVC only room system isn’t going to be able to handle this Mode 1 stream without some modifications.

b) Signaling translation – as stated above there’s often this misnomer hanging over standard signaling, Lync 2013 and the new world of SVC compounds this further given that even more work is offloaded to the endpoints i.e. dynamic layout composition and multi-stream video intelligence.

Another interim puzzle that some early Lync 2013 adoptees experienced is whereby H.263 is being leveraged for point-to-point Lync calls, Lync 2013 dropped support for this dated CIF resolution capable codec. So the priority level for compatibility within the items above become high on the UC agenda.

The answer to this problem hasn’t changed largely speaking, we’re still in the world of Gateways, MCUs and endpoints that natively support Lync. VIS fits neatly into the Gateway category, VIS should be regarded as a Back-to-Back User Agent or (B2BUA), co-located either on your Lync Front End or deployed standalone in environments where additional scale is required.

B2BUAs aren’t new to Lync, in fact Session Border Controllers have effectively been acting in this capacity with Lync for voice, specifically performing signaling translation. However in this case more than just signaling is augmented, bit stream information also needs to be modified to effectively setup calls, it’s still lightweight work i.e. there’s no transcoding but due to this requirement both signaling and media needs to flow via the B2BUA is all scenarios.

VIS Blog Post

 

A B2BUA registered VTC has no Lync intelligence, it’s completely unaware of Lync and the B2BUA component is acting as a SIP proxy, tunneling all payloads. A Lync client would behave differently and where possible in point-to-point scenarios will always seek out the best media path, this in turn offers lower latency and in many cases gives more back to the network folks by avoiding WAN traversal.

As per the demo at Lync Conference other Lync clients will now see presence and be able to add the VTC to a Lync multi-party call but single click-to-join from the VTC isn’t possible as Lync Online Meeting translation/presentation is a whole other story. Without performing significant heavy lifting a B2BUA isn’t going to add Gallery View (we’re entering MCU territory here), so a Lync 2010 style will be on offer for the VTC (single speaker voice switched experience). In this brave new SVC world DSP driven MCUs are becoming less relevant, but a non-SVC VTC isn’t going to be able to handle multiple simulcast video streams, therefore no snazzy layouts here.

Another consideration is content, VTCs have standardized on H.239/BFCP it’s not clever stuff and is nowhere near as sophisticated or collaborative as what Lync has on offer (RDP, PSOM & WAC), but unlike the video payload there is no way today in which these can be interoperable without transcoding.

In conclusion, seeing Microsoft’s investment in VIS is a really good thing, but as always there are other mechanisms for interoperability which either negate the need for this work to be performed by the backend or facilitate easier ways of joining Lync conference calls whilst also preserving the Gallery View experience.

For more information on this I’d encourage you to watch our presentation (for now it’s only open to Lync Conference attendees, but this will go big bang in the coming weeks…)

January 9th, 2014 | Tags:

The new year brings a number of events I’d like to call out, firstly this month a number of great user groups.

For those in North America check out the Lync User Groups website (I’ll be hosting the Silicon Valley Lync User Group together with Alex Lewis on the 23rd of Jan).

If you’re based in the UK, the Microsoft UC User Group London has a meeting on the 30th Jan (I’ll be presenting with Tom Arbuthnot and Justin Morris – alas over video) – be aware registrations have been pretty strong so we’re currently on waiting list :(

I’d also like to mention Lync Conference, this is the go-to place for the Lync Community where you can explore the latest advancements in Unified Communications at the only comprehensive event in the world dedicated exclusively to Microsoft Lync and supporting solutions.

I’ll be speaking together with Dustin Hannifin about Video Conferencing Solutions Interoperable with Lync, this will be a 300 level session where Dustin and I give an update on changes to video in Lync 2013 (including Panoramic video changes), H.264 deep-dive, Office 365 integration, back-to-back user agents vs. native integration, alignment of solution to application and the low-down on LRS standards-based video co-existence. This is just some of the topics we’ll cover, long story short you won’t want to miss it! :)

Look forward to seeing you at some point in 2014!

January 9th, 2014 | Tags:

powershell

Microsoft back in October released an LRS deployment guide (if you reviewed this upon release it was beta, so it’s worth re-reviewing the 1.0 version), however if you’re just looking to create a standard account with associated Exchange room mailbox follow the 10 easy steps below!

Run the following within Exchange Management Shell (these steps will create the room mailbox, define mailbox parameters for LRS calendar join/display and enable for authentication) :

Step 1.

New-Mailbox –Name "<insert display name>" –Alias "<insert alias>" –UserPrincipalName "<insert email address>" –SamAccountName "<insert account>" –FirstName "<insert first name>" –Initials "" –LastName "<insert last name>" –Room

Step 2.

Set-CalendarProcessing -Identity <insert alias> -AutomateProcessing AutoAccept

Step 3.

Set-CalendarProcessing -Identity <insert alias> -AddOrganizerToSubject $false

Step 4.

Set-CalendarProcessing -Identity <insert alias> -RemovePrivateProperty $false

Step 5.

Set-Mailbox -Identity <insert email address> -MailTip "This room is equipped with Lync Meeting Room (LRS), please make it a Lync Meeting to take advantage of the enhanced meeting experience from LRS"

Step 6.

Set-ADAccountPassword –Identity <insert alias>

Step 7.

Enable-ADAccount –Identity <insert alias>

 

Run the following from the Lync Server Management Shell (these steps will enable the room mailbox account for LRS sign-in, steps 9 & 10 are only required if Enterprise Voice enablement is needed – upon doing so a dial-pad is exposed within the LRS client)

Step 8.

Enable-CsMeetingRoom -SipAddress "sip:<insert email address>" -domaincontroller <insert domain controller FQDN> -RegistrarPool <insert front end FQDN> -Identity <insert alias>

Step 9.

Set-CsMeetingRoom <insert alias> -domaincontroller <insert domain controller FQDN> -LineURI "tel:<insert PSTN number>;ext=<insert extension no.>"

Step 10.

Set-CsMeetingRoom -domaincontroller <insert domain controller FQDN> -Identity <insert alias> -EnterpriseVoiceEnabled $true

 

That’s it!