RSS Subscription 168 Posts and 2,769 Comments

Archive for February, 2011

Lync 2010 Enhanced Privacy Controls

One of the new features in Lync 2010 is the ability to provide Lync clients enhanced privacy controls.  What this provides is the ability for Lync users to restrict their presence to users who are in their contact list.  By default, this feature is not enabled.  You may think to yourself, why?  Well, it’s because OCS 2007 R2 users can connect to Lync Server 2010 if the Client Policies allow for it.  Communicator 2007 R2 does not provide the capability to set these enhanced privacy controls.  It is because of this, you will want to make sure all users are utilizing Lync 2010 in the organization prior to enabling Enhanced Privacy Controls.  If for whatever reason, you have enabled enhanced privacy controls for a user, and they happen to downgrade to Communicator 2007 R2, these privacy settings are lost which is why it is important to restrict the ability for Communicator 2007 R2 users to be able to connect to Lync Server 2010.

To check what the current configuration is set at, we can run the following command:


We can see the EnablePrivacyMode is configured to False.

In the Lync 2010 client options, we see there are no options to prevent anybody from seeing our presence if they are not on our contact list.

But let’s say our Client Policies are preventing Communicator 2007 R2 clients from connecting.  We can set Privacy Mode to true.  Keep in mind, in order for Response Group Agents to receive Response Group calls, they will need to add their Response Group Agents to their contact list.  The Response Group workflow creation process creates a Response Group contact object in Active Directory.  Because of this, there is nothing special you have to do.  It will be as simple as utilizing the search feature in Lync 2010 just like you were trying to find any other user, and adding the Response Group user/contact to the Response Group agent’s contact list.

Now to enable Enhanced Privacy mode, we run the following command:

Set-CsPrivacyConfiguration -EnablePrivacyMode $true

Because Lync 2010 clients retrieve this mode through in-band provisioning, it will be necessary for Lync 2010 clients to log off and log back in.

Once users have logged back in, we can go back to the Lync 2010 options, go to status, and we see some new options.

We can now see the options look different.  By default, only people in the user’s contact list will be able to see their presence.

To illustrate what this looks like, I have two users:

  • Elan Shudnow
  • Elan Test

On the Elan Test account, I have Elan Shudnow added to the contact list.  But Elan Shudnow is showing up as Offline.  In fact, Elan Shudnow is actually set to Available.  Elan Shudnow just doesn’t have Elan Test as a contact.

I will now go ahead and add Elan Test as a contact to the Elan Shudnow account. Once doing so, I immediately see Elan Shudnow’s presence go to Available without doing a single thing on the Elan Test account.


Lync 2010 Edge Utilizing Windows Server 2008 R2 Federation TLS Issues

General Information

I just migrated a OCS 2007 R2 Edge on Windows Server 2008 last night to Lync Edge 2010 Edge on Windows 2008 R2.  All I can say is, it was a less than pleasant experience if you’re doing federation.  This is not a native Lync problem per se, but is more due to Windows 2008 R2; of course, this depends on your Outlook.

The migration process to migrate an OCS 2007 R1 Edge to Lync 2010 Edge is documented at the following URL:

The migration process to migrate an OCS 2007 R2 Edge to Lync 2010 Edge is documented at the following URL:

Note: The migration steps are in different locations.  The R2 migration documentation has you migrating federation and Media at the same time as an R2 Edge can do media for a Lync Pool.  The R1 migration documentation has you configuring Lync to use Lync Edge for Media while R1 Pool uses R1 Edge as an R1 Edge cannot do media for a Lync Pool.  Then, at a later time after all pools have been migrated, you cut over federation.

The Issue

The general issue is that Windows 2008 R2 has much fewer root certificates installed than does a Windows 2008 or previous operating system version.  In fact, Windows 2003 even has many more root certificates than Windows 2008. This doesn’t seem like a good trend going forward. Let’s take a look at a comparison between Windows 2003, Windows 2008, and Windows 2008 R2:

Windows 2003

Windows 2008

Windows 2008 R2

You can see, the amount of root certs has gone down drastically.  Now the problem is that when doing federated communication from our Lync 2010 Edge Server to other partners, the communication will occur using TLS.  This means the federated partner needs to contain the root certificate for our external edge certs and our Lync Edge needs to contain the root certificate for our federated partner’s external edge certs.  As you can see, Windows 2008 R2 doesn’t contain many root certs so this presents more risk for federated communication failures.  And… this is exactly what we saw.

What we actually saw is many of the following errors for many different federated organizations:

As we can see, we’re missing the root certs to communicate properly with our federated partners.  What to do?  Well… the solution is actually relatively simple.

Open up one MMC console but add 2 certificate snap-ins.  One is local on the Lync 2010 Windows 2008 R2 Edge and one is remotely connected to either a Windows 2003 or a Windows 2008 Server.  From the Remote 2008 or 2003 box, in the Trusted Root Certification Store, copy root certs (don’t cut as you still need them on the remotely connected machine) and paste into the Trusted Root Certificate Authorities store on your Lync 2010 Windows 2008 R2 Edge Server.

Afterwards, you will now have a Lync 2010 Windows 2008 R2 with the proper Trusted Root certificates in order to negotiated TLS with your federated partners.   One thing to keep in mind, you may still be missing a root cert after doing this.  You can still monitor 14428 event entries on your Lync 2010 Server 2008 R2 Edge and see what certificate vendor they are using.  Then go hunt down that root certificate on either a Windows 2008, Windows 2003 Server, or via the CA vendor’s website.