On my last project I ran into the chasm of the SharePoint 2010 people picker resolving to users across multiple domains. There's loads of blog posts out there (first, second, third), plus the Microsoft documentation, but there's one important piece missing to all of these posts.
In my scenario, corp.domainA.com contains all of the users (~1,600 in this case), and domainB.com contains all of our SharePoint servers, service accounts, etc. Now, the documentation states that if you have a two-way trust in place, then you don't have to do anything special to make SharePoint resolve those accounts within the trusted domain. In this scenario, a two-way trust is in place, but the trust is between the root (domainA.com), and domainB.com. I'll preface this with the fact that I'm not an Active Directory guy, but my "expectation" would be that if the root domain is trusted, the child domain is also trusted. That seems to be the case, but SharePoint will not resolve down to "corpuser" accounts when searching for a user in the people picker. My assumption is that despite the trust, SharePoint doesn't dive into a child domain of a trusted domain during the query, unless you tell it you want it to.
The solution is to use the peoplepicker-searchadforests STSADM operation (yes, this is one things that you still have to use STSADM for--no PowerShell equivalent yet). The other thing to note, which I didn't see mentioned in any of the blogs or documentation I found, is that you must run the STSADM operation against every URL for your web app. So if you have one or more Alternate Access Mapping setup on your web application, you must run the STSADM operation against those AAMs.
So in our case:
stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:corp.domainA.com;domain:domainB.com -url http://intranet stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:corp.domainA.com;domain:domainB.com -url http://intranet.domainB.com