John W Powell : SharePoint

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

SharePoint 2010 Localization with Visual Studio 2010

johnwpowell — Sun, 29 Nov 2009 02:30:00 GMT

In this walkthrough, I’ll show you how to create a SharePoint 2010 localized feature using Visual Studio 2010. The basic mechanics of localizing a SharePoint 2010 feature are the same as localizing a SharePoint 2007 feature, and is well documented. If you are unfamiliar with localization in SharePoint, please see Additional Resources at the end of this article. In a nutshell, localized resources are stored in Resources (.resx) files, and in SharePoint exist in one of the following locations:

\14\Template\Features\<Feature Name>\Resources\
\14\Resources\
\14\Config\Resources\
<Virtual Directory>\App_GlobalResources\ (note: resources files from \14\Config\Resources are copied here when provisioned)

Resources files follow a naming convention that consists of a base name such as “HelloLocalization.resx” and culture-specific resources such as “HelloLocalization.es-ES.resx.” In SharePoint, these files must be in a particular location depending on usage. In this walkthrough, I’ll show you how to create a “centralized” resources files that will be stored in 14\Resources. My preference is to store custom files in as few locations as possible within the SharePoint hive. I have also found that certain resources cannot be accessed from certain locations. So with that in mind, let’s get started:

Since we are deploying to 14\Resources, we need to add a mapped folder. Select Add > SharePoint Mapped Folder…

Select the Resources folder:

In the solution, delete the subfolder that was created in the Resources folder. Next, right-click on the mapped folder and select Add New Item. In the Search Installed Templates search box, type Resources to select the Resources file template. Rename the resources file to something unique to your feature:

Set the Build Action to Content for the resources file:

Add your localized strings to the resource file:

For each feature, set the Default Resource File to the resource file name. This enables you to reference a resource without fully qualifying it:

Optional: you can hide a feature when localized resources are not available for it by setting the Require Resources setting to True:

Now you can use the localized strings throughout your feature such as in the feature title and description:

When deployed, the feature appears like this in Site Collection Features:

The resources can also be used in the .webpart file:

<?xml version="1.0" encoding="utf-8"?>
<webParts>
<webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
    <metaData>
      <type name="HelloLocalization.LocalizedWebPart.LocalizedWebPart, $SharePoint.Project.AssemblyFullName$" />
      <importErrorMessage>$Resources:core,ImportErrorMessage;</importErrorMessage>
    </metaData>
    <data>
      <properties>
        <property name="Title" type="string">$Resources:HelloLocalization,WebPartTitle</property>
        <property name="Description" type="string">$Resources:HelloLocalization,WebPartDescription</property>
      </properties>
    </data>
</webPart>
</webParts>

Which appears like this in the Web Part Gallery:

When you add the web part to a page, it appears like this:

The localized resources can also be used in the web part:

protected void Page_Load(object sender, EventArgs e)
{
    var lang = SPContext.Current.Web != null ? SPContext.Current.Web.Language : 1033;
    webPartMessage.Text = SPUtility.GetLocalizedString(
        "$Resources:WebPartMessage", 
        "HelloLocalization", 
        lang);

}

Which appears like this when added to a page:

To support a different culture, copy the resources file, and rename it to [ResourcesFileName].[Culture].resx. For example, to create a Spanish (Spain) resources file:

Make the culture-specific changes to the resources strings:

If the language pack is installed on the SharePoint server, and the site has been created using that language, the resources file will be used:

For completeness, you should also be aware of the Visual Studio 2010 Feature Resources feature. When you select Add Feature Resource...:

you are prompted for the culture, and the appropriately named resource file is created automatically:

Conclusion

In this walkthrough, I showed you how to localize a SharePoint 2010 feature. Even if you aren’t targeting multiple languages, in my opinion it’s good practice to store resources outside of your compiled code. I hope you found this useful, and your feedback is welcomed!

Additional Resources

Enable the Developer Dashboard using the Object Model / Powershell

johnwpowell — Sun, 22 Nov 2009 23:05:00 GMT

The SharePoint 2010 developer dashboard has three display levels (see SPDeveloperDashboardLevel Enumeration.):

Off (default): The dashboard is not displayed, and there is no UI element to turn it on
On: The dashboard is displayed, and there is no UI element to turn it off:

OnDemand: A UI element enables you to turn it on or off

There are a few ways to set the developer dashboard level. One option is to use stsadm –o setproperty –pn developer-dashboard –pv “On”, but in this article, I’ll show you how to control the dashboard through the object model using PowerShell.

To configure the dashboard, use the SPWebService.ContentService object to set properties on the SPDeveloperDashboardSettings class. Here is the PowerShell script to set the level:

param($level = $(throw "level is required. Level is On, Off or OnDemand"))

# import assemblies
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Administration")

# set the level
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$contentService.DeveloperDashboardSettings.DisplayLevel = ([Enum]::Parse([Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel], $level))
$contentService.DeveloperDashboardSettings.Update()

Write-Host ("Developer Dashboard Level: " + $contentService.DeveloperDashboardSettings.DisplayLevel)

Here is a complimentary script to view the current settings:

# import assemblies
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Administration")

# get the level
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
Write-Host $contentService.DeveloperDashboardSettings.DisplayLevel

Visual Studio Extensions for Windows SharePoint Services (VSEWSS) Error: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information

