Lync to Windows Live A/V Federation

One of the coolest new Lync features is that you can now do A/V federation with Windows Live users, but you'll find this does not work out of the box. First of all, your organization must complete the Public IM Connectivity provisioning process. After that, there are two modifications required even if you've enabled Public IM connectivity for the external access policy assigned to users.

First, there is a hidden parameter allowing A/V federation to PIC only available through the Lync Management Shell. This example modifies the global policy to allow both Public IM and Public IM A/V traffic so change the scope appropriately if you're limiting by site or users.

Set-CsExternalAccessPolicy Global -EnablePublicCloudAccess $true -EnablePublicCloudAudioVideoAccess $true

Secondly, the Windows Live network does not support SRTP encryption of the audio/video traffic, but Lync requires this encryption by default. We need to change Lync to support encryption instead of require it. Once that change is made Lync will prefer encrypted sessions and still negotiate those first, but will allow unencrypted media to be exchanged if it can't agree on encryption. The other Lync default is to only allow VGA video quality, but you can do 720p to Windows Live if both endpoints support it. This example changes the media encryption and video quality at the global level.

Set-CsMediaConfiguration Global -EncryptionLevel SupportEncryption -MaxVideoRateAllowed Hd720p15M

That change should be picked up within 5 minutes on the Front-End. After that, sign out of your Lync client and back in. You can verify the change by holding down the CTRL key, right-clicking the Lync task tray icon, and selecting Configuration Information. The PC to PC AV Encryption should say "AV Encryption Supported" now.

If you don't make this change you'll see an error on Front-End servers when trying to initiate an A/V call that the encryption levels don't match:

Start-Line: SIP/2.0 488 Not Acceptable Here
From: "Eddie Vedder"<>;tag=ed272dd714;epid=8e3ef28192
To: <;mepid=F6333909B2AE4F60A2553FA59913B0A8>; tag=ab1e5513de
USER-AGENT: UCCAPI/4.0.7440.0 WLM/15.4.3502.0922 (Windows Live Messenger)
ms-client-diagnostics: 52017;reason="Encryption levels dont match"

Also, keep in mind the Windows Live user must be using the Windows Live Messenger 2011 version to support Lync A/V federation. When you're connecting a call the Windows Live client will recognize that you're connecting to Lync:

Happy federating!

Sharing Physical NICs with Guest VMs for iSCSI Traffic on Hyper-V

Since Microsoft has introduced support for virtualizing many more workloads with Lync Server 2010 we'll probably begin to see more and more deployments done with a hypervisor. One challenge can be providing shared storage access to a virtual machine guest operating system running on top of a hypervisor such as Hyper-V. An example here would be if a company wants to provide high-availability for the Lync pool back-end running a SQL server cluster, which requires shared storage for the quorum, MSDTC, and data volumes.

It's not uncommon for Hyper-V hosts to be configured in a failover cluster using dedicated NICs for iSCSI access, but how often does a guest VM typically need access to shared storage? Typically not often. Usually if a VM needs access to the SAN you can connect to the LUN from the host and then pass it through to the guest. With a SQL cluster though, both VMs should reside on separate hosts and need direct access to the SAN. In order to accomplish this you need to initiate iSCSI connections from within the guest VM directly to the SAN.

If you have unlimited NICs this is really easy. Just bind a physical NIC (pNIC) connected to the storage network to a Hyper-V virtual switch, create a new virtual NIC (vNIC) on the Hyper-V guest on this switch, and away you go - the guest now has iSCSI network access. For more realistic scenarios you may be limited on your NIC count and have to get creative because you can't dedicate a pNIC to VMs only.

If this is true the first option that comes to mind is to leverage VLAN tagging on a virtual switch already using a pNIC. This way you can tag LAN traffic and storage network traffic separately. The downside to this approach is you're now sharing the same pNIC for both LAN and storage traffic in VMs. The host OS still has a dedicated NIC for iSCSI traffic here. If the LAN traffic starts maxing out the capacity of the adapter you could potentially lose connectivity to the SAN and cause some serious problems for the cluster. This configuration would look like this:

