How to fix: "Unable to display this Web Part" when you want to initiate a workflow manually

Issue

This was a recent encounter (error message below) while starting a Workflow manually in MOSS (SharePoint 2007).

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator.

For your better understanding, let me first explain you where I was at, and where I was heading. I wanted to start a workflow manually on a Document Library. [That wasn't tough :)]

I navigated to the:

• Document Library >
• Library Item >
• Edit Menu >
• Click on Workflows.
• Under Start a New Workflow section, I clicked on the Workflow and was eye to eye with the error.

Analysis

As the error was instructing me to use SharePoint Designer, so I opened. And since this was a web part that was failing, I thought if I could remove the web part from the page and add it again. This was my source of greater understanding.

But since this was related to Workflows, I opened the particular workflow that was failing and noticed an .aspx page in the bundle (as below). This ASPX page represents the page that we use to manually run the workflow.

Resolution

I backed up this .aspx page, merely by changing its name. I then opened the Workflow (.xoml file) and published it. This action created a new ASPX page for me.

Now when I clicked on Start a New Workflow, the page appeared fine and I was able to run the workflow.

Download latest InfoPath form templates

"Change is inevitable", and it is true to InfoPath forms as well. Quite often the client asks you to make changes to the InfoPath forms and you may not have the original files.

Perhaps the files you have in your network location are outdated and old and have been gone through many update iterations.

You can download the latest form by navigating to the following path:

http://<domain>/FormServerTemplates/FormTemplate.xsn

Select the Form and click Save As or Download a copy

Note: The URL path may be different for you depending on your SharePoint Site hierarchy.

SPD Workflow error: Path needs to point to valid member

I had created a workflow and its always interesting to make few changes to it, or is it? It is not so welcoming though, but when you have a client instruction, you welcome it with a smile.

So here I was updating/editing the workflow. After updating it when I clicked Finish (this will associates the workflow to a SharePoint List), I received an error as below.

I haven't found any reference on the web or workaround for this issue.

(0, 0) Activity 'ID9355' validation failed: Path '_x005f_String135' used to specify member for 'ROOT' is invalid. Path needs to point to valid member.
(0, 0) Activity 'ID9325' validation failed: Path '_x005f_String136' used to specify member for 'ROOT' is invalid. Path needs to point to valid member.

I realized I had backed up the workflow before making any changes to it. So I opened the copy in Notepad (.xoml file) and was trying to trace the String '_x005f_String135' and '_x005f_String136' as in the above error.

I found that this string was referenced couple of times in the document. I then started comparing both the workflows (the one I was editing and the backed up copy).

Found that a statement like below were missing in the copy I was editing:

<ns0:WorkflowDataField Name="_x005f_String135" Type="System.String" />
<ns0:WorkflowDataField Name="_x005f_String136" Type="System.String" />

I believe this to be a declaration of strings used in the workflow which apparently went missing when I was updating the workflow. I have no idea why did this happen.

So I copied this part from the backup and pasted in the file I was editing. I then saved the .xoml file, opened the workflow and clicked Finish (to associate with SharePoint List.)

It worked!

Lesson Learnt, or rather an Affirmation to myself - Continue backing up often.

Unable to add Active Directory group in SharePoint

SharePoint Users are usually Active Directory Users when using SharePoint in intranet. A strange thing I came across was I was able to add individual AD users in SharePoint but when I was trying to add an AD group, it said "No exact match found." Even though the AD group is present in the domain's active directory.

•  Now to resolve this issue, browse to the Active Directory and right click the group to open it's properties.
• On the General tab, find the section Group Type.
• If it is set to Distribution, change that to Security.
• Now you should be able to add the AD group into SharePoint.

For details regarding Group Types, refer Microsoft TechNet Site here.

In brief:

Distribution Group

This is used only with e-mail applications (like Exchange) to send e-mails to a group. This is not security enabled.

Security Group

To give an AD group controlling access to shared resources, you need to use Security Groups. A concept called discretionary access control lists (DACLs)

Hope this helped!

Screenshot on HTC Chacha

Red button (Call End button) + Home button (on the screen)

Did you get it?

You updated the workflow, but the changes haven't taken effect

I know how frustrating this can get, I have been there.

I changed the workflow using SharePoint Designer 2007 and published it, but when I test the workflow on SharePoint 2007, it seems to have not been effected by those changes.

Seems like the SPD workflow cache is being superior. Here is how you go about resolving:

• Close the designer (SharePoint Designer)
• Navigate to %system drive%\Documents and Settings\%user%\Local Settings\Application Data\Microsoft\WebSiteCache
• Open the directory that you are referring to. This is similar to the name of your website.
• Delete the assembly that you were changing. (You might as well delete all the files here)
• Open SharePoint Designer, publish the workflow and check

The web application at [URL] could not be found

Here is an error I encountered while calling the SPSite object using the URL:

The Web application at [URL] could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application.

It was the first time I encountered this and this is how I moved about resolving the issue

1. Checked if the URL was really not available.

That wasn't the case. The URL was very much valid and hence this option got eliminated.

2. Google search on this issue almost always pointed to the bit-ness of the platform. That the application was targeting x86 platform and SharePoint Server was x64 bit platform.

In my case, this wasn't true either. Both my platforms were on x86. It was easy to eliminate this option.

3. AAM, Alternate Access Mapping not done properly.

Wasn't an issue in my case. Any guesses? This option was eliminated as well.

4. The code is a windows or web service application which you are running with an account that does not have permissions to connect to SharePoint or SQL Server.

This is where I was at and out of it. This was the issue in my case. My web service code was running on the DefaultAppPool and the identity for the DefaultAppPool was Network Service Account.

I selected configurable and provided the username and password of a user who had elevated privileges.

It all worked and I hope it does for you as well!