If you’re wanting to add an Asset Library to your SharePoint site but not finding it available as an option, chances are the Video and Rich Media feature for that site collection isn’t activated. This feature enables the asset library which is basically a modified document library but with metadata specific to rich media that can be auto-extracted such as width and height of images, duration of video clips, etc. Asset libraries are good for storing your audio, video, and image content types.
To enable it (as a site collection admin) go to Settings > Site Settings and choose Site collection features from under the Site Collection Administration heading.
Then scroll down and look for the Video and Rich Media feature. Click Activate.
As the description says, this will “[provide] libraries, content types, and web parts for storing, managing, and viewing rich media assets, like images, sound clips, and videos.” Once activated, you’ll now be able to add the asset library to your site(s) in that collection.
If you’ve created a workflow in SharePoint Designer and an email action appears to be configured correctly, but emails aren’t being sent to some individuals in the To: line, you may need to turn the email being used into a workflow variable and use that instead of direct addition to the To: line of the email step.
This often happens for group email inboxes or external recipients that aren’t just a “normal user.” If there is a mix of recipients, some may receive the message but the troublesome addresses don’t even appear in the To: line, as if they’re removed before sending.
In this post I’ll cover two symptoms commonly seen when subsites evolve from inheriting permissions (using existing groups) to being given unique permissions (having their own groups at the site’s level).
A site owner with full control gets “Sorry, this site hasn’t been shared with you” when trying to approve access requests.
When reviewing Access Request Settings, a user or owner sees the message “Members cannot share this site because this site is missing a default members group.”
Chances are the site was never set up with default, unique permissions groups. Perhaps the creator of the site chose to inherit permissions from the parent (using existing groups from a hierarchical level higher than the new site), then later decided to manually build out groups that resemble the traditional visitors, members, and owners groups at the new site’s level. Or perhaps the default groups were deleted. Either way, the following solution should set it straight:
We need to either officially designate or build new default groups for the site, using the same dialog you see when creating a new site. Since we can’t “reconfigure” the site with a wizard, we need to manipulate the site’s URL a bit to get to the configuration screen we’re looking for.
Add “_layouts/15/permsetup.aspx” to the end of the site URL. For example, it may resemble sharepoint.contoso.com/sites/ABC/EA/_layouts/15/permsetup.aspx. This takes you to the permissions setup page.
IF YOU HAVE GROUPS YOU WANT TO SET AS THE DEFAULTS
Perhaps after site creation, you created groups intended to be used like the visitors, members, and owners groups. Go to your site’s _layouts/15/permsetup.aspx page and simply:
Leave “Use an existing group” selected, and change the dropdown for each to the groups that were created and intended to be the new defaults. Click OK when finished. This will make them “official.”
IF YOU DON’T HAVE GROUPS YOU WANT TO SET AS DEFAULT
Change “Use an existing group” to “Create a new group” for at least the Members and Owners options. Here you can add the appropriate persons to each group, or add them at a later time via Site Settings > Site Permissions. Be sure to add your owners (approvers/permissions managers) to the new owner group.
The “Save site as template” action is not supported on this site.
This error is just referring to a site property known as SaveSiteAsTemplateEnabled currently set to false.
This can be remedied (property changed to true) with a little bit of PowerShell ran on a SharePoint server. Run PowerShell as an administrator then run the following script, replacing the site URL with your own site or subsite’s URL.
Once it completes, attempt to save the site as template again. You should now be able to proceed with saving the SharePoint site as template, and see the fields shown below:
Note that if a user activates the site collection feature SharePoint Server Publishing Infrastructure or the site feature SharePoint Server Publishing, you’ll need to run the PowerShell command again because activating those features includes disabling the SaveSiteAsTemplateEnabled property.
As with most errors, there’s no single cause when it comes to “The server was unable to save the form at this time. Please try again.”
However, if the error is occurring for random/specific users and not everyone in your organization it’s most often just a permissions mismatch. If my solution below doesn’t solve your issue, scroll down further for other potential causes.
Make sure users granted library/list-specific permissions also have read access to the hosting site.
I see this error most often when a user is granted permissions to contribute to a SharePoint list or library, but doesn’t have any permissions at the site level. In other words, someone isn’t a member (edit) or visitor (read) of the site hosting a list or library to which they’ve been granted permissions.
The simplest fix is to create a new permissions group at the site level and give it read access to the site but edit or contribute permissions to the list/library. Or if you’re already putting users in a SharePoint permissions group to edit the specific list/library, just grant that same group read permissions at the site level.
For example, if you need to create a new group:
Go to site settings > site permissions.
Click Create Group.
Name it, then be sure to select “Read” from the checkbox selection at the bottom.
Add members (the individuals to whom you’d been granting access to the list/library who are getting the error).
Go to the list or library settings > permissions for the list/library.
Grant permissions > Add the new group and select contribute (or whichever level you’d been granting the individual users).
Or if you’re already putting users in a group for the list permissions, just go to site settings > site permissions and add that same group with read permissions.
One of the best perks of upgrading to SharePoint Server 2019 from previous versions is the introduction of the modern/new list, library, and page experience. Modern web parts and layouts become available, lists look sleek and closer to what users are seeing in O365 in hybrid environments, etc.
It recently came to my attention, however, that the new list experience in picture and document libraries doesn’t render image thumbnails. According to Mike Lee in this thread, thumbnails in the modern/new experience rely on a cloud-based microservice that is incompatible with SharePoint 2019. Users, instead, just see image icons where thumbnails should be:
The only workaround in SharePoint 2019 to see image thumbnails in picture and document libraries is to revert to the classic experience. Each user can do this for themselves if we leave the default experience setting, but we want to force all users to use classic and not have the choice of using modern if we want them to see thumbnails.
I had an issue come up today where a user wanted to search a SharePoint list by the default ID column.
Problem: The ID column cannot be indexed and is not searchable using just the ID number itself.
Solution: You can still search ID numbers in lists if you include the proper Keyword Query Language (KQL) syntax. Format your search as ListItemID:3 (replacing 3 with your own ID number, of course) and it will work.
And yes, this works in both modern and classic list search experiences and in SharePoint Server and SharePoint Online/O365.
Once in a while, you’ll want to use the survey web part for one reason or another. There are awesome tools like Yammer polls, Microsoft Forms, etc. but sometimes the only tool suitable for a specific use case is still the out-of-the-box SharePoint survey app.
If you search for it when adding a new app and get “We didn’t find a match here, but check out…” don’t fret. It’s tied to a site feature that apparently isn’t activate on your site. This applies to both on-prem and online/O365 environments.
To get the survey app as an option on your site, you’ll need to be a site owner who can activate the Team Collaboration Lists site feature (settings wheel > Site settings > Manage site features).
Once you activate it, your site will now be able to add these apps:
…and much more
Here’s a quick GIF demonstrating activation of the required feature:
I’m late to the game trying out PerformancePoint Services, a has-been dashboard and KPI service for SharePoint server that still exists in production for many on-prem farms running 2013/2016/2019. I’d venture to guess most would prefer the more modern and flexible Power BI (either Report Server or the online service via O365) to PerformancePoint Services but, alas, change takes time.
So, anyway, when I tried to open Dashboard Designer on a PerformancePoint list for the first time, I received the following error.
Cannot Start Application
Cannot download the application. The application is missing required files. Contact application vendor for assistance.
I had tried to open Dashboard Designer using Chrome and CrEdge (Chromium Edge) without luck. The downloaded designer.application file just gave me the issue seen above.
In the end I found, as with most dated tools and functions in the SharePoint world, some things only work in Internet Explorer (IE). This particular button, however, worked in both IE and Edge!
So copy your list’s URL, move over to Edge or IE, and try to launch it again from there. This worked well for me. Good luck!
Today I ran across an issue where someone had created links within a classic document library that redirected users to documents stored in a different library. This is easy to do, but for some reason those links were now leading users to blank .aspx pages instead of the intended document.
Note that users weren’t taken to an “invalid” or “can’t be found” error page, but a completely blank page with a URL ending in .aspx. If you’re being redirected to anything other than a blank page the following solution probably won’t apply to you.
I figured out that, somehow, the library in question no longer had the “Link to a document” content type included. You normally can’t delete a content type that is in use, but with the right permissions and perhaps a migration tool or script, anything is possible. Without the content type on the library, the links that once worked under that content type now could not.
Important: The links are not necessarily broken – do not delete them. Once the content type is added again, they should work unless the original URLs have actually changed.
To re-add the link/shortcut content type to the library, follow these directions (same as if you were adding it for the first time):
1. Go to Library > Library Settings
2. Choose Advanced settings
3. Set Allow management of content types to Yes.
4. Click OK to save changes.
5. Under Content Types choose Add from existing site content types