A few months back I gave a presentation at the Houston SharePoint Users Group (HSUG) on how to customize the People Search Results Page. The presentation includes a brief high level walk-through on how to configure the Active Directory Profile Import to include additional Active Directory property mappings, and how to display these newly mapped properties in the search results page using the People Search Core Results web part.
You can download the presentation here.
I just recently responded to a post in one the MSDN SharePoint forums where a user was asking how he could determine what templates where being used by his sites. I didn’t really feel like having him look at the database, so I wrote a simple application page that exposes the WebTemplate and WebTemplateID properties of the SPWeb object. Here is what the code looks like:
Save the page to your layouts folder (usually c:\program files\common files\microsoft shared\web server extensions\12\template\layouts\). Once the page has been saved, you can access it from any of your SharePoint sites via http://yoursharepointsiteaddress/_layouts/pagename.aspx
Updated 8/26/2008: Updated code to remove “using” statement when getting a reference to the SPWeb object. Disposing of a shared resource such as an SPWeb object obtained from the current context may cause the SharePoint object model to behave unpredictably. Instead we should let SharePoint manage the object. See Best Practices: Using Disposable Windows SharePoint Services Objects for more information.
I recently performed another upgrade from SharePoint Portal Server 2003 to MOSS, and while the upgrade was executed without any major problems(I’ve earned bragging rights); we experienced a large number of calls due to broken links from other sites, and links that where saved as shortcuts or browser “favorites”. Most of them were due to a very large information re-architecture.
Some of the more important links where accounted for and redirected to the proper pages by adding URL mappings to the web.config file, a surprisingly easy though not very common technique. Undoubtedly many files would be left out, as its rather difficult (never say never) to find out what links and shortcuts people have saved. Ultimately they wanted a custom 404 page that would display a page with a friendly message using the portal look and feel.
This is fairly easy to accomplish as SharePoint does provide an SPWebApplication property (FileNotFoundPage) to specify a custom 404 page. Unfortunately the property is only accessible via the API, and the file must be an HTML page located in \\Program Files\Common Files\Microsoft Shared\web server extensions\12\LAYOUTS\Locale_ID
Of course it would be easier if we could set this property from Central Administration, and why stop there, why not allow an administrator to specify a page in the portal, or anywhere else, and of any type for that matter. So I developed a SharePoint solution containing the following:
- An HTML page to specify as the FileNotFoundPage of the web application. This page redirects all requests to custom application page where its easier to handle the request.
- A settings page from where custom settings on how to handle the request can be specified for each web application.
- A SharePoint application page that handles the request based on the custom settings specified for the web applicaiton
- A feature that creates a menu item in “Central Administration > Application Management” for the settings page
The HTML file is simply a copy of the sps404.htm file that SharePoint installs by default in “c:\program files\common files\microsoft shared\web server extensions\12\template\layouts\1033″, I’ve simply replaced the path it uses to redirect requests to with that of my custom 404 handler aspx page.
The Custom404Settings.aspx page allows the user to select a web application and specify a custom 404 page. The value specified is saved to a custom property of the web application that can later be referenced by the Custom404Handler.aspx page.
The following code is used to update the FileNotFoundPage property of the web application and create a new property “Custom404Path” to store the specified custom 404 path value.
SPFarm farm = SPFarm.Local;
SPWebService service = farm.Services.GetValue("");
string webAppPropertyKey = "Custom404Path";
Guid webAppGuid = new Guid(lstWebApplications.SelectedValue);
SPWebApplication webApp = service.WebApplications[webAppGuid];
//create a web application property to store the
//path to the custom 404 page
webApp.Properties[webAppPropertyKey] = txtCustom404Path.Text;
lblMessage.Text = "Changes saved";
//update the FileNotFound property of the web application
//this needs to be an html page in the LAYOUTS/1033
webApp.FileNotFoundPage = "Custom404Page.htm";
//update the web application
The Custom404Handler.aspx page checks the value of the Custom404Path property of the web application and redirects the browser to that page. If the custom 404 path specified returns as the path not found (“oldUrl” querystring parameter) the page does not redirect the user and serves the custom 404 message itself (this is to avoid going into an endless redirect loop).
The following code is used to check the custom 404 path of the web application and perform the redirect.
using (SPSite thisSite = new SPSite(SPContext.Current.Site.Url))
string custom404Path = "";
string pageNotFound = Request.QueryString["oldUrl"];
SPWebApplication webApp = this.Site.WebApplication;
custom404Path = (string)webApp.Properties[webAppPropertyKey];
if ((custom404Path != "") && !(custom404Path.ToLower().Contains("custom404handler.aspx")) && !(pageNotFound.ToLower().Contains(custom404Path.ToLower())))
The feature.xml and elements.xml files add a custom menu item to “Central Administration > Application Management” from where the users can specify the custom 404 settings.
Updated 7/28/2008 : Updated Samples, Project Files and WSP to include recommended changes for handling anonymous requests.
So, I’ve been asked about this subject several times (this being; how to give specific users full control over a web application.) The topic usually comes up when administrators or support personnel find themselves unable to access specific content in SharePoint, sometimes because they should not have access to the content (such as confidential HR documents, or the Clam Chowder Recipe at Monterey’s Fisherman’s Warf), and other times because an unknowing user with way too many privileges accidentally removes the administrators permissions from the site collection (this behavior is by no means a bug or limitation of the system, it is by design.) Either way there is an easy fix and way to get around this restriction: Policy for Web Application.
Policy for Web Application is a link located in Central Administration > Application Management under the Application Security section. It essentially allows farm administrators to create security policies allowing them to override standard SharePoint permissions for all sites in a web application, for any or all web application zones, regardless of what permission are given (or denied) at the site collections or sites.
You will find that some accounts are automatically given rights, typically the NT AUTHORITY\LOCAL SERVICE and the Search Crawling/Content Access Account. Be careful not to remove these. The Search Crawling account will automatically be given Full Read access, it needs it to properly crawl content.
A brief how to can be found at: http://technet.microsoft.com/en-us/library/cc179366.aspx
While upgrading a Shared Service Provider today. I received the following error which also happens to be the title of this blog post: Shared Services Provider creation failed Reason: User cannot be found.
A quick check of the SharePoint logs (c:\program files\common files\microsoft shared\web server extensions\12\logs) revealed that the error was thrown during execution of a method used to create site collections. The method requires a user to be specified as the site owner… but wait; the command I use to restore/upgrade the Shared Service Provider (stsadm -o restoressp) does not support specifying an account for the site collection owner.
So where could this account be coming from? Looking for the owner of the Central Administration Site revealed that the AD account specified as the Primary Site Collection Administrator no longer exists. I update the account to that of the new SharePoint farm administrator, execute the SharePoint timer jobs (stsadm -o execadmsvcjobs), and the Shared Service Provider provisioning process automatically continues (and succeeds).
Step by step instructions below:
- Go to SharePoint Central Administration –> Application Management.
- Click “Site Collection Administrators” under the “SharePoint Site Management” group.
- Make sure you select the Central Administration Site Collection.
- Update the Primary (and secondary of necessary) Site Collection Administrator accounts.
- Execute the following stsadm command:
stsadm -o execadmsvcjobs
You can verify the status/progress of the SSP by clicking on the “Shared Services Administration” link on the left navigation of the Central Administration site.