Woody Windischman

Aug-222011

Calling All People

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!

Published: Aug-22-11 | 0 Comments | 0 Links to this post
Tagged as: Administration, Lists and Libraries, SharePoint 2010, Design

Oct-202010

Simulating Explorer View in SharePoint 2010

Getting back what was taken…

SharePoint 2010 is leaps and bounds better than any previous version in many ways. However, there are areas where some folks feel a little bit was lost in the translation. One of these areas was the ability to create a view of a document library that actually used Windows Explorer “behind the scenes” to let you perform drag and drop style file manipulation. For SharePoint 2010, the Explorer View was replaced with an icon in the Library toolbar to “Open with Explorer”. This opens your library in a separate window, using the full Windows Explorer.

Note: Depending on your window size, the labels for Outlook, Excel, and Explorer may not be displayed.

While there are a lot of reasons the Explorer View option for Web Parts was taken out, the desire for that feature is still going strong. Although it isn’t exactly the same, the following workaround will get you pretty close to the old Explorer View. This is accomplished through a venerable web part that has been a part of SharePoint since the very beginning – the Page Viewer. A page viewer, in essence, is an HTML IFrame that you control through the SharePoint interface. It is capable of displaying almost any content that you can point a browser at.

To add a page viewer, start by editing a SharePoint page. Either in a Wiki Content zone or a Web Part zone (depending on your page type), select Insert, and click the Web Part tool in the ribbon, as shown below:

Select the Page Viewer part from the Media and Content category, and click the Add button. In the web part’s context menu, select “Edit Web Part”. Change the view type to Folder, and enter the UNC path to the document library you want to view (e.g. \\shareppointserver\site\library), as shown here:

Click OK or Apply, and voila! You will now have an explorer window on your page, that points to your document library. You can Edit the properties to give it a more reasonable title, or to make it an appropriate size for the page at hand.

There are a couple of caveats when doing this, however. The biggest one being that you don’t want to use this function on an Internet Facing web site, or on a population with browsers other than Internet Explorer. The other thing is, like the original Explorer view, you can’t control the window settings your users may have. Thus each person may get a slightly different experience.

Still, if you miss the Explorer View of a document library for embedding in a page, this is the only way I have found to make it happen.

Published: Oct-20-10 | 5 Comments | 0 Links to this post
Tagged as: Administration, Customization, Lists and Libraries, SharePoint 2010, Design

Dec-132009

SharePoint 2010 - Everything Old is New Again

"You Must Un-learn what You Have Learned!"

The public beta of SharePoint 2010 has been out for a few weeks now. Many people are discovering and blogging about some of the great new features you're going to find. Yet there have also been some significant changes to existing features. These are things you may have been using every day in SharePoint 2007 and WSS 3.0, but which in SharePoint 2010 have moved or changed in ways could cause confusion to experienced users.

In this article I'm going to focus on changes the typical end-user would see. In future articles I'll talk about changes for site owners and administrators.

If it Ain't Broke…

SharePoint 2007 took a lot of heat for having certain "quirks" in its user interface design. For 2010, much as they did for the Office clients in 2007, Microsoft put a lot of R&D into what it would take to make SharePoint easier for typical users. This resulted in a lot of changes.

Human beings are creatures of habit. With certain notable exceptions, we don't much like change. Despite having worked through a non-intuitive learning curve, or sometimes because of it, we would rather keep doing things the way we are used to than learn new ways - even if those ways are better.

...Fix it Anyway

Only time will tell if the changes Microsoft made truly are for the better, but they've definitely been made. Let's start by looking at the basic team site page in SharePoint 2010 side by side with its SharePoint 2007 equivalent:

