MS recommends using ADAMsync to sync data with ADLDS. But in the past ADAMsync has had problems with aging see KB927053. So I ended up writing a custom script to do the syncing for me.
I have no idea if the aging issues have been fixed with the switch to ADLDS.
Update:
These where written for ADAM but I assume they still apply.
To filter objects you can use a LDAP query in the object-filter field.
This has been a fun topic of discussion on Server Fault. There appear to be varying "religious views" on the topic.
I agree with Microsoft's recommendation: Use a sub-domain of the company's already-registered Internet domain name.
So, if you own foo.com, use ad.foo.com or some such.
The most vile thing, as I see it, is using the registered Internet domain name, verbatim, for the Active Directory domain name. This causes you to be forced to manually copy records from the Internet DNS (like www) into the Active Directory DNS zone to allow "external" names to resolve. I've seen utterly silly things like IIS installed on every DC in an organization running a web site that does a redirect such that someone entering foo.com into their browser would be redirected to www.foo.com by these IIS installations. Utter silliness!
Using the Internet domain name gains you no advantages, but creates "make work" every time you change the IP addresses that external host names refer to. (Try using geographically load-balanced DNS for the external hosts and integrating that with such a "split DNS" situation, too! Gee-- that would be fun...)
Using such a subdomain has no effect on things like Exchange email delivery or User Principal Name (UPN) suffixes, BTW. (I often see those both cited as excuses for using the Internet domain name as the AD domain name.)
I also see the excuse "lots of big companies do it". Large companies can make boneheaded decisions as easily (if not moreso) than small companies. I don't buy that just because a large company makes a bad decision that somehow causes it to be a good decision.
Best Answer
Just as with AD, you don't cluster AD LDS using MSCS. You configure it to have replication across LDS servers (just as AD, so you don't have shared storage like you need with clusters). There's (as near as I can tell) a feature called a Service Connection Point, which publishes the instance information into AD, so that clients can just bind to an instance, not one or more specific LDAP servers (LDS servers).
/edit - also, it appears that you can use NLB to front-end AD LDS. That will also handle the front-end connection in a HA manner.