Exclude Specific Content from SharePoint Search Results

This is a quick one, and I’m only posting because it took me a while to find the answer with my Binglage. It’s one of those things I know I can do, but I forget the syntax.

Image from pixabay

Most of the answers I found for this involved going into settings (or running Powershell or writing code – overkill!) to exclude content from results semi-permanently. That’s not what I want in this case.

Say you want to search SharePoint for a specific phrase. In my case today, we want to change the name of the Intranet, so I was searching for the old Intranet name. This would give me the places where documents or pages contained the old Intranet name so I could change it in the content.

When I simply searched for “Old Intranet Name” in Everything, I was getting back a whole lot of documents we put together as we were building the Intranet. The phrase in those documents was irrelevant, so I really wanted to exclude those documents from my search results.

The trick is to exclude the specific path (or any other useful attribute value) so that I reduce the result set down to what I really want. It works basically the same way most search engines do; if you put a value after a dash character, content with that value will be excluded from the results.

The trick is that you need to know what the specific attribute – which in SharePoint is a Managed Property – you need to use for the exclusion to work correctly. In this case, I wanted to exclude an entire path, meaning any document which lived at that URL or below.

While I’m working in SharePoint Online today, this works going all the way back to SharePoint 2007, I believe.

Good search skills are critical in today’s world, so knowing how to exclude content is just as important as including it.


It so happens that Brian Jackett (@BrianTJackett) just tweeted something analogous, so here’s a good reference that shows more possible options.

Reference

Advertisements

Wherein I Profess My Love for Document Sets, My Hatred of the 5000 Item Limit, and Some Tips

I love Document Sets. There, I’ve said it. They help us solve so many important business needs, it’s crazy. Unfortunately, because telemetry tells Microsoft that not very many people use Document Sets, they haven’t gotten any love for a long time. On the other hand, I hate the 5000 item limit in lists and libraries because they prevent us from getting good work done for our end users.

With Document Sets, we essentially get folders on steroids. We have a canvas available to us in the form of the Welcome page, which is a Web Part Page we can customize to our heart’s content. That means we an add images, other Web Parts, script (using a CEWP or SEWP), whatever we need in order to make the Document Set sing for our users. We can even push specific metadata from the Document Set level down into the documents within it.

While on the one hand it’s great that Microsoft hasn’t given them any love for a long time (they haven’t broken anything), it will be great when they eventually get the “modern” sheen. (See my comment about not breaking anything – that’s key if the “modern” version is to get any use.)

Today’s episode comes courtesy of one of my clients where we’re using Document Sets to the max in SharePoint Online. It’s a life sciences R&D operation, and we’re tracking most of their significant research data in Document Sets, among other mechanisms. It’s a really cool project, and I often wish I could show more of what we’re doing.

When we first built one of the main libraries using Document Sets as the basis (with 14 different Content Type variants inheriting from Document Set and each other), we talked about how many items would ever be in the library. At the time, 5000 seemed like a huge and distant number. Even so, I added some indices to hedge against it, but clearly not enough indices. It’s been over two years using this system, and we’ve done a bunch of development on top that we couldn’t have predicted originally.

Recently, a couple of things stopped working the way they should. Even though we never expected to, we recently went over the 5000 item limit in the Document Library – 5099 is the current count. Here are summaries of the issues and how we fixed them. The ever wonderful and talented Julie Turner (@jfj1997) came to my rescue on some of it, as you’ll see.

Adjusting the Indices While Over 5000 Items

This has historically been a HUGE problem. Once you cross the 5000 item limit and actually NEED indices on some of your columns, you haven’t been able to create them. When you tried to do so, you’d get an error telling you that you had more than 5000 items, so you couldn’t add an index. Helpful. Off to Sharegate to move some content out, fix the indices,then Sharegate the content back in.

In our Document Set instances, we were getting some errors where we were making REST calls to retrieve items related to the current one. (The Document Sets connect together in pathways of experiments, and we store the ParentID for each item’s parent Document Set.) The REST call would only retrieve one item from the library, since there was a filter:

