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:

• How to use the new “renamesite” operation to change the URL of a host-named site collection in Windows SharePoint Services 3.0.
• Renameweb Stsadm operation (Windows SharePoint Services)

Solution Explorer in VS 2008

In order to see the manifest.xml or feature.xml file, you have to look at the “WSP View“. WSP View can be accessed by going to the menu and hitting View–>Other Windows–>WSP View. The WSP View looks like the following:

WSP View

The manifest.xml file doesn’t contain “product description” type information. The manifest.xml contains assemblies and features information. The feature.xml file, that on the other hand, start containing “description” type data. Here’s what the feature.xml contents typically look like:

<?xml version="1.0" encoding="utf-8"?>

<Feature Id="cfc5cfdd-62cf-4d98-aeba-e1b38ec6f64f"

             Title="HelloPart"

             Description="A Web part that wants to say hello to you."

             Scope="Site" Version="1.0.0.0" Hidden="FALSE"

             DefaultResourceFile="core" xmlns="http://schemas.microsoft.com/sharepoint/">

  <ElementManifests>

    <ElementManifest Location="HelloPart\HelloPart.xml" />

    <ElementFile Location="HelloPart\HelloPart.webpart" />

  </ElementManifests>

</Feature>

See that Title and Description attributes inside the Feature element? They will get displayed in the Site Features Gallery: 

WP Title and Description in the Features Gallery

What about the Web part file (in the example I’m using above, the filename is HelloPart.webpart)? What information can be customized and modified here? First, let’s take a look at the contents of the webpart file:

<?xml version="1.0" encoding="utf-8"?>

<webParts>

  <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">

    <metaData>

      <!--

      The following Guid is used as a reference to the web part class,

      and it will be automatically replaced with actual type name at deployment time.

      -->

      <type name="247ef4d4-489d-46d1-a628-8d8daa6267a3" />

      <importErrorMessage>Cannot import HelloPart Web Part.</importErrorMessage>

    </metaData>

    <data>

      <properties>

        <property name="Title" type="string">Gabe's Hello Web Part</property>

        <property name="Description" type="string">HelloPart is a user-friendly Web part....</property>

      </properties>

    </data>

  </webPart>

</webParts>

Inside webPart–>data–>properties section, there are property elements. The first one is the “Title” and the other is the “Description“. The values for “Title” and “Description” contained in the webpart file are what gets displayed in the Web part catalog:

WP Title and Desription in the WP Catalog

Finally, let’s take a look at the Web part XML file (in the example I used above, the filename is HelloPart.xml). The Web part XML file contains the following:

<?xml version="1.0" encoding="utf-8"?>

<Elements Id="247ef4d4-489d-46d1-a628-8d8daa6267a3" xmlns="http://schemas.microsoft.com/sharepoint/" >

  <Module Name="WebParts" List="113" Url="_catalogs/wp">

    <File Path="HelloPart.webpart" Url="HelloPart.webpart" Type="GhostableInLibrary" />

  </Module>

</Elements>

See how the File element doesn’t have any children? We can put a Property element as a child of the File element. This Property element will contain the “Group” the Web part appears in the catalog. By default, like the in the Web part XML file example above, the Group is not specified and therefore, the Web part gets listed under Miscellaneous Group in the Web Part catalog. If you want the Web part to appear in a group other than Miscellaneous, transform the Web part XML file from the above example to the following:

<?xml version="1.0" encoding="utf-8"?>

<Elements Id="247ef4d4-489d-46d1-a628-8d8daa6267a3" xmlns="http://schemas.microsoft.com/sharepoint/" >

  <Module Name="WebParts" List="113" Url="_catalogs/wp">

        <File Path="HelloPart.webpart" Url="HelloPart.webpart" Type="GhostableInLibrary">

              <Property Name="Group" Value="My Stuff"/>

        </File>

  </Module>

</Elements>

We added the Property element below the File element. The Name attribute of the Property element should have a value of “Group” and the Value attribute is the group name you want the Web part to appear in the catalog. In the example above, after the Web part gets deployed, the Web part appears in a category called “My Stuff“:

Web Part appearing on specified Group

I found this walkthrough from Bamboo Solutions on how to install SharePoint on Windows 7. It worked and all I can say is wow! Now, there were two issues that I ran into when I tried to follow the walkthrough. First issue I ran into was is making the boot-strapper launch the MOSS installer. I have the original media from 2007 and no matter how many times I tried to make Bamboo Solution’s setup-helper launch that setup.exe, it wouldn’t launch it. The error message that I got was:

WSS on Vista - Setup Controller Command Line Help

I tried renaming the setup.exe file to SharePoint.exe, thinking maybe, just maybe the setup-helper is file-name dependent. It didn’t work. Finally, I decided to just go ahead and download the trial version of  MOSS (if you have proper license):

• x86 MOSS 2007 Trial
• x64 MOSS 2007 Trial
• x86 WSS 3.0
• x64 WSS 3.0

If you don’t have MOSS license, just download WSS 3.0. If you have MOSS license, you can enter your key during the installation to make the installation permanent. I tried x64 MOSS 2007 trial with the Bamboo helper and it worked.

