How to fix SharePoint workflow files that are checked out

I recently ran into an issue where I was getting the dreaded “failed on start” error for some of the workflows in a SharePoint 2010 environment. At first I was concerned that some sort of Microsoft KB had killed workflows again as described here and here.

However, that didn’t appear to be the case. After some investigation I noticed that the files that make up a particular list/ library workflow were checked out!

The problem(s)

This first issue was the “failed on start” error message in the workflow field within the list. It was a pretty niche edge case though as it appeared to only affect newer workflows that contained a send email action.

Another interesting issue was that when creating brand new workflows to test if the error persists brought its own set of problems. Once published, the new workflow would appear as normal to be ran manually for a new list item and would proceed to fail on start.

Workflows failing on start from within SharePoint 2010.

However, any new list items would not have the workflow listed to be ran against. Jumping back into SharePoint Designer proved equally useless as clicking on the workflow within the list just brought you to a SharePoint error.

Then I found that digging deeper into the workflow files within SharePoint Designer showed that some of the files that make up a workflow were in a checked out state – what?

You are unable to check these files in, as when you try you receive a message stating:

“Server error: you cannot discard check out because there is no checked in version of the document. please delete this document instead”.

After googling this, as I’d never seen this before led me to this brilliant post on SharePoint stack exchange which brought me to a resolution. Specifically, this comment:

I also would like to thank TashasEv for his answer. It provided the key clue I needed for troubleshooting a similar problem. In my case, it was not the Document content type which had the title set to Required, but the User Workflow Document content type.

This is one of two content types that are shown listed when (in SPD) you right-click on the Workflows folder in the left Navigation panel (the other being Folder). I used the Administration Web Page (it’s a button in SPD when on the Properties tab for the Workflows folder). Changing the Title property of this content type to Optional solved the issue.

https://sharepoint.stackexchange.com/questions/75978/workflow-files-wont-check-in-cant-undo-checkout

Solution

So as described in the above post, here are the steps involved:

1. Find the hidden properties menu

  • Open SharePoint Designer 2010 and open the site where you workflow is running
  • Press All Files > Workflows
Open Workflows from with All Files in SharePoint Designer.
In Workflows, after clicking on the affected workflow you will see all the files associated that are in a checked out state.
  • Right-click on any workflow (I selected the affected one) > press Properties
“Hidden” properties button can be found by right-clicking on a workflow.

2. Set the title of the user workflow document content type to optional

  • Within Properties, under Content Types > select User Workflow Document
  • Under Customization > press Edit content type columns
Within the User Workflow Document, press the edit content type columns button.
  • Select the Title column > then press Administration Web Page
  • This will open a browser window, under column settings set the column to Optional
Make the hidden title column optional from the administration web page.

3. Re-publish the affected workflow(s)

  • Navigate to the affected workflow(s) via the Lists and Libraries section
  • Open your workflow, make a small amend > Save and Publish

Now, when you run the workflow(s) affected they should complete as normal, and if you check the files within the All Files > Workflows section in SharePoint Designer they should be checked in and all OK.

Advertisement

How to stop all Office files in SharePoint 2010 opening read-only

(This post was written using a SharePoint 2010 environment)

In this post we look at how differing versions of Microsoft Office ProPlus affects SharePoint 2010 and the ability to open and edit Office files, plus how to fix them.

The situation

I began to get reports from users that were trying to open Office files from SharePoint that the files would only open read-only. These users have historically always had permissions to edit the files and have previously been able to open the files in edit mode from libraries within the SharePoint environment.

In this scenario we were running Microsoft Office 365 ProPlus version 16 and updates were on the monthly channel.

Investigation

There were several suggestions already within the Microsoft community on how to fix this issue, which I initially tested myself to see if they would work. I tried:

  • Clearing the Windows credentials of the MicrosoftOffice16 credentials
  • Turning off the “require documents to be checked out before they are edited” option in the a libraries settings

However, neither of these things worked completely. I didn’t notice any difference clearing credentials, and with the checking out files feature – this wasn’t turned on for the majority of the libraries I tested. Plus I didn’t really like the idea of having to turn off the checking out functionality in every library within our SharePoint environment!

So I continued to investigate and found the following:

The read-only issue appeared differently depending on the Office file

For Word and PowerPoint files, I saw that files would show this window when opening:

Word & PowerPoint files would open read-only after clicking open from this prompt.

Then the files would be read-only, if you tried to save the file it would ask you to save a copy. If you tried to overwrite the file saved in SharePoint it would tell you it is read-only and cannot be saved.