Unfortunately, ParentID wasn’t indexed, so we were getting 500 errors back from our REST calls. Sigh. I assumed I’d need to shuffle some content out to add the index.

Just on the off chance, I went to add the index anyway, even though we were over the 5000 item. Never hurts to try, right?

Miracle of miracles, I was able to add the index without SharePoint batting an eye. I haven’t had a chance to test this elsewhere, but in this tenant I was able to do what previously was impossible.

If this is indeed the new normal, our lives have indeed gotten a lot easier.

We can add indices to lists and libraries with over 5000 items!

In any case, it solved my immediate problem. Maybe I shouldn’t talk about it so loudly near the tenant in case it changes its mind.

Fixed the broken default view

No one – and I mean no one – likes to see this message on a SharePoint page:

This view cannot be displayed because it exceeds the list view threshold (5000 items) enforced by the administrator.

 

To view items, try selecting another view or creating a new view. If you do not have sufficient permissions to create views for this list, ask your administrator to modify the view so that it conforms to the list view threshold.

We were seeing this horrible messaged in the List View Web Part at the bottom of the Welcome Pages. Since I have code running in the page, I wasn’t 100% sure that it wasn’t my fault.

Since the List View Web Part is only showing documents for this Document Set, it should only want to show a handful for each Document Set; nowhere near 5000. I was starting to think the Document Set was fundamentally broken by design.

Luckily, Julie was online and I asked her to take a look. She had the answer, and probably saved me hours trying to figure out why this was happening.

Her suggestion was to make sure the view doesn’t have “Show all items without folders” set to true. Sure enough, when I checked the view we were using for the Document Sets List View Web Parts, that was the setting. Julie pointed me to the article Manage large lists and libraries in SharePoint, specifically:

If you choose the Show all items without folders option in the Folders section when you create or modify a view in this list or library, you must then use a filter that is based on a simple index to ensure you don’t reach the List View Threshold.

Aha! For whatever reason over the years, we had set that very setting, and that was the problem. By turning that off, everything was right as rain again.

Document Sets Can Have Unique Views

This leads me to a little known thing about Document Sets: we can have a different view at the root of the library than inside the Document Sets. In fact, since you can inherit from Document Sets, you can have a different view per Document Set-based Content Type!

In fact, I was just reminded this yesterday from reading a post from Cameron Dwyer. Sure, it’s a setting on the Document Set settings page, but frankly, I’ve rarely noticed it.

The setting isn’t visible in the Document Set settings page when you create the Content Type, because you aren’t yet in the context of a list. Once you have enabled the Content Type on a list, you’ll see the additional settings.

Here’s the bottom of the Document Set settings in the Content Type definition:


and here’s the bottom of the page in a list context:

Note that the options are slightly different. In the list context we can choose a unique view for the Document Set-based Content Type. That means in my library, I could have 14 different views of the Document Set contents, one per Content Type, should I choose to do so.

Summary

Document sets are awesome. The 5000 item limit is not.

References

Want to Get a Look at the New Communication Sites? Here’s a Trick!

If you’re like me, words can be confusing. When Andy Haon (@AndyHaon) tweeted that Communication sites were starting to roll out, I wanted to get a look. However, I didn’t see the option in my First Release tenant. I wondered what “Select Users” meant and whether I wasn’t one somehow.

Luckily for me, Twitter is really useful for stuff like this. Rick de Vries (@RickdeVries) pointed out that there a two “flavors” of First Release – First release for everyone and First release for selected users.

By switching my tenant so that Julie (@jfj1997) and I are “selected users” instead of just having the tenant-wide setting, we can now see the option to create Communication sites.

Here’s how you do this, assuming you have administrative permissions.

Got to the Admin center and click on Settings / Organizational profile / Release preferences. There you’ll see the two different First Release options:

For more information, check out Set up the Standard or First Release options in Office 365. I couldn’t figure out how to get the UI to add individual users to work, so I ended up uploading a csv file with our two email addresses. #YMMV Note that it took at least a few hours (possibly overnight) for me to see the Communication site option.

Et voila! We can now create Communication sites from the SharePoint home page.

