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, but unlike those available within the Lync 2010 timeframe (Radvision’s Scopia Gateway) VIS is non-transcoding Gateway and 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. A B2BUA isn’t performing any heavy lifting it isn’t going to add Gallery View, so a Lync 2010 style will be on offer (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!

September 13th, 2013 | Tags: , , ,

UCS 5.0 delivers a wealth of new Lync related capabilities:

  • Better Together-over-Ethernet (AKA BToE)
  • Support for the Lync Software Updates Service (UCS 5 onwards updates can be pushed out via the Lync Server rather than a Polycom provisioning server)
  • Lync Address Book
  • Call Park
  • Lync Status (Lync configuration information delivered via the handset)
  • Boss/Admin (sharing line appearance)

In this post I’m going to go over pre-requisites for the latter (Boss/Admin), if you’re interested in learning about the features then check out a great overview from Jeff Schertz here.

The Boss/Admin feature in UCS 5.0 leverages native Lync capability in Lync Server 2013, all that is required is to add delegates by using Call Forwarding Settings within the Lync Client followed by selecting either Call Forward or Simultaneous Ringing to activate the feature. (see below)

BossAdmin01

One word of warning however is for folks still utilising Lync Server 2010, whilst this feature is supported an extra administrative step is required (this is configured out of the box with Lync Server 2013).

To enable the feature for Lync Server 2010 you need to run a Microsoft SQL command against your backend database (specifically the RTC database), for Standard Edition this will be co-located with your Front End and for Enterprise Edition this will be located on a dedicated SQL Server.

Before you run the command you can check to see whether the “dialogInfo” category has been created or not by executing the following command (change the server be.contoso.local to the name of the server running the RTC database):

osql -E -S be.contoso.local\RTC -Q "use rtc;select * from CategoryDef"

In my case this had not been created and the query returned 19 rows “dialogInfo” wasn’t one of them. To add this element to the database execute the following command (again replacing the be.contoso.local server name with your own):

osql -E -S be.contoso.local\RTC -Q "use rtc;exec RtcRegisterCategoryDef N'dialogInfo'"

That’s it!

August 30th, 2013 | Tags: , ,

A year ago I posted an article that detailed an update for the CX7000, specifically version 1.1, this introduced a number of new features one major feature being support for Office 365.

However there was a calendaring limitation, the scenario is whereby you book a meeting and invite the CX7000 or mailbox associated to the room. This in turn accepts or declines the booking (based upon availability) and updates the CX7000 calendar/home screen with the necessary metadata to facilitate a “one click to join” online meeting.

Long story short this is a common expectation from a video conferencing system and the workaround for Office 365 folks was to utilise the hot-desking functionality (also introduced within the 1.1 update).

One year on Polycom releases a new update to the CX7000, yes you guessed it…version 1.2! :lol:

This release includes a number of new features, specifically:

  • Support Microsoft Lync Server 2013
  • HDMI input support for content sharing
  • VGA content auto-detection and shared window auto-popup and auto shutdown
  • Full-screen VGA content window in Lync multiparty meetings
  • User interface enhancements
  • Microsoft Exchange Impersonation

Most of these new features are fairly self-explanatory, except the last item – Microsoft Exchange Impersonation.

Exchange Impersonation leverages an Exchange Web Services Managed API to enable a service account to access and use the rights of — or “impersonate” — one or more specified user accounts and perform certain types of mailbox operations for those accounts.” For more information on this API, it’s well documented on MSDN here.

By utilising this API the CX7000 is able to gain access to the Room Mailbox calendar via a service account, thus resolving the aforementioned calendaring shortfall.

So how do you set this up? Never fear I’m going to explain this process below with a short step-by-step guide on how you make this work within Office 365 multi-tenant (this capability can also be utilised within Office 365 dedicated, but I will not be documenting this process).

Step 1. Connecting PowerShell to your Office 365 tenancy, for this you need to run:

$LiveCred = Get-Credential

This will then prompt for your tenancy admin credentials. Next run the following command:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange –ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic –AllowRedirection

This command will initiate the connection to Office 365. Then run:

Import-PSSession $Session

This will import and load the necessary PowerShell cmdlets.

Step 2.  Prepare Exchange Online objects. Within the Microsoft Online data centers, certain objects are consolidated to save space. When you try to use Windows PowerShell to modify one of these objects for the first time, you may encounter an error. By running the cmdlet below tenant administrators are able to create or modify objects within their Exchange Online organization. Proceed by executing the command:

Enable-OrganizationCustomization

Leave your PowerShell session open, we’re going to re-visit this in a moment

Step 3. Create a Room Mailbox within the Exchange Online administration portal (see below)

mailbox-imp01

I’ve created a Room Mailbox called “sjroom”, this in turn creates a user within Office 365 without any assigned licenses or authentication capabilities.

Step 4. Assign licenses to the Room Mailbox account and enabled authentication (see below)

mailbox-imp02

In this step you need to assign licenses (Lync being a minimum) and reset the password, once the password is reset you need to sign-in and change this to a permanent password.

Step 5. Create your mailbox service account, no licenses need to be applied and once created you need to sign-in and create a permanent password, I created an account called “mailboxservice”

Step 6.  Assign mailbox impersonation rights to your service account by executing the following command within the PowerShell session you created earlier:

New-ManagementRoleAssignment –Name “Mailbox-Impersonation” –Role “ApplicationImpersonation” –User mailboxservice@<tenantname>.onmicrosoft.com

Step 7. Ensure the comments are not deleted from within Room Mailbox invitations, without doing this your appointments will get their Lync meeting meta data removed, so click-to-join will be broken.

Set-CalendarProcessing “sjroom” -DeleteComments $false

Step 8. Provision your CX7000 with the “sjroom” account by completing the start-up wizard, this can be re-invoked by resetting within the admin settings (this does not rollback the update/version of the system software).

Step 9. Configure the Room Impersonation settings. The e-mail address should be for the room account/mailbox (in my case sjroom@<tenant>.onmicrosoft.com) and the username/password for the service account (in my case mailboxservice@<tenant>.onmicrosoft.com) – see example below:

mailbox-imp03a

Following this step your home screen calendar should be populated with Lync invitations. For more information on the 1.2 update for CX7000 go to the support page at http://support.polycom.com/PolycomService/support/us/support/video/cx/cx7000.html

August 23rd, 2013 | Tags: ,

 

This may perhaps be a niche case as I’m aware there aren’t many folks than have braved split-domain configuration with Lync on-prem and Lync Online, but to those that have (and still see the value in this type of deployment, which even without telephony there still is I might add), you are likely at some point to get the request for enabling Lync-to-Skype connectivity.

Lync-to-Skype connectivity was announced earlier this year, this of course was inevitable when Microsoft bought Skype back in mid-2011 and many (like myself), made these amongst other predictions – okay so Microsoft still haven’t made good on some of them but never say never, right?  :-)

