Posted by: Gabe Hilado in SharePoint on June 24th, 2010

Interesting issue we had to troubleshoot today. This issue is related to SharePoint 2007.  Say you have a sub-site in a SharePoint site collection (let’s call it “Subsite A”) and the user/admin changes the URL of the site to something malformed, what happens?

We start “Subsite A” like the following:

Then, we change the URL into something malformed (deliberately for this exercise). See the Web Site Address field below? We’re purposely putting in a bad value (the end-user accidentally did it in the real-world scenario).

After you click the Save button on the Title, Description, and Icon Settings Page, you get the following error on the browser:

This error (HTTP 500 Internal Server Error) means that the website you are visiting had a server problem which prevented the webpage from displaying.

Trying to access the site yields HTTP 500 error:

You think maybe you can rename using SharePoint Designer. But SP Designer throws you an error message instead:

Server error: The version of the Windows SharePoint Services running on the server is more recent than the version of the SharePoint Designer you are using. You need a more recent version of the SharePoint Designer.

But the SharePoint Designer error message is misleading–the SharePoint site is MOSS 2007. It’s the bad URL causing this.

You can fix this by using STSADM renameweb command. In the screenshot below, I rename the badly-formed URL to its original URL using STSADM renameWeb:

The site owner accidentally put in a bad URL and that is why we’re using STSADM to fix it. It’s hard to mess-up the site-collection URL. But if you need to change the URL of a site-collection, you can use STSADM renamesite.

For more details on how to use these commands, visit:

Posted by: Gabe Hilado in ASP.NET, SharePoint on April 14th, 2010

We had a previous SharePoint project where we installed a custom HTTPModule to the SharePoint Web application. Since the SharePoint manifest file cannot inject entries into the httpModules section of the Web.config file (the manifest file can only insert entries inside the SharePoint section of the Web.config such SafeControl entries), we had to use a custom feature-receiver class, based on the SPFeatureReceiver. The custom feature-receiver class did it’s job nicely; whenever the feature got activated, the required entry in the httpModules section of the Web.config file got inserted.

Sequence property of the WebConfigModification can be used to figure out the uninstall order.

Unnamed sections such as connectionStrings and bindings sections, appear to have an XPATH expression that may result in duplicate matching. But, the ApplyWebConfigModifications method of the WebConfigModifications object will do it correctly as long as:

  • EnsureChildNode is used as the type
  • Add/Remove in order that is logical. Example: add connectionStrings section first then the add elements inside the connectionString section.
  • If you are worried that de-activating a feature will obliterate the connectionStrings section because your feature created it, don’t. SharePoint will only take out the connectionStrings if there are no other entries created by the ApplyWebConfigModifications inside the connectionStrings section. If other features inserted 1 or more connection-string entries there, your feature-receiver will not remove the connectionStrings section. Now, if the connectionString section got edited manually, the SharePoint WebConfigModifcations object will not know this and it doesn’t matter how many child-nodes there are inside the  connectionString object. The root element (connectionString) in this case will be removed because in SharePoint’s perspective, there are no existing Web-config modifications inside connectionString.

Conclusion: if you are going to adopt feature-receivers to install web.config entries such as connection-strings and bindings (for Service-References), you must also adopt to policy to discourage manual insert/modification of the web.config entries. Be consistent.

Posted by: Gabe Hilado in Networking Events, SharePoint on April 6th, 2010

SharePoint Saturday is coming up to the DC Metro area once more! It is scheduled for May 15 and it is going to be held at Northern VA Community College in Annandale. Here’s the link:

http://www.sharepointsaturday.org/dc/default.aspx

If you’re around DC area and you’re an IT professional using SharePoint, I recommend you attend. And you don’t want to miss this one. The last SP Saturday DC that I attended, they intentionally banned discussions of SharePoint 2010 in the official agenda (you can talk it on the hallways and breaks but wasn’t allowed at the session topic). Looking at the current lineup of the sessions, there are going to be a lot of SharePoint 2010 sessions! So attend!

SharePoint Saturdays typically have good sessions and it’s an opportunity to meet other SharePoint folks. If you’re not from the DC area, SharePoint Saturdays are all over the country and I would recommend checking  what the closest SharePoint Saturday is.

Newer Posts »