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!