Sue Hernandez's SharePoint Blog

SharePoint and Related Stuff

Monthly Archives: September 2014

Problems publishing SPD 2010 workflows and InfoPath forms

So I have been working on a project on SharePoint 2010 that is basically a list where the input form has been customized using InfoPath.  We decided to go this route using a list instead of using a Forms library because of the capability in workflow to send dynamic emails to multiple people if and only if it comes from a Person or Group column.

The problem came when I got up around 75 columns.  Suddenly, I found that I could no longer publish the InfoPath form.  I got “The SOAP Message could not be parsed.”  If I removed a column or 2, or got rid of a rule, or a data connection, suddenly I could publish again.  But there seemed to be this magic, undefined breaking point that I couldn’t exceed before I’d start running into problems.

So now, I had to implement the SharePoint Designer 2010 workflow.  I knew I needed probably 3 workflows, one for create, and 2 for on change.  However, once I got past 2 or 3 IF statements, I could no longer publish the workflow either.  It would save, but on publish it would give me “Unexpected error on server associating the workflow.”  Now mind you, I did NOT have any Start Approval Process or similar actions – one of those content-type actions.  These were just simple conditions, emails, and setting of a few fields.

I found that I had to break my work up in to 16 workflows.  Each one started out with a condition to see if it should run.  This was getting ridiculous, and finally I got to a point where I couldn’t get any more granular and still it wouldn’t publish.  As suggested by some posts, I tried increasing $app.UserDefinedWorkflowMaximumComplexity in PowerShell (where $app is the SPWebApplication in question) and I also tried adding a timeout value to the  web.config.

 

So this whole time, I’m working from my contractor’s computer.  The SharePoint system in question was exposed over the internet using a UAG appliance for firewall and authentication.  Normally, this is not an issue, as I can usually get everything done I need to. On a whim I decided to open everything up from the customer’s computer, which incidentally has a VPN connection to their system, and voila, I can publish InfoPath forms and Workflows now with no issue.  <sigh>  It’s the little things that get you.

 

http://fairulshahrizat.blogspot.com/2012/12/sharepoint-designer-2010-workflow-error.html

 

SharePoint 2013 Sorry this site has not been shared with you

Recently I ran into an issue with a site that had been migrated from SharePoint 2007 through to SharePoint 2013.  The home page was a Publishing page in the Pages library, and the Pages library inherited permissions from the site, and none of the pages had unique permissions.  I had a couple of users who were in groups that had full control.  Those users were able to browse to the home page just fine, but when putting the page in Edit mode, received the message “Sorry, this site has not been shared with you.”

I went to the page in question and did a “Check Permissions” and sure enough they DID have rights – full control – to the page.

So I went into the SharePoint ULS logs and there was an Access Denied error logged, sure enough, but right around that error it was referencing something about the Publishing infrastructure.

 

So on a hunch, I checked permissions on the library at the root – Master Pages and Page Layouts.  Someone way back when had broken permissions on this library and removed EVERYONE’s permissions on this library except the system account and one administrator.  So I added the users to Full Control for the library (probably read would have sufficed, but they needed full control anyway) and the problem was resolved.

In general, you also want to be careful of permissions around the Style Library and/or Site Assets, depending on where your css files and images are stored.  We always have lots of people who think they are locking down their site remove the “Style Resource Readers” group (which by default has NT Authority\Authenticated Users in it) but the end result is no users can browse to anything because they don’t have rights to view the stylesheets.