Unexpected error on server associating the workflow

Recently we had to throw together a SharePoint Designer workflow in a hurry for a client. It consisted of 20 plus If Then Else statements that then triggered a separate custom task process.

About halfway through designing it, it started throwing the following error when publishing:

Unexpected error on server associating the workflow

I was able to determine that there was a default limit of 7000 on the UserDefinedWorkflowCompexity property of the web application. I used the follwoing PowerShell script to increase the limit and get passed the error:

$app = get-spwebapplication http://sharepointwebsiteurl/


$app.UserDefinedWorkflowMaximumComplexity = 30000

$app.Update()

After running this script, do an IISRESET and try publishing your workflow.

User Cannot Approve Task - Access Denied

I created a SharePoint Designer workflow that assigns an approval task to a user when a list item is created. I began receiving reports that users were receiving the task emails from SharePoint, but when they attempted to approve or reject the task they received "Access Denied" .

Further troubleshooting showed that they had access to the task library, and could see the tasks, but they could not open any of their tasks. I broke inheritance and gave the users "Full Control". This did not resolve the issue.

I found mentions on the webthat publishing the workflow files to the local file system resolved this issue. As crazy as it sounds, this resolved my issue. Here are the steps I took:

Open SharePoint Designer and browse to the workflow in question. Right click on the workflow and select "Publish Selected Files"

Select the radio button labeled "Local File System", and browse to any area on your local drive:

If you receive a dialog stating that no website exists and asking if you wish to create it, click yes. Allow the files to be copied to your local drive.

At this point, my users were once again able to approve their assigned tasks.

Disabling the Upload Button on a Document library

I have a document library that houses InfoPath forms. When a new form is submitted, a series of workflows are triggered and tasks assigned, etc. I had an issue where workflows were getting started multiple times, creating multiple tasks, and generally causing chaos.

I traced the issue to the fact that users were not only using the "New Document" button to create a form, but were also saving old forms and re uploading them using the "Upload" button; resulting in duplicate files, duplicate workflows, etc.

I resolved the issue by simply removing the Upload button from each page that linked to the document library. Here are the steps to do this:

1) Use SharePoint Designer to open the page in question.

2) In Design View right-click the List View Web Part and select convert to XSLT Data View  from the context menu.

3) Switch to Split View and locate the "New" button ,and you will see the XSLT code""

4) Set the "td" visibility as "hidden" as shown below:

Additionally, to prevent an unsightly 'blank space' in the menu, I moved the location of the now hidden button to the be the last button on the right of the menu.

Now users have to use the "New" button to create a new document and cannot use the upload button. Keep in mind that you'll have to do this for each view that the users have access to, as each view has it's own page that will need editing.

Identifying Problematic Features After Upgrade

In the course of upgrading my SharePoint 2007 farm, one of the more frustrating experiences was identifying problematic features or items that failed to upgrade properly.

One of the issues I recently dealt with was an error produced when I selected "Site Actions", then "Manage Content and Structure". This would immediately produce an error with a cryptic correlationID message. Searching the internet produced a consensus that I had a corrupt list on the site. Here is how I tracked it down and eliminated it.

The first step was to edit the web.config file to produce a more usable error message. In the web.config, alter it so that "customErrors mode = off", and CallStack = True". Do an IIS Reset and you should now get a more usable error message.

In my case the call stack indicated that the error was because List Template ID 432 was not installed. So, I knew this was a corrupt list, and it was a list on the main page of my site. A quick Google search turned up the fact that that List Template 432 was the KPI List template, which was deprecated in SharePoint 2010. Any list in my production farm built using this template would have to be deleted.

Now that I knew what type of list it was, I went back to my production 2007 farm to identify the lists in my farm built on this template. I used ControlPoint to run a report that identified every site in my farm that had one of these lists on it.

Using this information, I set about deleting the corrupt content on my 2010 farm. Some people have indicated that you can use SharePoint Designer 2010 to connect to the site and delete the content. I was unable to do this, as SharePoint Designer would not display content for pages that contained the corrupt list.

I finally resorted to using stsadm -o forcedeletelist -url to get rid of the lists. Once I deleted the offending content, I was able to open the Manage Content and Structure page and browse site content normally.

One last tip. Once you get Manage Content and Structure working, you can simply click through every site in your Site Collection. If a site contains any corrupt items, it will produce an error rather than expanding the treeview. This is a fast way to check sites for corrupt content.

SharePoint Designer Workflow Errors

If you've ever tried to debug a problematic SharePoint work flow, you know it's not a simple, clear cut process. Recently I had a workflow that was designed to strip and reset permissions on documents checked into a document library. The idea was that the creator of the document, and members of a SharePoint group would be granted access to the document, while all others would not be able to see it. In most instances, the workflow executed properly; but in some cases, it would throw an error leaving the document visible to all users.

I began troubleshooting the issue by removing all the steps in the workflow, then adding them back in, one at a time, executing the workflow after each step was added back in. It was then that I realized that the issue involved setting permissions with multiple, nested groups.

The work flow consisted of three steps:

1. Strip permissions from the document for all users
2. Grant Contribute permissions to the document creator
3. Grant Contribute permissions to the "Document Reviewers" group

If I created and submitted a document, the workflow failed. If a different user created the document, it worked fine. It was then that I realized that, since I was a member of the "Document Reviewers" group, as well as the creator of the document, it was trying to grant access to me after I had already been granted access.

Once I removed myself from the group, it worked fine. The workflow would also execute fine when a user who was not a member of the group submitted a document.

If you experience errors with workflows that assign or strip user permissions, look into the composition of the group. That may hold the key to your errors.