You can limit the scope of Lync directory searches by defining multiple address books, often referred to as address book partitioning or segregation. The concept is quite straight forward; out of the box every user exists within the same default address book and can search for everyone else. By modifying the properties of a user and placing them in an alternate address book, their search results become restricted to other users in that same address book. In the same vein, users in the original default address book will no longer see the modified users in their own results. It’s of great importance to stress that this is purely cosmetic and relates solely to search functionality. Defining multiple address books will not prevent users from typing the full URI of a user and adding them as a contact in Lync. Further more it in no way restricts or impedes the ability of a user to call or IM another user, we’re purely affecting search results by logically grouping users. To that end defining multiple address books should not be viewed as a security measure. If you’re organisation requires an ethical boundary / wall solution that truly segregates users operating on the same platform and removes all interoperability between them, then a third party solution would be required for this task.
The aforementioned property that allows us to control this behaviour is the msRTCSIP-GroupingID attribute in an active directory user object. The attribute can be viewed under the ‘Attribute Editor’ tab in the properties of any given user account. Turn on ‘Advanced Features’ from the ‘View’ menu of active directory users and computers if you don’t see the ‘Attribute Editor’ tab. Below you can see that Ironman currently has the default Null value associated to this attribute. This is true for every single user in your environment, which is why everyone resides in the same address book and is searchable by everyone else.
To siphon a user off into a new address book, we simply need to modify the above value to something other than null. The value must be a GUID (globally unique identifier), and users who go on to share the same GUID will reside in the same address book. As an example; to split 100 users into two address books (50/50), we would leave 50 users untouched with a Grouping ID of Null, and apply a new common Grouping ID to the remaining 50. This would result in two distinct address books whereby users will only be able to search for users who share the same GroupingID.
Typically users who we would like to be in the same address book will also reside in the same OU, or if in multiple OU’s will likely share the same parent container. In my reading, it seems to have become a practice to use the Object GUID of the OU / container that the users reside in as the new msRTCSIP-GroupingID value. This makes sense given that the logical grouping you are looking to create in your address book scheme is likely already reflected in your active directory OU structure. You can view the object GUID of an OU or container by once again looking on the ‘Attribute Editor’ tab on its properties page, and locating the objectGUID attribute as seen below in the properties of my Gecko-Studio OU.
By selecting ‘View’ or double clicking the attribute to open the attribute editor window, you can easily copy the Hex value to your clipboard. All we simply do from here is head back to the msRTCSIP-GroupingID attribute of our chosen user and paste the Hex value in as the GroupingID value. We’d add this same value to all users who we want to segregate from the default address book. If you wanted to create a third address book, then another GUID value would need to be used for all those users. In my example, the objectGUID for the OU that Ironman resides in is ’95 29 FB 5F 37 53 F6 44 BD E7 ED AF 65 78 3A 87′, so I will using this as the msRTCSIP-GroupingID value on his account.
Once you’ve finished editing the msRTCSIP-GroupingID for your users, open the Lync Management Shell and run the Update-CsAddressBook in order to generate the newly defined address book. Be patient, once the address books have been updated you will see an extra folder located in %LyncShare%\1-WebServices-1\ABFiles\00000000-0000-0000-0000-000000000000. The first 6 characters in the folder name will be different, but the remainder will be identical to the value that you used for the msRTCSIP-GroupingID.
From this point on Ironman will only be able to search for users in his Lync client who share the same GroupingID value, he would not see anyone who still has a value of Null. Also note that if you are performing this as a planned action prior to enabling someone for Lync, then it will work right off the bat. But if you have already enabled a user for Lync and then decide to change their GroupingID, they would have already downloaded and cached a copy of any previous address books. In this instance you will need to delete the locally cached GalContacts and GalContacts.db.idx files from the below location on the client.
Automating the Process
Changing the GroupingID of hundreds or thousands of users en masse using the aforementioned manual method would not be feasible. A chap by the name of Sundeep Paluru has kindly contributed a freely available script to the TechNet community gallery (RTCSIP GroupingID Lync Addressbook.ps1) that can automate this process. Executing the script will prompt for an active directory OU or container name, and then take the GUID of that OU or container and apply it as the GroupingID for all user objects nested within – so naturally it requires that your active directory is structured in such a way that it reflects your address book requirements. Also be aware that the script has no way of removing GroupingID values, so if you run this against an OU with 10,000 users in, you better be sure.
In addition to Sundeeps script, you might choose to use PowerShell to modify a users properties on mass. Although there are many different ways to skin this cat through PowerShell, an example piece of code can be found here.
Thirdly, there are an array of active directory bulk editing tools available on the market. Classic uses for these include uploading of employee images to AD, and editing of attributes that are common across all users with ease – you might choose to use a software based solution like this to edit the GroupingID value of users in bulk.
Remember, each user can only have one GroupingID associated to them. So once you apply a different value to even just a single user, that means there will be no one in your organisation who is capable of searching the entire company. Note also, that implementing this to prevent people from searching a particular individual, also then means that particular individual will not be able to search for those people they’re hiding from!