Thursday, April 12, 2012

MOSS 2007: New Users Not Found On Select People And Groups Dialog Search

Since I spent so much time troubleshooting through this issue I thought it needed to be posted somewhere.



I heard complaints from some users about an issue when they tried to give permissions to new users joining the organization, in SharePoint. The issue seemed quite random and the first thing that came to my mind was to check the User Profile Synchronization.


We have a mid-sized SharePoint farm with 2 web front end servers and 1 application server running MOSS 2007.



The User Profile Synchronization seemed to be fine, and I couldn't find any errors in the crawl logs. I was able to find the users in the Shared Services Administration / SSP / User Profiles and Properties / View user profiles.


I was convinced that the users existed in AD and that SharePoint was able to import their profile properties.


These are the steps I followed to reproduce the odd behavior:



  • Go to Site Actions / Site Settings / People and Groups
  • Select the Site “Members” group from the quick launch
  • Select from menu bar New / Add users
  • At the Add users page I clicked on the Address book icon
  • At the Select People and Groups Dialog box I searched for first name, last name or Domain\User id of a recently added user in AD

I've got the following message in red: No results were found to match your search item.


I found that I was able to grant permissions if I skipped the Select People and Groups Dialog Box that is, clicking the Address book icon and instead I type in the user ID in the standard Domian\User ID format, then clicking on "Check Names" icon to resolve the names at the Users/Group white box (or people picker).



This was our workaround to grant site permissions while I researched. Google search results didn't provide any solutions.



The next day I found that the users that wouldn't come up in the results at the Select People and Groups search, were showing up! I just couldn't make any sense out of it.



After several hours troubleshooting this issue and going nowhere, I thought of testing this straight from the MOSS servers, and I'm glad I did!



So, I looked for some user ID's recently added in AD and tested. I discovered that the odd behavior would show up when testing through any of the web front end servers, which they sit in the DMZ; while testing on the application server which lives guarded behind our firewall, would return the user search as expected.



This new information changed the focus of my troubleshoot effort. I thought that most likely, SharePoint servers in the DMZ were not able to talk properly with the AD server, but still it wasn't clear why sometimes the users were found; just like the next day when I tested and the users previously added to the permissions group where found in the same People and Groups search results regardless of the client machine or browser running the query.



More research revealed that there’s a hidden 'User Information List' at http://site/_catalogs/users/, apparently this list, which exists at the Site Collection level, gets populated when a user is given permissions over the site and/or they log into the site for the first time.



All my testing and the experienced behavior was pointing to the fact that there were two different mechanisms in play. The Users/Groups people picker's Check Names button, would validate and resolve the user straight at the AD, while the SPAG Dialog Box (Address Book icon) would 1)Attempt to validate against the User Information List, if the user was not found then 2) it would query the AD server. It was obvious that the latter was failing.

I asked our Network Administrator to help me troubleshoot this. He traced the network communication just as I search for a User through the SPAG Dialog box, and he discovered that the SharePoint server was trying to communicate with the AD server through specific ports that we're not allowed on the firewall rules.

The issue was resolved by setting firewall rules for ports 80, 3268 and a range of RPC ports.

Mystery solved!



No comments:

Post a Comment