At first glance, they're pretty similar. The WSS logo has been replaced with a "real" picture, but there's still a banner, title area, quick launch, and content space. But look a little closer. The Site Actions menu has moved. No big deal there - lots of custom master pages move that around. But, the new placement is comparable to the Backstage/File menu in the new Office 2010 client applications, thus making it a "natural" place for users to look for "application"(site)-wide functions. This analogy becomes even more obvious when some of the other tabbed interface options start showing up. (You'll see that later in the article.)

Where's MySite?

Another subtle change is the "personal" section of the banner. In SharePoint 2007, you had separate entries for User ID, links, and a direct link to your "My" site.

All of these options are now accessed through the menu under your name. There is also no reference to My "Site", rather it simply calls it your "Profile".

I think the hope here, is that by de-emphasizing the "independent site" aspect of the profile and personal storage, while actually expanding its function (the new profile features could fill up several articles on their own), resistance to deployment in certain enterprises would be reduced.

Bread-Crumbling Navigation

Getting around from site to site, and from place to place within a site, has received a LOT of attention in SharePoint 2010. In many cases, this has meant "reimagining" the concept of a breadcrumb.

In the case of 2007 site navigation, a breadcrumb stretched across the top of the page content area:

For large site hierarchies, this could become unwieldy as it stretched across the page. For 2010, Microsoft replaced it with a folder icon in the tab banner, which produces an indented hierarchical view of your current location:

Going the other direction, in SharePoint 2007 lists and libraries selecting a view was accomplished by selecting it from a drop-down list on the toolbar.

In SharePoint 2010, there is no list toolbar. While you can drill into the ribbon and find the view settings, then select your view, that's a lot of clicking. Fortunately, Microsoft has turned the title panel into an in-site breadcrumb. When looking at a list or library, the last item in that breadcrumb is the name of the current view. If you look carefully, you'll notice that there is a "down triangle" arrow. That's your hint that this element is actually a dropdown menu, where you'll find all of your view selecting goodness.

Tied up with a Ribbon

Of course, the rest of the stuff that used to live on a list or library's toolbar:

has been moved into the Library tab of the new ribbon interface:

By the same token, individual items that lived in an individual item's dropdown:

have been moved into the Documents (or other appropriate item's) tab:

Note: In this case, the individual item dropdown is still there as well.

Summary

Some folks say, "The more things change, the more they stay the same". There have been a lot of changes in SharePoint 2010. While there are some things that have stayed the same, they are actually in the minority. In this article, I have gone over some of the many changes to "carry over" functionality you will find when moving from SharePoint 2007 to SharePoint 2010. There are many more than I could hope to address in a single posting. I hope, however, that this article has given you some ideas of where to look if you can't find your favorite function where it used to be.

Published: Dec-13-09 | 6 Comments | 0 Links to this post
Tagged as: Design, Office 2010, Lists and Libraries, SharePoint, Training, SharePoint 2010, Upgrade

Sep-202009

Indexing SharePoint List Columns

MCj03800210000[1]

Helping SharePoint Help You

A SharePoint system manages a huge amount of data. Amazingly, in a SharePoint content database, all of the data, for every list and library item, in every site and subsite, is stored in a single table. Looking at hundreds of sites, each with dozens of lists and libraries, each potentially containing hundreds or thousands of items, and you end up with one massive table!

Not So Limiting After All

Everybody has heard about the so-called "2000 item limit" in SharePoint. Remember that this isn't really a limit. SharePoint is quite capable of handling lists with tens, or even hundreds, of thousands of items. The issue is the "rendering" of those items, which starts becoming perceptibly slower if you have more than 2000 items in a single view.

While the indexing discussed in this article can have a minor effect on this rendering, it really is more general, and can improve list performance across the board.

Ask any DBA how to achieve maximum performance on a huge table, while other options may also come up, at a minimum you'll always hear the word "indexing". And make no mistake - SharePoint (whether Windows SharePoint Services 3.0, or Office SharePoint Server 2007) does do a lot of indexing. But that is only dealing with the user data table as a whole.

Once SharePoint has figured out which site and list the data belongs to, normally it is pretty much done with indexing. When you perform a query - whether in code, or for a web part view - each item in the list is examined individually for a match. As the amount of information in your sites grows, this can take quite a bit of time and cause significant slowdowns (This is independent of the "2000 item limit" - see sidebar).

Fortunately, you don't have to put up with this default behavior. SharePoint gives you the additional ability to index the information within individual lists or libraries.

Look at the settings page for just about any list or library, and you will find a link for "Indexed columns":

When you click the link, you will be given the opportunity to select which columns in your list you wish to index. This is where an understanding of your information, and how you use it comes into play. While you could just click everything, that isn't usually a good idea. For each column you index, SharePoint needs to store extra information about every item in your list.

You should only select columns for indexing that you will be using to query/filter, sort, and group your list. For this list, I'll usually need to do this with the item's title (or name), who created or modified an item, and when it starts. So those are the columns I'll select to index:

Note: When setting up indexed columns, you will almost always want to include the title or name field.

Once you click OK, SharePoint will build the appropriate extra indexes. While there won't be any change to the way your list looks, you should see the performance results almost immediately. (Of course, the more items in your list, the greater the impact will be...)

One place you usually see immediate results is when you click on the context menu of a column title to change the sorting or filtering. The list of unique values builds much faster on an indexed column.

That's all there is to it! Setting up indexed columns in your SharePoint list really is that simple. Give it a shot, and you might be surprised at how much faster your SharePoint applications can be.

Published: Sep-20-09 | 8 Comments | 0 Links to this post
Tagged as: Administration, Lists and Libraries, Search Server, SharePoint, WSS

Next >>

The Sanity Point - Making Sense of the SharePoint World

Search

Categories

Links

Blog Roll

Archives