Which Way did They Go?

One of the big attractions (and honestly, biggest fears) of SharePoint for overworked Network Administrators is its ability to delegate permissions management to site collection owners. For purposes of this article, I'm going to gloss over the details of where users are coming from. Suffice to say that they can come from Active directory, or any number of other sources. I'm also not going to talk about breaking inheritance, or anything like that. Instead, I'm going to show you where to find a very useful tool.

Generally speaking, if you have groups available, you want to use them to apply permissions in SharePoint. For example, you might put a network (Active Directory) group into one of the default SharePoint groups. Although it isn't an ideal practice, on an Intranet, it is common to apply a base level of permissions to anyone who has logged into your network:

Once users log in and start doing things, they leave a trail of things they have touched, and thus show up as users in SharePoint. On SharePoint 2007, you had an easy to see option to list who had actually done things on your site. This was the "All Users" view. Unfortunately, in SharePoint 2010, there is no obvious way to access this same information. In fact, there are several types of users who you can't readily see:

• Individuals who are members of Windows groups (such as Authenticated Users above).
• Site Collection Administrators
• People given permissions through Web Application policies

The good news is, the information is still there. To get to it, open any group in People and Groups:

Then, in the URL, change the "MembershipGroupId" to zero:

This will result in the classic "All People" view showing up, including every user who has made updates to your site!

A Word of Caution

Although this view is very useful, there are probably good reasons that it was suppressed in SharePoint 2010. The most likely has to do with a classic SharePoint foible - the so-called"2000 item limit". While that is not (and never was) truly a "limit", the fact is that when lists grow to many thousands of items, rendering views can get pretty slow.

SharePoint 2010 has made great strides in working around this issue compared to SharePoint 2007, but there are still some performance constraints when rendering large lists. Given the importance of the Users list, having it locked during a large read could be "a very bad thing." In a large environment, you could have tens (or hundreds) of thousands of people accessing a singe site collection, meaning tens (or hundreds) of thousands of items in the Users list. Attempting to render an unfiltered view of "All People" in such a case could be disastrous.

So, now that you know how to find the All People view, you need to treat it like a sharp knife or a power tool. Handle with Care!