Posted on

Solution: SharePoint Designer email action’s To: line has a valid email address, but is removed and doesn’t send when triggered

Photo by Snapwire from Pexels

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.

Note: If you’re sending to external recipients specifically and this post doesn’t solve your problem, check out my other post for additional help: Sending emails via SharePoint Designer workflow to external recipients using Gmail, Yahoo, Hotmail, etc. addresses

To “variablize” an email (this is using a SP 2010 platform workflow type):

1. Set a new workflow variable of type string to the email address(es) that aren’t receiving emails as expected.

Click to enlarge
Click to enlarge
Click to enlarge

2. Now in your email settings, use the “Workflow Lookup for a User” option and select your new variable from “Workflow Variables and Parameters” data source.

Click to enlarge
Click to enlarge
Click to enlarge

3. Publish the changes to your workflow and test.

Posted on

Solution: SharePoint site owner with full control unable to approve access requests; site is missing a default members group

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

Symptoms

  • 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.”

Cause

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:

Solution

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.

Posted on

The “Save site as template” action is not supported on this site solution for SharePoint 2013/2016/2019

My preferred way of creating a new site template from an existing site or subsite is just appending _layouts/15/savetmpl.aspx to the end of the site’s URL. However if saving sites as templates isn’t enabled for the site from which you’re creating a template, you’ll get the following error:

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.

Add-PSSnapin "Microsoft.SharePoint.PowerShell"
$web = Get-SPWeb https://WebApp/sites/SubsiteIfApplicable
$web.AllProperties["SaveSiteAsTemplateEnabled"] = "true"
$web.Update()

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:

Screenshot of a SharePoint site’s “Save as template” form fields.

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.

Posted on

Solution: “The server was unable to save the form at this time. Please try again.” error for individual SharePoint users

Photo by Anna Shvets from Pexels

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.

Solution

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:

  1. Go to site settings > site permissions.
  2. Click Create Group.
  3. Name it, then be sure to select “Read” from the checkbox selection at the bottom.
  4. Add members (the individuals to whom you’d been granting access to the list/library who are getting the error).
  5. Go to the list or library settings > permissions for the list/library.
  6. 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.

Other causes/ideas

Some users also report adding “use remote interfaces” to a read permission level when working with broken permissions to fix this issue. I haven’t had to do this, but my issues so far have only been general lists and don’t involve folders.

Check out these other resources if the above solution doesn’t solve your problem:

Posted on

Image thumbnails not showing in SharePoint Server 2019 modern/new library experience

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.

Go to User Voice and vote for this issue to be resolved, adding support for image thumbnails in SharePoint 2019 modern experience views. In the meantime, here’s how you can change a library’s default experience back to classic:

Set library view to classic experience

1. Go to Library settings (settings wheel in upper right > Library settings).

OR if you’re already viewing classic experience, Library settings is found in the Library ribbon menu.

2. Click Advanced settings.

3. Scroll to the very bottom and for List experience select Classic experience.

4. Click OK.

Now all users will see the classic experience and not have the choice of toggling back to modern where thumbnails cannot be shown.

Posted on

Solution: Searching by ID column in SharePoint list not working

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.

Posted on

Solution: Survey app missing in SharePoint

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:

  • Document library
  • Custom list
  • Tasks
  • Picture library
  • Issue tracking
  • Survey
  • Discussion board
  • …and much more

Here’s a quick GIF demonstrating activation of the required feature:

Click to enlarge
Posted on

Solution: PerformancePoint Dashboard Designer “Cannot download the application…missing required files”

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!

Posted on

Solution: SharePoint document library links/shortcuts to other documents go to a blank .aspx page

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

Click to enlarge


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

6. Select Link to a Document and Add >.

Click to enlarge

7. Click OK.

Now check your links, and they should work!

Posted on

Possible solution: “Sorry, something went wrong. The file is locked for exclusive use by…”

I recently ran into the following error when someone tried to edit a shared Excel file from OneDrive (we’re running SharePoint Server 2016).

“Sorry, something went wrong. The file {address} is locked for exclusive use by {name}.”

Troubleshooting

The user in question, who had it “locked for use,” had the file open in Excel (client, not online) when their computer unexpectedly shut down. This locked others from editing the file. The first few things you should try (stop if one of the steps fixes the issue):

  1. If the user still has it open, have them save and close out. If it really was checked out, check it in with their account.
  2. Make sure the user who has it locked has closed all office apps (Task Manager is a good way to see if anything is running in the background)
  3. Have that user restart their machine used to edit the file in the first place for good measure
  4. You can try waiting a day to see if the lock lifts overnight or after a few hours.

What worked for me

Now that you’ve confirmed the individual who had the file locked can’t really have it open or locked, you can try the solution that worked for me. At the bottom of this post, I’ve listed more ideas I tried that might work for you.

  1. Open the user’s OneDrive in SharePoint Designer (the address may resemble https://mysites.COMPANY.org/personal/USERNAME)
  2. Navigate via “All Files” via the left nav to the file in question. It probably has a padlock icon on it.
  3. Right-click the file name and select “Edit File in Advanced Mode”
  4. Save the file in SharePoint Designer.

I can’t explain why this worked, I know it’s completely illogical, but it worked.

Here’s a thread on SharePoint’s user voice regarding this error.

What might work for you

Here are some things you can try that were not successful for me (but might work for you):

  • I tried copying the file and deleting the original but could not delete it (in browser, PowerShell, or SharePoint Designer)
  • I tried this PowerShell solution and it told me who had it “checked out,” and when it would expire which was helpful, but it was unable to release the lock
    • P.S. I waited for the expiration, but it renewed itself
  • I tried checking it in via browser and SharePoint Designer (because it appeared checked out) but got a message saying it wasn’t
    Click to enlarge
  • From the owner’s OneDrive (where the file was stored/created) I disabled check-out requirement via Site Contents –> Library Settings –> Versioning settings
    Click to enlarge