One more issue I ran into was when I ran the SharePoint Configuration Wizard for the first time. It said that I don’t have IIS installed. Well, I already had IIS running–IIS 7. When I picked the Windows feature to install, I did not select the IIS 6 Management Compatibility:

Turn on IIS 6 Management Compatibility in Windows Features

The moment I turned on IIS 6 Management Compatibility, the SharePoint Configuration Wizard was able to proceed.

I’m very happy with my laptop setup now. I have MOSS running on it and I don’t even need a virtual machine anymore. Do I think it’s risky to install MOSS on my base OS? I don’t think so; I’ve been installing and running SharePoint since 2007 and I have yet to see it mess up the operability of an application or service in Windows. But then again, I’ve always used Windows 2003 Server. Who knows what kind of issue I will run into running MOSS on top of Windows 7.

As much as I recommend you guys trying MOSS/SharePoint on Windows 7, I highly recommend you run the upcoming SharePoint 2010 beta on a virtual machine only! When SharePoint 2010 Beta comes out next month, I will be running that inside a virtual Windows 2008 Server.

Okay, so install Search Server 2008 Express edition on top of WSS 3.0. This upgrades the configuration database of the existing WSS 3.0 farm. (There are many ways to upgrade WSS 3.0 to have Search Server 2008 but what I was doing was upgrading an existing WSS 3.0 farm configuration database.)

SS 2008 Express installation ran fine without any problems. The Configuration Wizard launches after the installation and the Configuration Wizard ran fine too. Now, when you access the Central Admin for the first time after installing SS 2008 Express, instead of default.aspx at the Central Admin site, you get presented with the Search Server Wizard Page instead. It is http://centraladmin/_admin/SearchServerWizard.aspx. Here you can specify the databases and other setttings for your Search Server.

Well, if the SQL Server 2005 hosting the content and config databases is not SP2 or later, you will get the following error message when click the OK button at the Search Server Wizard page:

Search Server has detected that the minimum database server version requirement is not met. The computer that hosts the database server role must have Microsoft SQL Server 2000 with SP3a or later or Microsoft SQL Server 2005 SP2 or later.

The problem is the instructions for installing Search Server 2008 does not mention anything about making sure your SQL Server 2005 is SP2 or higher.

Lesson: make sure you have your SQL Server 2005 upgraded to SP2 or higher before you install Search Server 2008.

The WSS 2.0 environment has “moved around” a lot. The front-end and SQL backend has been toasted at least once and the environments had to be recreated from scratch. The only backups they had were SQL backups. The SQL backups were okay.

Now, he wants that WSS 2.0 upgraded to WSS 3.0. I thought, well, this should be easy–only one Web front-end and one SQL server. Also, he had no intention of keeping WSS 2.0. So, just do an in-place upgrade, and it should be done, right?

Well, I ran into problems when I did the pre-upgrade scan prior to running the WSS 3.0 Configuration Wizard. You’re supposed to run the pre-upgrade scan tool prior to upgrading WSS 2.0 sites to WSS 3.0. Otherwise, if you run the Configuration Wizard without running the prescan tool, you will get:

Configuration Failed.
One or more configuration settings failed. Completed configuration settings will not be rolled back. Resolve the problem and run this configuration wizard again.

To run the prescan tool, go to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Bin and execute the following command:

prescan.exe /all

(For more details, see the Microsoft KB article 938216. )

When I ran the prescan tool, I encountered errors and it says on the log file:

Upgrade has encountered one or more lists that were not updated by Prescan.exe and must exit. The most likely reasons for Prescan to skip a list are covered in the Knowledge Base article at: http://go.microsoft.com/fwlink/?linkid=69958&clcid=0×409 (http://go.microsoft.com/fwlink/?linkid=69958&clcid=0×409) For more information about the lists that are not upgraded, see the upgrade log file.

It seemed like there were orphaned objects. I told you, this WSS 2.0 had been recreated a few times and they used SQL backups to restore the contents. Things have been orphaned or convoluted along the way. Oh yeah, the Web front-end server also had several (non-WSS) virtual sites that were running on port 80; they were differentiated only via the use of host-headers. I couldn’t find the orphaned objects to drop and realized that the I’m stuck and couldn’t proceed with the upgrade. I spent an hour performing the recommendations on how to repair/remove orphaned lists and then I stopped.

So here’s what I did instead:

1. Backed up the WSS 2.0 site collection using stsadm
2. I restored the WSS 2.0 site collection in a different environment/farm. I used my home lab environment for this.
3. I then upgraded my home lab WSS 2.0 to WSS 3.0.
4. I backed up the WSS 3.0 site collection using stsadm. Now I have the site upgraded to WSS 3.0.

Only thing I have left to do is cleanup the Web front end server at my customer’s site and re-install WSS 3.0 without the upgrade option. Once WSS 3.0 is installed and configured, I can restore the site collection. I’ll do that tomorrow.

Sometimes, you just have to do what you have to do to get the job done.