Another Boston "T" Party?

The last time I was in Boston, it was for TechEd 2006. When I wrote about the experience on my old blog, I called it the "Boston T Party". It was my first TechEd, and it was a real blast!

Well, I found out yesterday that I'm going back to Boston for another technology conference. I'll be presenting two sessions at The SharePoint Technology Conference, June 22-24. This "T Party" will be a much more intimate affair, focused on helping you get the most out of SharePoint.

The organizers have just finalized the agenda, and posted it to the site along with updated speaker bios.

I look forward to seeing everyone in Boston!

You mean there are limits?!?

I had an interesting Twitter conversation recently. Someone was shocked when told that a single SharePoint server could handle tens of thousands of users. As an isolated point of fact, this is true.

But, there is a "but". And it is a huge one. Such support depends both upon what those users are doing, and what that SharePoint server is doing. Microsoft now has some excellent performance and capacity planning documents for SharePoint, and if you look at the one for WSS in a collaboration environment, you will see that even under their "heavy" usage scenario, up to 15k users could be supported. Dig a little deeper, however, and you notice a big assumption: only 2% of that usage is document management (DAV reading and writing).

Many people envision using SharePoint as a replacement for their regular network file shares. While there are any number of good articles pointing out why that isn't a good idea (at least not without some serious planning), they all rely on talking about the SharePoint side of things - stuff like the "2000 document limit" (which isn't really a hard-cap, but that's fodder for a whole different article). Even taking appropriate topology and taxonomy steps, heavy file-based SharePoint usage is going to significantly reduce the "rated" capacity of a SharePoint environment.

SharePoint Itself is Probably Not the Limiting Factor!

Yet with the "I can consolidate these file shares/servers into SharePoint" stars in their eyes, many of the reasons these separate systems exist in the first place are forgotten. In a non-SharePoint file-sharing scenario, would you envision 15,000 (or more) users accessing a single server, let alone a single file share within that server, on a day-to-day basis? Of course not! Now consider if the users are geographically spread out. Would you want to channel all of the current file-server usage in your remote offices through a single WAN link? Maybe you could consider it - if you have point-to-point fiber. But otherwise? I didn't think so.

So take SharePoint, which itself resides on a Windows server, and stores everything in SQL Server databases, and consider what an all-out consolidation would mean. The articles I linked to earlier can help you with the capacity and availability considerations for SharePoint itself, but don't forget that SharePoint is only one piece of the total puzzle. Your network, your geographical distribution, and other factors, need to play as large a role in your planning for SharePoint as they do with any other system in your enterprise.

Note: This article is also available on the online blog/magazine - End User SharePoint...

Human beings are creatures of habit. Once we become accustomed to certain ways of doing things, we want to keep doing them, even if "something better" comes along. I firmly believe that SharePoint Designer is one of those something(s) better. So much so, that I wrote a book about it.

Microsoft Office SharePoint Designer 2007 is a very powerful editing tool for most of the files you can find on SharePoint sites. It includes fully integrated editors for HTML, ASPX, CSS, and various others, with features such as WYSIWYG and IntelliSense.

Yet, you may have your own favorite editor that you want to continue using for certain file types. Fortunately, SharePoint Designer gives you the option of configuring which editors are used for the different file types.

Opening with an Alternate Editor

When browsing through a site in SharePoint Designer, you double-click a file and it opens in the "default" editor. But you also have the option to right-click the file, and select "Open With", to display a list of the available editors configured for that file type.

Notice that you also have the option to "Choose Program..."

This produces the standard Windows file association (Open With) dialog, listing the programs available on your PC.

At the bottom of this dialog, you have some persistence choices. If you want to use your selected application to open the file "just this once", uncheck both boxes. If you want the program you select to always be available as an "Open With" option for the type of file you have highlighted, check the first box (Associate...). Finally, if you have chosen to associate the program with the file type, you are also given the choice to "Set as default", which means that SharePoint Designer will thereafter use that program any time you double-click on a file with that type.

Configuring Editors "en Masse"

You aren't limited to configuring your editors on a file-type by file-type basis. SharePoint Designer also gives you direct access to configuring the editors it uses. To get to that option, from the Tools menu, select the Application Options entry.

Note: There is also a "Page Editor Options" choice on the Tools menu. While intuitive, this actually is not the item you want. This choice is for configuring options in SharePoint Designer's built-in editor.

Once you have selected Application Options, click the Configure Editors tab. You will get the dialog shown below:

On the left is a list of file types (Extensions), and on the right are the editors associated with the currently selected type. Or types. Notice that for popular graphic files, several file types are listed together, separated by spaces.

Many Microsoft Office applications have the ability to save files as HTML. The checkbox at the bottom of the Configured Editors tab gives you a blanket option of letting SharePoint Designer invoke the creating application when you try to open a file.

You can add or delete extensions and editors using the or icons over the appropriate column. Clicking the add icon will summon an "Open With" dialog similar to the one shown earlier. For extensions, there is an additional field to enter the extension itself. The other difference is, since it is summoned from a dialog who's purpose is association, the association check-boxes are not present in these cases.

A Real-world Example

Let's say that you want to open graphic file formats with Adobe Photoshop. You would first highlight the graphic extensions as shown in the earlier dialog. Then click the add icon, and select Adobe Photoshop from the list of programs - browsing to its location on the file server, if needed.

When you click OK, it appears in the Editors list. You can then use the buttons in the dialog to change its presentation order, and/or set it to be the default editor for your graphics files (the top item in the list automatically becomes the default).

From that point forward, Photoshop will appear in your options for opening an image file, and if you set it as default, it will open automatically when you double-click one.

Summary

SharePoint Designer provides an array of powerful, built-in, editing tools for many different file types. Yet, you may have files in your site that SharePoint Designer cannot edit "out of the box", or for which SharePoint Designer's included support is weak. Maybe you have your own favorite editors. Rather than forcing you to change your habits, by allowing you to associate different applications with your files, SharePoint Designer adapts to you.

Gift-wrapping Web Applications with the Page Viewer Web Part

With the Holidays upon us, everyone is putting things in boxes. Boxes are very convenient – they let you just drop something into them without having to change anything about the item being packaged.

As you start to deploy SharePoint in your organization, you will often find people wishing that they didn’t have to bounce from one web site to another all of the time. With Data Views, Search Federation, and other tools, you have seen how easy it is to get the information from other systems and applications into SharePoint. However, there are times when you just want to be able to get to another application directly within your SharePoint page.

Fortunately, there is a web part made just for such a situation – the Page Viewer Web Part. The Page Viewer is nothing more nor less than a box in which you can place and display content from another location.

You add a Page Viewer to your page just like any other Web Part.

The initial web part doesn’t have anything in it except instructions on how to add content:

Once you click the link to open the tool pane,

You can select a web page, a folder (file share), or specific file. Unlike some other web parts, this file is NOT accessed by the SharePoint server as an intermediary. It is retrieved and rendered directly by the user’s browser. Because of this, make sure you are specifying a location that is accessible from your expected users’ client PC’s.

Note: Technically, what you are doing is feeding an “iFrame” – essentially a browser within a browser.

You will probably want to adjust the settings of the "Appearance” section in order to make sure the web part is big enough to show the critical parts of the page you are selecting.

Then, once you hit “OK” and exit page edit mode, the external page is living happily inside your SharePoint site!

Of course, it is helpful if the site you are embedding in the Page Viewer offers a mode without a lot of extraneous “chrome”. Some applications offer a “portal mode” page, just for such usage.

So, that’s it. Very “back to basics”, but also potentially quite useful.

I hope you enjoy this little gift, in a little box, from SharePoint.

I wish you all a Merry Christmas!

Giving Your SharePoint Users Site-Specific Online Help

"Press F1 for Help" has been ingrained into the psyche's of PC users since even before Windows. OK, WordPerfect users originally had to press F3 instead, but the concept is the same.

In any case, SharePoint allows you to take advantage of this convention through its page event model. Page-level scripting in SharePoint has received a big boost in attention recently. Ever since Microsoft has announced its endorsement of JQuery in Visual Studio, articles are popping up all over as people learn to leverage this new framework. This is not one of those articles.

Introducing the WPSC

Instead, this is about one use of a component that has been a part of SharePoint (under various names) since it was called the Digital Dashboard Resource Kit - The Web Part Page Services Component (WPSC). I devote a whole chapter in my book to using this and other client-side components, but briefly, the WPSC is a set of JavaScript objects and functions that allow Web Parts to communicate with SharePoint, each other, and your users.

One of these functions allows you to register for events. These events can be defined in other Web Parts, or pre-defined by SharePoint. This example uses one of the pre-defined events - "onhelp". In essence, the WPSC watches for users to press the F1 key, and then raises this event so that any interested components on the page can respond to it.

Making it Happen

In general, working with a WPSC event requires two things:

1. Registration for the event
2. A function to execute when the event is raised (this is called an "event handler" or a "callback function")

For a help function, you will also want a page to contain the help information. You can create this page any way you like, but you might find it useful to make a Wiki Library for your help files. This makes them easy to update and expand as needed. For purposes of this example, let's assume you have a Wiki Library called "MyHelpLib", and the primary help page for this topic is "MyHelp.aspx".

1. The first thing you need to do is add a Content Editor Web Part to your page. From the Site Actions menu, select Edit Page:
   
2. Select a Web Part Zone, and cick the Add a Web Part link.
3. From the Add Web Parts dialog, select the Content Editor Web Part, and click the Add button. (It will probably be in the "Miscellaneous" section)
    
4. Once the part is added, click the "open the tool pane" link in the part:
   
5. Instead of clicking the "Rich Text Editor" button, we're going to click the "Source Editor" button.
   
6. The Source Editor is just a text entry window, with a Save and a Cancel button.
   
7. The code shown in the screen shot is correct, but here it is in plain-text form, which you can copy and paste into your text-entry window: <script language="javascript">
   function showMyHelpPage() {
   window.open('/MyHelpLib/MyHelp.aspx','MyApplicationHelp')
   }
   WPSC.RegisterForEvent("urn:schemas-microsoft-com:dhtml","onhelp",showMyHelpPage);
   </script>
8. Click Save.
9. There is one more change to make before we're ready to exit edit mode. So that this web part doesn't show up on the page, you want expand the Appearance section of the task bar, and change the the "Chrome Type" to None.
   
10. Click the Apply button, and the Exit Edit Mode link.

At its most basic, that's all there is to it! Pressing the F1 key on your page will now summon the help page you defined.

Taking it Further

Of course, that doesn't prevent you from getting even fancier. For example, you may want to set some parameters so your help window is a certain size, and centered on the screen. Once you have the basics set up the way you like them, you could export the Web Part to a .DWP file, and add it to the site's Web Part Gallery. Or, instead of using the script in a Web Part, you might put it into a master page, so it is available throughout your site without further intervention.

