Now that we’ve spent a couple blogs evangelizing the use of metadata in a document library, let’s reverse course. Today I’m going to focus on Explorer view. This has been something SharePoint has had for a few iterations now (at least SharePoint 2010, probably 2007). But it surprises me how infrequently it’s used. There are some caveats, which I’ll cover in this blog, but there are some very distinct advantages. Using it in the right circumstance can save you hours of waiting and frustrating.
What is Explorer View?
Explorer View allows you to open a SharePoint document library in Windows Explorer. It uses WebDav (which has its own limitations) but it allows you to move files to and from the library as if it were a local folder. The obvious advantage is being able to download and upload multiple files in a single shot.
How to Use Explorer View
In older versions of SharePoint, there was an option in the ribbon bar called Open with Explorer. Simply click on the button when using Internet Explorer and the document library opens in a Windows Explorer window.
In Office 365, the option is available from the Document Library menu.
When you click View in File Explorer SharePoint opens a new tab with the traditional view of a document library. From there, you click Open with Explorer.
After you click the correct option, Explorer opens with the view into your document library.
Now you can copy and paste as if the library were a local folder.
Good Times to Use Explorer View
Starting a New Library
You may have occasion to create a new library in order to store a series of documents. You can, of course, create the library, add the columns (metadata) to the library, and then upload the documents one-at-a-time, completing the metadata as the documents are uploaded.
But using Explorer View and Datasheet View will save you time and frustrating. Here is the approach I would recommend:
- Create new library
- Add metadata columns to the library. DO NOT MAKE ANY OF THE FIELDS REQUIRED at this point. If you do so, it may muck up the process because SharePoint will want the required fields populated when saving the document.
- Create a view that contains all the metadata columns you want populated.
- Access Explorer View.
- Copy and paste all the documents into the library.
- Return to the library and use Datasheet View for the view you created.
- Populate metadata for the documents you just uploaded.
- If necessary, in the Document Library settings, mark those columns you want required as Required.
- The library is now current and ready for new documents!
Downloading Multiple Files from the Library
I’ve used – and still use – too many versions of SharePoint. It’s hard for me to remember which version can do what. You may need to download local copies of multiple documents in a library. It seems as if you should be able to select all the files you want and click download. This definitely doesn’t work in older versions of SharePoint. The last time I tried in Office 365, the documents download as a zip file… and even then I thought the process was clunky.
Regardless of the version of SharePoint I’m currently using, Explorer View has always worked for me.
Simply open the library in Explorer view, and use standard Shift-click or Ctrl-click to highlight the desired files, and copy them to my local machine. Easy.
Saving Files when Folders are Necessary
What? I just spent some time the past few weeks detailing why folders are an unnecessary evil of SharePoint libraries and encouraged all of you to use metadata instead. However, there are occasions when folders are necessary.
I use it when creating online curriculum that I want to save in SharePoint. The HTML 5 files produced by Adobe Captivate contain a standard index.html file and then a series of folders.
Of course, I could recreate this structure in SharePoint manually. I’d have to create folders, upload each document to the correct folder, and if there’s subfolders within the folder, repeat the process. It’s much easier to do it all with a quick copy and paste.
So I simply navigate to the library where I want the files stored. I open the folder in Explorer View. And then I just copy and paste the entire output of Captivate to the library (after changing the json references… but that’s for another blog).
After waiting a bit, the files are uploaded with the correct foldering structure, and the curriculum is ready for view. A user just has to access the index.html file.
When Not to Use Explorer View
If you want a previous version of a document, do not use Explorer View. Explorer View displays the most recent version.
If you need the metadata Explorer View will not work. If you need to move a series of documents from one library to another, it may seem the best way is to open both libraries in Explorer View and just pop the documents from one window to the other. However, if you do this, the metadata will not be in the new library. This can cause problems if you are actually CUTTING and PASTING. If you go this route, not only will the new library NOT contain the metadata, but because you actually moved the documents, the metadata will not be in the old library. It’s just lost.
Big files. WebDav’s limitation is 47.7 MB. I usually try to stay below 45 MB as a general rule. This holds true regardless of the maximum upload setting in SharePoint. The limitation is not SharePoint’s, it’s the WebDav technology. This maximum size is per file, not per bulk process. So if you have 100 documents that are each 1 MB, you are save to use Explorer View. If you have 1 document that’s 50 MB, don’t even try. It will bomb out.
Using Explorer View can make your SharePoint life easier, especially when working with multiple documents. But you need to use it judiciously. There are occasions when it may cause more harm than good. But if used wisely in the right circumstance, it can spare you hours of frustration.
So far in this series we have covered a few of the tools a SharePoint administrator must master in IIS Logs, ULS Logs, and ULSViewer. Another that tool that every SharePoint administrator absolutely has to master is PowerShell. Every Microsoft application platform these days has a PowerShell API, including the cloud applications. To truly set yourself apart as an automation-focused administrator you need to learn PowerShell. In this article we will cover the basics of SharePoint PowerShell. We’ll also touch on some ideas on how you can put it to work for you.
Getting Started: Permissions
First things first. In order to run PowerShell commands against SharePoint (object model and databases) you are going to need the permissions to do so. You are going to need to be a farm administrator and have your account added to the SP Shell Admin group on the databases. Actually your account can be granted object model and limited content database access if you do not need full farm access. This is done using the “-Database” parameter of the Add-SPShellAdmin cmdlet. For our purposes we are going to ensure your account has full access to everything.
There are a couple different PowerShell IDE’s that are available as part of Windows Server and the SharePoint installation where you can author and run PowerShell scripts. These are PowerShell ISE (integrated scripting environment) and the SharePoint Management Shell. You can find these by searching form the Windows Server start menu. ISE is better suited for writing longer reusable scripts where the SP Management Shell is good for quick commands. Another very good options is Visual Studio Code which is more powerful than ISE, but we won’t cover that here. It requires a separate install and is free from Microsoft’s website.
The SharePoint Management Shell is just a PowerShell console window with the SharePoint module pre-loaded for you. The SharePoint Module is the SharePoint PowerShell API that contains hundreds of cmdlets specifically for SharePoint. If you prefer ISE then you’ll need to add “Add-PSSnapin Microsoft.SharePoint.Powershell” as the first line of your file to gain access to the SharePoint cmdlets.
Adding User Accounts
If you open the SharePoint Management shell and you see an error that the local farm is not accessible, then your account has not yet been added using the Add-SPShellAdmin cmdlet.
To add this user account to the SP Shell Access role you’ll need to run:
Note the account you’re using to run this command will need to have DB_Owner on the target database. In this case the SharePoint configuration database. This also adds the user account to the WSS_Admin_WPG local groups on each farm SharePoint server.
Checking Brett’s SQL permissions we see that he was added as a login in SQL Server. He was also added to the SP Shell Access and SPDataReader roles on the configuration database.
We have not added Brett’s access to our content databases yet, so he will not be able to run PowerShell commands against sites in those content databases. We only have one content DB in our farm named WSS_Content_usclouddemo1604.uscloud.com. Running specific commands against the site content will result in access denied errors to the content database.
To grant Brett access we’ll need to run the same Add-SPShellAdmin command but specify the database name as a parameter. We have to use the Get-SPContentDatabase cmdlet inside of parentheses because the –Database parameter requires a specific SPContentDatabase object type to be passed into it.
Now Brett has been granted Shell Admin Access on the configuration database and our content database. He can now run PowerShell commands that interact with those databases behind the scenes. If Brett is going to need to run PowerShell against specific service applications like search or user profile, he will need additional Administrative rights to those service applications and their databases.
There is a wealth of information from here online about the available SharePoint PowerShell commands. Check out this API reference. The above should get you the basic access you need to get started playing with SharePoint using PowerShell.