Beware the Office 365 Group -Based Site Regional Settings!!!

This is a quick post, yet it’s still an important one. We’re using more and more Office 365 Group -based SharePoint sites these days. Even when you know you aren’t going to use some of the goodies you end up with, this type of site is making more and more sense.

<addendum data-datetime=”Sun May 14 2017 10:56:53 GMT-0400 (Eastern Daylight Time)”>
Several people have asked me in other forums the basic question: “So what?” If all dates and times are stored in UTC, does it really matter what the site’s Regional Settings are? Frankly, that’s got me a little bit stumped.

It certainly feels wrong that the site’s settings don’t match its primary locus, but since team members can span the globe, what’s the impact?

I know I struggle as a developer to show everyone things in the right date/time based on their settings, and it feels like the platform doesn’t give us great tools for this. What other issues does it raise? Please add your thoughts and issues in the comments. I’m interested in things other than the usual “The people in Redmond don’t realize that we’re not all in their timezone” stuff – which is basically all I’ve pointed out here.
</addendum>

BUT, there’s a simple problem that can have longer-term ramifications. The default time zone for every new Group-based site we create is PDT, also known as UTC-08:00. You have to go into Site Settings to change it manually for every site you create this way. Since a lot of my clients are in EDT, this is tedious.

I’m guessing no one in Redmond even notices this, because PDT is their time zone. I spot it every time I create a new Group-based site during a migration because Sharegate warns me the time zones of the source and destination sites are different when I start to copy content across. (Yay, Sharegate!)

If you happen to be a non-US person, then ALL of the regional settings are likely to be wrong for you. I’ve checked, and there is no way to change the default here – unless it’s a VERY recent change.

Here are some Office 365 UserVoice suggestions you can run off to vote for:

 

Dear Microsoft: Confusing Failures in “Modern” SharePoint Libraries

Moving documents around in the “modern” Document Libraries in SharePoint Online (Office 365) has certainly gotten easier. Instead of opening libraries in File Explorer, downloading the files, and then uploading them into the new location, we have nice options like Move to, Copy To, and Rename right in the toolbar. That’s a big upside.

Sadly, there are downsides. While the new capabilities are awesome, I’m finding that the UI is often confusing – both to me and my clients.

When you use one of these new file manipulation capabilities, you get a little feedback message ion the right side of the toolbar telling you how it went. Unfortunately, the message location isn’t all that obvious, and it usually feels as though the operation succeeded even when it didn’t.

Here’s and example of a Move to operation that failed for me. Note that the message says “1 item wasn’t moved”.

There’s no other feedback, and on my wide monitor, the message is way over to the right side. I don’t usually notice it.

In the case above, I did see the message, so I clicked on the message to see what was up. The reason I saw it was that I was looking for something wrong. A client of mine told me that a Move to wasn’t working. Every time she went back to the library, the documents were still in the same place, no matter how many times she moved them.

As you can see from the expanded message below, there was indeed an issue: there was a file with the same name in the destination location. I have two logical options, either to Keep both files or Replace the original.

 

The message really isn’t obvious enough, and I’ve been caught many times because I didn’t see that something I did failed. Even worse, to my client “SharePoint is broken”. I’m hoping the Product Group can come up with a more informative way to provide the feedback that something has gone wrong – which happens surprisingly often!

There is yet another “unfortunately” here, though. In my client’s case, even when there is no error in a Move to operation, the files are boomeranging right back into the original position after a few screen refreshes.

I also tried the Content and Structure page to see if moving the document that way would help, but still no dice. I checked to see if perhaps there was a workflow in play here causing issues, but that’s not the case. The only other thing I see which MIGHT be a problem is that the library has 4988 documents in it, which is pretty close to the 5000 list view threshold. I hate that threshold with a steaming passion (have I mentioned that here and here and  here and here and here and probably tens of dozens of other places?), but I can’t think why it would matter in this case.

So we’re at an impasse. The error messages aren’t so great, and the Move to operations are failing when there aren’t errors. Maybe SharePoint really is broken.

Anybody? Anybody?