This blog has moved and can now be found here: http://sharedpointing.blogspot.ch/
Great guide pointing out that if you should happen to install SQL Server Reporting Services 2012 before installing SharePoint, you must then let SharePoint 2010 know it’s there and install the service. Thanks Dan!
Update (7/22/2011): Added a note about an IE Security setting for SharePoint menus at the end of the post. I will add a PDF of this posting either tonight or over the weekend if anyone is interested in that.
Update (7/24/2011): Added PDF download of the posting for printing, offline, and eReader availability at end of posting in the File Download section.
With the recent release of the SQL Server Denali CTP3 there have been a few changes in the installation process. One of those is with how the SharePoint integration configuration works. There was new post yesterday in regards to this process Getting up and running with SQL Server Denali for Business Intelligence (Crescent and PowerPivot in CTP3). In this post is goes through the steps assuming that you have installed SharePoint 2010 first. What if you are like myself and installed all of the…
View original post 982 more words
The Issue
Recently, while attempting to publishing a SharePoint Designer workflow I was receiving the following error message:
“Errors were found when compiling the workflow.The workflow files were saved but cannot be run”.
Detail: “Unexpected error on server associating the workflow”
I researched the issue and found many suggestions and workarounds for this issue. Fixes and workarounds that worked for others range from Permissions configuration, configuring the correct task list, right through to code fixes. On some occasions the problem was purely a minor detail that had been overlooked by the developer.
Knowing that none of these fixes and workarounds applied to my scenario I was a little baffled to say the least.
What worked for me
A colleague of mine suggested using ProcessMonitor (opens in new window) to find out what was happening when attempting to publish the workflow. What we discovered is that each time I tried to publish the workflow, it was writing to and referencing a cache on the client machine (where SharePoint Designer is running).
Cache Location on Vista/Win2008:- C:\Users\[Username]\ApPData\Local\Microsoft\WebsiteCache
Note: If you happen to know where the cache is located on other operating systems I’d appreciate your input.
Having cleared out the cache the workflows published. Hurrah!
The Extranet Collaboration Toolkit for SharePoint (WSS v3.0 & MOSS 2007) has a little gotcha which is rather annoying. The gotcha is an auto-append of CN=Users to the LDAP Connection String to the SharePoint web.config file. Here’s how it tripped me up…
When configuring the ADAM instance, you are asked to input a User Container Name in the form of part of an LDAP connection string (see screen-shot below):
What this does is create an ADAM instance and a container at the path specified (User Container Name). When the ADAM instance is created, it also creates a sub-tree of CN=ExternalUsers, as shown below:
Now, when you run the ECTS setup wizard to configure and install the SharePoint solutions and features, you are asked to input an ADAM Server Name, you’re then asked to provide a User Container Name at which to point the SharePoint solution to enable it to add the LDAP Connection string to the SharePoint web.config file.
Now here’s where the gotcha hits – I looked at my ADAM instance using ADSI Edit and supplied the ECTS Setup Wizard with a User Container Name something along the lines of CN=Users,CN=ExternalUsers,DC=server,DC=domain,DC=suffix.
Now, when the ECTS Base feature is activated, it puts several items into the SharePoint web.config file. One of these items is the LDAP Connection String. What I didn’t know at that time is that it automatically prefixes CN=Users to the User Container Name that you chose when configuring ECTS for SharePoint.
Given that I specified a User Container Name of CN=Users,CN=ExternalUsers,DC=server,DC=domain,DC=suffix when configuring ECTS for SharePoint, this would of course then become CN=Users,CN=Users,CN=ExternalUsers,DC=server,DC=domain,DC=suffix
(note the repeated CN=Users).
For a while, I manually updated all of the web.config files in my farm that were affected by this. Soon it became quite a burden; every time a modification was made that involved the web.config being re-written from the database, the repeated CN=Users would always re-appear.
I suppose you could put this down to my ignorance, or perhaps you’ll agree with me that the documentation doesn’t make this as clear as it should be – whichever way, I thought it might be useful to share this.
 | Aldo on SharePoint Designer: Errors we… |
 | Mj Ferdous on SharePoint Designer: Errors we… |
 | Serryn on Windows Server 2008 R2: Active… |
 | Jason on SharePoint 2010 – New Se… |
 | rchinnam on SharePoint 2010 – New Se… |
Shared Pointing 