John W Powell : WSS3

SharePoint Database Naming Standards

johnwpowell — Tue, 15 Dec 2009 14:44:00 GMT

Call me picky, but I think it’s important to consistently name your SharePoint databases—especially on a shared SQL Server hosting multiple farms and applications. Not only is it a good practice, but by showing that you care about the databases, you’ll earn the respect of even your most grumpiest DBAs. I wish the SharePoint administrative interfaces ushered you into a naming convention, but the reality is that consistent naming requires diligence and a little planning. I would bet that a majority of the SharePoint installations in the wild were configured using using the Products and Technology Wizard GUI. When you use the GUI, it creates the Central Administration content database without giving you the opportunity to provide a meaningful name. If you’ve seen a database named SharePoint_AdminContent_[YOURGUIDHERE], you know what I’m talking about. Imagine you are supporting multiple SharePoint farms—is it easy to tell which database belongs to which farm? Shouldn’t it be?

Naming Convention

Here is the naming convention I recommend for SharePoint 2007:

SharePoint_[Farm Name]_[Database Type]_[Name] where database type is one of the following:

Config
Content
WSSSearch
SSP
SSPSearch

For example, the AdventureWorks MOSS 2007 Enterprise Intranet farm would have the following databases:

Database	Purpose
SharePoint_AWIntranet_Config	Farm Configuration
SharePoint_AWIntranet_Content_CA	Central Administration Content
SharePoint_AWIntranet_Content_Intranet	Company Intranet Content
SharePoint_AWIntranet_Content_DefaultSSP	Default SSP Content
SharePoint_AWIntranet_Content_DefaultSSPMySite	My Site Content for Default SSP
SharePoint_AWIntranet_Content_OtherSSP	Other SSP Content
SharePoint_AWIntranet_Content_OtherSSPMySite	My Site Content for Other SSP
SharePoint_AWIntranet_SSP_DefaultSSP	Default SSP Database
SharePoint_AWIntranet_SSP_OtherSSP	Other SSP Database
SharePoint_AWIntranet_SSPSearch_DefaultSSP	Default SSP Search Database
SharePoint_AWIntranet_SSPSearch_OtherSSP	Other SSP Search Database
SharePoint_AWIntranet_WSSSearch_SPWFE01	WSS Help Search Web Front End 1
SharePoint_AWIntranet_WSSSearch_SPWFE02	WSS Help Search Web Front End 2

What I like about this naming convention is that the databases sort nicely. On a shared SQL Server, the SharePoint databases are separated from other application databases. Within SharePoint, each farm’s databases are together. Within each farm, the database types are together, and finally, a meaningful name makes it easy to determine which area it belongs to.

Implementing the Naming Convention

The best way to ensure consistency is to script configuration changes. I use PowerShell to tear down and build up my development environment, and I use the same approach to make changes to production servers. In a future post, I will provide a sample, but essentially, I create a script that takes an environment-specific XML configuration file as a parameter. For example:

Provision-Farm.ps1 johnpowell.development.xml

If you are lucky and brilliant enough to have a naming convention in place before the farm has been configured, it is much easier to implement the database naming convention. Implementing a standard after the fact will require additional steps. So let’s suppose you just installed the SharePoint bits and are ready to configure SharePoint. Stop! Rather than use the GUI, use PSConfig from the command line. This enables you to control the Central Administration content database name. For example, to create the configuration and CA database, use the following command:

psconfig.exe -cmd configdb -create –server sqlcluster.aw.com -database SharePoint_AWIntranet_Config -user svc-sp-aw-farm -password pass@word1 -admincontentdatabase SharePoint_AWIntranet_Content_CA

But what if you have an existing farm? In that case, this post describes how to rename the Central Administration content database and this post outlines the procedure for renaming other content databases.

Conclusion

It is good practice to have a database naming convention, and to define and document it during the planning phase. Although the SharePoint administrative interfaces do not enforce a database naming convention, with a little planning and governance you can implement a standard. Once a standard is defined, scripting configuration changes is the best way to ensure they are implemented consistently. For example, you could have a script Create-WebApplication.ps1 that takes a few parameters and implements your naming convention. SharePoint 2010 has significantly more databases that 2007, making database naming even more important. So here are your “go dos:”

Define and document a database naming standard
Create scripts to implement your standards
Evaluate existing farms against your standards, and create a plan to rename them

Make the RSS Feed Viewer Web Part Dynamic Using Filters and Web Part Connections

johnwpowell — Sun, 01 Mar 2009 19:16:00 GMT

One of the shortcomings of the RSS Viewer web part is that it can only be bound one feed. In this walkthrough, I’ll show you how to make the RSS Viewer web part dynamic with filter web parts and web part connections to enable binding to multiple feeds.

