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!

Public Certificates for Exchange 2010 Federation

I think that one of the coolest features of Exchange 2010 is the seamless free/busy and calendar federation between organizations. In order to get federation provisioned there are a number of steps you need to take which you can find detailed on Technet.

The first step of this setup involves creating a Federation Trust to the Microsoft Federation Gateway (MFG), but in order to create this trust you need to use a public certificate issued by one of the following Certificate Authorities (the haphazard thumbprint formatting is Technet’s, not mine):

CA certificate friendly name Thumbprint
Comodo NA
Digicert Global Root CA ‎083B:E056:9042:46B1:A175:6AC9:5991:C74A
Digicert High Assurance EV Root CA ‎91 8d a5 e4 99 c1 5f 7c 62 75 b1 24 fe de 53 35 7c 34 bd 36 CA (2048) 801D 62D0 7B44 9D5C 5C03 5C98 EA61 FA44 3C2A 58FE
Entrust Secure Server CA 99A6 9BE6 1AFE 886B 4D2B 8200 7CB8 54FC 317E 1539
Go Daddy Secure Certification Authority ‎7c46 56c3 061f 7f4c 0d67 b319 a855 f60e bc11 fc44

I recently was involved an Exchange deployment that involved purchasing a SAN certificate from Comodo. One of the certificate authorities Comodo uses to issue SAN certs is the USERTrust Legacy Secure Server CA, which has its own certificate issued by the Secure Server Certification Authority. Bottom line is the certificate you get verifies up to the Entrust certificate you can see below which the Federation Gateway supports.


After trying to create the Federation Trust we were seeing the following error:


An error occurred while attempting to provision Exchange to the Partner STS. Detailed information “An error occurred accessing Windows Live. Detailed information “The request failed with HTTP status 403: Forbidden.”.”

Basically this is the MFG’s way of saying “I don’t trust this certificate.” It turns out the MFG is geared to only accept certificates issued directly from one of the certificate authorities listed above which is not something I saw in the documentation. So if the Entrust Secure Server Certification Authority had issued our webmail certificate it would have been accepted. But like in our case, if your certificate is issued from a 3rd party intermediate certificate authority it won’t be accepted even if it technically verifies up to a support rooted authority.

The good news is a call to PSS resulted in Microsoft making a change on the MFG to accept certificates issued by this particular intermediate CA going forward for everyone. So if ran into this error previously you should be able to try again with the same certificate and see the trust succeed. As of this writing I’ve requested them to also add support for the AAA Certificate Services intermediate CA Comodo also issues certificates from.