Summation

Ill start this post out by saying that this is why i so LOVE the SharePoint Community. It is a true example of "many hands make light work”, first Jim Bob Howard @jbhoward one of my @PlanetTech work colleagues faced a problem, since it was a topic of interest to me, I decided to put some time into it as well. I was able to prove out most of the issues, but there was this last one (see blog post to what this is referring to in a link below) that just didnt make sense. What do i do when that happens, well I’ve never been ashamed to reach out to my friends in the SharePoint Community so I blogged the issue, showed what we did so far, and without tagging anyone in the tweet we had folks from the UK joining in the conversation, folks from all Time Zones here in the United States chiming in as well. Late Friday night I emailed a copy of the Workflow to my good buddy @givenscj Chris Givens. I really wasn’t surprised when even on a Saturday, Chris called me up on the phone, and we spent like 2 hours on a Screen Share looking at ULS logs, then he went off on his own, and within an hour, he came back with a solution.

My Plea for help on my blog which gives more details than the forum post allows is here. This post is basically closing the loop on the problem

Findings

Chris blogged his findings here, go look at it, but the main point ill just borrow from is blog…

“…The main issue of Fabian’s was that when he made the Web Service call he would pass a pre-created FedAuth token (yeah I told him he would have to figure out how to generate this in the future) which established a context for him. This context was as his SharePoint admin account, but the actual running account (the "actor") was the Workflow service. Of course the SP Admin account can do whatever it wants, but the workflow service cannot. This workflow service account is NOT the account that the actual workflow manager backend window service is running under.”

Screen Shots form what Chris and I worked on

First we wanted to see what was happening ON Prem with this both from a Fiddler standpoint as well as SharePoint Designer 2013, here is what we saw. The offending item was the account it is running under MS.SP.EXT which is the App Principal for the Workflow from Workflow Manager. Further down you will see this inside the Content Database and the permission it is set to run under.

with a little more detail below

Below is a peek into the App Principal Table. This table as Chris describes is where the App Principal Accounts live, you can see that i have a few that are Titled as my Workflow Apps and one called just “Workflow” and it is that one if you look under “Name” has MS.SP.EXT 🙂

Now, lets go look at the permissions, now mind you, if you look at permission it is set to “5” right now for the ID 1, that was set to “3” before i ran the PowerShell that Chris has on his web site and i will put below for complexness.

Once I did that, all we did next was re-Run the workflow, NO other changes, here was our result

and in All Site Contents

Finally

So, all is well in the world of SharePoint again. I hope Chris goes and puts his solution as the answer to the question in the @Office365 Forums so we can have a record out there as well. I hope this helps someone else that falls prey to this, I agree with Chris, this is the first time I have ever seen anyone blog or talk about this in a public setting.

Cheers

Fabian Williams with contributions from Chris Givens

UPDATE SECTION

So, because i wanted this to work in Office 365 as well, we needed to find out if these PowerShell options are available there too. For completeness I loaded up the ISE and I have here all the options that you can do with the App Model for GETS and SETS, both for On Prem and OnLine, you can see that the Online version is very limited

ON PREM

and sad to say I could get EVERYTHING from ONLINE in one screenshot. 🙁 sad panda

If you want to know more about Powershell for SharePoint Online regarding how to set it up in your environment, see Patrick @pcfromdc Currans blog post here.