Making Sense of the SharePoint World

Oct-272008

Taking Accounts into Account

MCj02314460000[1]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.

image

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)


Published: Oct-27-08 | 0 Comments | 0 Links to this post
Tagged as: Administration, General, Governance, SharePoint, WSS

Oct-242008

Welcome to the Hotel...

 California Site DefinitionMCj02972890000[1] - Your Last Resort

"You can check out any time you like...

...but you can never leave."

(Apologies to the Eagles.)

Joel Oleson, ex of Microsoft, and now an independent consultant and speaker, has just published a new article called "Just SAY NO to Creating Custom Site Definitions". In this article, he provides several excellent arguments for not using Site Definitions. This is fully consistent with the article I wrote a few weeks ago - "First Do No Harm - The SharePoint Customization Hippocratic Oath."

In that oath, the last point was "The Definition of Success: If you must use a Site Definition, understand the ramifications." I expanded it as follows:

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 upgradable. 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.

Elsewhere in that article, I also say that a Site Definition should be pretty close to your last resort. While I have always maintained this position, it is good to see others also coming around.

In many respects, for unwary developers, a custom Site Definition resembles another kind of lodging - euphemistically called a "motel". Site definitions may be attractive, but beware - Sites check in, but they don't check out!

Update:

Ian Morrish has also recently commented on the dangers of using Site Definitions indiscriminately.


Published: Oct-24-08 | 0 Comments | 0 Links to this post
Tagged as: Administration, Design, Governance, Programming, SharePoint Designer, SharePoint, WSS, Customization

Oct-212008

A List, a View, a Part, in SharePoint

MCj02305090000[1]

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...

image

(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.

image

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:

image

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.

image

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.

image

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.

image

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.

Published: Oct-21-08 | 0 Comments | 0 Links to this post
Tagged as: Administration, Lists and Libraries, WSS, SharePoint, General

Oct-122008

Finding Buried Treasure - Built-in Usage Reports in SharePoint and Search Server

MCBD06653_0000[1]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.

image

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:

image

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:

image

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

image

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.

image

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:

image

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.

File Purpose Unique Characteristics
usage.aspx Text Mode Site Collection Usage Summary The only report that shows total registered site collection users, and storage compared to quota.
usageDetails.aspx Text Mode Web Usage Details The only built-in reports that can show a cross-tab of items by day. Monthly summary and daily views for each of several metrics.
SpUsageSite.aspx Site Collection Scope, graphical and text representations of usage. Includes Quick-launch links for Search Queries and Results reports.
SpUsageWeb.aspx Individual Site Scope, graphical and text representation of usage. Easily digestible information on a single Site.
SpUsageSiteQueries.aspx Site Collection Scope, graphical and text representation of user queries. Rolling 30 day and 12 month query charts, Top query phrases, and percent of queries by scope.

SpUsageSiteResults.aspx

 Site Collection Scope, summary of query results. Most popular results, and diagnostic tables. Zero result queries, Best Bet info, queries with low click-through to results.

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.

image

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.

image

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 this zip file. 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:

image

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

image

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.


Published: Oct-12-08 | 4 Comments | 0 Links to this post
Tagged as: Administration, SharePoint, Search Server