Another option here is to leverage the network adapters already used by the host system for iSCSI access, i.e. the same adapters accessing the SAN and providing high-availability for the guest VMs. That may seem like a poor idea, but I think the alternative of sharing LAN and iSCSI network on the same adapter is far worse. In this configuration the Hyper-V host and the VM guest are both accessing the storage network through the same physical NIC, dedicated purely for storage traffic. A virtual NIC is created on the host and the host traffic also passes through the Hyper-V virtual switch in this scenario. The host and guest sharing a pNIC setup is depicted here:

In order to accomplish this setup you'll want to use the following steps:

  1. Shut down any VMs running on the host OS.
  2. Stop any iSCSI access from the host.
  3. Create a new Hyper-V virtual switch using the pNIC previously dedicated to iSCSI. Be sure to check the box "Allow management operating system to share this network adapter."
  4. Configure the new network adapter on the host OS with the old pNIC IP address and settings.
  5. Reconnect iSCSI targets.
  6. Edit the VM guest and add a new network adapter. Assign the network adapter to the iSCSI network virtual switch.
  7. Configure iSCSI targets from within the guest VM

At this point, all your storage traffic is isolated to the same physical NIC.

Warning: I cannot for the life of me find documentation from Microsoft on whether or not this actually supported. If I were to wager a guess it's on the unsupported side, but probably because of the "We haven't tested this" reason more than the "It doesn't work" reason. Your mileage may vary on your deployment, but this appears to be working just fine. I was a little reluctant to try this thinking the host OS may have iSCSI performance problems through the Hyper-V virtual switch, but all seems well so far.

Lync Online Meetings Default Browser Woes

When Outlook 2010 and Lync 2010 are installed on the same system users see a "Join Online" button in calendar reminders that allows them to join a conference in Lync immediately. Users can also click the "Join online meeting" link within the meeting invitation and Lync will automatically put them in the meeting.

The way this works for IE is through the use of an ActiveX control which detects whether the full Lync client is installed by detecting the user agent string and if it matches IE, Lync is used to join the conference. For Firefox, there is a Microsoft Lync 2010 Meeting Join plugin which pulls off this detection. If neither method succeeds, the user is directed to the Lync Web App login form.

Joining through either method usually works great, but the caveat is that this only works when the user's primary browser is Internet Explorer. Let's face it, IE has come a long way, but many folks (like this guy) prefer Google Chrome or Firefox to be the default browser.

In those cases clicking the button on the reminder, or even just clicking the "Join online meeting" hyperlink within the meeting invite will cause the default browser to open and the user to be presented with Lync Web App. Since IE isn't being used the ActiveX control can't load and automatically join using Lync. This is frustrating because the desired action would instead be to use the full Lync client to join the meeting by default.

What I've found as a workaround is to use the IE Tab extension within the other browsers to accommodate Lync online meeting joins. These extensions allow you to specify URLs that if accessed through Chrome, should be rendered within IE instead. When you load one of these sites within Chrome it will detect a match and then use the IE engine to display the page. This allows the ActiveX control to detect Lync is installed and properly join the meeting.

As a user you can either define just the online meeting URL used for your organization like* Or, since online meeting URLs defaults will probably be consistent across most Lync deployments you can use some wildcards. I recommend using https://meet.* as the address to automatically open in IE Tab. That way, whether you click a join link for or for you'll be placed in the meeting with Lync automagically. This allows you to join conferences hosted by federated partners just as easily. Of course, if you visit some other website that matches the meet.* critera it will open in IE, but that's an annoyance I can live with.

So to get started, install the IE Tab extension for Chrome:

Once installed, click the little IE icon on the toolbar.

Click the second icon from the left, the little funnel (icon choices leave a bit to be desired?), to configure your matching URLs.

In the address section enter your pattern to match such as https://meet.*

Click an online meeting link and you should see Chrome begin to load the page, flip to IE tab mode, and then join the meeting with Lync. The process is slightly slower than if IE is the default browser, but the important part is that it still works.

On a related note, Mr. Elan Shudnow sitting next to me just tested within Firefox and apparently if you've also installed the Lync Attendant Console it will open automatically without any of this configuration. Good luck viewing a PowerPoint or Desktop share in that client though!

Note: Updated 1/25/2011 to correct information about IE and Firefox behavior.