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:

• 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)

I was viewing my blog today and noticed the tag cloud on my sidebar. The most prominent tags are “SharePoint”, “Developers”, and “Administrators”. SharePoint. Developers. Administrators.

From time to time, I will meet SharePoint professionals in networking events or when interviewing job applicants at a customer site and I will ask what their SharePoint experience is like. “Oh I am a SharePoint Developer“. Then I find out that the extent of their development experience revolves around master-page and page-layout design, style/CSS customizations, and graphical/logo design. Basically, branding tasks. And then there is the “SharePoint Administrator“. “Oh, I am the site collection administrator and manage user-permissions, site-collection features, and sometimes recycle items for end-users from the Recycling Bin.”

I think people are calling themselves SharePoint Developer more than they should. In my opinion, a SharePoint developer is someone who can develop Web parts, workflows, user-controls, Web controls, ASPX pages, client-side scripting, and complete SharePoint solutions. In addition, they also understand deployment options such as creating solution packages. If your experience around SharePoint is limited to CSS, branding, and design stuff, you’re a designer, buddy; not a developer, but a designer.

Now, let’s talk about the “SharePoint Administrator”. Yes, to a point, the site-collection administrator is an administrator. But to me, and again, this is just my opinion, farm admins are the real SharePoint administrators. To call yourself a SharePoint administrator, especially on job interviews, you better know your SharePoint deployment scenarios, Central Admin, SharePoint disaster/recovery procedures, IIS, SQL Server, Windows Server OS, and the beloved “stsadm” command.

Sometimes I will encounter resumes where the job applicant puts “SharePoint Developer” or “SharePoint Administrator” in their work history but nothing in the roles and responsibilities indicate the degree of technical expertise required to be called a “real SharePoint Developer” or a “real SharePoint Administrator”! 

The point I’m trying to make is please, please, please–do not inflate your work experience, especially when applying for jobs. You might fool the recruiters but you’re not going to fool the technical leads. Please be honest in your resumes because people will catch you if you think the inflated titles will make you a better candidate for a job.

Honesty people!

In my previous post, I listed the sessions that I attended on SharePoint Saturday. Michael Lotter’s session was about building and deploying custom SharePoint Application Pages. Out-of-the-box pages suffice for more SharePoint users. But at some point, your customers or organization will want to add custom ASPX pages into SharePoint. This topic is relevant to teams wanting to create custom ASPX pages in SharePoint.

The basic ideas for building and deploying custom SharePoint Application Pages:

1. Create a VS 2005 or VS 2008 solution
2. Edit your ASPX pages, edit your code-behind
3. Compile the solution—you should get the DLL files and the ASPX and/or ASCX files plus resource files such as images files (GIF, JPG, etc.)
4. Create a new WSP Solution project in VS 2005 or VS 2008 using VSeWSS, Andrew Connell’s STSDEV, or Codeplex WSP Builder.
5. In the WSP Solution, you put the ASPX and ASCX pages that you are trying to deploy.
6. Also, the DLL that was compiled from Step 1 has to be included in the WSP Solution.
7. Depending on which WSP tool you are using, the files location in the WSP solution might differ from one tool to another. But the key things you specify in the WSP Solution are the following: Manifest file and DDF file. If you have other things to add such as custom actions, you will also need to specify the Features file. The Manifest file specifies where the files in the WSP package will go.
8. Compile the WSP solution.
9. Run STSADM on the WSP file to deploy your custom files and pages.

Here’s a sample Manifest file:

<Solution SolutionId=”AAEC1250-5354-7839-F94F-50307E84AF1B” xmlns=”http://schemas.microsoft.com/sharepoint/”>
<FeatureManifests>
<FeatureManifest Location=”FeatureLibrary\feature.xml”/>
</FeatureManifests>
<TemplateFiles>
<TemplateFile Location=”ControlTemplates\Zenpo\myZenpoControl.ascx”/>
<TemplateFile Location=”Layouts\Zenpo\myZenpoPage.aspx”/>
<TemplateFile Location=”Layouts\Zenpo\myZenpoBanner.JPG”/> </TemplateFiles >
<Assemblies>
<Assembly DeploymentTarget=”GlobalAssemblyCache” Location=”ZenpoSoftware.Sharepoint.myFeature.dll”/>
</Assemblies>
</Solution>

In the example manifest file above, my files went to the Layouts, Images, and ControlTemplates folder. Meanwhile, I specify that my custom assembly file should go to the GAC.

If you are creating custom pages or Web controls with no code-behind files (as-in it’s just all ASPX code or maybe a little bit of in-line server-side scripting), you can skip steps 1-3 and start at step 4 right away.

One thing worth nothing is if you’re going to deploy files to the 12-hive folder, it’s best that you create your own folder. In my example above, I specify in the manifest file that a “Zenpo” folder be created in the Layouts, ControlTemplates, and Images folder.

In the session, Michael Lotter deployed custom pages to the Layouts folder. He also had custom actions specified in the Elements.xml file that made the Site Actions menu include links to his custom pages.

It was a good session for those who have not yet done deployment of custom SharePoint pages in SharePoint. I will admit I was looking for something a bit more advanced but overall, the session was good since people who have never done this before can go back to their shop and should be able to build and deploy custom application pages.