#response groups

In this post I will cover how to hide Response Groups from the Lync Address Book. You can hide users by setting the msExchHideFromAddressLists value to TRUE either by using the Exchange Management Console or Exchange Management Shell (If you have MS Exchange). You can also hide contacts (e.g. Common Area Phones/Analogue Devices) by setting the same value to TRUE using adsiedit. Microsoft also provide a tool in the Lync Resource Kit called ABSConfig that lets you configure who to include in the Address Book files.

To hide Response Groups you can use the same msExchHideFromAddressLists value but you need to find the object in adsiedit which can be a bit tricky. In this example my Lync global AD settings are stored in the Configuration container but yours may be in the System container.

System Container:        CN=Application Contacts, CN=RTC Service, CN=Microsoft,CN=System,DC=domain,DC=local Configuration Container:    CN=Application Contacts, CN=RTC Service, CN=Services,CN=Configuration,DC=domain,DC=local

Open adsiedit (start > run > “adsiedit.msc”)

On a 2008 R2 server by default you won’t see the configuration partition in adsiedit

Right click “Default naming context [dc.domain.local]” and click “Settings”.

Change “Select a well known Naming Context:” to “Configuration”.

Expand Services > RTC Service > Application Contacts

As you can see it is not easy to identify your response groups in the Application Contacts container. For each object if you right click and select properties you will see the Attribute Editor:

To identify which response group the object refers to find the “proxyAddress” value. This is the sip address of the Response Group. Once you have identified the Response Group you want to hide from the Address Book, find the value “msExchHideFromAddressLists” and set it to TRUE.

I've recently been looking at an issue where connection times when dialling a response group (RGS) have been longer, well, longer than you would expect or hope. This was briefly covered in the TechNet forum posting here by Jeff Shertz but doesn't go into too much detail. So to hopefully save other people time I thought it best to blog about it.

In this scenario we have both Snom and Polycom CX600 desk phones in production. Below is a summary of the RGS connection times in testing.

Snom -> Polycom = 7/8 seconds

PSTN -> RGS = 1-2 seconds (to be expected)

Polycom -> RGS = 5 seconds 

After much investigation I found the above behaviour is to be expected, even the increased delay for the Snom (Snom support confirmed this). As Jeff notes in the above article Microsoft should be releasing CU2 for Lync Server 2010 in April which should eleviate the problem although I've had no confirmation directly that it will. Snom also said they are working with Microsoft but wouldn't commit to whether CU2 would fix the problem although I suspect it will definitely improve performance. 

Any questions on this drop me a tweet - https://twitter.com/#!/LyncServerPro