The following script is one you might place in shared Web Part or a master page. It adds the formatting parameters, but it also uses a variable for the "help context".

    <script language="javascript">
     var myHelpContext = '/MyHelpLib/MyHelp.aspx';
    function showMyHelpPage() {
     var width  = 500;
     var height = 400;
     var left   = (screen.width  - width)/2;
     var top    = (screen.height - height)/2;
     var params = 'width='+width+', height='+height;
     params += ', top='+top+', left='+left;
     params += ', directories=no';
     params += ', location=no';
     params += ', menubar=no';
     params += ', resizable=no';
     params += ', scrollbars=no';
     params += ', status=no';
     params += ', toolbar=no';
     newwin=window.open(myHelpContext,'MyApplicationHelp', params);
     }
     WPSC.RegisterForEvent("urn:schemas-microsoft-com:dhtml","onhelp",showMyHelpPage);
    </script>

This myHelpContext variable allows you to override which page is displayed by setting it on individual pages. In a web part, you just edit the myHelpContext variable for the page you are on. If the main script is embedded in a master page, you would just add a Content Editor Web Part (as described above) with a very short script block:    <script language="javascript">
     myHelpContext = '/MyHelpLib/ThisPageHelp.aspx';
    </script>

In either case, pressing F1 gives that page's help.

Conclusion

In this article, I have given you a taste of the power available to you with the SharePoint client-side scripting model, and the Content Editor Web Part. We used the event model to provide traditional, F1, Help to your users. But the Web Part Page Services Component (WPSC) gives you access to many other functions as well. You can find many of them documented in the Windows SharePoint Services SDK, and you can see more examples of how to use them in my book. I hope you will take this to heart, and discover even more ways of using the SharePoint client-side programming model!

"It's not just for Firefox anymore"

Today I'm going to talk about one of the earliest enhancements that was available for the current release of SharePoint. It has been around for so long, that it has either fallen off folks' radar, or has never made it onto the screen for newer users. That's a little sad, because it has always been a very useful component, and in its latest release is even more so. What is this magic add-on? The Telerik RadEditor Lite.

Considering the complexity of the markup SharePoint generates, its out of the box cross-browser compatibility (though not perfect) is pretty good. One area of weakness for non-IE browsers, however, is rich text editing. Recognizing this, Microsoft came to an agreement with tools vendor Telerik, whereby they would produce a version of their RadEditor that could be downloaded and used within SharePoint sites - without cost, and without sacrificing supportability. (They had a similar deal for Content Management Server, or CMS.)

That was the state of affairs in 2007, which is all well and good. But, time marches on, and it is almost 2009. If you are new to SharePoint, or if that early release was the last time you evaluated (or updated) the RadEditor Lite, you could be missing out on some nice improvements that go beyond cross-browser compatibility.

Note: Almost everything in this article applies to all "rich text" experiences within SharePoint, from Announcement lists, to MOSS Publishing Pages (the original purpose). I'm going to be using a SharePoint's Wiki here for two reasons:

1. Wiki pages, by default, are basically one big rich text field, making screen shots easy to get and understand.
2. One of the primary complaints about the SharePoint Wiki feature is that it is too hard for users to incorporate images into their pages. As you will see, the RadEditor Lite makes this problem go away.

The Basics

Consider the default SharePoint experience. For most users, just browsing the site, things are pretty consistent, regardless of whether you are using Internet Explorer (left) or Firefox (right):

 
(Click on the image to see the full-sized screen shots, if desired.)

But click the "Edit" option, and you can see the problem -

In IE, you get a traditional editing toolbar, and everything looks pretty much like it does on the read-mode page:

But in Firefox, all you see is plain text, with embedded HTML markup:

Not exactly the experience you want for a typical, non-technical, user - the kind that Wikis were intended for.

Installing the RadEditor Lite Control

The first step, of course, is to download the control from Telerik's web site. It isn't exactly high-profile for them these days, so you'll either have to dig for it, or just follow the download links I've provided on this page.

That that will get you is a ZIP file containing an EULA document, the solution package (RadEditorMOSS.wsp), and a very extensive help file. Since I'm not going to go into all of the customization details possible with this control (and there are a lot of them), you might want to keep this in mind.

This control does not provide an automatic installer, so you will need to manually add the solution to your farm.

1. Extract the WSP from the ZIP file
2. Add the solution to SharePoint:
   stsadm -o addsolution -filename {path you extracted to}\RadEditorMOSS.wsp
3. Deploy the solution to the web applications where you want to make this control available. You can do this either through the Operations tab of Central Administration, or by using the STSADM command with the deploysolution operator.
   Note: This solution is deployed on a per-web application basis, not farm-wide.
4. Activate the feature on the web sites where you want to use the RadEditor Lite.

Notice the granularity allowed in the deployment. The feature activation itself takes place at the Site, rather than Site Collection level. You also have two options for activation:

1. Use RadEditor to edit List Items
2. Use RadEditor to edit List Items in Internet Explorer as well

Once you have activated the first feature, you will see that FIrefox now shows a much richer editing experience, complete with all of the expected toolbars:

If you using RadEditor Lite on MOSS, you're done! Maybe (see the next section). If you are using it on WSS, there are a couple more steps to perform on your server. This is because, by default, the RadEditor Lite relies on some controls that are part of MOSS. However, it does have its own built-in controls that perform similar functions, so you just need to adjust an XML configuration file. (You can use RadEditor's native controls on MOSS, too, by making the same adjustments.)

The XML configuration file is usually located at:

c:\Program Files\Common Files\microsoft shared\Web Server Extensions\wpresources\RadEditorSharePoint\4.5.4.0__1f131a624888eeed\RadControls\Editor

"4.5.4.0__1f131a624888eeed" above is the version of the control you are using, and so may vary.

You need to edit the file named "listtoolsfile.xml"

Find the line

<tool name="MOSSLinkManager" />

and edit it to remove "MOSS", resulting in a tag reading:

<tool name="LinkManager" />

I would also add one of the following lines:

<tool name="AjaxSpellCheck" />

or

<tool name="SpellCheck" />

The tool provides spell checking, so why not use it?

Progress is Progressing

There are a couple of questions you might be asking yourself at this point:

• Why are there two separate activation options? and
• Why would I need to use this control in Internet Explorer, when it already supports rich text editing?

The answer to the first question is this - when the free RadEditor Lite was first released for SharePoint, it was officially licensed for one purpose - to provide rich text editing to non-Internet Explorer browser users in MOSS Publishing sites. That is because the agreement with Telerik was carried over from a similar agreement relating to Content Management Server (CMS), and MOSS Publishing was the direct replacement for CMS functionality. It wasn't until much later that the agreement was expanded to allow use on WSS and for non-Publishing scenarios in MOSS. The original activation option allows for full compatibility with the pre-expansion scenario, while the second activation allows for the answer to the next question.

The second answer has a few different facets. The first is simple consistency. You may have noticed from the screen shot that the RadEditor uses the browser's default font, rather than the SharePoint styled font. By using the RadEditor in IE as well, you get the same experience for your users, even if it isn't "perfect".

The other piece is related to the spell-check activation I advised above. Even though it is limited compared to their paid version, the RadEditor Lite has a lot of features the default SharePoint rich text editor doesn't provide. By activating the component for Internet Explorer, you gain access to all of these features. Spell checking is just one of them. Another is that its tools for inserting tables and images are much richer. Look at the comparison below of the Image insertion dialog.

First is the default SharePoint's. You can type in a URL to an image, and enter an alt tag. That's it.

Now look at the RadEditor's image manager:

Not only do you get an easy browser, including image preview, notice the "Upload Image" tab. That's right, you can upload images to your site while editing a page! Besides cross-browser editing, Image management and spell checking have been some of the biggest complaints about SharePoint wikis, and the RadEditor Lite makes them all obsolete.

Summary

The Telerik RadEditor Lite is one of the oldest free add-in components available for SharePoint. It is also a very mature product, which has gone through a number of revisions over the years. It offers a lot of functionality to SharePoint users, developers, and administrators, no matter what the browser. Not only that, its use is fully endorsed by Microsoft. (See the SharePoint and ECM Blogs.)

Who could ask for anything more in a free download?

Welcome back! This post will be the conclusion of my Search Federation article. In Part 1, I talked about Federation in Microsoft Office SharePoint Server (MOSS) and Microsoft Search Server (MSS/X), and showed you how to create a basic Federated Location to query an external resource - in this case, Twitter.

While that Location definition is functional, it doesn't really bring the "feeling" of Twitter into your SharePoint search. Sometimes, that may be exactly what you need. However, today, I'm going show you how to take it to the next level by using SharePoint Designer.

This post assumes you have already read Part 1, and have access to the Federated Location created there. You can either follow the instructions in Part 1 now, or download and install the Location from here.

A Starting Point

I'm going to use the basic Twitter Federated Location I created in Part 1 as the starting point for our prettier, deluxe version. To start, Go into Central Administration, and navigate to the Manage Federated Locations page. Find the Basic Twitter Results location, and select Copy Location from the drop-down menu.

All of the settings we created for that location will now be pre-fed into a new location definition, except for the Location Name. We're going to call this location "TwitterDeluxe", and change the display name to Enhanced Twitter Results. Otherwise, leave everything the same for now, and click "OK".

Once you have saved the Location, it will appear in the list along with all of the others.

Exploring the Source

In order to see just what we can do with our Location, we need to know what is "in" it. The key component is the Query Template, where we told Search Federation what to query. Let's review the Query Template for our Federated Location.

Go back into the properties by selecting "Edit Location" from the item's menu. Once the editing page opens scroll down to the Location Information section, and expand it. You will see the query defined by Twitter:

http://search.twitter.com/search.atom?q={searchTerms}

To generate some example data, I'm going to replace the {searchTems} token with an actual value - "SharePoint"

http://search.twitter.com/search.atom?q=sharepoint

Clicking this link will call the Twitter search service, and return an Atom feed of the results:

Notice that there is much more information showing than we saw in our Federated Location result set, including such information as the Tweet's author, and the date/time stamp. So, how do you get to this in the Federated Location?

In Part 1, even though we didn't change it from its default values, I told you that the Display Information section of the Location definition was going to play an important role in this Part. Now's the time. In the Edit Location page, scroll down to the Display Information section and expand it. I'm only concerned about the first block: Federated Search Results Display Metadata.

Notice there are three properties here:

• XSL
• Properties
• Sample Data

All of these properties are nice XML and XSL files. Personally, I'm not a big fan of manually editing XML and XSL. Fortunately, we have a wonderful tool designed just for editing such data - SharePoint Designer. in a perfect world, we could just add a Federated Results component to a page, assign the appropriate Federated Location, open the page in SharePoint Designer, and edit it to our heart's desire.

Unfortunately, we don't live in a perfect world. Yes, we can open the page in SharePoint Designer, and edit the part. But no, we don't have access to "The Full Monte". It starts out promising. We can uncheck "Use Default Formatting", view the source from our RSS results, and paste that into the Sample Data field. When we save the Location, assign it to a Federated Results Web Part, and open the results page in SharePoint Designer,  we can see the sample data:

We can even change the format of the existing columns. But, although SharePoint Designer recognizes the Federated Results as a form of Data View, it doesn't give us full access to the Data View editing features. We can't easily get to the rest of the information we know is coming from the feed. Since Federated Search arrived much later than SharePoint Designer, I can't really fault SPD for not fully supporting the web part, but I hope that gets resolved in a future update.

