Configuring Custom 404 Pages using PowerShell


I came across an interesting challenge while working on my current project; which is a migration from a classic HTML-based website to SharePoint 2010 For Internet Sites, Enterprise.  Custom error pages…

Out of the box, SharePoint likes to give the user a useless 404 error like this:

image

While there is out-of-the-box support for custom error pages in SharePoint 2010, it’s not completely obvious how you set the custom error pages for a web application.  First of all, SharePoint includes an sps404.html page in the /_layouts/{language} folder which by default includes an STSNavigate reference to handle the redirect.  That’s all well and good, but I want my own!

Here’s how I got what I wanted:

Copy the sps404.html page and rename it to sps404custom.html – leave the new file in the same location.  Open the file in your favorite HTML editor and look for the STSNavigate line – change the link to an appropriate page, example /Pages/Page-Not-Found.aspx.

This would replace the OOTB 404 behavior with an automatic redirect to a Publishing page under the root Pages library of my web application.  Cool!

Now I just have to create a page at /Pages/Page-Not-Found.aspx and add some text.  The page will inherit whatever branding elements I’ve applied to the rest of my site, leaving the user with a much cleaner and consistent experience.  Once I’ve done those two things, there’s a little PowerShell that must be done to actually set the custom 404 page:

$WebApp = Get-SPWebApplication http://url
$WebApp.FileNotFoundPage = "sps404custom.html"
$WebApp.Update() 

Once that’s done, try going to a bogus page in your site and you should be taken to your custom 404 page!

image

Why PowerShell and SharePoint 2010 Are So Cool


Anybody who has read one of my posts knows that I am a huge PowerShell geek, I tweet about it, I blog about it, I talk about it SO much at my client that my contacts at said client make me add a dollar to the “PowerShell Jar” whenever I use the word “PowerShell.” 🙂

People who don’t ‘touch’ SharePoint may not completely understand why PowerShell and SharePoint are so cool, so I wanted to put together a quick, fairly non-technical post about why they are so cool…

  1. PowerShell allows SharePoint Developers and IT Pros to automate tasks that in the past would’ve required a LOT of scripting – however, we can do it much, much quicker and easier in PowerShell.
  2. PowerShell allows SharePoint IT Pros access to something that in the past we haven’t had easy access to – the SharePoint API or Object Model. (Note: I’m not a developer so if I use a term incorrectly, forgive me. :))

#1 is fairly obvious, but #2 is really where the power comes in.  There are times when an IT Pro is administering SharePoint and he or she needs to do something that just isn’t possible in the UI or through the standard command interfaces.  Having the ability to call methods from the SP Object Model in PowerShell takes away a lot of headaches!

Example: I need to forcefully delete a service application but can’t do so because I blew away the database.  Remove-SPServiceApplication won’t work at this point because that’s the graceful way to do it and I can’t communicate with the service application database.

Resolution:

$app = Get-SPServiceApplication -Identity
$app.Delete()

That’s right, two quick lines of code and I’ve now deleted the old service application that I couldn’t delete using Remove-SPServiceApplication or through the Central Administration interface.

For other examples of using PowerShell and the Object Model to accomplish tasks that in prior (non-PowerShell-enabled) versions were not possible without code – see one of my other recent posts…

Access Denied (401) on SharePoint 2010 Sites


I came across a weird error today, site collections which were working great just last week are now giving Access Denied errors. Surely I have access, I’m using the System Account… So I tried the normal things like trying to go straight to http://myintranet/_layouts/settings.aspx, etc but to no avail.

After some log reading and searching, I came across this Technet Post which triggered my memory. I was getting the SuperUser Cache warning in my Health Analyzer, so I created a domain account (DOMAIN\SPCache) and configured it to be the super user cache account. Great I thought at the time, warnings now gone, cache working, awesome… Not so awesome, this super user account needs Full Control to the Web Application(s) which it caches.

Not a big deal, I added the account to the Web Application User Policy with Full Control and Voila!; the sites are now back to normal. Whew!