If you’re looking for more information on how to deploy a regular on-premises enablement of Skype, I won’t be covering that here as Microsoft have an extensive deployment guide. What I’m going to cover is how to go about this process when you’re deploying (or have already deployed) split-domain.

So there’s

  1. The wrong way (AKA the way I went :oops:) and by this I mean enabling Skype connectivity after deploying split-domain – I’ll explain how to reverse this later…
  2. The right way, enabling Skype connectivity prior to adding your domain to Office 365.

If you’re not subscribed to my feed then it’s likely the wonders of SEO have brought you here and you need to know how you can reverse the (pardon the pun) “PIC”le you’re in  ;-)

It can be done easily, without intervention from Microsoft Office 365 support…

1. Log into Office 365 as an administrator, then head for the Lync administration page. Once here go to Organization -> External Communications. Next disable public IM connectivity.

 

SkypeSplitDomainPIC01

 

2. Wait 24 hours…
3. Apply for PIC enablement (or Skype connectivity provisioning), if you tried this previously then this process would fail as it would effectively appear to the PIC administrator that you’re already enabled (as per the PIC enablement within Lync Online above)
4. Wait again for this to be enabled, this will be confirmed via email
5. Once you’ve received your email confirmation then you’re all set and you can re-enable the setting you disabled in step 1!

That’s it!