For Excel files, again you get the above prompt before the file opened, however when you opened the file a yellow banner would appear, allowing you to edit the workbook:

Excel files performed differently to other Office files when opening form SharePoint.

If you press “Edit Workbook” you could edit the file and save back to SharePoint no problem.

Some users could edit files from Open with explorer, but not all

So in this example some users could work around the issue by opening the file in explorer, which would allow them to edit the file and save back to SharePoint.

This wasn’t consistent for everyone, in some cases when users opened a file from explorer view, they would be prompted to check out the file from a yellow message in the ribbon, which would then error to tell them they can’t as the file is read-only.

Older versions of Office updates did not experience this issue

Not all of the users in this scenario had the same Office updates. One user who was running version 1611 on their machine was able to open and edit the same files from SharePoint that users running 2002 and above Office updates could not.

Solution

Im calling this a solution, but really it feels more like a sticking plaster as I’ve personally noticed this issue has been presenting itself in varying ways since at least the 1908 Office update, but this latest issue presented itself with the 2002 and 2003 Office updates. Anyway, here’s what we did to get files opening again:

  • Uninstall any Access Database Engine downloads you may have installed (2007, 2010 is what I noted)
  • Run an Office repair on the machine(s) with the issue
  • Install, or re-install Infopath 2013

Once Infopath was installed, when opening the same Office files (Word, PowerPoint or Excel) the above prompt changed to look like this:

Once Infopath 2013 was installed, the above prompt would appear when opening files from SharePoint.

I continued to test, going so far as to switch on the “require documents to be checked out before they are edited” setting just to see if that had any bearing on things, which it didn’t as the prompt just changed slightly:

With the check out option configured, the prompt to open and edit files in SharePoint slightly changes.

Like I mentioned earlier, this is by no means a solution to this problem, but it’s got us out of a jam for the past few Office updates, so hopefully it will help someone else too!

Resources

How to create a custom ID for lists and libraries

In this example I demonstrate how to create a simple solution that allows users to submit a request to a list, then a workflow fires that updates the request ID field with our custom ID number.

ID numbers, reference numbers, ticket numbers…this is something that regularly gets asked to be a part of any SharePoint solution or request based system. My first thought when this is required is “easy, we can just use the SharePoint item ID column and use that”. However, creating a simple calculated column that leverages the in-built ID column is not as easy as it seems.

My first attempt at creating a custom ID column involved creating a new calculated column, and appending some text before the ID and then inserting the ID column into the formula, like this:

="REQ-00"&[ID]

The problem with this approach is that when new items are added, the ID appears to “slip” resulting in the custom ID column having no ID number being pulled from the SharePoint ID.

Custom ID column – modern SharePoint

1. Pre-requisites

Before you begin you will naturally need to create either a list or library in SharePoint, and the relevant apps checked as part of your O365 license.

2. The setup

  • Create a new column, with the type Number – I called this ‘solIncrementNum
  • Create a new column, with the type Calculated – I called this ‘solReqNum‘, later renamed ‘Request Number’
    • In the formula field, add the following: ="SOL-00"&[SolIncrementNum]
    • For the Data Type, select Single line of text
Setting the formula for the solReqNum column in list settings

NOTE: for the Request Number formula if you want to prefix your custom ID with something else just replace what’s between the ” “ in the formula field above.

3. Build the Flow

Flow action: when a new item is created

  • Create a new flow from the template “when a new item is created, complete a custom action”
  • Give your Flow a name, I called mine “Populate Solution Request Number”
  • In the “when a new item is added” step, make sure the site address and list name are the same as the list you built the custom ID column for earlier
Step 1 of the Populate Solution Request Flow

Flow: update item

  • Press + New step, start typing “update item”, select the update item action from the selection
  • Select the site in question, then copy and paste the List Name from the previous action
  • Make sure this action has the following fields set:
    • Id: ID
    • Title: Title
    • solIncrementNum: ID

NOTE: make sure that when you set these fields, that the values you use are coming from the “when a new item is created” action.

Step 2 of the Populate Solution Request Flow

Now when new items are created within the list or library, the flow will fire and create a new request number.

Modern SharePoint list with Flow that populates Request Number

How to fix SharePoint sites that don’t appear in top navigation

(this post applies to SharePoint 2010, 2013, 2016 classic sites)

So in this scenario, a user was unable to get new SharePoint 2010 sites to show in the top navigation, even though some where hidden. If this happens to you try the following:

  • Navigate to Site Actions > Site Settings
  • Under Look and Feel > Navigation
  • In Global Navigation > update the maximum number of dynamic items
