Fixing the ‘Failed on restarted (retrying)’ error with corrupt SPD workflows after restore from template

This post describes an issue of using custom created SharePoint designer workflows when trying to instantiate a previously saved site with SharePoint designer workflows. As a result of this limitation, SharePoint designer workflows won’t start due to incorrect versions of files. This post describes a technical plus pragmatic workaround and provides an utility to fix this. Therefore enabling the re-use of workflows in sites that are saved as template and instantiated.


Pfew! Look at that sentence full with buzzwords. As everyone knows we can create workflows easily in SharePoint Designer (SPD). However, after some modifications and we wish to save the site as template and later restore it, the workflows do not seem to work on the newly created site. The error is something like: Failed on Start (retrying). This is because the versions of the workflow files and the workflow association config xml doesn’t correspond anymore. I’ve created a little STSADMCOMMAND that repairs this association by opening the configuration file, synchronizing version information and saving it back to the server, it also re-attaches the workflow using the WebPartPages webservice, which basically the same SOAP command when you are editing workflows in SPD and saving them. This tool comes in quite handy if you need restore loads of workflows on a site.

The command for this STSADM command is:

stsadm.exe -o repairworkflowassociations -url <url of site where WF are broken> [-resetversions]

The url parameter is the parameter of the web that need its workflows repaired.
The resetversions basically sets the version of the workflows back to 1.0.

So you can save your templates and let fix the workflow the following way:

1. Create a site, edit your workflows as you like.
2. When you are done save your site as template
3. Instantiate your template somewhere else, try to start the workflow, see it fail.
4. Run the tool, on that site. It should correct the workflow.
5. Run the workflow again, it should work now.

Optionally you could also run the tool with the -resetVersions option. This saves the workflow files as version 1.0. If you save that template, and instantiate the site using that template. The workflow will work, and every site instantiated with that template will work. Be sure to run it in the instantiated site and not in the site you are authoring your workflow because it will destroy the WF version history. WARNING: If you use the -resetVersions option, the workflow version history will be destroyed, so make sure to create an backup.

Download the WSP file here.

NOTE: The WSP file hasn’t been thoroughly tested yet, if you find any bugs, please send me an e-mail. I’ll post the source later..

And the now pragmatic approach if you dont have too many WFS: You could also save your template, instantiate the new site using that template, disable versioning in Sharepoint Designer on the workflows list (right click, properties), open each workflow and  save it using SharePoint designer. Save that template, that template can also be instantiated.

This need to be done in that exact order.

Advertisements

Customized _LAYOUTS folder on site collection basis

I’m not really a blog-linker but heck. This one needs to get in the open. Microsoft has now an supported method of customizing the _LAYOUTS folder on SharePoint! This was actually quite a common question I got from my clients. Read the full scoop here: http://support.microsoft.com/kb/944105/en-us.

Developer awareness and the bad reputation of ‘SharePoint Designer’ – A post to all developers.

This post ferociously tries to persuade standard .NET developers by offering them candy to give SharePoint a designer a chance, cause it is indeed a black-belt ninja. And you want it, you know you do.


As a contractor, I often run into the same thing over and over again. For instance, when an client need to get things done in SharePoint (and I’m not available), they often acquire an traditional ASP.NET developer. However, this is what usually happens. Because traditional developers are technical experts they often try to solve the problem using their comfort zone and start hacking in Visual Studio. Most developers haven’t even considered using SharePoint Designer or InfoPath because it’s ‘a WYSIWYG tool, meant for analysts that are wannabe developers, and just looks like front-page’ . Well, don’t blame them, front-page wasn’t that good and Visual Studio has been superior in many ways. And heck, my first SharePoint experience was  indeed in combination with Visual Studio. (I’ve always been an developer, and still am!) But don’t be fooled here guys! It’s time for a change..!

At least 70% of the solutions that customers want in SharePoint can be done using SharePoint designer, without typing any or little code. It provides work-flows, custom forms, designing pages, roll-up functionality and loads more. If you are unsure of its capabilities, check out: WSS 3.0 40 Application templates. Its a nice showcase on what SPD can do.

Therefore, the first thing I do is inform the new developer to learn that custom development in SharePoint is only meant as a last resort, should not be taken lightly, and should be aimed at developing specific bits of reusable functionality. Such as WF activities, site creation logic or other things that don’t come out of the box. I say this, because as soon as coding place, the project gets a lot harder to manage. 

This is usually because the developer has an incredible extensive object model to take in account with all its features such as security, deployment and performance. Also actual development process is slower in general because proper SharePoint development consists somewhat out of an more complicated development cycle: Build, sign, build WSP, addsolution, deploysolution, find bug,  attach debugger, etc etc. And then there is the feature framework to take in account. Of course many things can be automated but it is still somewhat slower than traditional ASP.NET development. Also, the development tools available for SharePoint are still a bit lacking. Another pitfall with SharePoint development is that a lot is often assumed to work in a particular way. Furthermore, the custom developed solution needs to be tested, and maintained trough every version iteration of SharePoint. This doesn’t mean that SharePoint development is a no-go, or a bad thing to do, its just something that needs to be considered thoroughly, planned and carefully managed. Also, one needs to be 100% sure that their isn’t an alternative available out of the box. SharePoint development should never be done ad-hoc or sold that way by managers to customers. I personally recommend every developer to try to solve the problem using SharePoint designer first, and if that isn’t possible see whether one can extend SharePoint designer’s functionality by for instance developing custom workflow activities or web-parts that can be reused in SPD.

However, SharePoint designer is not the holy grail. And at some points you need to have a hybrid solution, thus half of you project will be done using SharePoint designer, and the other half will be solved using custom development. It is not a hard line, but just make sure you get the highest efficiency using both products.

All traditional developers should become aware of this, should be thinking less about the technical part, and more about the functional aspect of the solution. SharePoint is an product intended to be used by businesses for creating solutions to gain more ease and speed by using out of the box software. Make sure you know every bit of SharePoint before you start up that Visual Studio and hack away!