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)

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!

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.

If you want a straight and fast backup and restore, use the stsadm backup and restore operations.

To back up a site, go to the 12-hive bin folder and type the following command:

stsadm -o backup -url http://mysite -filename myfile.dat

Then to restore your backup, use the following command:

stsadm -o restore -url http://mysite -filename myfile.dat

Notes about using STSADM backup and restore commands:

1. Security settings (owners and permission levels) and other user-informated (Created By and Modified By fields) will carry over when you restore it.
2. This is faster than using STSADM export/import operations.
3. You can only do this on a top-level site. Say you want to get a subsite inside your site-collection, forget it–this operation can only get that subsite by backing up and restoring the whole site collection.
4. Point is, backup/restore is not granular. It’s an all-or-nothing backup and restore of a site collection.

If you want to get ‘somewhat’ granular, you can use STSADM export/import command. I say ‘somewhat granular’ because you can’t really drill down to list or library level. But if you have many subsites and you just want to backup and restore (or migrate) a few, then STSADM export/import will be for you.

To export a sub-site, go to the 12-hive bin folder and type the following command:

stsadm -o export-url http://myserver/mysite -filename myfile.dat

Then to “restore your backup”, use the import command:

stsadm -o import-url http://myserver/mysite -filename myfile.dat

Notes about STSADM export/import command:

1. Slower than using backup/restore
2. Security settings and other user information (Last Modified By, Created By, etc.) do not carry over to the new site. I didn’t had a chance to test this operation with a site that uses some type of approval workflow–I don’t think the “Assigned To” properties will stick with export/import simply based on the observed behavior on standard documents and list libraries.
3. Yes, you can export a sub-site so that you don’t have to export the whole site-collection. But you can’t export a library or list or document. You say “why not just template the site and include the content in the template”. You got size-limitations there bud and you won’t be able to ‘template’ a site and include its content if the library or list has too many files.

By the way, I’ve only shown examples using the required parameters -url and -filename. There are other optional paramters to use when using these STSADM commands. For full details, visit the Microsoft page Index of STSADM Operations and properties (Office SharePoint Server)