Update the maximum number of dynamic items to show all your sites

That’s it! now all your sites that haven’t been hidden will be displayed in the global navigation.

Configure a default view for Document Sets

(This post was written using a SharePoint 2010 environment)

Document sets are a pretty awesome way to convert people from traditional folders to using metadata in SharePoint, but retaining the ‘feel’ of a nice folder structure.

When you start using document sets you might want to play with the default view of your files, this isnt as straight forward as just setting a new default view. Here’s how to do it

Create and configure the view

  • Create your view
  • Under Folders > ensure show this view is set to In folders of content type: document set
  • Press OK
Select the document set content type in the view settings

Select the view for the Document Set Content Type

  • Navigate to the Library Settings
  • Under Content Types Select the Document Set
  • In Settings > Select Document Set settings
Document Set settings
  • Under Welcome Page View > select your view
  • Press OK

Now the changes made to your custom view will be present inside each document set!

Bonus

For more on document sets, check out my write up of the quirks of document set routing.

How to show the folder path of a file in library views

Introduction

This post looks at ways in which you can show the folder path of a file as a standalone column within a SharePoint document library view.

UPDATE: I’ve updated this post after some comments asking how to do this for modern SharePoint libraries. Click here for more.

Classic SharePoint

The scenario

A common request I get is:

How do I see what folders/ sub-folders my files are in at a glance

– all users everywhere

Out of the box, there aren’t any columns available that you could potentially leverage to display this information in a standard SharePoint 2010 library.

The solution

So, just by adding one value in SharePoint Designer, here’s how you do it:

  • Navigate to the library you wish to change, create a new view under Library Tools > Library > Create View
  • Choose the relevant format of your view, give your view a name and press OK
  • Open SharePoint Designer > Open the site > open the library you were just working in
  • In the Views pane > click to open the view you just created
In SharePoint Designer, clicking on the view name will open the view in edit mode
  • In the code editor window, scroll down until you see something like the following:
<ViewFields>
	<FieldRef Name="DocIcon"/>
	<FieldRef Name="LinkFilename"/>
	<FieldRef Name="Modified"/>
	<FieldRef Name="Editor"/>
</ViewFields>
  • Add the following field reference in between the opening <ViewFields> and closing </ViewFields>
  • Add the field reference in the display order you would like it to appear in the view
Add the field reference to the View Fields list
  • Press the Save icon to save your changes
  • Press the Preview button to see your view in action in the browser

Now you will notice there is a new column being displayed “Path”, that is showing us the full location of the file or folder in the libary. You’ll also notice that this path will display data when at the library root, or in any folders or sub-folders in the library.

Library root displaying a files path
File in sub-folder displaying relative location

Bonus

Taking this one step further, what if we wanted to show files of a certain type, then create a view that groups these files by their folder location? Guess what, that’s exactly what I did!

  • Navigate to your library > create a new view as before, this time base your new view off the one you just created
  • If you wish to only show files of a particular type, use the filter by settings (for example below is filtered to only shows Word documents)
  • Make sure “show all items without folders” is selected
  • Press OK
Filtering to only show word documents, also showing items without folders
  • Back in SharePoint Designer > Open up the view you just created
  • Scroll down until you see the opening <Query> tag and add the following beneath it:
<GroupBy Collapse="FALSE" GroupLimit="30">
	<FieldRef Name="FileDirRef"/>
</GroupBy>

Save and preview your view, it should now be grouping by the Path field:

I know this has proven really useful for my company, so hopefully this helps out someone else too 🙂


Modern SharePoint

The scenario

With Microsoft retiring SharePoint 2010 designer workflows, plus the movement away from SharePoint Designer in general, a few readers have asked for a solution that works with modern SharePoint.

When researching this I considered whether suggesting to use SharePoint Designer 2013, as the above solution would still work in SharePoint Online using SPD 2013. But, as Microsoft say themselves although SPD 2013 remains supported, it’s depreciated – so I decided to go in a different direction.

The below example walks you through how you can create a flow in Power Automate to update a file after it’s been created to have the folder path shown in the document library view:

The solution

For this solution you will need to have access to create Flows in Power Automate, as well as an existing Document Library created in SharePoint Online:

  • Navigate to the document library you wish to show the folder path for
  • Add a single line of text column to the document library > give it a name (I called mine FolderPath)
  • Under the ellipsis, press Automate > Power Automate > Create a flow
  • In Power Automate, either use an existing, relevant template or start from blank
  • The trigger action should be When a file is created (properties only)
  • Set the Site Address and Library Name where you want to add the folder path
  • Insert a new step > select Update file properties.
  • Set the following values for the update file properties step:
    • Site Address: same as previous step
    • Library Name: same as previous step
    • Id: ID
    • FolderPath: Folder path

NOTE: The FolderPath within the Update file properties step is the custom column we created earlier. The Folder path (highlighted in red) is dynamic content available within the step in the flow. The folder path dynamic content is the path to the folder the item is in, relative to the site address.

Ensure you select the system Folder path dynamic content to pull the right data into the custom FolderPath column.

Here’s the flow in it’s entirety:

At this point test and save your flow to make sure it is working as expected 🙂

Bonus #1 – turn your folder path column into a hyperlink column

So if like me you want to take this one step further, wouldn’t it be good if we could easily make our newly showing folder paths, actual hyperlinks to the folders? Well the good news is you can!

  • Navigate back to your document library > click on the FolderPath column > Format this column
  • Under Apply formatting to make sure FolderPath is selected
  • Paste the following JSON into the custom formatting box:
{
  "$schema": "https://developer.microsoft.com/json-schemas/sp/column-formatting.schema.json",
  "elmType": "a",
  "style": {
    "color": "blue",
    "font-weight": "bold"
  },
  "attributes": {
    "target": "_blank",
    "href": "='YOUR SHAREPOINT SITE URL' + @currentField"
  },
  "txtContent": "@currentField"
}

NOTE: for more information on turning field values into hyperlinks, check out this awesome sample from sp-dev-list-formatting.

  • Press Save
  • Your FolderPath column values should now be legitimate hyperlinks that click through to the relevant folders

Bonus #2 – update existing files in the document library

This was another suggestion from a reader with regards to how to update files that existed in the document library before the flow was created.

Running a flow manually for individual files

When I began to consider how to do this I started by looking at ways to manually start the flow.

It appears the only real way to do this is to create a new column that adds a button next to each file, that allows you to run the flow. I’m not really enamoured by this approach as it doesn’t seem ideal to have an extra column to run a flow showing on every file in your library. If this is something you would like to pursue then I would recommend this great article by WonderLaura who has the process of creating a button to trigger a flow covered!

Update our flow to update all files if folder path is empty

My solution to this problem was to update the flow we created earlier to get the properties for all files in the library, then add a condition that checks if the FolderPath column is empty, then if yes runs our flow as before.

  • First, I added a Get files (properties only) action which gets all the files from the source library
  • Then I added a new Condition action, which simply checks if the FolderPath column we created is equal to null. You will also notice a new Apply to each action will be created
  • I then moved the previous Apply to each action into the “If yes” condition
  • I left “If no” blank, as it is ok to leave a condition blank if you don’t want it to do anything

Here’s the updated flow in full, which changes highlighted in red:


Problems creating list or library views based on created date

The situation

Data retention and deletion…I’m sure this is a something that anyone involved in Office 365, SharePoint on information management in general gets fed up of saying since the recent GDPR legislation!

Recently we have been rationalising and cleaning up our data in preparation for moving to Office 365. We are starting with SharePoint as the first target repository or silo of content.

The general consensus is to delete files and folders over 7 years old unless there is a pre-existing data retention policy to adhere to. So the next task is to identify those files that fall within our threshold, and ultimately delete.

Luckily, we have Tree Size Pro and ShareGate so I was able to relatively easily identify the files in question (there were a lot!).

The setup

As our SharePoint environment is a) rather full; and b) rather old, I made the decision to incrementally delete files rather than en-masse to mitigate risk, targeting the lists/libraries containing the most out of date content. I started by creating a view in the first library – library A with the following parameters:

  • Standard library view
  • Filtered by Created Date if less than or equal to 01/01/2011
  • Folders or Flat: Show items inside folders
    Show this view: In all folders

(all other settings are left default)

Results this returned looked good, I could see folders and files in this view that matched the criteria – brilliant! Based on my previous statement I decided to delete in batches out of working hours, again to mitigate risk. I deleted first from library A, then from the first stage and finally from the second stage recycle bin all in this fashion.

The problem

I had permanently deleted around 50% of the total volume of content to be deleted from library A when we started to receive reports of current files being ‘missing’ from library A…not a good day.

After these reports were investigated they were indeed true. It turns out that when folders are included within a library view, folders that match the filter will be shown in the view, regardless of whether the files inside match.

We tested the view exluding folders and all the files returned matched the filter criteria. The same results were demonstrated from a SharGate report of the same nature. The report of all files over 7 years old brought back folders over 7 years old, but they also contained files that were newer.

