Anyone who has worked with SharePoint development in the golden age of server-side object model development (SOM) likely used the property bag for different requirements in their solutions. With the onset of new development techniques and foundations, the property bag went by the wayside and wasn’t used as often (or at all) when creating solutions. With the new adaptive scope feature in Microsoft Purview, property bag usage has made a resurgence as a necessary location to store values when assigning policies. I will be covering these features in a future post, but for now, I’d like to set the foundation for these posts by discussing property bags and their usage.
Let’s admit it. Sometimes things just go wrong and you need an easy or straight forward way of cleaning it up and starting over again. An example of this happened to me the other day where I had a bad workflow that went unnoticed and started suspending. By the time it was noticed there were about 50+ suspended workflows (it was an active list). So after stopping the workflow I started working through cleaning it up and thought there has to be a way to terminate SharePoint 2013 workflows with PowerShell. Turns out I could do it. Here’s how:
I had to build a fairly complex workflow not long ago. The workflow was built in SharePoint Designer 2013 and had a lot of moving parts to it. So many, that when I went to publish it I received the following error message: “Microsoft.Workflow.Client.ActivityValidationException: Workflow XAML failed validation due to the following errors: Activity “SomeXActivity” has 65 arguments, which exceeds the maximum number of arguments per activity (50).” This error message is actually telling us that our workflow has too many variables within it. Basically, this is happening because when the workflow is running the Workflow Manager has to manage more 58 (in my case) variables. Workflow Manager only allows there to be 50 variables in the workflow… by default.
I recently had a need to read data from an xml configuration file that was stored within a SharePoint library. To make things easier I of course went to Google (or Bing) and checked to see if someone else had yet blogged this. Couldn’t find anything, so in order to help out someone else that may need to do the same at some point, I wrote up a quick little blog. Note: this will only work for on-premises versions of SharePoint. I’ll update with a SharePoint Online version in the future. I’ll also write up how to add and delete contents in a future post as well.
I have been working with SharePoint for a long time. An error was encountered not long ago that I have never seen when patching a SharePoint server (and unfortunately I have seen a lot of errors over the years). While running the configuration manager I received the following error:
“An exception of type System.Data.SqlClient.SqlException was thrown. Additional exception information: Invalid object name ‘Webs’.”
The error of course was really nice and pointed me to the log file to get more information. Opening up the log file and searching for ERR (put space at the end to have a better chance of finding an error entry instead of other words containing those letters) I was expecting loads of information to be made available to me so I could easily fix this problem. I really should have known better as I received the following:
At no point in the logs did it tell me where this problem was occurring. So where do we go from here?
Well let’s dig into it shall we?