Cannot complete this action. Please try again. SharePoint 2007 Default.aspx Problem

A user tried to access their site on a SharePoint 2007 server, but was unfortunately greated with the wonderful, unhelpful message of:

Cannot complete this action.  Please try again.

This error occurred when trying to access the default page of the site i.e.: http://Server/subsite/default.aspx

A quick search around the internet and it seems many people have had this same problem at some point, but no one could find a solution that wasn’t as drastic as deleting and creating the site, restoring the server or even trashing and rebuilding SharePoint!! On a live production system, this wasn’t practical and would require a bit of work to sort out!

I run one server which consists of a main site for my project, with sub sites for each team on that project.  The problem was occurring for just one team sub site.  With a little poking around, I found I could still navigate to all the sites content and its settings, via the parents Content and Structure options – (“Site Actions” –> “Manage Content and Structure”).

Using this navigation option, I went to the master page viewer and tried to upload the master.default page from my fail over server which was working perfectly.  This didn’t work and caused a new “File not Found” error when trying to view the home page of the site.  I restored the previous version to get back to square one.

With my only option looking to be to restore the subsite from the backup, I tried one last thing.  Within the Manage Content and Structure pages, I deleted the Default.aspx file from the problem site.  I then copied a default.aspx page from a known working sub site.

On refreshing the problem site, this solution worked fine and I was once again able to navigate to  the problem site with no errors.

I am still not sure why the original problem occurred, so if anyone has any ideas I would be most grateful.

Advertisements

Restarting a stalled workflow where the delayActivity has stopped responding

I released a number of changes to my projects workflows, making sure I had released them as a new dll version in the GAC.  The workflows use a DelayActivity to “sleep” for about four hours, before waking and checking if the due dates of the tasks involved are out of date.  If so, then an email is sent to the task owner.  After I released the new workflow version, new workflows instances would start fine, but after the four hour delay, an ominous error was found in the Workflow History and now email escalations occurred:

“Workflow Failed to run”.

Checking the ULS log, there was also the following error:

“OWSTIMER.EXE (0x07EC) 0x0E58 Windows SharePoint Services Workflow Infrastructure 98d8 Unexpected System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow originalWorkflow, SPWorkflow workflow, Collection`1 events, SPRunWorkflowOptions runOptions)”

A quick Google search brought up this old Microsoft Blog post where a number of users where experiencing the same problems.  Although the bug has been fixed in later hotfixes and service packs (which my system already had), one of the causes stood out as the reason for my problem.  That is; when releasing new versions of code into the GAC, the timer service is still using old versions which are non existent and so it falls over.

One recommendation to prevent this problem is to restart the Timer service, which is fine, but it doesn’t fix the workflows already running which are experiencing the problem.  However, reading through the blog someone mentioned being able to view the status of the timer jobs in the content database using the following SQL command:

SELECT * FROM ScheduledWorkItems Where id = ’20EF2AC4-64D1-47E4-91C1-4E5F4BFC7CD4′ — where this is the problem workflow ID.

When you run this command, you will notice the DeliveryDate.  This is the time the system will wake up the workflow. There is also the column “InternalState” which for problem workflows seemed to always be set to “9” and for ok workflows set to “8”.

Using a broken test workflow, I did some hacking around, and changed the internal state value of the problem workflow to 8, and set the DeliveryDate value to sometime shortly in the future.  I also, noted that the time originally in this field was 1 hour behind what I expected, and assume this is because I am running under GMT +1 timezone.  Therefore I set the DeliveryDate to be one hour behind the time in the future, or else I would be waiting another hour longer than I expected! Hope that makes sense!

I then restarted the Timer service on the SharePoint server and low and behold, the problem workflow shortly “woke up” and did its job as expected when the DeliveryDate time had passed.

I changed all the other problem workflows in the same way and they all came back to life with no problems.

I have now made sure I have amended my deployment procedures of new workflow versions to restart the timer service so this problem shouldn’t happen again.

SharePoint 2007 Workflow wont autostart when using IP address

I have had a lot of trouble recently with one user who was using a SharePoint 2007 site configured with a custom workflow, that should autostart when a new item is added to a list.  The WF wouldn’t start just for this user and so I would start it for him, assigning the list item to him.  The WF would then create a task for him, but on the user submitting the task, the workflow wouldn’t progress.   No error, nothing.  Just stop.  I initially thought it was some bad code in the custom WF I had developed as I kept seeing the tp_workflowversion value in the userdata table of the SharePoint Content database being set to 512.  I would set it back to 1, then submit the task again, but to no avail.

I then read this blog post form Corey Roth:

http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2009/01/29/workflow-doesn-t-start-when-accessing-sharepoint-site-via-ip-address.aspx

And realised the user in question, (being a network admin), was accessing the site via its IP address instead of hostname.  A quick test later and I could replicate the problem perfectly!  Asking the user to access the site via the hostname allowed the workflows to start automatically this time and progress as normal.

Now all that is left is to work out why this is such a problem……

Versioning custom workflows in SharePoint 2007

Whilst developing a custom workflow in SharePoint 2007, one of the main problems I encountered was managing changes and updates in the workflow code.  If major changes to the workflow code are performed, when the new solution is released, the original code stops working, causing existing running workflows to stop and error.  The way to get around this is to release a new version of the code as a new solution.   This way the existing workflows continue to run as they are referencing the version one code in the gac, but a new workflow can be added which is running under newly installed code in the gac.

The steps to do this are as follows:

1.  Edit the projects AssemblyInfo.cs file in Visual Studio, changing the AssemblyFileVersion to a new version number.

2.  Using Visual Studio tools, generate a new GUID and change the GUID of the solution in the solutions manifest.xml file.

3.  In your workflows.xml file, copy the existing workflow definition and paste it under your existing workflow definition.
–  Edit the newly pasted code giving it a new name, say “Workflow V2”.
–  Give the newly pasted definition a new GUID.
–  Change the newly pasted code to use the new version number in the codebesideassembly value.

4.  Amend any referenced which use the GUID or name of the new workflow version in your workflow or other code.

5.  Change any front side pages or code which reference the assembly to use the new version number.  I.E aspx pages which have your project dll referenced as an assembly.

6.  Change any cab.ddf scripts used to package the code into a wsp file by giving the wsp file generated a new name.  Say, WorkflowV2.wsp.

7.  If you have an install script for retracting, deleting and deploying the solution, change this so that it references the new wsp file.

Now build your project in Visual Studio and generate the WSP file.  This can be moved to the live server and installed as normal.  If all is well, you should now see a new version of your code in the C:\Windows\Assembly directory.

Finally, in SharePoint, go to your list where you workflow should be running.  Edit the list and add a new workflow.  You should see your new workflow listed.  Then go to the remove workflow option and select “no new instances” of the version one workflow to stop any new version one workflows being run on the list.