You might think that this leaves us at an impasse. But it doesn't. Because, while SPD doesn't give us full Data View support on the Federated Results web part, we do have another way to edit XSL - the original Data View/Data Form Web Part!

A Data View Refresher

The Data View Web Part is a way to display information from virtually any source within SharePoint. Data Views are created in SharePoint Designer, in association with another feature called the Data Source Library. This is not to be confused with the "Business Data Catalog", or BDC. While both the Data Source Library and the BDC deal with presenting data from external sources within SharePoint, the BDC is a part of MOSS Enterprise, and allows a much deeper integration of the data with various aspects of SharePoint. The Data Source Library, on the other hand, is available in all editions of SharePoint - from WSS on up - and is primarily used to generate Data View/Data Form Web Parts.

Data Views and the Data Source Library are a very powerful combination - so much so that almost two whole chapters of my book are devoted to them. Obviously, I can't go into that kind of detail here, but while this particular example is fairly simple, it covers a lot of ground.

The link between Federation and Data Views is pretty close. In fact, prior to Search Server or the Infrastructure Updates, you could use a Data View to achieve very similar results. We're going to take advantage of this by building the look we want in a Data View, then transferring it into the Federated Location definition.

Creating a Data View

Before we can create a Data View, we need create a new item in the Data Source Library for our Atom feed.

To do this, Select "Manage Data Sources..." from the Data View menu in SharePoint Designer to summon the Data Source Library task pane. Atom and RSS feeds fall into the category of "Server-side Scripts" that return XML, so expand the Server-side Scripts section and click "Connect to a script or RSS Feed." You will see the dialog below. Fill in the URL with the same Twitter Atom query we have been using:

The query parameter (q) will automatically be passed into the list as soon as you change the focus from the URL field. "SharePoint" will become the default parameter value, and give us something to see as we customize the look.

Now that we have the Data Source, we need a place to put it. This can be any web part page. While you can use the results page if you feel so inclined, because we aren't going to be using the Data View directly, it doesn't need to be.

Once you have a web part page open, select a Web Part Zone, and then pick "Insert Data View..." from the Data View menu. The Data Source you created above will have a drop-down menu associated with it. Select "Show Data".

You will see the Data Source Details task pane, with the structure of the Twitter Atom feed displayed.

I've maximized my task pane for this screen shot in order to show you how the SharePoint Designer data source displays the entire structure of the feed. Notice the folders and item scrolls for the various elements. The Twitter Atom feed is a "hierarchical" data source. This means that the data has nested, potentially (and in this case, actually) repeating, elements, which in turn may have their own nested elements.

