SharePoint 2013 Document Libraries Missing View Selectors and Search Box after Content Database Upgrade
This is probably the most major problem we ran into during our upgrade from SharePoint 2007 to SharePoint 2013 using the Content Database Attach method. We spent a great deal of time trying to understand this problem and why it was so intermittent and I am glad we found a resolution and the problem is behind us now.
At the top of a SharePoint 2013 document library, you will see a view selector and a search box (“Find a file”):
We noticed this whole section was missing from most of our document libraries after the upgrade:
If we deleted the web part and added it back again all the functionality returned. After we spent a great deal of time with Microsoft, they eventually pointed us to the following MSDN Gallery page written by Christopher Buchholz called “Copy or Replace List Views” (http://gallery.technet.microsoft.com/office/Copy-or-Replace-List-Views-91178033). Unfortunately the script provided by Christopher did not work as supplied because it was built with some dependencies on some custom functions he wrote that were not supplied.
As you can see, the first paragraph of the page reads:
You may find the need to mass-update list views, especially after performing a migration to SharePoint 2013. This set of functions will search and replace document library views for any web or site collection, or let you override and replace views for a specific list.
This described our symptom exactly!
I modified the script slightly to make it run in any environment. The script is available to download here: http://1drv.ms/1hPPgcE
One you have the script downloaded, you can execute the following commands to loop through all your web applications and fix all the views that have this problem:
Get-SPWebApplication | Fix-SPWebApplication #-verbose uncomment for verbose
Public Service Announcements
The original script essentially converted Personal views to Public views. My script has been modified to just log personal views as it is running. If the users want the functionality back, you can have them delete their personal view and simply create a new one.
This process will completely change your view ID’s. For the average environment this probably will not be an issue but if anyone is using a link that contains the old view ID, those links will not work properly.
When does the view ID become part of the URL?
If you navigate to a document library and then click on a folder within that document library, take note of the URL. It will look something similar to this:
Since the link is referring to the View in the query string it will try load that view when the user clicks on it. If it cannot find the view, it simply redirects to the root library.