Whenever you customize the default list forms (NewForm.aspx, Dispform.aspx, or EditForm.aspx) in SharePoint designer, never, ever, under penalty of torture using Ed Wood movies, ever, I mean ever, delete the default ListFormWebPart that is on those pages.  Doing this will subtly corrupt how your list is defined in SharePoint and can cause you all sorts of grief.

The most minor problem I've seen is that you lose the ability to specify the Supporting Files for the list.  Oh sure, it will look like you can set them and it will even save and refresh properly in Designer.  However, SharePoint will simply ignore that and go right along showing the default files instead.

The bigger problem is that deleting the ListFormWebPart from the NewForm.aspx page can effectively disconnect the "New" option on the list toolbar resulting in the ever annoying "Invalid page URL" dialog box when anyone clicks on it.  This is a known issue and the only way to fix it is to delete and recreate the list.  Not Fun.

Instead, save yourself some grief when editing these pages and just leave those web parts on there and add a new DataFormWebPart above or below it and customize that to your liking. 

Note: make sure that you insert the new web part into the existing WebPartZone or else you will lose the 'Edit Page' option for that page on the Site Actions menu.

Once you have the customizations you want in place, you will need to hide (not delete!) the original ListFormWebPart.  To do this in Designer, simply change the IsVisible element in the WebPart XML to 'false'

Alternatively, you can hide it using a browser as well.  Simply browse the page and edit it, either by using SiteActions -> Edit Page or by adding "&PageView=Shared&toolpaneview=2" to the querystring in the browser.

Then edit the web part properties for the original ListFormWebPart and hide it

This keeps the original web part on the page which keeps SharePoint happy.  Your users only see the customized list view that you want them to see, which keeps everyone else happy.

Sharepoint likes to use the Embedded version of SQL Server when you choose a stand-alone install of WSS.  Normally, this is not an issue but there are times when you need to get into that database.  Unfortunately, getting into that database is considerably more difficult than you might expect.

Why would you want to get into a database that Microsoft keeps you out of intentionally?  In my case, I had to switch an existing installation from using the default NETWORK_SERVICE account to a domain account.  An account that had no permissions in the WSS databases whatsoever.

In order to get into MICROSOFT##SSEE

1. Log on to the machine running WSS as a user that is in the Administrators group
2. Open Sql Management Studio (I'm told that the Management Studio from Sql Server Express will also work)
3. Enter '\.pipemssql$microsoft##sseesqlquery' as the Server Name (minus the quotes)
4. Rejoice

From there, I just added my domain account with the proper permissions and WSS was happy again.

I ran into an odd issue the other day where the Approval workflow for a Publishing site simply would not work. .Net 3.0 was installed properly and the site was otherwise functioning perfectly so it didn’t appear to be a problem with the install.

What was happening was that when I pulled up the first page in a workflow, I received one of these two messages:

“The form has been closed” – which is the lovely generic InfoPath version of the Sharepoint “An error occurred” message. Not terribly useful

– or –

“The server is currently being taken down for maintenance. Check with your system administrator to see when this server is scheduled to come back online.
Click Try Again to attempt to load the form again. If this error persists, contact the support team for the Web site.
Click Close to exit this message.”

… yet, the site was running fine aside from the workflow.

The Solution
Somehow the site had gotten itself into a partially quiesced state where some of the site was convinced that the whole farm was quiesced while other parts thought everything was running fine. The fix was to go into the Quiesce Farm option in

Central Administration > Operations > Quiesce Farm and then restart the farm. After that, everything worked fine.

An interesting thing that pointed even more to this was the error in 12/LOGS that read: “Loading event log failed, because the form was quiesced”.

After moving the content database to another SQL Server, I started getting the following message in the event log every hour : “A duplicate site ID … was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.”

Nice and simple and even a recommended solution in the error message – except that it wouldn’t work. After a lot of additional searching I turned up this command, which did work:

stsadm -o sync -DeleteOldDatabases 0

I am reposting it here because of how hard it was to find in the first place.  For what its worth, the full syntax of this is:


stsadm -o sync
{-ExcludeWebApps <web applications> |
-SyncTiming <schedule(M/H/D:value)> |
-SweepTiming <schedule(M/H/D:value)> |
-ListOldDatabases <days> |
-DeleteOldDatabases <days>}


The original answer was posted by Vikram Garlapati.

The other day, I was asked by my management to provide the exact day that our Eval copy of SharePoint 2007 would expire.  Well, I knew it was before Christmas and I could get a rough idea by looking at the timestamps in the 12 hive, but still didn’t have the exact date and time.

After some digging, it turns out that Microsoft was nice enough to include the exact date and time right in the Central Administration console, albeit tucked away in a less than intuitive place.

When you go to Central Administration -> Application Management -> Office SharePoint Server shared Services -> Check Services enabled in this farm, you will see a message like the one below that lists the exact date and time that your SharePoint eval will go belly up . or whatever it is that SharePoint does when you hit the expiration.

I asked MS about the expiration behavior and they said that it was hard to say exactly what it would do, but it would be something between “stop working entirely” and “disable all admin and publishing functions”.  Really!