In older versions of SharePoint Server, such as SharePoint 2010 or 2013, you are able to update the site logo of any site or site collection by opening up the site settings and accessing the title, description and icon settings under look and feel.
I recently migrated a SharePoint Server publishing site into SharePoint Online using the copy structure and content option within ShareGate Desktop. Aside from the migration being bloody brilliant (seriously, everything copies across and works the same! more on this in another post), one thing that didn’t work was the site logo.
How to update the site logo for classic SharePoint publishing sites in SharePoint Online
So in my earlier example, I’d just migrated a publishing site into SharePoint Online and noticed that the site logo was broken and affecting some of the navigation links of the homepage.
This Microsoft article makes mention of how to change the logo, title and description of your SharePoint site. The article also states that if you don’t see this option, it may be that you don’t have permission to see it – well I’m the primary administrator of said SharePoint site so that isn’t the issue!
I figured out a way around it thanks to trusty old SharePoint URLs. Below is how I got to the page, but if you just want to go straight there just add _layouts/15/prjsetng.aspx to the end of your site URL.
Open your SharePoint Online site
Add _layouts/sitemanager.aspx to the end of your URL
Click on the drop-down icon next to your site collection name > Press General Settings
This is the title, description and logo page as described in the Microsoft article previously. From here you can upload your site logo and save it to update your classic publishing site. It’s also worth noting that once you update the site logo from this location, it will also be visible within the modern elements of your classic publishing site (for example Documents).
How to update the site logo in SharePoint Server
For SharePoint Server, follow the steps below to update the site logo:
Before you begin 💡
Make sure you have saved your site logo in a location that is accessible to all users of your site.
Within your site or site collection > Press site actions > site settings
Under Look and Feel > Press Title, description and icon
Under Logo URL and Description > enter the URL path of your site logo
How to update the site logo in modern SharePoint sites
With modern SharePoint sites it is really easy to change the site logo. There are two types of site logo you can change:
Site logo thumbnail – appears in search, on the site card and where ever else a square logo is needed. Recommended size is 48 x 48px
Site logo – appears in the site header, which can be transparent or non-transparent. Recommended size is 64 x 64px
Add a new site logo
Navigate to the modern SharePoint site you wish to add a site logo to
Press the cog icon ⚙️ > Press change the look
Within change the look > Press Header
Scroll down until you see site logo thumbnail and site logo
Press Change on either the site logo thumbnail or the site logo
Select a relevant site logo from your computer and press open
If you want to remove a site logo, just open the header > scroll down to the logos and press Remove 🗑️.
This post is to serve as a reference point for all the useful shortcut URLs in SharePoint that help admins and super users get their jobs done much easier.
There are several blog posts by others with these URLs in them, but I wanted to preserve them in my own blog for future generations! Most of these links have come from SharePoint 2010, so if you want them to work in differing versions just add a 14, 15 or 16 after the layouts folder to work in 2010, 2013, 2016 or SharePoint Online.
(this post was written using a SharePoint 2010 environment)
A while ago I was trying to find a way of getting a list of all user profiles that didn’t have a profile picture uploaded. I searched around online a bit and could only find examples that involved writing PowerShell which I thought was way to complicated a thing to do!
So this post will show how you can easily export user profile data from SharePoint, apply some excel filters to find all users without a profile picture.
This method applies to all on-premises versions of SharePoint, but also will work for SharePoint Online.
Get user profile data
To get started, open the Excel desktop app
Press Get Data > From Other Sources > SharePoint List
Enter the root site collection URL for your SharePoint environment
This will open a navigator window, which will display all the available lists within the root site collection.
Scroll down until you find the UserInformationList
Click on it and a preview will load, scroll across the preview and make sure you can see the Picture column
NOTE: at first I was using the Get Data > From Web option but that only brought back the first 30 rows from the UserInformationList.
I didn’t want to increase the view limit as there are thousands of rows to display but I found that the way described doesn’t have that issue.
Now this will take a little while to download all the rows if you have a fair few users, but you’ll see when its finished in the right-hand Queries and Connections pane as it shows you the number of rows downloaded once complete.
Filter your data
The first thing to note about this data is that it does also contain some stuff you wont need. With my list data I noted that I had SharePoint security and domain groups, service accounts and other general use/ non-user accounts listed. Here are some of the filters and logic I applied:
Filter the Picture column to only show blanks
Filter the Content Type column to only show Person
Or filter the ContentTypeID to only show the corresponding Person content type ID
Filter SIPAddress to only show rows with an organisational email address
That’s all there is to it, a pretty quick and super easy way to get a list of all user profiles without a picture 🙂
Recently I came across an issue with a SharePoint 2010 publishing site. The site had a page on it that was being edited and after a series of web parts were added, crashed and would no longer load. An additional issue here was that there wasn’t another, recent version of the page to restore to.
So, in the steps below detail how I was able to access the page using web part maintenance mode and delete the problem web part:
Navigate to the problem page’s URL
At the end of the URL add ?contents=1
This will then open the problem page up in web part maintenance mode. From here you are able to close, restore defaults or delete web parts from your page
NOTE: make sure you page is checked out before trying this else you won’t be able to make any changes.
Select the web part(s) which you think are causing the issue
Now select to either close, reset or delete the web part. I chose delete
A warning message will appear > press OK
When writing this post I wondered if this method of accessing web part maintenance mode still worked for modern SharePoint – the answer was no! When you try to open a modern page using ?contents=1 you get this:
However, after reading this handy article from Microsoft about maintenance for client-side web parts in SharePoint Online I just switched my query to ?maintenancemode=true and it worked!
Different to the classic example, modern web parts when in maintenance mode show summary, manifest and data tabs with information about each web part.
If you wish to delete a web part from this view you will need to edit the page and delete it from there, then republish like in the example below:
There are loads of URL’s that either I can never remember or haven’t come across that are listed here. However I wanted to keep a list of them on my site just for reference:
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!).
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.
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.
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 🙂
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.
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 🙂
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:
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:
.lock, CON, PRN, AUX, NUL, COM0 – COM9, LPT0 – 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
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:
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:
Carrying on from my last post – creating a data connection, we are now good to go and begin to build our first PowerApp!
Just like setting up the data connection, creating a PowerApp can be a really simple thing to do.
However, I’ve found either creating a PowerApp from the SharePoint list or library is really quick and easy, but it doesn’t necessarily give you the most flexibility when it comes to wanting to do it your own way…
Creating a PowerApp
You can create a PowerApp from a list or library literally from the push of a button! Its as simple as:
Create your list or library, add all the associated columns and data you wish to be displayed in your PowerApp
Press the ‘PowerApps’ button on the list menu, then press ‘Create an app’
You’ll then be prompted to create your app, start by giving it a name and press ‘Create’
After a few moments your app will be created! It will open in the PowerApps web editor and you should see your list columns and data displaying in your shiny new PowerApp!
You can also take a look at the app in the preview to get a good look at how it operates and how the data is displayed…
That’s it! Your all set…but if you’re like me you’ll have some questions. Like, what if I want a desktop app and not a mobile one?
Well for that you’ll need to build an app from scratch, I’ll be going over creating a new PowerApp in the next part of this series so hold on as i’ll be posted the next part very soon!
Continuing on from my previous post – setting up the default gateway, we should now be in a position to create a new data connection within PowerApps. On the surface this is pretty easy to do, all that’s needed is to choose the connection type – press create – authenticate – job done!
However, when we need to create a data connection for an on premise SharePoint environment, its a little bit of a different story. Here are the steps involved for setting up a new data connection for a SharePoint on premise environment:
In the search bar, search for “SharePoint” – press the plus icon
The SharePoint data connection popup box should appear, under “how do you want to connect to your data?” select Connect using on-premises data gateway
Set the authentication type to Windows and then specify your username and password (you may need to include a domain name as part of the username)
I used credentials of a user that had owner permissions for the SharePoint environment I connected to, it makes sense to me that the account you specify here would at the very least need to be able to read/write to the SharePoint list that acts as the data source.
Choose the gateway we set up in part 1 of this series, if you can’t see it you might need to install it again or refresh the list until it displays.
I actually had to create the default gateway using a different account than the one I created my first PowerApp with, so it wouldn’t show for me initially. I had to share the gateway I created and set my PowerApps user as an admin for it to show in this list.
You will now see your newly created data connection appearing in the connections list! Your able to edit and delete the data connection at any point and can also check who the owner is, the connection name and crucially the status of the connection under the details button.
There is also this article from Microsoft talking through connecting to SharePoint from PowerApps that lists the known issues with certain column types: