Topic Last Modified: 2011-04-11

In Office Communications Server 2007 R2, if the parameter PartitionByOU (maintained in Windows Management Instrumentation (WMI)) is set to TRUE, then a user search returns only contacts of other users that are members of the same organizational unit (OU) as the user that submitted the search. This is a very handy feature if your organization has a group of users that would prefer not to have their contacts revealed by general user searches.

In Lync Server 2010, WMI is deprecated in favor of the Central Management store and Active Directory Domain Services (AD DS) for the management and storage of settings for user or server objects. The re-engineering of this feature takes into account that many organizations have a very rich structure of OUs, and limiting users to siloes based on OUs became a boundary that was no longer feasible as a user management practice. Users need to have visibility beyond their OU. Lync Server 2010 adds an attribute onto user objects. This attribute, msRTCSIP-GroupingID, can be populated with the Globally Unique Identification (GUID) unique to users that need to be able to search for each other. Unless the user is a member of the tagged group, the search results will not display the user contacts. However, it should be noted that even though a user may not be able to receive search results for specific users by means of the Address Book, this does not prevent them from using email contact information or manual entry of contact or phone number information.

For customers that are currently on Office Communications Server 2007 R2 that have been using the PartitionByOU method, there are two possible scenarios to move from the PartitionByOU to the msRTCSIP-GroupingID method.

Option 1: Set the msRTCSIP-GroupingID attribute on the user object with the GUID of the OU, for all users in that OU. This method ensures that the members will still retain the same functionality that they have enjoyed to date. The attribute can be populated with a Windows PowerShell cmdlet or script.

Option 2: Design the partition that you want from scratch, and then populate the attribute of the user objects according to your organization’s needs. New customers and existing Office Communications Server customers who are looking to redesign their current solution would use this approach.

A recommended approach would to be to write a Windows PowerShell script to populate the attribute for the users that you silo into the groupings.

If you choose to use the msRTCSIP-GroupingID to silo users into specific groups, the following table describes a simple configuration:

Users	GroupingID	OU ID
User1	GUID 1	GUID X
User2	GUID 3	GUID X
User3	GUID 2	GUID X
User4	GUID 1	GUID X
User5	GUID 3	GUID X

If User1 searches for contacts, the result would be User4, and User2 would have a result containing User5. The OU ID has no impact on the search results, only the GroupingID attribute.