(This post was written using a SharePoint 2010 environment)
So you’ve got a SharePoint site, it all looks good (well, as good as it can!) but you notice that the Publish tab isn’t available in the ribbon.
First things first you check the site settings to see if SharePoint Server Publishing is turned on.
If you get to this point and your still no further forward it’s likely that your site wasn’t set up as a publishing site, but if you follow the steps below and your pages will be able to be published in no time.
Open the site in question, then go to Site Actions > View All Site Content
Open the SitePages library
Under Library Tools > Library, select Library Settings
Under General Settings > Versioning Settings, turn on Create major and minor (draft) versions > press OK
Go back to the original page, you will now see the publishing tab has appeared!
Drag and drop to re-order the left-hand site navigation
You can now re-arrange the order of your site navigation elements with a nice, user friendly drag and drop gesture. This removes the multiple clicks involved in he ellipsis, move up or down options of old. This new gesture also works for dragging/dropping into a sub-navigation location.
Bulk check in/out
This one I’ve been waiting for awhile for! You will soon be able to check in/out multiple files at the same time form the modern ribbon in a document library.
File signals or status icons are being added into SharePoint to add visual clues regarding the status of a file, such as check-out status, sharing, DLP blocks or missing metadata. This applies to modern lists and libraries.
A revamp of an old favorite, column totals and subtotals are coming to modern lists and libraries. These totals and subtotals are displayed in the footer. This is a welcome change from the old total count in classic views!
Add columns between columns and drag and drop
You can now insert new columns in place between existing in and modern list or library view, plus move a column around by simply dragging the header to a new location in the view.
Smarter file hover cards
The file hover card gives you a sneak peek into your most important files. Now, as soon as your hover over a file you will be able to see important stats like number of views, who’s viewed and who’s modified. This functionality is now being extended to almost all file types.
This new experience will also appear for files listed in your Shared by Me view.
Microsoft Authenticator allows you to receive security notifications for important events on your personal Microsoft Account. When you receive a notification, you can quickly view your account activity to take action if needed.
Microsoft Authenticator can be used to add two-step verification for added security if needed. It supports fingerprint, face ID or PIN authentication.
I had this issue myself in the last week where EVERY SINGLE workflow across the farm on premise stopped working. SharePoint Designer and Nintex workflows all reported “Failed to start” when triggered to run.
The workflows stopped working due to a series of .NET security updates Microsoft released in September 2018. Microsoft released a public KB article on this – with resolution steps which can be found below:
But also this msdn blog post contains all the solution scripts and steps that includes Nintex workflows also (transcript below):
I noticed shortly after the fix was implemented that some of my SharePoint designer workflows were exhibiting odd behaviour. For example the screenshot below shows a SharePoint desinger workflow that previously worked without issue or errors in the history after the fix was applied:
Someone on reddit had already spotted this which drew my attention to the common issue, this only presents itself for workflows with pause steps!
I will update this post with my findings once this latest fix is applied.
After applying .NET Security Only patch to resolve CVE-2018-8421 (Remote Code Execution Vulnerability) , all SharePoint out of the box Workflows fail to execute and the log will show an error like this:
09/13/2018 01:59:07.57 w3wp.exe (0x1868) 0x22FC SharePoint Foundation Workflow Infrastructure 72fs Unexpected RunWorkflow: Microsoft.SharePoint.SPException: <Error><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″…
The error suggest that System.CodeDom.CodeBinaryOperatorExpression is not in the authorized types.
Workflow Foundation (WF) will only run workflows when all the dependent types and assemblies are authorized in the .NET config file (or added explicitly via code) under this tree:
However, after the update, the following lines are necessary for SharePoint 2013 and beyond:
Please notice that sometimes SharePoint Timer Service (SPTimerV4) runs workflows. If you notice that the application showing the error is ULS logs in OWSTIMER.EXE, you should also include the authorized types in [SharePoint Hive Folder]\bin\OWSTIMER.EXE.config. The Hive Folder will change by version of SharePoint. For SharePoint 2016, it is normally at c:\program files\common files\microsoft shared\web server extensions\16. For 2013, at c:\program files\common files\microsoft shared\web server extensions\15.
If you have Nintex workflows you should run like this:
To undo the changes, run:
The script needs to run only once on any WFE. All web.config files related to SharePoint on all servers will be modified. New web applications created after that will also include the changes. Even if a new WFE is added to the farm, the entries will also be included in web.config. The change is a permanent requirement from now on since the WF patch. You do not need to undo the change before applying the SharePoint patch addressing it.
There is a second script to update OWSTIMER.exe.config. This one should only run if you see the symptoms in ULS logs with process OWSTIMER.EXE. Otherwise, you do not need to update. if you have the problem though, you need to rerun the script if a new machine is added to the farm. No line needs to be uncommented for this one. The script name is:
Microsoft is aware of this issue and patches for SharePoint 2010, 2013 and 2016 are being worked as of 9/17/2018. I will update when we have an ETA. I had confirmation from the product team on 9/18/2018 that this information and solution on this post is in the line with the future patch and it is the recommended action plan until the patch is out. If anything change, I will update the post.
Some people using third-party workflows (like Nintex) need to also include this:
As a SharePoint administrator, you should be fairly familiar with this error message:
If you’re not, it could mean that your SharePoint’s site access requests aren’t going to the correct email address…or you might just be ignoring them! In any case if you find that you need to manage where these site access requests go you can do.
When a SharePoint site collection is provisioned, site access requests are configured to be sent to the email address(s) specified at the point which the site was created, but a site administrator can change this for each site within the site collection they administer. By default, when a sub-site is created the same email address(s) that are configured on the parent site are used for access requests to the sub site.
Follow the steps below to change these settings:
In Site Actions – Site Permissions
Select Manage Access Requests from the ribbon
Specify the email address to send requests to and click OK. Note: you can add multiple email addresses here, just separate each address with a semicolon.
Note: With manage access requests configured users can click a link on the access denied page when they are unable to access content. If no email address has been configured for this site, the link will not appear on the access denied page.