For now, the primary entity we are interested in is the "Entry" folder. Look at the screen shot to the right. Highlight the elements in the "Entry" folder as shown, and select "Multiple Item View" from the "Insert Selected Fields as..." menu. (Yes, I know. It looks like a button, but trust me - it's a menu!)

A table will be inserted into the web part. That's got most of the information we want, but it isn't terribly pretty. So, let's fix it up!

The first column contains the "href" entity. Ironically, even though there is a separate entity for the Author, one of the two links listed for each user is the Author's avatar. The other is a link to the Twitter URL of the tweet itself. For our results, we really only want the avatar, so we're going to do two things - Change the display to show the image instead of the URL, and hide the other URL.

To change to an image view, click one of the URLs in the href column. To the right will be a little box with a chevron in it:

When you click it, you will have choices to modify the current field. Select Picture.

You will get a warning that URLs and Pictures can be dangerous. We know that, so click Yes.

The changes you make here will affect all of the items of that series. (You probably noticed that they were all highlighted in a different color when you clicked on any one of them.)

Once you have done that, to suppress the other image (which will show as a "broken" picture), Right-click the broken link and select "Conditional Formatting". In the Conditional Formatting task pane, select "Show Content" from the "Create" menu (another one of those "buttony" menus). In the Condition Criteria box, set the conditions like this:

The broken link will go away.

Next, we want to merge the rest of the cells in the row. This is just like any other table action - highlight the data cells (not the labels) for content, updated, name, and uri. Right-click, and select "Modify/Merge Cells". Now we're cooking! Just a couple more tweaks, and it will be there.

Select the tweet content text, and change its format to Rich Text (just like changing the image format above).

Select the date, and format it to your regional liking.

Notice that we have a link to the Author, the Author's name, and the Author's avatar. Wouldn't it be great to have the name and the avatar actually link to the Author's page? Well, we can. If you click the chevron by the link, you will see that the field being displayed is called "ddw1:author/ddw1:uri". For the text, change the format to Hyperlink, you will see the following dialog. You can use the "fx" icons to select the fields you wish to use in the hyperlink, or enter the values manually. In either case, you want the "Text to display" and "Address" fields to be set as shown:

Setting the link on the picture is easy, too. Just right-click the image, and select "Hyperlink" from the context menu. Set the address to the same token as you used above. Now you can delete the field that shows the text of the author link.

You should now have a web part that looks a lot more like what you would expect from a Twitter search:

Pretty good, but I'm still not satisfied. :)

Notice the Chevron icon in the upper-right corner of the web part.

If you click it, you will summon the "Common Data View Tasks" menu:

Click Data View Properties. You will get this dialog:

Click "Show view header" and "Show view footer", then click the "Paging" tab.

Click "Limit the total number of items displayed to:" and enter a reasonable number for a search results page. (I picked 5). (You need to do this because the XSL we are creating will not have a link to the Federated Location web part's "Results per page" property.) Click OK.

Display the Data Source Details task pane, and drag the first title field available into the newly created header. Click in the footer, and delete the Item Count. In the "link" group (above the "title" field you just used), make sure item 1 (rel = "alternate") is selected. Highlight the "href" and select "Item(s)" from the Insert Selected Field menu. Change its format to a Hyperlink. Leave the Address as-is, but change the Text to Display to "More Results..."

I'm going to delete the field name row, rearrange the fields slightly, and also apply the style "ms-searchChannelTitle" to the Header cell. This results in a part that looks like this:

Moving the XSL

Now that we have something that looks how we want it, how do I get this style into my federated location? If you don't like code, this is going to get a bit messy, because now we need to enter "Split" view in SharePoint designer. Essentially, we need to copy the XSL markup from this web part. To do this, click the "Split" view icon at the bottom of the SharePoint Designer design surface workspace window, then click the title bar of your web part. This will highlight the code that makes up the web part. Using the scroll bar, Scroll through the highlighted code area until you you find the <Xsl> tag. It will be followed by lots of code. You want to copy everything below the <Xsl> tag until you find the closing </Xsl> tag to the clipboard. (Do not include <Xsl></Xsl> themselves.)

Now, go back to your "TwitterDeluxe" Federated Location definition in Central Administration. Go to the "Display Information" section, and replace the contents of the "XSL:" field in the Federated Search Results Display Metadata with the code you just copied. Click OK to save the changes.

The Net Result

Now you can go to your results page, and assign your Enhance Twitter Results location definition to your Federated Results web part. Here's what it looks like in action:

Now, this was a lot of steps. In reality, it is a lot faster to do than to describe. However, as promised, I am making this location available for you to download.

Click this link to download the Federated Location definition file (TwitterDeluxe.fld).

I hope you have enjoyed this article!

Today I'm going to walk you through setting up a Federated Location in Search Server and post-Infrastructure Update SharePoint. (Twitter fans, pay attention, as that's the service I'm using in these examples...) While that certainly qualifies as "Back to Basics", that's just "Part 1". I'm not stopping there. The second part of this article will to show you how to take it to the next level by using SharePoint Designer's XSLT Data View editing capability. I'm even making the Location definition files available for you to download and use in your own sites!

What is Federation?

When Microsoft introduced Search Server (MSS) and Search Server Express (MSSX), they introduced the concept of "Federation". With the Infrastructure Update, they brought Federation directly into Microsoft Office SharePoint Server (MOSS). Federation allows users to send the same query to multiple independent repositories, and display the results from each in its own region on a results page. In the example below, the query "SharePoint" is not only generating results from the internal site, but from Live.com search as well.

Note that with Federation SharePoint and Search Server aren't crawling the content themselves. They're just acting as the "middle-man". All SharePoint or MSS/X are doing is passing on the query, then receiving, formatting, and displaying the results. The other service is doing all of the heavy lifting.

Setting Up a Federated Location

Microsoft has provided a very easy method for adding Federated Locations to your MOSS and MSS/X installation.

Through Central Administration, Click into your Shared Services Provider (SSP). On Search Server, you will be taken directly to Search Administration. In MOSS, you will need to manually navigate to that page. Once there, you should see "Federated Locations" in the Administration Bar (Quick Launch). You will see the page illustrated below:

Note: If you are using MOSS and do not have an Administration Bar in your Search Administration page, you do not have the Infrastructure Updates installed. Search Federation was added to MOSS by these updates (along with a lot of other improvements), and they must be installed before you can proceed. Read all about them on the Microsoft SharePoint Team Blog.

On this page, you can see some nice stats for the Federated Locations on your system. You can also import pre-created Location files, edit existing Locations, or create a new Federated Location. It is that last option that interests us today. When you click "New Location", you are presented with a very long form:

While there are a lot of fields, the main reason this form is so long is because of all of the "tutorial" information embedded in the descriptions. It is definitely worth a read. I've started filling it out in the screen shot above. As mentioned in the introduction to this article, I'm going to be creating a location for the Twitter micro-blogging/massively-multiuser-chat service.

Next I enter who I am, and the version of this Location:

I'm leaving the "Trigger" at its default of "Always". this is one of the places you can get really fancy with your definition, at least as far as determining when you want to actually invoke a query.

Next, we need to enter some information about what the target of your queries expects. In this case, we're going to tell the Federated Location to use the OpenSearch protocol, which sends your query terms as a URL parameter.

The Query Template lets you define the parameters your target, in this case Twitter Search, requires in order to return a result. I got this from Twitter's online API documentation. Since SharePoint and Search Server support Atom responses, that's the format I chose for Twitter to emit for its results.

The last thing I'll enter for this Federated Location is a link for "More Results". Again, the Twitter API documentation shows us that for "normal" results, we just omit the ".atom" from the URL. This parameter is optional, but very useful:

Note: While we aren't changing anything in the "Display Information" section at this time, this setting group will be very important to us in Part 2.

That's all there is to it! Click OK to save your new Federated Location, and it will appear in the list on the Manage Federated Locations page:

Using your Federated Location

Now that you have created your Federated Location, you need to add it to a Search Results page. The easiest way to do that, is to go to your Search Center, enter a query, and once you have the results, select "Edit Page" from the Site Actions menu. Click "Add a Web Part" in the banner of a Web Part zone. In the dialog that appears, select the Federated Results web part and click Add.

This will add a new Federated Results part to your page, but it probably won't be displaying the Twitter results. You now need to edit the part to point at the Federated Location you want.

1. From the Edit menu of the web part, select Modify Shared Web Part
2. In the Location Properties section, select "Basic Twitter Results"
3. Click the "Apply" button.

You should now see results similar to the following:

Exit Edit mode on your page, and you're done!

You can download this version of the Twitter Federated Location file, as well as the one from Part 2, here.

"When it Absolutely, Positively, has to be Found."

One of the key features of Microsoft Office SharePoint Server 2007 (MOSS), and Microsoft Search Server 2008 (MSS) - including Express (MSSX), is Enterprise Search. What you may not realize is that SharePoint actually includes two fundamentally different mechanisms for providing search results to your users. I'm not talking about WSS versus MOSS/MSS search. Rather, I'm talking about a second, parallel, system that returns results to user queries - often on the same page as the "regular" search engine.

So, what is this "shadow" search mechanism? Keywords and Best Bets. Although you may have heard of them - possibly even used them on your sites - you probably didn't know that they were completely independent of your main Enterprise Search corpus. This independence brings with it a number of ramifications. While mostly positive, it is important to understand them in order to both avoid potential pitfalls, as well as take maximum advantage of this powerful capability.

Enterprise Search - Not Enough on its Own

Enterprise search is a great tool to help your users find the information they need; however, a search system alone cannot solve all problems related to true "Findability". Bill English's series on Findability and SharePoint details many other factors, such as corporate culture and information architecture, that play a major role. Still, the technology of search itself can be a limiting factor.

Most people are aware of how the basic search functionality works - you define a content source, and SharePoint crawls it - interpreting and indexing the contents of the files it encounters. Then, when your users enter a query into a form, the server looks in this index and returns results that match. Of course, this relies on several things being true. Among them:

• The information exists
• The information is in a content source being crawled
• The terms being queried are contained in the crawlable properties of the information
• The information has actually been crawled and compiled into the index at the time of the query (lag time)

Even where this is true, the user still may not actually "find" the information that is needed. Perhaps there are a large number of similar documents containing the chosen query term, or the desired term has special meaning in your organization, but is also used differently in other contexts. (This is also discussed in Bill's article series.)

Note that this weakness is not unique to SharePoint search. Any system you put into place - whether it is MOSS, the Big Yellow Box, or some other system - is going to be faced with the same issues. (While the others may also offer comparable capabilities, I'm focusing on the SharePoint/Search Server version here.)

All of this adds an element of risk to the search process. Like spinning the roulette wheel, you might hope you get the result you want, but there is always that element of doubt. Fortunately, in this case, you are actually "the House", and therefore have the ability to control the odds. In fact, you can stack the deck to ensure that the right information always comes out on top.

Place Your (Best) Bets!

The Keyword and Best Bets feature in SharePoint works very differently from the primary search. This is a completely manual system. You enter the terms you expect your users to use, and the results those terms should generate. No crawling, indexing or other "automated" processes need to take place. No services need to be reset. Results are available in queries immediately, and you know what the results will be, because you have defined them.

In many respects, this makes Keywords system more of a direct lookup system than a "search" system per se. But "search" is still the action your users perform, and "find the right information" is the desired result. Let's see how to make that happen.

Configuring Keywords and Best Bets

Keywords and Best Bets can be easily configured by a site collection owner. As always, you start with the Site Actions menu, and select Site Settings. Since Search is configured at the site collection level, if you are in a sub-site you will need to click through to "top level site settings" in order to get the page below.

Click the "Search Keywords" link. This will bring you to the Manage Keywords page.

The Manage Keywords page looks and operates much like a SharePoint list. You have the toolbar with its Add button, for example. Notice though, that it has a somewhat different search bar. Search can be very important here because you could end up generating a lot of keywords. The "where" dropdown gives you the ability to look up keywords various ways.

In addition, there are some predefined views listed in the Quick Launch area. These provided an appropriately reduced list based on information entered into the keyword definition. When you click Add Keyword, you are presented with this form, which is also used to edit existing keyword definitions.

Again, it looks a lot like any other list form in SharePoint.

There is only one required field - the keyword itself. Of course, a keyword alone doesn't do much to help your users. The Synonyms field allows you to register other terms your users might enter which should bring up the same results. For example, if your company president's name is "Selma Superior" you might have that as a keyword, with synonyms of CEO, Managing Director, President, or even Big Cheese. From that point on, any of these terms will return the entry associated with the keyword.

Note: Remember that the keyword/best bets system is independent of the primary search service. Synonyms you enter here will not affect regular results. To achieve a similar effect there, you need to edit the Thesaurus files on the SharePoint Servers.

Once you have used a term as a keyword or synonym, the system knows it has already been used, prevents you from using it again in another keyword definition. This can help you avoid creating ambiguous results.

The best bets are links to the actual pages or documents you want your users to find when they enter the keyword or its synonyms. When you click "Add Best Bet," you will see the form listed below.

In addition to the link itself, you can provide some descriptive text. You can have multiple best bets on a keyword. You can also associate the same best bet with multiple keywords. Using the earlier example, one of the Best Bets for the CEO might be the Executive Committee's Newsletter/Blog. That location could be equally valid for the CFO and CIO.

You can enter some descriptive text, which will be shown along with any matching results. You can also use the keyword feature for time-sensitive information by entering a start and end date for the keyword's display, and review date to ensure the content is still valid. The contact information allows you to distribute ownership of different keyword entries, as well as automatically notify people when entries are due for review.

The results from keywords and best bets are displayed on the default SharePoint results page above the results from the standard search.

The keyword search system has its own web parts for displaying results. If you are creating your own results page, you will need to add either a "Search Best Bets" or "High Confidence Results" web part to that page.

More Ways to use SharePoint Keywords and Best Bets

Earlier I pointed out that most of the fields in a keyword configuration are optional. While it is true that a keyword "by itself" isn't very useful, there are a lot of ways you can use keywords that go beyond highlighting particular pages and files in your corpus. This is one of the big benefits of the system being independent of the primary search. Here are just a few examples:

So, What's the Catch?

Of course there's a catch. Administration.

As a manual system, you need to be careful that information is not only entered correctly, but also maintained. If someone moves a document flagged in a best bet, you need to manually change the entry in the keyword system. You should be careful to include review dates and contact information on as many keywords as possible. Use the views provided for keywords that have expired or are due for review, and check them regularly.

One other thing to be aware of, is that because the Keyword and Best Bets system is independent of normal SharePoint functionality, it does not recognize permissions that may be applied. Therefore, you should only add items that you really want everyone who uses this search center to see. Of course, if you place a search center in a site collection that itself has restrictive permissions, only the people who have access to that site collection can get to it.

Conclusion

The keyword and best bets system in SharePoint and Search Server gives you a powerful tool to increase the findability of information within your organization. However, it is not a panacea. Like any other aspect of SharePoint, it requires careful planning and long-term commitment to ensure that you get the most out of it. But if you double-down, do the legwork, and keep up with the maintenance, you will find you have a system that will put your users on a winning streak.

Over the last few weeks, I have veered a bit "off topic". But now that TechEd is over, it is about time to bring things back on track. So today, I'm getting back down to the business of helping you to understand SharePoint with another "Back to Basics" article on the subject of Lists and Libraries.

In this article, I introduce you to some columns that SharePoint creates and manages automatically, and describe some of the ways these can be useful. In the process, you will see how to create a custom list or library view.

Introducing the System Columns

Every list and library type you can create in SharePoint has certain unique characteristics, including fields/columns specific to that list type, a default set of views, etc... (See A List, A View, a Part, in SharePoint) But in addition to the things that make a particular list or library unique, SharePoint also creates a set of System Columns that are common to all lists and libraries. Generally speaking, these columns are "Read Only" from the user's perspective (i.e. users can't directly update them on their own), but they contain very useful information, such as who created the item, and when. They are maintained by SharePoint itself.

The automatically generated, or System, columns in a SharePoint list or library include:

If the list or library is set to require Approval, two more columns are added to the list automatically. I'm listing them here for completeness, but because they can effectively be edited by site users (with appropriate rights) I won't be discussing them in the rest of this article.

While your users can't update most of these columns, they can be read and used when creating views. Consider the view below...

This view includes the Title of the item, and all of the automatic columns described in the first table. From this, you can tell a lot about this list. For example, Content types are enabled (the two items have different types). You can also tell that versioning was - at least temporarily - enabled, but was also disabled for some time, because the first item shows a 2.0, while the second item, even though it was clearly modified (notice the different Created and Modified information), is still showing 1.0 for the version.

Note: Normally, you won't be arbitrarily mixing content types in a list, or enabling and disabling versioning. I have done so on this list simply to illustrate possible different values for these columns, and their behavior.

Using the System Columns

This information, even though you don't enter it yourself, can be very useful. For example, you don't have to worry about someone manually changing records of when a file was last updated. While SharePoint maintains this info, it is available for you to use in customizing your users' experience.

Suppose you want give your users a view of only "their" items? That's as easy as creating any other view in SharePoint!

From the "View" drop-down, select Create View. You are given several options:

Notice that, in addition to the stock view formats, you can create a new view using a existing view as its basis.In this case, we're just going to create a Standard View.

I'm going to call the view "My Items", leave it a public view, and include the same custom columns I used in the view above. Notice that you can select the automatically system-maintained columns just like any other column for your list or library:

Scrolling on down the page, I'm going to set filters on the Created By and Modified By columns, looking for the token [Me] in either location. This token resolves to the User ID of the person currently viewing the page, so if the current user either created or updated the item, it will be listed for them. Otherwise, they won't see it. (For consistency, I've also chosen the "Boxed" style to match the earlier view.)

Now, if Amelia signs in and selects the "My Items" view, she only see the item she edited:

Summary

For any list or library you create, SharePoint creates a set of system columns that it manages automatically. Although your users generally can't edit these columns, you can use them just like any other in the creation of views. I demonstrated one option, filtering based on the current user. But you can also use these columns for sorting and grouping your views as well.

I also showed you how to create a filtered list view, and a select a specific layout. That process applies equally well to columns specific to a particular list or library type, and to columns that that you create.

Every service which runs on a Windows server requires an account. While there are built-in accounts designed to facilitate these services ("Local Service" and "Network Service"), many times you will find it is better to use a domain user account when setting up services. This is especially true with Microsoft SharePoint products and technologies.

Whether it is Windows SharePoint Services, Search Server, or Office SharePoint Server, there are a number of places where you can specify a distinct account. In theory, it is possible to use the built-in accounts under some circumstances; however, it is rarely advisable. In fact, if you are setting up multiple servers in a farm, you must use domain accounts. In that instance, is also possible to use the same domain account for all of these functions, and SharePoint will "work". Doing so, however, is asking for trouble down the road.

On the other side of the scale, you could define separate accounts for virtually every aspect of SharePoint. That could quickly become an administrative nightmare.

The Big Three

While the exact set of accounts required will vary somewhat based on your individual company's requirements, for most installations you should count on setting up at least three accounts. These are for some roles that should always be kept separate:

• The Setup User account
• The Server Farm account
• The Default Content Access account (for versions of SharePoint that include Enterprise Search - MSS/X, MOSS)

Combining these roles could result in administrative confusion, and/or excess information disclosure.

The Setup User Account

The Setup User account is unique among these accounts in that it is not a service account. Let me say that again: the Setup User account is not a service account. This is the account you use to log into your server(s) when you set up SharePoint.

This account is very powerful. You could think if it as a SharePoint Administrator, but it is even more. During setup, it gains some implicit power over SharePoint that cannot be removed. Even before starting setup, you need to assign the following permissions to it:

• The Setup User must be a local administrator on each server in the SharePoint farm (SQL Servers not running SharePoint components not included)
• The Setup User needs to have the Dbcreator and Securityadmin roles in SQL Server

While the Setup User account needs to be a Local Administrator on the SharePoint servers, it does not need to be a Domain Administrator. If your SQL Server environment is separate from your SharePoint farm (which it should be in most production environments), this account does not need to be an administrator on your SQL Servers. Instead it only needs the roles mentioned above. Finally, even though it is a is used to log into the SharePoint servers for installation and administrative purposes, it should not be the "day to day" account of any user. (Note, this separation is good practice for any administrative account - not just SharePoint.)

You can assign additional users to administrative roles within SharePoint following installation The Setup User account will always have that level of control, however, even if removed from administrative user listings.

Even after setup is completed, a user account with comparable capability will need to be maintained in order to provide full administrative functionality. In particular, services need to be started and stopped, IIS web applications and application pools need to be created and removed, etc...

This is the only account that needs permissions pre-allocated (as described above).

The Server Farm Account

The Server Farm account is a true service account in that it is not used by a user to log in. As noted above, you do not need to do any manual configuration of this account beyond its creation. When you specify this account during setup, it will be assigned appropriate rights and permissions. In particular, this account is used for the Central Administration site's application pool, and is assigned to the SharePoint Timer service. If someone does log into SharePoint using this account, they will be identified in the top navigation bar as "System Account", rather than with the "real" name or ID of the user.

There are other disadvantages of logging in with that account. Certain functions are restricted. For example, in SharePoint Designer (if you can open the site at all), contributor settings limit the kinds of customization allowed unless the account is also designated as the Site Owner - not recommended.

The Default Content Access Account

On versions of SharePoint that include Enterprise Search functionality, such as Microsoft Search Server 2008 (including Express), and Microsoft Office SharePoint Server 2007, you will also need to designate a Default Content Access account. This is the account used by the Indexing service to crawl SharePoint, as well as any other content sources (unless otherwise specified). It is given read access to all content in the SharePoint farm. Like the Server Farm account, while it should be a domain account, it should not be used by any users to actually log in to SharePoint.

Other Possible Accounts

Once you get past the big three, there are many other places in SharePoint where you can designate service accounts. The Search Services (crawl and query) themselves, for example, need an account which should not be the the same as the default content access account. Application Pool accounts can also each be assigned their own accounts, and this may be appropriate in your environment. In many cases, however, you can simply reuse the Server Farm account for these processes. Be aware, though, that you should never assign the Setup User account to any services in a production environment.

Summary

In this article, I have explained some of the accounts you should consider when planning your SharePoint deployment. In a single-server test or demonstration environment, you might be able to get by with built-in accounts, or a single domain account. But in production, you should have separate accounts for the major roles. While you can go overboard and assign distinct accounts to every possible aspect of SharePoint, most of the time, the three described above will be sufficient.

For more information, you should see the Microsoft guidance for the particular product you are configuring:

Plan for administrative and service accounts (Office SharePoint Server)

Plan for administrative and service accounts (Windows SharePoint Services)

Plan for administrative and service accounts (Project Server)

Plan for administrative and service accounts (Search Server 2008 including Express)

Today's subject is something of a "back to basics" article. I talk about some very fundamental SharePoint concepts, but I'm adding a little bit of a twist. Lists and libraries, Views, and Web Parts are interrelated components. Sometimes it is hard to tell where one of them stops, and the next one begins. In this article, I'll try to make those boundaries a little easier to find.

One of the great things about SharePoint is the way it hides the complexity of web design and data storage from the end user. When you want to add a piece of content - a Customer Contacts list, for example - to your page, just pick a web part, and "Poof!" like magic, there it is. But this simplicity and abstraction carries a down side, and that is potential confusion about exactly what it is you have just added.

What You See vs What You Get

Microsoft does little to allay this confusion within SharePoint itself. Consider the Add Web Parts dialog box...

(Note: You get to this by selecting Site Actions/Edit Page, then clicking on the Add a Web Part banner in a Web Part zone. Your available parts may vary.)

Notice that this section is entitled "Lists and Libraries", and it simply gives the name and description of the the publicly viewable lists and libraries on your site. As a typical user, you could be forgiven for thinking "If I want to add a new customer contact list to my site, I just pick this web part." Unfortunately, that isn't what you would get.

For example, let's say you have a web page that has a Customer Contacts "list" on it, and you want to add a new list, with different customers.

If you were to follow the instructions above to add a "new" Customer Contacts list, you would end up with the same list, displayed twice:

Obviously, this isn't what you want.

The reason for this confusion is because when you add the "Contacts list" to the page from the Web Parts dialog, you aren't actually creating a Contacts "list" at all. You are adding a "List View" web part, which points to an existing list. This is an important distinction. The web part you are adding does not contain the list itself. Rather it holds a "View" of the list.

So, What's the Difference?

What you have been working with are three distinct, though related, elements:

• The list (or library) itself
• A view of the list
• A List View web part

Lists and Libraries

Lists and libraries are the fundamental elements of storage in SharePoint. In many ways, they behave like database tables or spreadsheets. They have rows of elements called "Items". Each item has a selection of columns or fields which hold the actual information. A contact item, for example, will have fields defined for First and Last names, company, address, phone numbers, etc... A document library's items will include the file itself, and could also have columns for such attributes as its title, author, ISBN number, or other information.

Note: For now, assume that all of the items in a given list or library have the same set of fields, or "schema"; but be aware that SharePoint has a feature called a "Content Type" which allows for exceptions to that rule.

Each site you create will have a number of lists and libraries pre-defined, depending on the template selected. You are not limited to the ones created by default, however. You can add more of your own. But you don't do it through the "Add a Web Part" dialog. Instead, you use the "Create" option on the Site Actions menu.

Views

While a list or library contains your data, in order to see it, a "View" needs to be defined. With a view, you can tell SharePoint how to display the information contained in the list or library. You can define almost any subset of the columns, and their order; define how many items to show - both per "page", and in total; select from various display formats, and even set filters for which items to display.

You can define any number of views for each list or library. For example, you can have views that are pre-filtered by one of the fields, or which contain the same information in several different formats.

Typically, when a list or library is created, a selection of views appropriate to the expected content is also created. One of these views will be the "Default" view, which is what you will see when you click on the list or library's name in the Quick Launch bar, or in the title bar of a web part. You select an existing view from the combo-box in the upper right hand corner of the display area, as shown below.

You can also create new views, or modify the existing view, from this menu. Views can be displayed as stand-alone pages, or within a List View Web Part.

List View Web Parts

This brings us back to where the article began. The web part labeled "Customer Contacts" in the dialog we started with is a List View Web Part. When a list or library is created, a corresponding List View Web Part is also created. (Note: It is still called a List View Web Part, even if it represents a library.) The List View Web Part allows you to place a list or library's views on any web part page in your site.

In addition, using the List View Web Part means that you aren't limited to showing lists or libraries just one time, or in just one place, or in one format. While each List View Web Part has a default View (typically called the "Summary View"), you can select any of the Views you have defined for the associated list. In addition, you can further refine the selected view within the web part.

You can, for example, have one view showing the list of contacts, with another view showing an individual contact laid out as a card. You could then use the Web Part Connections function to select which contact's details to display, as shown below.

Summary

Lists and libraries, Views, and the List View Web Part are distinct, but related elements of every SharePoint site. Site managers need to be aware of how they related to one another. In general:

• Lists and libraries define and hold the content of your site,
• Views define how to display that content, and
• List View Web Parts allow you to select where to display the content.

If you have a web site, you need usage reports. You need to know how often people are visiting, what they're looking at, and where they're coming from. While this information is a kind of buried treasure in and of itself, I'll also show you how to get to some "bonus" usage reports in Microsoft Search Server.

All of the SharePoint Products and Technologies have some form of usage reporting built in. While they don't have the flexibility or detail of a dedicated reporting system, SharePoint's reports can still provide you with a lot of useful information. What you get, however, varies considerably from product to product - and sometimes even from template to template within the products.

Basic WSS Reporting

The most basic reporting is available in Windows SharePoint Services (WSS). This is a set of simple text-based reports, giving a hand full of statistics for your site (or sub-web) in either a monthly summary or daily detail table. For the Site Collection, you get a summary of the total storage, quota (if any), and bandwidth. These reports are also used by default for most site types in Microsoft Office SharePoint Server 2007 (MOSS) if the Office SharePoint Server Standard Site features (or Publishing Features) aren't activated, and Microsoft Search Server 2008 (MSS), including the Express edition (MSSX). and are easily accessed through the Site Settings page.

Note: WSS does not include the Search Queries and Search Results reports highlighted in green. Search Server, and MOSS sites with the Search features activated, however, include the green-boxed reports as well. That will prove important later.

The site collection usage summary isn't all that fancy, but it does have some useful information:

The Site Collection Summary (_layouts/usage.aspx)

The Site Usage Reports have a lot more detail. They give you your choice of daily detail, or monthly roll-up information for:

• Page hits
• User activity
• What web browsers people are using
• What OS the users are running
• What sites and pages are referring users to you

Here are typical examples of the month summary and daily details of the various sub-web site reports:

Web-scoped Usage Detail report (_layouts/UsageDetails.aspx). Month Mode.

Web-scoped Usage Detail report (_layouts/UsageDetails.aspx). Daily Mode. 

Again, a bit plain, but informative.

"Advanced" Reporting

Turn on the MOSS features, however, and a much more attractive set of reports become available. Here's the MOSS version of the Site Collection usage summary.

Site Collection-scoped Usage Detail report (_layouts/SpUsageSite.aspx).

Quite a bit more information than you saw in the WSS and MSS/MSSX version. However, the information is not identical (I'll talk about that a little later in the article). There is a Web-scoped version of this report at _layouts/SpUsageWeb.aspx. The web-scoped version does not have the search report links, but is otherwise similar. On MOSS Sites with that have the advanced reporting turned on, these reports replace the reporting links found on the Site Settings page.

Search Reports

Again, notice the Search reports I have highlighted in green. These are the same reports that were available as separate links on the Site Settings page for Search Server (MSS/MSSX). On those products, you normally only see these links in the Site Settings, or in the Farm level Search Administration pages. On MOSS, on sites with Advanced reports enabled (as above), these are not separate Site Settings links, rather they are only accessed through the Usage Summary.

Here's a typical Search Queries report:

Site Collection-scoped Search Query report (_layouts/SpUsageSiteQueries.aspx).

The Results report link points to _layouts/SpUsageSiteResults.aspx.

The Report Pages

You may have noticed that I called-out the names of the pages as I talked about them. Here they are together:

• usage.aspx
• usageDetails.aspx
• SpUsageSite.aspx
• SpUsageWeb.aspx
• SpUsageSiteQueries.aspx
• SpUsageSiteResults.aspx

All of these pages reside in the _layouts folder of your site. The SpUsageSite.aspx and SpUSageWeb.aspx pages have several subsidiary pages for specific reports that are accessed through their quick-launch menus.

I mentioned earlier that the information in the "Advanced" reports isn't exactly the same as that in the basic WSS reports. While the presentation of the Advanced reports is much easier to take in at a glance, it is all cumulative, or "rolled up" in some way. Daily information is always rolled up from all elements (e.g. pages or referrers), while element information is rolled up across all time. If you want to see the daily breakdown of individual elements, you need  to use the WSS Usage Details report.

The table below shows what makes each of these reports unique.

Unfortunately, at least in Site Settings, the "Standard" and "Advanced" reports appear to be mutually exclusive. In other words, you can only have links to either one set or the other. Fortunately, that is only appearance. The feature that creates the links (AnalyticsLinks) only hides the Standard reports. It does not remove them. You can run them at any time as long as you know the URL, which now you do!

Happy Easter!

OK, this isn't technically an Easter Egg, as it is simply standard functionality. However, unless you are exploring the whole User Interface in Central Administration, you will never find it. (Maybe that does make it an Easter Egg - what do you think?)

I mentioned before that Search Server (including Express) includes the Search reports, and shows them separately on the Site Settings page.

Did you notice how much the Search Queries report looks like the Advanced Usage reports? Even down to the filename (SpUsageSiteQueries/Results)? Here's the good news - In order to provide this kind of report for the search functions, all of the pretty, advanced usage reports came along for the ride. They are available to you on Search Server and Search Server Express! You can access them through typing in their URL, just as you can on MOSS sites without the Advanced reports active.

They're not turned on by default, however, and this section will show you how to enable them. (These steps will also work for MOSS. If your advanced search options are not working there, go ahead and follow along.)

Enabling Usage Reporting in Search Server and MOSS

First, open SharePoint Central Administration

Second, although Search Server normally enables usage processing, you should make sure it is turned on. On the Operations tab, in the Logging and Reporting section, click "Usage analysis processing". Make sure the "Enable logging" and "Enable usage analysis processing" boxes are checked. Leave everything else as-is unless you know you need to change them. Click OK.

Third, enable reporting in the Shared Services Provider. To do this, Click the "SharedServices" link in the Quick Launch. This will take you to the Search Administration page. That's not exactly where we want to be. Click the "Home" tab. This will take you to the Shared Services home page (if you were on MOSS, this is where you would have ended up in the first place). In the Office SharePoint Usage Reporting section, click "Usage reporting". Check the "Enable advanced usage analysis processing" box. Don't uncheck Enable search query logging! Otherwise the Search reports won't work.

You may need to wait a day or two to get meaningful results from your report pages, but otherwise, that's it!

Or is it...

Merry Christmas!

For those of you with Search Server (including Express), I have a little gift.

While it is easy enough to type in the URL for the Advanced reports, wouldn't it be nice if you could get to them through Site Settings, just like the WSS Standard reports? Well, now you can! I've put together a simple SharePoint Feature that adds links to the Advanced to the appropriate locations in the Site Settings page. Unlike the MOSS Feature that does essentially the same thing, I leave the Standard reports available for you as well!

Simply download allReports.zip from my SkyDrive. Detailed instructions are in the ARReadMe.txt file, but here's the short version:

1. Extract the AllReports folder into the {12 hive}\TEMPLATE\FEATURES folder.
2. Run this STSADM command:
   stsadm -o installfeature -name AllReports
3. Go to the Site Settings page of your site, and select Site Features
4. Activate the new "All Usage Reports" Feature:

Now on your Site Settings, you should have two new links, which will take you to the Advanced reports!

Obligatory disclaimer: Even though all this does is add links to your Site Settings page, I have to warn you that use of this feature is at your own risk. Always try downloaded components in a test environment. Never deploy ANYTHING directly to a production environment without testing it first!!!

Conclusion

Usage reporting is critical to anyone that runs a web site. The SharePoint Products and Technologies provide a number of useful reports for analyzing your site's usage, but different products expose their reports in a slightly different fashion. By understanding where these reports are, you can always get to exactly the report you need, even if it isn't displayed in the menus.

Last month, I talked about my SharePoint Hippocratic Oath, and using the right tool for the level of customization you are looking for. One of my key suggestions was using CSS (e.g. a SharePoint Theme) for the bulk of the work, and only moving into your Master Pages (or beyond) for those things that can't be accomplished via styling. In this posting, I will compare the what you can do with a SharePoint Theme and some minor Master Page tweaks (essentially "Redecorate and Remodel"), to what has been done with a completely green-field design (the "Tear-Down" approach).

The "Tear-Down" Approach

While it might not look like it, this blog is based on SharePoint. It was built using the Community Kit for SharePoint: Enhanced Blog Edition (CKS:EBE). This is one of the many freely available SharePoint related projects on Microsoft's CodePlex web site. As it's name implies, the CKS:EBE is a set of features that significantly enhance SharePoint's blogging functionality.

CKS:EBE is also an example of the green-field, or "Tear-Down" approach to SharePoint site design - the designers essentially scrapped SharePoint's original design, and substituted their own (why do the "Mythbusters" suddenly spring to mind...). They rely on Master Pages and CSS that were built from the ground up, with bits of SharePoint functionality added here and there. While this method works (obviously), it carries a number of drawbacks. The following table explores some of the pros and cons of this approach:

The Redecorate and Remodel Approach

Another thing about the CKS:EBE is that it works only for blogs. While it does that quite well, no other SharePoint site type can benefit from the admittedly very nice designs. This posed a problem for me, as I wanted to make my "regular" web site visually consistent with my blog. Since my regular site is not blog-based, I couldn't just apply CKS:EBE. Besides, I *like* the standard SharePoint Functionality I have. :)

This is a situation very similar to one I described in my recent post on Change. Granted, I wasn't taken over by GadgetCo, but I still wanted my professional web presence to be more consistent across the board.

I faced a choice:

1. Give up most of the CKS:EBE functionality;
2. Create a MTF theme that looked more like SharePoint; or
3. Create a "regular" SharePoint Theme that looked like the MTF "Intensive" theme.

I chose "Door number 3". Not only was this consistent with my "Hippocratic Oath", it also provided me with an opportunity to show just how far you can go with a Theme. The two screen shots below show my web site before, and after.

Before: A typical SharePoint site (In this case, a Wiki).

After: A site that looks very much like this blog.

All SharePoint functionality is intact. In addition, the theme - like all standard SharePoint themes - applies across the board, including system and administrative pages.

Is it perfect? No. I make no claims to being a graphic artist. Some of my adaptations don't totally reflect the original source. (I'm sure Heather Waterman, who did most of the CKS:EBE designs, can point right at the differences.) With a bit more time and effort, I'm sure I could get most of the more subtle details in place.

In addition to the theme, I did have to make one "tweak" to the default.master page. For some reason, Microsoft chose to "hard-code" the width of the primary content area (a table called ms-main) to 100% of the page. That makes effects like the alternating bands on either side next to impossible to attain through styling alone, because in CSS, "last in wins", and specific beats general. The theme applies in general, and the explicit styling of ms-main takes precedence. For a single page, I could override the width with some CSS in a Content Editor Web Part, but I wanted the sidebars to appear as close to everywhere as possible. That meant I had to touch the master page.

Fortunately, the only change I had to make was to adjust the width from 100% to 950 pixels, and add the "center" attribute. Again, this is fully consistent with the Oath - make only the changes needed to accomplish the goal.

Summary

Clearly, you can accomplish great things with a tear-down. Without the baggage of existing design, you can let your imagination run free. You can make a SharePoint site do and look like anything you want.

Yet, there is something to be said for "standing on the shoulders of giants". Redecorating (themes) and remodeling (default.master page tweaks) allow you to leverage the tried and tested functionality of SharePoint, while complying with almost any branding standards.

"What's In a Name?"

The recent turmoil in the financial industry has got me to thinking. (And no, this isn't an article about the finance industry, or the turmoil.) What happens when something really foundational changes? How will you adapt your SharePoint environment to the new situation? How can you adapt it to the new situation?

When you are planning and configuring a SharePoint Server farm, you often take certain things for granted, or at least, have certain things pre-ordained. For example, most companies have standards in place for things like machine names and service accounts, and especially for the domain the servers live in. You follow your standards, configure your SharePoint portal with a site URL that users will know it by, and go on your way.

Well, things change. Companies merge, divisions re-align, and suddenly, you may find that your company, WidgetCo, now belongs to GizmoCorp. Reality dictates that you won't be asked to bring things into compliance overnight; however, you will eventually have to integrate your SharePoint sites with the GizmoCorp way of life.

Fortunately, most of the changes you might be expected to make can be accomplished with minimal disruption. Others will take a bit more effort. Here are the things likely to be impacted, and the probable order in which they will probably need to be addressed.

1. Branding
2. URLs
3. User Accounts
4. Windows Domain
5. Server Names

Of course, this assumes that GizmoCorp likes the WidgetCo intranet and Internet presence well enough to want to keep them. You of course have made this a foregone conclusion by making them indispensable resources to your users and clients... :)

Branding

Most acquiring or reorganized companies want to stamp their new identity on things right away. In the beginning, it might just be adding "a GizmoCorp company" to the banner, but eventually they are going to want things to match the marketing department's standards. Fortunately, if you have followed best-practices in designing your site, re-branding SharePoint while leaving the content intact is pretty easy, and very well documented. You shouldn't have any problem here.

URLs

This is almost a subset of branding. If you've rebranded WidgetWize to GizmoZone, having your users type http://widgetwize to get there isn't going to earn you any points with the management. Again, SharePoint's native functionality comes to the rescue. You can easily make your site respond to any name you like with "Alternate Access Mappings". Or any set of names.

That last is important. Even once you have changed your site's primary URL to http://gizmozone, you will probably find that people have created lots of "hard coded" links to pages in http://widgetwize. To just change the name without leaving the old URL would break all of those links. At some point after the conversion, you will want to search for pages that still have links to http://widgetwize and have them updated to the new namespace - or better yet, make them root-relative (i.e. start with just a slash "/", rather than the site name.)

Don't forget, you need to have your internal DNS configured to direct all appropriate site names to your SharePoint Web front end server's (or load balancer's) IP.

Long-term Maintenance Tip: Whenever possible, advise your users to make manual links within a site relative to the current page, or the site root, rather than using the full absolute URL.

User Accounts

Once the information is flowing between the "old" and the "new" organizations, a tighter integration of user management is likely. The networks will be connected, and "Trusts" will be established between the companies' domains. But that's just the first step. Eventually, there will probably be an account consolidation into a single domain. Unfortunately, all of your users will have their permissions assigned in SharePoint via their original accounts. Once they get moved onto their new account, how will they access their SharePoint content?

You need to make sure that, as part of the domain migration process, you take SharePoint into account. SharePoint has an API that allows you to rename a user's account, and have all of their permissions remain intact under the new name. You can access it through custom code, or via an STSADM operation. operation is called "migrateuser", and has the following form:

stsadm.exe -o migrateuser
           -oldlogin <DOMAIN\name>
           -newlogin <DOMAIN\name>
           [-ignoresidhistory]

This command ONLY changes the windows user account associated with the SharePoint account. It does not change any of the metadata or profile information associated with the user. If that also is changed as part of the domain move, you will need to do a crawl of AD to retrieve the updates (for MOSS).

Service Accounts and Windows Domain

Once your users are moved, or possibly even before, you will probably be asked to move the SharePoint farm into the new domain. This is where things get a little complicated. Not because it is hard, but because it is tedious. There are (potentially) lots of accounts used by the various SharePoint services. If you do things in the wrong order, you can potentially end up with major headache trying to straighten things out. In general, here's how you should prepare to move SharePoint into a new domain:

1. Establish a two-way trust between the old and new domains.
2. Test. Make sure users in the new domain can see SharePoint, and users in the old domain can see resources in the new one.
3. Create service accounts in the new domain with permissions to match the accounts currently used by SharePoint.
4. Assign the new accounts to their respective services in SharePoint. (SharePoint MVP, Eli Robillard, has an excellent article on that process, and cross-references a good Microsoft KB article which includes a script to automate the process...)
5. Test. Making sure everything still works. Do it after each account change in Step 4.
6. Make sure any other services on the servers also have accounts in the new domain! (This is an easy step to forget...)
7. Join the SharePoint servers to the new domain.
8. Test again.

Now, if the two-way trust is fully functional, it is possible to change the domain before you reassign the accounts, but that opens you up to a more difficult situation. That's because if the old domain's service accounts can't be reached for some reason, the whole thing comes tumbling down. On the other hand, if you are changing your accounts one a time as described, it is easy to revert to troubleshoot the problem.

Server Names

If you are lucky, you won't ever be asked to rename production application servers - of any kind, not just SharePoint. There are just way too many (sometimes surprising) things that can get messed up. Unfortunately, sometimes "rules are rules", and you must rename your SharePoint servers to comply with some policy. If the worst happens, and you must do so, there is a relatively straightforward STSADM operation that can tell SharePoint about it - "renameserver". Like migrateuser, the syntax is quite simple:

stsadm.exe -o renameserver
           -oldservername <oldServerName>
           -newservername <newServerName>

This makes the appropriate updates to the Configuration Database. You should run this command immediately before performing the actual server rename operation in Windows. Of course, nothing is that easy. While this command updates the Configuration Database, it doesn't make any other changes to your system. For example, you may have other services on the server that need to be updated, or there may be references on other machines to the old name. These are beyond the control of SharePoint.

In addition, this does not affect any links in your Start menu, or within SharePoint's content databases. If you rename the server Central Administration is hosted on, for example, you may have trouble accessing the site. Make sure you set up Alternate Access Mappings (just like setting URLs for the content sites) to the Central Administration web application (also for Shared Services, if appropriate for your environment) for both the old and new server names before you begin the rename process. In addition, you will need to manually edit the link to Central Administration within the Start menu to reflect the new URL.

Conclusion - Planning for Change

The only constant in life is change. Even the most stable company can decide to rename itself for a new generation. There are many reasons you may be asked to make fundamental changes to an existing SharePoint environment. In addition, the information you gather to prepare for an environment migration can also be used in a Disaster Recovery scenario. In a worst-case situation, you may find you have to bring your configuration back online in a new domain, or restore into an environment where your names will conflict with with existing servers.

By understanding the things that may need to change, and how these changes work, you can have a head start, and avoid the panic that can strike the unprepared.

When I was speaking at the Wisconsin SharePoint Users Group last week, someone asked me: "How do you know when to choose SharePoint Designer or Visual Studio for a particular change to a site?" I explained that I had a sort of "Hippocratic Oath" for SharePoint customization. In essence, it involves not making changes any more complicated than they need to be in order to achieve the design objectives. The ever popular "KISS" principle - Keep It Super Simple. (Yeah, I know, there's another breakdown for this acronym, but I think this is a little nicer.)

So, here it is:

The SharePoint Customization Hippocratic Oath.

First, Do No Harm

Use the Product: Don't customize where SharePoint already does what you need.

Do it with Style: Don't build a Master Page when a CSS theme will suffice.

Take the Data View: Don't build a binary web part when a Data View or Content Editor can do the job just as easily.

Master It: When you do need to make major changes to the layout of your pages, customize the Master, but don't throw the baby out with the bath water.

Feature it at Staples: Don't build a Site Definition when you can achieve your goals with Features and Feature Stapling.

The Definition of Success: If you must use a Site Definition, understand the ramifications.

Now, I'll talk about each of the points in a little more detail.

First, Do No Harm

If it isn't broken, don't fix it. Consider why you want to make the change. Are you trying provide a function your users are asking for? Do you need to meet some corporate guideline for branding on this site? If so, fine. Go on to the next step. Or are you just trying to change something "to be different" or "because you can"? Just don't do it! SharePoint works pretty darned well, right out of the box. Which brings us to the next principle:

Use the Product

As noted in my article, Your (Share)Point of View, SharePoint has a lot capability and flexibility. Before you go building new functionality, make sure SharePoint doesn't already have a feature that performs that task. You can add logos to pages, change colors with several existing Themes, build custom menus, re-arrange components, manage content, and all sorts of other things right from the Web-based User Interface. Don't re-invent the wheel. Use what's there.

Do it with "Style"

Ok, the existing themes can leave something to be desired, especially if your marketing department is insisting that the top banner be "Pantone 321". Now it's time to open SharePoint Designer. You're still not hacking pages apart, or worrying about chasing "Ghosts". You want to take advantage of SPD's CSS editing capabilities. You can do a lot with CSS. Not just colors, but fonts, sizes, background graphics, and lots more. Although the default Master pages used by SharePoint make using CSS for positioning a bit problematic, you even still have some flexibility there.

The big thing is, unlike Master page customizations, anything you do with a theme's CSS can apply to every page in your site - even those in the troublesome _layouts folder. Even if you do ultimately need to go to the next level with a Master page, by starting with a CSS Theme, you can make fewer Master changes, and thus minimize the visual shock your users would experience when those _layouts pages come to the surface.

Take the Data (Point of) View

Get to know the SharePoint XSLT Data View Web Part. When it comes to easy, powerful, customization, the Data View is the cream of the crop. Graphical menus? Yep. Mash-ups with external data sources? You got it! The Data View in SharePoint Designer can save you hours of coding when it comes to in-page functionality. (Oh, and the Content Editor Web Part is no slouch, either!)

"Master" It

When it comes time to totally change the look of SharePoint, the only way to go is to build a new Master Page. Once more, the tool of choice is SharePoint Designer. If you're doing a public facing web site, you can start from scratch, and drop in your SharePoint functionality only as you need it. But if you are doing an Intranet portal, you should keep as much of the "stock" SharePoint as you can. Again, start with the theme CSS, and then start working on your Master page. You might find you don't need to change nearly as much as you initially thought. There are a lot of standard SharePoint components used in the default Master page. Learn about them, and don't throw them away when you build your own Master pages.

"Feature" It at "Staples"

When you finally reach the point where you just can't implement the functionality you need through Themes, the Data View, or custom Master Pages, only then do you need to reach for Visual Studio. But even here, there is a hierarchy of needs. You don't need to come out of the gate with the "big guns" - a new Site Definition. In fact, that should be pretty close to your last resort. Instead, go for creating Features. Features can be added to sites as needed. You can even force their deployment through Stapling them to existing Site Definitions. Features can be activated, deactivated, and even upgraded, on existing sites.

The (Site) Definition of Success

None of this is to say that Site Definitions are obsolete, or should never be used. You just need to be aware that this is a very fundamental construct. Once you build a site from a site definition, you cannot change it to a different definition later. You can still tweak it with additional features, but you can't change the "kind" of site it is. It will not be a "SharePoint Team Site", easily and transparently upgrade-able. It will be an "Acme Group SIte", or whatever you have called it, and you need to plan for its entire life-cycle (Much like adopting a puppy). There may be extra steps in the upgrade process, for example (though, at this time, we don't know what those steps might be). You may have trouble getting support if the person who created the Site Definition moves on to greener pastures. This may be worth it for your environment, but it is something you need to take into account.

Note: This classic post was one of the most popular on my old site. I'm including it here for your "enlightenment"...

SharePoint is big. Really big. So big, in fact, that it is very hard, some might say impossible, for any one person to fully comprehend. Now, I wouldn't go quite that far, but I will say that many people approach SharePoint in much the same way as the blind men approached the elephant.

What? You haven't heard the parable of the blind men and the elephant? Well, sit back and relax, while I digress a moment…

Once upon a time (don't they all begin this way?) Anyway, once upon a time, there was a group of blind men traveling down the path to enlightenment when they encountered an elephant and his trainer. The elephant was totally blocking the road, so the trainer said to the men, "Please wait, while I move my elephant out of your way."

"We have never met an elephant before," the men said. "May we touch it so that we may know what an elephant is?"

"Of course!" The trainer said, and the men approached the elephant.

The men reached forward as they walked, and each spoke to the others according to what they perceived.

The first man walked into the side of the elephant, felt up, and down, and side to side and exclaimed "I have encountered a wall. An elephant is a large, warm wall!"

The second man had walked up to the elephant's leg. He said "Are you crazy? This is no wall, but round, and sturdy, like a tree trunk, or a pillar. An elephant is a kind of tree!"

The third had encountered the trunk and said "You are both wrong. An elephant is a large serpent, like a python, but without bones!"

The fourth, who had felt the elephant's ear, believed it to be a piece of canvas, while the fifth was equally convinced by his encounter with the tail that an elephant was a brush for cleaning things better left unmentioned in a family blog.

The blind men argued with each other, each believing that his view of the elephant was the correct one. They were about to come to blows when the trainer, who was also very wise intervened: "Gentlemen, please, you are each right, in your own way, but also all of you are totally wrong. An elephant is neither wall, nor tree, nor serpent, or even bottle brush. It is a vast creature of many parts, some of which resemble the familiar things you have perceived. But to truly understand the elephant you must expand your perception, and approach not just the piece you are familiar with, but the entire animal."

With that, the trainer had moved the elephant from the path of the blind men, who had just taken another major step on their journey toward enlightenment.

Now, back to our regularly scheduled blog post…

What you see when you first approach SharePoint will vary considerably depending upon your experience and what you expect to find. You might, as a network administrator, first see SharePoint as a stand-alone application. And you would be right. SharePoint provides a great "out-of-box" experience, with tools for file sharing, team collaboration and communication, project management, all wrapped up with easy distributed administration functions.

As a business analyst, you might say "Wow! Look at the all of the tools I have to aggregate knowledge and business intelligence" You see SharePoint as an integration portal, able to give you windows into data scattered throughout your organization through search, through the BDC, or even Forms and Excel Services. And again, you would be right.

As a software developer, you might see SharePoint as a rich application platform. Almost like an extension of the .NET framework, with its own API, an extensive object model, built-in modularity, and extensibility. Also correct!

SharePoint is all of those things. And more. But to treat SharePoint simply as an application, or BI aggregator, or development platform is missing the "Point". What if I told you that you could, in your integration portal, add connections between your views and information already within SharePoint so you can filter results dynamically, customize the look, enter in new information, and notify your team of changes, all without writing a line of code? Or by adding a little custom code behind the scenes, alter the experience to the point where you might never know you were using SharePoint? This is all possible, just shifting your mind set.

As an administrator, look at the SharePoint API and object model to see what you can do with just a little programming (e.g. my previous blog entry regarding "The SharePoint Nobody Sees")

As an analyst, don't just look at how SharePoint can connect to your data, but how you can connect the pieces of a page together to coax even more intelligence from your knowledge.

As a developer, familiarize yourself, not just with the object model, or the web service API, but with the front-end customizations that are available before you even open Visual Studio. Web part connections, Data web parts, and the WPSC are just waiting to do your bidding!

Like the elephant in the story, SharePoint is a beast of many parts that each can, at first glance, look complete. But to truly understand it, you must venture outside your comfort zone, and see how the parts connect and relate. Only then can you say "I have seen the elephant!"

This is the conclusion of a two-part article about customizing the SharePoint (MOSS), and Search Server, Advanced Search Web Part. In Part 1, you learned about the basic settings of the Web Part - which search options are shown, and how they are labeled. In Part 2, I'll show you how to change which language and document type filters are available to your users.

We completed Part 1 by describing how to configure groups for the Display group option in the "Scopes" section of the settings task pane...

Below the Display group option you will find the options for showing and labeling the language and result type pickers.

Checking the checkbox shows the picker, and entering text in the label field replaces the default label text. Just as with the other choices, clearing the text will restore the default label for the selection.

The next group of settings is "Properties", and this is where things start getting a bit more complicated.

Notice that there are only three options:

• A "Show Properties" checkbox
• A section label
• A "Properties" text field.

Just as before, the checkbox and label fields display and label the Properties list. But it is the Properties field which really interests us.

In the small part shown in this text box, you see the beginnings of an XML definition...

As they say, "this is just the tip of the iceberg". This XML is actually over 100 lines long! That is because it provides definitions for virtually everything else on the Advanced Search form. If you highlight the field, you will see the "elipsis" button as shown above. Clicking this will summon a larger text editing window:

Note: There are no line-breaks in the default XML. They are provided in the following examples for clarity.

There are four primary nodes under the root:

• LangDefs
• Languages
• PropertyDefs
• ResultTypes

Modifying the Language Filters

LangDefs, or Language Definitions, provides a list mapping all of the languages that SharePoint Search supports, ranging from Arabic to Vietnamese. A typical LangDef sub-node looks like this:

<LangDef DisplayName="Lithuanian" LangID="39" />

The nodes for the default languages are:

<LangDef DisplayName="French" LangID="12" />
<LangDef DisplayName="German" LangID="7" />
<LangDef DisplayName="Japanese" LangID="17" />
<LangDef DisplayName="Spanish" LangID="10" />

The LangID parameter is used in the next section, Languages. The Languages section, by default, lists the four nodes for French, German, Japanese, and Spanish:

<Languages>
  <Language LangRef="12" />
  <Language LangRef="7" />
  <Language LangRef="17" />
  <Language LangRef="10" /> 
</Languages>

The LangRef parameter is the LangID parameter from the LangDefs node of the desired language. To add another language to the list, simply add another Language Node. To remove one, remove the node. The languages are presented in the order listed. Substituting the code for Lithuanian(39) for Japanese(17) in the Languages section gives the following results in the Advanced Search form:

Properties and Result Types

Just as LangDefs were used for Languages, the PropertyDefs are used for the ResultTypes. The actual implementation is a bit more complex.

Here is the default PropertyDefs node and its children:

<PropertyDefs>
  <PropertyDef Name="Path" DataType="text" DisplayName="URL" />
  <PropertyDef Name="Size" DataType="integer" DisplayName="Size" />
  <PropertyDef Name="Write" DataType="datetime" DisplayName="Last Modified Date" />
  <PropertyDef Name="FileName" DataType="text" DisplayName="Name" />
  <PropertyDef Name="Description" DataType="text" DisplayName="Description" />
  <PropertyDef Name="Title" DataType="text" DisplayName="Title" />
  <PropertyDef Name="Author" DataType="text" DisplayName="Author" />
  <PropertyDef Name="DocSubject" DataType="text" DisplayName="Subject" />
  <PropertyDef Name="DocKeywords" DataType="text" DisplayName="Keywords" />
  <PropertyDef Name="DocComments" DataType="text" DisplayName="Comments" />
  <PropertyDef Name="Manager" DataType="text" DisplayName="Manager" />
  <PropertyDef Name="Company" DataType="text" DisplayName="Company" />
  <PropertyDef Name="Created" DataType="datetime" DisplayName="Created Date" />
  <PropertyDef Name="CreatedBy" DataType="text" DisplayName="Created By" />
  <PropertyDef Name="ModifiedBy" DataType="text" DisplayName="Last Modified By" /> 
</PropertyDefs>

These represent the standard managed properties used by SharePoint Search. Each PropertyDef provides the actual managed property name, a DisplayName (or Friendly Name) for use in the Property Restrictions dropdown, and the DataType, to allow the UI to provide appropriate comparison prompts. If you define your own managed properties in Search, you will need to manually add each property to this list if you wish your users to be able to choose them in the "Add property  restrictions" section. In addition, you will need to add them to the appropriate ResultTypes.

The ResultTypes node contains the definitions for the items which appear in Result type dropdown:

A typical result type definition, for Word documents, is listed below:

<ResultType DisplayName="Word Documents" Name="worddocuments">
  <Query>FileExtension='doc' Or FileExtension='docx' Or FileExtension='dot'</Query>
  <PropertyRef Name="Author" />
  <PropertyRef Name="DocComments" />
  <PropertyRef Name="Description" />
  <PropertyRef Name="DocKeywords" />
  <PropertyRef Name="FileName" />
  <PropertyRef Name="Size" />
  <PropertyRef Name="DocSubject" />
  <PropertyRef Name="Path" />
  <PropertyRef Name="Created" />
  <PropertyRef Name="Write" />
  <PropertyRef Name="CreatedBy" />
  <PropertyRef Name="ModifiedBy" />
  <PropertyRef Name="Title" />
  <PropertyRef Name="Manager" />
  <PropertyRef Name="Company" /> 
</ResultType>

You might wonder, "Why are all of these properties listed here, when they were already defined above?"

The answer is simple, not all properties apply to every document type. Something few people have noticed is, when you select a result type, the property restrictions list changes to reflect the properties defined for that result. For example, a Zip file would not have metadata for most document properties. if you have added a Zip iFilter to your search environment, you could add a Result type node for Zip files that looks like this:

<ResultType DisplayName="Zippy Results" Name="zippy">
  <Query>FileExtension='zip'</Query> 
  <PropertyRef Name="FileName" />
  <PropertyRef Name="Size" />
  <PropertyRef Name="Path" />
  <PropertyRef Name="Created" />
  <PropertyRef Name="Write" />
  <PropertyRef Name="CreatedBy" />
  <PropertyRef Name="ModifiedBy" /> 
</ResultType>

Now, not only can your users search specifically for Zip files, they won't be confused by being offered the option to search for "Comments" that don't exist.

The query node isn't restricted to just file extensions. You can set up a result type with virtually any query supported by the SharePoint Search engine. The "Documents" Result type, for example, simply uses the IsDocument property:

<Query>IsDocument=1</Query>

Summary

This article has given you an overview of the tremendous flexibility of the Advanced Search web part. You have learned about both the easy "checkbox" options and the not so straight-forward XML configuration file. You can now tailor Advanced Search to the specific languages, documents, and custom properties used in your environment.

If you have been using MOSS Search or Search Server, you have probably noticed that the Advanced Search page gives you lots of options to restrict results. From different word filters, to particular languages, to document types - even specific document properties. You may have wondered how (or even if) you could cut back the list of word filters. For example, you might only want your users to search for exact phrases. Or maybe you want the language list or document types to reflect the languages and documents actually in use by your enterprise, without reinventing the whole form.

Well, you can. In fact, you can make a lot of changes to the Advanced Search form. This two-part article will show you how to get the most out of this powerful control. This part will focus on the "easy" part - the word filters and enabling scope-based search. Part 2 will describe configuring Languages, and talk about customizing Advanced Search for the documents in your organization.

Take the typical Advanced Search page shown here...

It contains an Advanced Search web part (you can also place this part on any page on a with the Enterprise Search parts Feature activated). There are three primary selections of the web part:

• Find documents with...
• Narrow the search...
• Add property restrictions...

The first section, Find documents with..., is pretty easy to control. The first thing you'll need to do is get to the properties pane for the web part. On the default Advanced Search page, you don't have access to the title bar of the web part unless you are in Edit mode, so the first thing you need to do is get there! (If you have added an advanced search web part to a different page, you may be able to simply select "Modify Shared Web Part" from the Part menu.)

1. From Site Actions, select Edit Page.
2. From the Edit menu that appears on the web part, select "Modify Shared Web Part". This will summon the properties task pane.
3. In the task pane, expand the "Search Box" section, and you will see check boxes for each of the word/phrase options, as well as the section label.
   

From here, you can enable or disable each of the four word-search types. You can also customize the display to use prompts other than the defaults. While I think the descriptions used for this section are pretty good, perhaps for some reason instead of "None of these words", you want the prompt to say "Exclude these words". Just the updated text into the text box below the check box, and click Apply. (Note: due to caching you may not actually see the results until you access the page again through the site navigation.)

Couldn't be easier, right?

If you use multiple scopes in your site, you can also configure the Advanced Search box to show them. The next section of the task pane is the "Scopes" section.

Just as with the word restriction options, you can easily show or hide the scope picker, and change the labels of both the section as a whole, and the Scopes block. Notice that you can also enable, disable, and re-label the languages and results types from here. I'll talk about that more in Part 2.

For now, notice the "Display group" option. This is where you control which scopes are displayed in your advanced search form. The default is, naturally "Advanced Search". However, you can change this to any display group configured on your site.

To configure a display group, you need to go to your Site Settings page. Then, under Site Collection Administration, click the View Scopes option. You will see a page that resembles the one below.

When you create or edit a display group, you will see the form below.

Here you first give your group a title (which was used in the Display group form above). Then, select which of your scopes to include, the order in which they appear, and which will be selected by default when using a drop-down control, such as that the one in the "corner" search box.

(Note: The actual defining of scopes is a subject for another article)

In this part, you have seen how easy it is to configure the "top" half of the Advanced Search box. MOSS (or Search Server) provides an easy interface for enabling and disabling sections, and for configuring Scope Display Groups.

Unfortunately, the rest of the configuration isn't quite as simple. The second part of this article will take you into the depths of the XML required to customize the remainder of the Advanced Search box.