In this multi-part “tutorial”, we build a single-server SharePoint Server 2016 farm inside a subnet of a Microsoft Azure virtual network. The purpose of this server will be for development and testing and as a basis for demonstrating what’s possible in SharePoint 2016. This is the introduction article.
The SharePoint snap-in needs to be loaded before you can execute commands against the SharePoint object model. This snap-in is automatically loaded for you by the SharePoint Management Shell. But the SharePoint management shell does not offer many of the advantages that PowerShell ISE offers (like debugging with breakpoints, etc). To get PowerShell ISE to autoload the SharePoint snap-in, follow the steps in this article.
For quick reference: C# and PowerShell code snippets to grab the SharePoint central admin url for a farm.
When the out of the box SharePoint approval workflow publishes an item, it sets the “Modified by” field as “System Account” instead of setting this to the actual user who did the approval. One way around this could be to add another column to hold the correct Modified by user instead of the out of the box Modified by column. But since not all clients will be satisfied with this approach, I will explain another way here.
The idea here might look really crazy. But on a few occasions, I’ve had to loop through an entire SharePoint Farm in search of a list with a unique title (and then create the corresponding SPList object). One time I’ve had to do this was when passing control to an aspx page in the layouts folder from a modal dialog that was just closed.
A while ago, I noticed a peculiar behavior with one of my custom SharePoint workflows. Tasks were getting locked out after the first edit. The first edit proceeds fine but when we attempt to edit the task a second time, we get an error like this:
This task is currently locked by a running workflow and cannot be edited.