Conclusion

At present, we are not entirely sure as to why these filters are not able to drill down past a top-level folder. It appears to be difficult to specify via view settings to only show files within folders, including the folder itself that matches the criteria.

We have decided to omitt folders from our reports and views going forward and to solely focus on files as this is the most reliable way we can delete files.

Bonus: for those of you with ShareGate, heres an example of my report we created to bring back all files over 7 years old, excluding folders. I ran this report across the entire intranet application over a weekend and it worked a treat 🙂

SG-report

Fix pages with no publishing options in SharePoint

(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.

SP2010-publishing-feature.png

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.

  1. Open the site in question, then go to Site Actions > View All Site Content
  2. Open the SitePages library
  3. Under Library Tools > Library, select Library Settings

    SP2010-librarysettings
  4. Under General Settings > Versioning Settings, turn on Create major and minor (draft) versions > press OK
    SP2010-versioning

  5. Go back to the original page, you will now see the publishing tab has appeared!

File naming restrictions in SharePoint

This post is a reference point for all the restrictions and limitations around the restrictions that apply to file names and file types in SharePoint and OneDrive.

When uploading files into SharePoint or OneDrive that are subject to any of the restrictions, you may receive an error similar to something like this:

filename-error

What are the restrictions?

Restrictions have become more difficult to untangle in Microsoft 365 with SharePoint and OneDrive, plus the ability to sync. The key takeaway is that the entire decoded file path, including the file name can’t contain more than 400 characters. This limit applies to the combination of the folder path + file name after decoding:

  • The entire decoded path can’t contain more than 400 characters
  • File uploads cannot exceed 250GB
  • You can’t share more than 50,000 items
  • You can’t copy or move more than 100GB in total, no more than 30,000 files and each file must be less than 15GB

Invalid characters, file or folder names

  • ” * : < > ? / \ | all aren’t allowed in file or folder names, plus leading or trailing spaces
  • # & are supported and can be enabled in the SharePoint admin center
  • .lockCONPRNAUXNULCOM0 – COM9LPT0 – LPT9_vti_desktop.ini, any filename starting with ~$. are not allowed for files or folders
  • forms” isn’t supported when the folder is at the root level for a library
  • You can’t create a folder name in SharePoint that begins with a tilde (~)

Blocked file types

  • There are currently no known types of files that cannot be added to a list or library in SharePoint Online. Custom scripting must be allowed for custom script file extensions to be work
  • Temporary TMP files will not be synced to OneDrive
  • Files that are used by your local computer, such as desktop.ini on Windows or .ds_store on macOS, don’t normally sync
  • Outlook .PST files are supported, however they are synced less frequently compared to other file types to reduce network traffic

File uploads, names and path length

  • The file size limit for uploads is 250GB
  • Each segment of a path cant exceed 255 characters if files are synced to a PC or Mac
  • The length of the root folder in OneDrive, or synced SharePoint library, plus the relative path of the file (up to 400 characters) cannot exceed 520 characters
  • In SharePoint Server, the entire path of files can’t exceed 260 characters
  • Thumbnails are not generated for images larger than 100 MB
  • PDF previews are not generated for files larger than 100 MB

Sharing

  • There is a limit of 50,000 items that can be shared within a folder and any sub-folders
  • You can’t synchronize the Shared with me view grouping of files from a OneDrive for work or school site

Syncing, copying or moving files

  • Although SharePoint Online can store 30 million documents per library, for optimum performance Microsoft recommend syncing no more than 300,000 files across all document libraries. Additionally, performance issues can occur if you have 300,000 items or more across all libraries you are syncing, even if you are not syncing all items in those libraries.
  • If you use the previous OneDrive for Business sync client (Groove.exe), the sync limit per library is 20,000 items (including 5,000 items per team site)
  • Differential sync is possible for Microsoft Office files in the new file format, .docx, .pptx, .xlsx
  • You cannot copy or move more than 100 GB of the total file size
  • You cannot copy or move more than 30,000 files
  • Each file being copied/ moved must be less than 15 GB
  • SharePoint libraries/ lists can hold 50,000 major versions and 511 minor versions
  • When using onedrive.com, you can only copy up to 2500 files at one time

How it used to be – restrictions in SharePoint Sever

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: ~ ” # % & * : < > ? / \ { | }. in SharePoint 2013
  • 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

References

https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file – Names, paths and namespaces by Microsoft

http://www.sysadminsblog.com/microsoft/file-name-length-and-character-restrictions-for-sharepoint/  – Original write up by Mischa Oudhof of Sysadminblog.com