We have a strange problem with one of our MOSS 2007 SharePoint installations. When you use the people picker to find IDs in our Active Directory, it does not resolve them all! In one instance we created a new ID in AD, and SharePoint immediately saw it (we could resolve the ID using the people picker function) but when we went back to AD and created a new ID the same identical way, SharePoint couldn't see the new ID! One of our other SharePoint farms resolve both IDs just fine, it is just this one that is having problems. One difference between the two farms is that they are sitting in different Domains, so we are looking at anything that's different in how the Sharepoint servers are connected to the Domains... If anyone has seen similar problems with their SharePoint installations, I'd love to hear about it! -Richard.

hello Rich, have you checked the profile import settings? especially the schedule? Maybe when first time you added the new user entry in AD, profile import was running which immediately imported the user. Hope this helps, Regards, RC

I'll have to check with my Domain Admin, but I believe they are in the same Forest, but different Domains. There are also one-way trusts between some of the domains. However, that does not explain why the first test ID was immediately resolved and the second, almost identical test ID, in the same domain, in the same OU, created within minutes of the first test ID, was not resolved! We can add the IDs to an ACL on the server, so we do not believe that it is a Windows-AD issue, but a SharePoint-AD or PeoplePicker-AD issue. But because the other Farm can resolve the IDs, we suspect it is a SharePoint-AD issue, so we are looking at the service accounts next. It is almost like there's a load balancer in AD where SharePoint sees one side, but not the other, of the full picture. However, why this is showing up now after almost two years would be a mystery. See my other reponse about the "limit" theory, that does not work either... The help is appreciated! Thanks, -Richard.

I have a workaround! It is not pretty but it works... If you impersonate the user by using the "sign in as another user" capability, and get the SharePoint "access denied" error page, then you can resolve their IDs in the people picker. Only their ID get's imported into their profile, but at least you can provision them into a SharePoint group. I am waiting for our Import process to run to see if the rest of the user's information gets populated in their profile (like their FN, LN, email address, etc.) This was a bit of an issue finding out in our environment because we have the IIS Change Password utility installed, and new IDs were directed to the IIS Change Password page before SharePoint could recognize them. Unfortunately, the change password function did not work... When we unchecked the IDs' "change password upon next login" option it bypassed the change password utility and we were able to get the Access Denied error. We then went back and turned that option back on for those IDs. We are investigationg whether it is a problem with the service account, but we can't schedule a downtime for another week or so. So it may be awhile until I have more on that topic. -Richard.

This turned out to be an intermittant issue, as it no longer is a problem. We do not know what was the root cause of the problem unfortunately. Aw well! -Richard.