Don´t recommend a backup restore to anyone after 3 days…
Hi folks, here it is, another real life story…
A while ago when I arrived to a customer site, he came to me and told me that he had a problem in his MOSS 2007 Server Farm, that for 3 days no one was able to access one of the intranet main site nor any of it sub-sites. The error was:
500 INTERNAL SERVER ERROR
When I asked him what append to cause the problem, no one knew to answer. So I started analyzing the problem. To start with I accessed the customer site and used Site Content and structure to check the structure of the site:
Figure 1 - Scenario created only for purpose of this post
When navigating the tree of the Site Content and Structure it was perfect form the structure point of view, and I was able to navigate on the structure without any issue. But when I tried to do any other kind of action like Open Link in New Window or creating a new item there was the issue again.
500 INTERNAL SERVER ERROR
The next thing was to look at the URL and there was something funny, no matter the action called on the HugeSite_LotsOfSubsites or one of its sub-site I would end up with the same URL https://intranetSite/HugeSite_LotsOfSubsites.aspx/Pages/default.aspx.
Analyzing the URL I noticed 2 .ASPX in the same URL K https://intranetSite/HugeSite_LotsOfSubsites.aspx/Pages/default.aspx, and “there is the problem…“. It was the problem, alright, but how was it caused and how to solve it. Talking to the customer I showed him only the URL the site (https://intranetSite/HugeSite_LotsOfSubsites.aspx) and pointed that this should be the problem. After that moment our conversation was more or less like this:
Me: This is the url that is causing the problem https://intranetSite/HugeSite_LotsOfSubsites.aspx
Customer: That is an aspx page.
Me: No, this is your current site URL.
Customer: No, that is an aspx page.
…
You get the idea J…
Just after our chat he remembered that some user was changing some Site Title´s and Url Name´s using the General Settings feature like the images below:
The cause was found in the Url Name: text box, someone wrote HugeSite_LotsOfSubsites.aspx instead of just HugeSite_LotsOfSubsites, makingthis site inaccessible and all of its child sites. Now we had to find a solution, because using General Settings of the site to correct it was out of question, since any action on HugeSite_LotsOfSubsites would cause the ….
500 INTERNAL SERVER ERROR
In a previous conversation the customer had told me that restoring the backup should be our last resort, because the problem started 3 days ago, the sites that were working continued to be changed by users. So all I had left was the powerful SharePoint object model J.
To validate the assumptions made before, I did a console application to validate the ServerRelativeUrl of SPWebin question:
using(SPSite site = new SPSite("https://intranetSite/HugeSite_LotsOfSubsites.aspx")) { using (SPWeb web = site.OpenWeb()) {
Console.WriteLine(string.Format("The relative Url is: {0}",web.ServerRelativeUrl));
} }
|
Code 1 - Validating in C#
The equivalent in Windows PowerShell is:
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") Try { $site = New-object Microsoft.SharePoint.SPSite("https://intranetSite/HugeSite_LotsOfSubsites.aspx ") $web = $site.OpenWeb() " The relative Url is: " + [string]$web.ServerRelativeUrl } Finally { if ($web -ne $null){ $web.Dispose() } if ($site -ne $null){ $site.Dispose() } } |
Code 2 - Validating in Windows PowerShell
The result was:
The relative Url is: /HugeSite_LotsOfSubsites .aspx |
All that was left to do was using correcting the URL with some simple code like the following in C# that would change the ServerRelativeUrl of SPWeb object in question:
using(SPSite site = new SPSite("https://intranetSite/HugeSite_LotsOfSubsites.aspx")) { using (SPWeb web = site.OpenWeb()) { web.ServerRelativeUrl = "HugeSite_LotsOfSubsites"; web.Update(); } }
|
Code 3 - Correcting the problem C#
An even easier way to do it was to use Windows PowerShell to do the same thing:
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") Try { $site = New-object Microsoft.SharePoint.SPSite("https://intranetSite/HugeSite_LotsOfSubsites.aspx") $web = $site.OpenWeb() $web.ServerRelativeUrl = "HugeSite_LotsOfSubsites" $web.update() } Finally { if ($web -ne $null){ $web.Dispose() } if ($site -ne $null){ $site.Dispose() } } |
Code 4 - Correcting the problem Windows PowerShell
With this, the problem was solved without having to restore the 3 days ago backup. This was a problem easy to troubleshoot and to fix, thanks to the flexibility of the SharePoint object model. This also shows that SharePoint being so flexible makes it easy for less experienced users to do big damage if they have sufficient privileges to do it. With this post I also wanted to show you how easy can be using SharePoint API with PowerShell, and more important of all never name a Sharepoint site ending in .ASPX.
See you next time!