Last night I was working with my friend and fellow UC architect, Peter Pawlak, on a customer design item. This particular customer is a subsidiary of a larger organization. The subsidiary is deploying OCS but the parent company is not. Not a problem since each of them have their own forests. However, the parent company pushes down it's users as contacts via an LDAP replication tool. The issue was that the subsidiary is deploying telephony integration in their OCS deployment and the contacts that are coming from the parent company include phone numbers that are not formatted in such a way that they could be accounted for in the normalization rules (too many different formats). There were also duplicate phone numbers and other similar issues. In the end it was decided that the best plan of action was to simply exclude these contacts from the address book altogether.
To do this we used address book filtering. If you aren't familar with address book filtering, check the section around Table 19 of the OCS Technical Reference (page 78). What we had to do was find an attribute that did not exist for contacts but did exist for users and groups. We settled on SAMAccountName and Peter made the appropriate changes to the AbUserEntry table in SQL, excluding objects that do not have a SAMAccountName attribute by setting the 0x8000 flag for that attribute. This ensured that all users and groups were still included in the ABS.
Unfortunately the address book filtering capability for OCS is very basic, so you can't do things like string comparisons or value matching. There is a resource kit tool that provides a UI for updating the AbUserEntry table, but I have seen that tool cause problems so I don't recommend using it unless you are extremely uncomfortable making the changes in SQL yourself (make sure to take a backup first if you do this in a production environment!).
Hopefully MS will consider more advanced filtering capabilities as this is a common request from customers.
Posted
Jun 12 2008, 09:04 AM
by
Mike Stacy