According to Microsoft's documentation and the (expired) Internet draft "Incremental Retrieval of Multi-valued Properties" <http://www.ietf.org/proceedings/02mar/I-D/draft-kashi-incremental-00.txt>, supportedControl (incorrectly identified in the draft but correctly indentified here) should contain 1.2.840.113556.1.4.802. As far as I know, Active Directory is the only directory that supports this option.

Not all clients correctly parse the results, as the option is not, strictly spearking, implemented in a standard way. The JNDI LDAP provider should work correctly, though.

Trevor, do you know of a control id for the ranged search results for attributes? In other words, is there a way I could ask the LDAP server "hey, do you support this?" and then use it, similar to the other features?

That actually shouldn't be the case. The searches do "true ldap searches", so the paged results should be irrelavent assuming you aren't getting back a lot of pages of csm results. =) Anyone else running into problems with searching?

As for the contact list sharing, that's something I plan on looking into. It's kind of bizarre that it takes that long. My assumption is that it's doing a getUsers search even if it doesn't have to. It's hard to say without trying it some more though and watching what occurs.

I also experienced the Problem that If i enable Contact-List sharing the server takes about 30 seconds and only adds 4 from 16 users to the shared roster
I first thought that this 4 users are only users which are in the first 1000 of results, but they're not.
That's really a problem, do the sharing for all 16 users by hand is some work.

A short example:
If i search in groups for 'csm' then i get an empty result page, but on the top there are 17 pages shown, so i think this is also an issue related to the paged results, 'cause we have about 40.000 groups