Locking MOSS or WSS at 1:40 PM

Server or site migrations require that you give yourself ample time for the transition.  The last thing you want is for users to be making changes on the site while you are taking a backup and moving to another location.  There are many ways to avoid this server-side that will interrupt the users viewing experience.  But, there is one way that you can still allow the users to interact with the MOSS or WSS site without allowing them to add/update/delete content.  By using the site lock feature you can switch an entire site collection to read-only mode.

stsadm –o setsitelock –url http://server/site –lock { none | noadditions | readonly | noaccess }

none = sets site to “normal” mode allowing adds/edits/deletes

noadditions = no additional content can be added, current content can be edited as long as it doesn’t add to the total content

readonly = entire site becomes readonly.  No adds/updates/deletes are permitted

noaccess = locks total access from the site.  User will see an error specifying that they contact the administrator for more information

Failure Decompressing Data from a Cabinet File at 1:31 PM

The MOSS/WSS GUI is great for many of the day-to-day administrative tasks, but I have found that it falls short on many of the larger tasks such as migrating entire sites or even large lists.  Using the STSADM command line tool with the correct parameters can solve errors like the one in the title of this entry.

stsadm -o export -url http://server/site -includeusersecurity –nofilecompression -filename C:\directory
stsadm -o import -url http://server/site -includeusersecurity -nofilecompression -filename C:\directory

-includeusersecurity = will add ALL of the user accounts that have posted, edited, or have been given direct access to the site.  This can either be a great help or a major pain.  If the site and lists on the site rely heavily on tracking who created/modified files in document libraries, or you have workflows that use people pickers or utilize the createdby or modifiedby fields this should be included.

-nofilecompression = makes the export larger, but does not throw the failure decompressing error.  Using this flag also requires that you use the command line tool to import.

If either of these flags are included on the export, they will also need to be included on the import.

Another Custom Form Issue at 7:43 AM

After making a few changes to a custom form “NewForm_2.aspx” in WSS I realized that I needed to start over.  I deleted the form and copied “NewForm.aspx” again and renamed to “NewForm_2.aspx”.  When doing this you need to point WSS to the new form by using SharePoint Designer, right clicking the list, then using the “Supporting Files” tab browse to the newly created custom form:

The issue was when I deleted “NewForm_2.aspx” I broke the hook that WSS had to the form.  Even recreating the form did not reset the hook.  When clicking the “New” button on the list I got the error “Invalid Page URL:”.  Microsoft has a KB article on this:

http://support.microsoft.com/kb/935504

But that does not resolve the issue.  It states “To resolve this issue, delete the list, and then re-create it.”. This was not an option with a list with over 400 items and 50+ fields.  So I went on the hunt and finally found this article:

http://blogs.msdn.com/dszabo/archive/2007/02/20/custom-list-newform-aspx-ruined-in-wss-3-0.aspx

In the article they explain the issue and a few ways to resolve it without deleting the list and recreating.  The option that I found that worked was in the “POST-POST COMMENT: ALTERNATIVE RESOLUTION” section.  Here you just need to replace a piece of the HTML code used by WSS to build the page.  It worked like a charm!

SharePoint Custom Form Issue at 7:17 AM

A few days ago my boss and I were on a 4.5 hour call trying to fix a SharePoint custom list that had started behaving strange after a migration from MOSS to WSS.  The creator of the list customized the “NewForm.aspx” and named it “NewForm_2.aspx”.  The issue was a single column that was not saving when a new item was created, but could be edited and it would save fine.   It was a lookup column to a list on the same site that had about 25 items.

First, we recreated the column with a new name & copied the data over then deleted the old column.  I refreshed and reordered the SharePoint custom data list on “NewForm_2.aspx”.  Still not saving…

Second, we recreated the lookup list.  Still not saving…

Third, we changed the column to a standard choice control and hard-coded the values from the lookup list into the choice field.  Still no luck…

I would go into all that we did, but it might take a few hours to list… so after “NewForm_7.aspx” was created (2,3,4,5,6 failed) I decided to not rearrange the fields on the form, leave them as they were default.  It worked!  So I reordered the columns in the list settings and created “NewForm_8.aspx”.  All is good now.

Lesson of this story: When creating custom forms in SharePoint.  #1 do not delete the placeholder where the data control is.  #2 Do not move fields on the form.  Removing fields is OK, but once they are moved you get unpredictable results.  Use the list settings to reorder the columns how you want THEN create the form.