johnwpowell — Sun, 16 Aug 2009 17:10:00 GMT

One error you may see when packaging solutions with VSEWSS is: Microsoft.SharePoint.Tools.Utilities.VSeWSSServiceException VSeWSS Service Error: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information. Like most error messages from VSEWSS, there is not enough information provided to resolve the issue, so I hope to save you some time by providing a workaround that will permanently fix this problem.

When VSEWSS packages your solution, it uses reflection to enumerate the packaged assemblies. It works fine until it encounters an assembly that implements an interface that is defined in another assembly as is often the case in the Microsoft.Practices.* assemblies. I am unsure of exactly why, but the extensions are unable to resolve the dependent assemblies. To work around the issue, you can copy the dependent assemblies to the GAC, but I don’t think this is the optimal solution and doing so will cause pain during development and debugging. Another option is to copy the dependent assemblies to the VSEWSS service bin directory post build. After trying this for awhile, and maintaining the script, I decided it would be much simpler to just copy all assemblies in my solution to the VSEWSS service bin directory on post build. Here is the script:

@rem======================================================================
@rem
@rem    This script copies assemblies to the VSEWSS bin directory
@rem    to eliminate the packaging type load exception that occurs
@rem    when an interface is defined in a separate assembly.
@rem    
@rem    usage call $(ProjectDir)Scripts/CopyAssembliesToVSEWSSBin.bat $(TargetDir)
@rem
@rem======================================================================

@echo off

@echo ========== Locating VSEWSS bin directory ==========
@set vsewssbin=%programfiles%\Microsoft SharePoint Developer Tools 9.0\svc\bin
if not exist "%vsewssbin%" set vsewssbin=%ProgramW6432%\Microsoft SharePoint Developer Tools 9.0\svc\bin
@echo VSEWSS bin: %vsewssbin%

@echo ========== Copying assemblies to VSEWSS bin directory ==========
@xcopy "%1*.dll" "%vsewssbin%" /R /Y

To use the script, create a bat file in your project and call it from a post build event. It does take 64-bit installations into account, and it will also work on your Team Build server.

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!

References and Additional Reading

How to Copy an Assembly From the GAC to the File System

johnwpowell — Wed, 14 Jan 2009 04:20:00 GMT

Sometimes you need a local copy of an assembly from the GAC and here is a quick tip on how to do it. The GAC can be found in the c:\windows\assembly directory, but if you try to browse it, the following custom shell extension appears:

This view does not provide the ability to copy assemblies, but it does provide some very useful information such as the strong name details. Here are some options to get around that feature to copy an assembly from the GAC.

Option 1: Disable the Shell Extension in the Registry

One possibility, but not the best one, is to disable the shell extension. I don't like this approach because it involves editing the registry and I like the information provided by the shell extension. Here's how to disable the extension if you want to. Open the registry editor and add/set the HKLM\Software\Microsoft\Fusion\DisableCacheViewer DWORD value:

Set the value to 1:

Once you make that change, you can browse the directory:

Option 2: Go Command-O

Another option is to copy assemblies from the GAC from the command line. This approach works well if you prefer working from the command line, but if you like to right-click with a mouse, this might not be the choice for you.

I highly recommend PowerShell, but you can use Windows Command Prompt. Find your way to the c:\windows\assembly directory and copy the file you need:

Option 3: Use the SUBST Command

The SUBST command allows you to create a shortcut to a path on your file system and assigns that shortcut a drive letter. I really like this approach because you have the option of using Windows Explorer without having to disable the shell.

Suppose you want to create a G Drive (G for GAC), use the following command: SUBST G: C:\WINDOWS\ASSEMBLY

Then in Windows Explorer you are free to double-click and right-click to your heart's content and still use the shell extension.

Search SharePoint from the Internet Explorer Toolbar Using a Custom Search Provider

johnwpowell — Tue, 08 Jul 2008 21:06:00 GMT

Here is an easy way to search a SharePoint site from the IE toolbar without having to develop a custom add-in. Before showing you how to implement it, let's examine how custom search providers work.

How Custom Search Providers Work

When you browse to an Open Search enabled site in IE 7, the search provider drop down lights up

You can use a search provider temporarily while on the site (the yellow star indicates it's temporary), or permanently add it to your list of search providers

To temporarily use a search provider, click the provider name and the search box will change

To permanently add a search provider, click Add Search Providers and select the provider name

A confirmation dialog appears

After that, your custom search provider will remain in the list (note there is no yellow star) no matter which site you are currently on

When the users searches from the search box, they are taken to the SharePoint search results page

How to Implement A Custom Search Provider in SharePoint

To implement a custom search provider, create an XML file that describes it and place a link to the file on the site home page.

Let's create the search provider XML file. The XML is self-explanatory, with the key element being the Url. There is a special token: {searchTerms} that will be replaced with the text the user types in the search box. Note that the Url is absolute and will be different if you are using the MOSS Search Center (searchcenter/Pages/Results.aspx?k={searchTerms})

Upload the XML file to the Shared Documents library

Place a link tag in the home page of your site. You can put it anywhere in the page, but put it in the <head> element if possible. The simplest approach is to use a Content Editor web part with the Chrome Type set to None

That's all there is to it!

Summary

As you can see, implementing a custom search provider for SharePoint is simpler than a single-colored Rubix Cube. If you would like to learn more about Open Search, the full specifications are available here: http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_description_document.