Create the RSS Feeds List

In View All Site Content, select Create

Select Custom List and enter a name such as “RSS Feeds.” Next, add two columns to the list. The first column will hold the feed URL and the second column is a one-line description of the feed that will be displayed in the filter list. Name the column “Feed URL,” set the type to Single line of text (not Hyperlink), make it required, and add it to the default view.

Add the description column. Name the column “Feed Description,” set the type to Single line of text, make it required, and add it to the default view.

Next, add some feeds to the list:

Add an RSS Viewer Web Part

Add an RSS Viewer web part to a page:

Configure the web part to default to your favorite feed:

Add a Filter Web Part

Add a filter web part to the page to control which feed is displayed in the RSS Viewer. Add a SharePoint List Filter web part to the page:

Configure the filter web part to use the values from the feed list:

Connect the Filter Web Part to the RSS Viewer Web Part

Next, connect the filter web part to the RSS viewer web part. Select Connections > Send Filter Values To > RSS Viewer:

Set the Connection Type to “Get Feed URL From”:

Test the Filter

Click the browse button on the filter:

Select one of the feeds and the corresponding feed should display in the RSS Viewer:

Conclusion

The RSS Viewer web part can be made more dynamic and provide a better user experience by using filter web parts. In this walkthrough I showed you one type of filter, but I invite you to investigate other approaches using some of the other out of the box filter web parts.

References and Additional Reading

Subscribe to SharePoint Web Parts using Internet Explorer 8 Web Slices

johnwpowell — Mon, 02 Feb 2009 00:34:00 GMT

One of the new features of Internet Explorer 8 is Web Slices. This feature enables you to subscribe to a section of a web page and notifies you when the content changes. By design, SharePoint Web Parts are a natural fit for this feature, and in this article I’ll show you how to build a Web Part that does just that. I’ll also show you how easy it is to develop a web part using the CTP release of Visual Studio 2008 Extensions for Windows SharePoint Services (VSSWse) 1.3.

About Web Slices

Web Slices enable you to have a very narrow control over the content you subscribe to. When you browse a page that has Web Slice sections, they “light up” when you hover over them:

In addition, the new Web Slice icon on the toolbar lights up, and the menu is populated with all the slices on the page:

When you subscribe to a slice, the web page section is added to the toolbar and is periodically refreshed. The refresh interval is completely customizable and can also be refreshed manually:

Defining a Web Slice Section

Web Slices are defined with HTML tags that have certain CSS classes. You can read the full specification, but here’s all you need to know to build your first Web Slice:

To define a Web Slice section, use the hslice class name:

<div class="hslice" id="1">…</div>

To define the slice title, use the entry-title class name:

<p class="entry-title">Game System - $66.00</p>

To define the slice content, use the entry-content class name:

<div class="entry-content">This auction closes in 4 hours.</div>

The end result looks like this:

<div class="hslice" id="1">

<p class="entry-title">Game System - $66.00</p>

<div class="entry-content">This auction closes in 4 hours.</div>

</div>

Build a SharePoint Web Part

For this example, I’m using VSSWSE 1.3 which you can read about here. I would recommend it not only because it’s easy to use, but also because it is sure to become the de-facto standard. To get started, create a new Web Part project:

Choose if you want to deploy to the GAC or bin directory. We’ll use GAC for this example:

A solution is created with a default web part named WebPart1. Rather than renaming it, delete the WebPart1 folder and add a new Web Part to the project with a more descriptive name:

Next, configure the url of your SharePoint site you want to use to test the Web Part. On the Debug settings, set the start url:

In the Web Part, override the CreateChildControls method:

This code generates the needed HTML and is pretty self-explanatory. I chose to hide the Web Slice entry-title as it would be redundant beneath the Web Part title. To test the code, right-click the solution or project and select Deploy. This will package the Web Part as a feature and deploy and activate it on the site:

Next, add the Web Part to a page in the site and test it.

How I Wished It Worked

Web Slices are powerful, but I don’t really want to develop a bunch of new Web Parts to use that feature. I wish every Web Part were capable of wrapping its content in a Web Slice div tag. I’m sure there is a way to inject this functionality (and there might even be a supported method), but I wish it were built in to the Web Part framework. Every Web Part could then have a Web Slice category with relevant settings:

Wouldn’t that be powerful?

Summary

In this article, I demonstrated how to build a Web Part that users can subscribe to using Web Slices. I also showed you how easy it is to build a Web Part using the CTP release of Visual Studio 2008 Extensions for Windows SharePoint Services version 1.3. Happy slicing!