(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!
It’s back again…a few months ago a wrote about my experiences with workflows failing on start after a .NET security update that was applied. You can read that post here:
Recently, the same .NET security update was applied to our SharePoint 2010 farm, which in turn caused the failing on start error to present itself again across all the workflows in the farm.
After identifing the issue soon after the update was applied, we decided to follow the same tact as before and roll back the patches, restart the servers and re-test the workflows – However, this time the results were different.
What was different?
Previously, rolling back the security update and any other patches added during this time, plus restarting the servers “fixed” the issue. This time, the same process did not yeald the same results and the workflows were still broken.
After performing the steps above, we observed that standard SharePoint workflows with a pause started to run sucessfully again, but Nintex workflows with a pause step either failed on start, or completed but errored after the pause step and sent an error notification.
Example 1 of nintex workflow with pause step failing on startExample 2 of nintex workflow with pause step erroring, but completing
How we fixed it…
So this time we followed the updated step-by-step guide provided below on how to update the web.config files and OWS timer files via Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1 PowerShell script on the SharePoint Application server.
We ran the script as recommended, which re-added the assemblies and dependancies to the OWSTimer config file and the web.config files on associated web servers and this in fact fixed the issue! As the script does an IIS reset/ Timer Job recycle we didnt even need to restart the servers!
I hope the that tidbit regarding the nintex workflow pauses helps someone else 🙂
Firstly, full credit for this information goes to Mischa Oudhof and this sysadmin blog for this really useful post in 2010! I thought i’d write it up here just for my own sanity (and incase that page were to ever not exist) plus add a few extra bits of my own.
So recently a user was trying to upload multiple documents into SharePoint 2010 by copying/pasting using file explorer for the destination library. When copying across the files they received something like this message:
What are the restrictions?
There are a whole load of restrictions when it comes to file name, length, characters within SharePoint. This affects site collections, sub-sites libraries or lists. Here are some of the more general restrictions:
File and folder name lengths can’t exceed 128 characters in both WSS 2.0 as WSS 3.0
Link list items can’t exceed 256 characters
The entire path of files can’t exceed 260 characters
Here are some, more specific restrcitions again applying to site collections, sub-sites, libraries or lists:
Can’t be longer than 128 characters
Can’t use: ~ # % & * { } \ : < > ? / + | ”
Can’t use the period character consecutively in the middle of a file name (blah…blah.docx)
Can’t use the period character at the end of a file name
Can’t use the period character at the start of a file name
Can’t end with:
.files
_files
-Dateien
_fichiers
_bestanden
_file
_archivos
-filer
_tiedostot
_pliki
_soubory
_elemei
_ficheiros
_arquivos
_dosyalar
_datoteke
_fitxers
_failid
_fails
_bylos
_fajlovi
A deep dive into all the potential restrcitions can be found in the msdn blog here.
Things have changed in Office 365…
Microsoft announced in 2017 that the old maxpath limit has been expanded to 400 Unicode code units. Microsoft also announced more URL improvements for the support of # and % characters.
I was recently updating a view in a SharePoint List, the view was set up to use metadata fields to sort and group the content…lovely stuff. What I was required to do was to implement a choice field with a numerical order within it (i.e. 1. First step, 2. Second step, 3. Third step).
With sort order in List/Library views, it works with either alphabetical or numerical options ascending or descending. What I found was with choice fields operating as the number order, once you hit 10 the numbering system went out the window!
What you end up with is something like this:
1) First choice
11) Eleventh choice
12) Twelfth choice
2) Second choice
3) Third choice
and so on…
By default, SharePoint interperates the choice field as alphabetical so the way I got around this was to just use:
a)
b)
c)
This gets around any issues with numerical values over 10 or having to create lookup lists or anything else 🙂
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:
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.
Symptom
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.
Cause
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:
<configuration>
<System.Workflow.ComponentModel.WorkflowCompiler>
<authorizedTypes>
<targetFx>
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:
Add-CodeDomAuthorizedType -IncludeNintexWorkflow
To undo the changes, run:
Remove-CodeDomAuthorizedType
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.
Note 2
Some people using third-party workflows (like Nintex) need to also include this:
(This post was written using a SharePoint 2010 environment)
I recently found myself needing to create a site template for a customer who required multiple sites created following a base format. So I decided to create a site template to achieve this to speed up the site creation process for said customer.
At first I went into the site settings of the site that the template would be based off to create it. I looked under look and feel in site settings, but alas the option to save as site template wasn’t there!
Next, I accessed the site via SharePoint Designer, looked under the site ribbon menu and would you believe the save as template button was greyed out there also!
After researching online, it appears there can be problems creating templates from publishing sites in SharePoint 2010, however I found that following the steps below enabled me to create a new site template and activate it not problem!
Navigate to the site collection/ sub-site you wish to create the template from
Add the following to the URL at the end of the site name
/_layouts/savetmpl.aspx
Go back to the site collection or sub-site you wish to create new sites under
Site Actions – Site Settings – Look and Feel – Page Layouts and site templates
Find your newly created site template within the subsite templates list
Press Add
Press OK
Please note: if your sub-site is inheriting from the parent site, you will need to navigate to the parent and add the subsite template there for it to be available.
UPDATE 27/08/2019
Saving as site template is not a supported feature of SharePoint Online for modern sites. You will find for modern sites that this option is not available, but you have the ability to re-instate it via activating a feature. The official stance from Microsoft is:
Just to be clear. Using save-site-as-a-template with modern
team sites or publishing sites is NOT supported. You can always find
aways with tenant admin permissions to achieve things, but the fact that
it’s doable does not mean it’s supported.
Any sites created with the template which has been produced with this
method can have unexpected issues in the future, so provided steps
should never be used.
Best regards,
Vesa Juvonen, Senior Program Manager, SharePoint Engineering, Microsoft.
UPDATE 27/08/2019
Saving as site template is not a supported feature of SharePoint Online for modern sites. You will find for modern sites that this option is not available, but you have the ability to re-instate it via activating a feature. The official stance from Microsoft is:
” Just to be clear. Using save-site-as-a-template with modern team sites or publishing sites is NOT supported. You can always find aways with tenant admin permissions to achieve things, but the fact that it’s doable does not mean it’s supported.
Any sites created with the template which has been produced with this method can have unexpected issues in the future, so provided steps should never be used. “
– Vesa Juvonen, Senior Program Manager, SharePoint Engineering, Microsoft.
I wanted to post this as I was banging my head against a brick wall for hours recently with this issue. Full credit goes to this stack overflow thread that described pretty much exactly what I was experiencing:
However, my situation was a little different so thought I would post this in case it helps someone else in future!
The details
SharePoint 2010 environment using a standard SharePoint Designer workflow. Straight-forward workflow that runs once a list item is created, creates a document set in a separate library, then updates the list item with a link to the document set (plus some other item metadata). All this is wrapped up in an impersonation step that uses a site collection admin user account.
Why an impersonation step?
An impersonation step is being used because when you create a new list item using a workflow, that new item is created by the System Account. So on any new item created by a workflow, “Start workflow on create” will not work because system account is not allowed to start a workflow.
The problem
Intermittently the workflow would fail on creating the document set. The workflow status showed “The workflow could not create the list item. Make sure the list exists and the user has permissions to add items to the list.”. The outcome is “Unknown Error”.
After speaking with users this didn’t seem to affect everyone all of the time. It only affected some people occasionally but it was affecting one user way more than others.
This user was creating the list item in exactly the same way as others in the team. I overserved the user creating the list item and couldn’t see any problems with how it was being done. Yet each time we conducted a test copying field information from an existing item the workflow continued to error.
The solution
In my case, when I started to look at the list items where the workflow had failed, I noticed that the Name field for each list item contained a trailing space at the end of the text. I asked the user who this issue consistently affected to try creating new list items several times, copying the Name as normal but this time removing the trailing space and we no longer had issues!
Moral of the story…check for trailing spaces and beware!
If you’ve ever been in the situation where you try to edit a page in SharePoint and you see this seemingly unchangeable message appear at the top of the page stating:
“Page has been declared a record or placed on hold and is read-only”
Fear not! I’ve seen this message appear and it usually occurs when a user (or service account) is operating as a system account. This could have been set manually by said user if they have access to the web application via central admin:
If this is the case, you can overwrite the system account check in via SharePoint Designer. You’ll obviously need the correct permissions to access SPD beforehand! In the following example I’m using a SharePoint 2010 environment. To do this:
Connect to your web application in SharePoint Designer
Navigate to All Files – Pages
Right-click on the page that is currently locked
Undo checkout
NOTE: You won’t be able to view the individual pages within each Page Library if you navigate through Lists and Libraries. This space is used to view and manage the settings for each list type you have. All Files takes you to the ‘root’ of your web application, where you can see everything that sits under the web application.
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.
InfoPath, I really like InfoPath. I like the interface and how easy it makes editing custom list forms in SharePoint (especially if you want to make snazzy looking forms in SharePoint 2010). However, custom actions do not like InfoPath, not one bit.
The problem
Here’s the situation, we have a heavily customised custom SharePoint 2010 list which was leveraging InfoPath based forms. We were getting reports of latency when trying to open the InfoPath forms and the decision was made to revert back to the default ones.
Also, another requirement was to have a two edit forms for this list, one set as default with several fields omitted for end users – another one for administrators of the list. Once the edit forms were created I embarked on my journey of creating a custom action that would open the administrator’s edit form from the ribbon, utilising rights masks to make it only appear for those with adequate permissions.
I quickly found that this wasn’t going to work. I tried several times to create the custom action but it just wouldn’t appear. Even after reverting the list back to the default forms from InfoPath through list settings and deleting the InfoPath forms from server the custom action wouldn’t show. I found some useful conversations about this issue below:
After I realised the custom action approach wasn’t going to work, I made the decision to go down the route of having one custom edit form that would conditionally show or hide fields based on their permissions – the answer I found was within a XSLT conditional if test!
The solution
Here are the steps taken to hide a field based on a user’s permissions within a custom edit form:
Open the list you want to edit in SharePoint Designer
In the Forms section, open your custom edit form
Switch to Advanced Mode
Use the design view and select the field you wish to hide
In the code view, add the following code snippet above and below your field:
<xsl:if test="ddwrt:IfHasRights(2048)"> </xsl:if>
The end result should look something like this:
Save the changes
If this has worked, you should now be able to test the edit form as a user with the correct permissions and see the field, then verify that for a user without the relevant permissions it’s hidden.
Within the if test, the number corresponds to a permissions mask that assigns a particular value (i.e. 2048 = Manage Lists).
Here is a list of all the values and permissions masks:
