PowerShell can be very useful to quickly write up a script when you need to say update a field value for items in a list.
But what happens if your list happens to have 100,000+ items? Doing SPList.Items is going to get throttled.
And while PowerShell doesn’t have an equivalent for the ContentIterator class (which can iterate through large data sets while avoiding throwing a SPQueryThrottledException), we can run custom code through PowerShell that utilizes ContentIterator.
The script below does a simple field update for items of a specific content type in a list.
When trying to delete a site column, you may get the error “Site columns which are included in content types cannot be deleted. Remove all references to this site column prior to deleting it.”
This simply means that the site column needs to be manually deleted from content types before it can be properly removed.
You may have already manually done so on all content types you know of that refers to the site column, but the error still persists.
This is because it not only needs to be deleted from content types on the site collection level, but on all site level content types as well!
Had an issue at a client SharePoint environment where all SharePoint sites stopped working one day, with the error Cannot connect to the configuration database.
Server architecture documentation was a few years old, and didn’t have the current SQL server name. Can’t get it through Central Administration or psconfig either because they can’t open when they can’t connect to the Config DB.
So how do you find the connection string that SharePoint uses to connect to the Config DB?
It’s in the registry 🙂
This issue is similar to the problem reported at https://social.technet.microsoft.com/Forums/office/en-US/50001a2f-bf80-44fb-b8c9-4835cc15b7f6/problem-with-metadata-navigation-key-filters-and-grouped-views.
The error happens when you’ve enabled the Metadata Navigation and Filtering feature, and configured a list with Metadata filters, and has a list view that is grouped by a column:
- If the Group By is set to Collapsed by default, then when you apply a Metadata Filter and expand a group, it brings back all items instead of filtered results.
- If the Group By is set to Expanded, applying a Metadata Filter works fine, until you go to the next page, and again all items are returned instead of filtered results.
While Microsoft released a fix for this in the SharePoint 2013 July 2014 CU, it seems that there is still 1 edge case where this error is happening:
- The Group By column you’re using is a Lookup field
As of March 2017, it seems to be happening in SharePoint Online as well.
The Content and Structure page in SharePoint (aka Site Manager) has useful reports that allow you query for items in your site collection, such as the Checked Out To Me report that brings back a list of all documents currently checked out to the user.
All the reports run recursively, meaning it brings back results from your currently selected site and all its sub sites and lists/libraries.
However, one of the most common issues around is that the report is not bringing back results recursively from its child locations, or it used to do it but has suddenly stopped. And the only way to get the results is going into the same level at which the items are at (in the list/library itself, or even in the folder the item is in) to be able to show up in the report. Not as useful anymore…
Why does this happen?
Using Managed Navigation is a nice alternative to Structural Navigation, for when you want to have more control over how the navigation links are built, or when building sites and pages with friendly URLs as opposed to the more structured site based URLs.
However, it is not without its problems, some of which are quite obtuse. I’ll outline in this post how Managed Navigation can be set up as well as what some of its idiosyncrasies are that I’ve found while working with it.
Recently we were trying to update our company’s SharePoint Online intranet’s top navigation into displaying as a mega menu. As part of the change, there was also a need to clean up the links currently being displayed to be more usable to the staff users.
Because the current top navigation was using Structural Navigation, and we weren’t prepared to overhaul the entire site structure to accommodate the new navigation’s information architecture, we decided to switch to using Managed Navigation, and use a Navigation term set to define the links.
However, by default, new pages created under Managed Navigation will be added to the navigation automatically, and will be using Friendly URLs. This is set in the Navigation Settings for each site.
Because we’re trying to keep the structure of the top navigation controlled, and because the users are used to fully structured URLs as opposed to having friendly URLs, we would want both those options switched off across all our sub sites.
EDIT (2/02/2017): Added ability to specify the name of the navigation term set to connect to for Managed Navigation.
The PowerShell script below achieves that: Continue reading