So I’ve taken a bit of heat from some of my fellow SharePoint geeks over a recent post on how to map a SharePoint library (or site, even) as a network drive. Doing this gives you easy access to your favorite SharePoint content via a familiar interface, the Windows File Explorer.
Many of the responses I’m getting basically boil down to two things:
- If your users want to use File Explorer, then just give them a shared drive; and
- You can’t get the robust functionality of SharePoint if you map it as a network drive.
While these are well-intentioned thoughts, I take issue with whether they’re always true or practical. I’d like to cover the arguments on why File Explorer can be a good solution. The first section covers thoughts on the solution from an IT perspective; the second section covers arguments in favor of drive mapping from a user perspective.
I acknowledge this is a bit of a rant, but I want it to be clear that I don’t offer recommendations to use drive mapping willy-nilly. It absolutely has very good use cases.
From the IT side
Argument against: “You lose SharePoint features”
But how often do you use these? They’re amazing features for sure, but I’m generally not jumping into version history to restore files on a daily basis. If I am, I’m probably SharePointing wrong. Version history is there when you’re in a bind. Alerts are there for when you need to set up notifications, which isn’t all that frequent (they’re meant to be set-it-and-forget-it).
For when you just need to open or edit a file, a mapped drive is way faster and more practical. And when you really need SharePoint features, you go to… SharePoint. If you’ve already trained your users about SharePoint’s benefits, then drive mapping is simply a convenience. And if you haven’t trained them that much, drive mapping greases the skids into a SharePoint world.
Argument against: “You can’t use metadata”
If you’re using File Explorer, you get no benefits of metadata. That’s true. But in many cases, online workspaces don’t use much (if any) custom metadata anyway. Folder structures are still common (if not default). This may not be best practice, but it’s a real-world response by users who have lived with folders for decades. Even the best SharePoint users still employ folders (me included).
But that doesn’t even matter all that much because you can still use metadata. You can have SharePoint auto-tag files with the name of the folder they live in so you can either look at the files in SharePoint using the metadata, or you can see the folder structure in File Explorer.
Sure, you can’t sort, filter, or group your files in File Explorer. But do you do that regularly? You may answer “yes”, but many people will say “not really”. And that’s okay.
Metadata tagging systems and taxonomies are very useful in publishing environments, where files are controlled and catalogued. Most people don’t publish, they collaborate. And taxonomies¾at least in my experience¾don’t work well in workspaces because things change too quickly and users need freedom to organize content easily and quickly; SharePoint metadata has yet to prove useful for either.
I’m not hating on metadata; I love it. But it only works well 1) in places it’s meant to be used and 2) where it’s supported indefinitely by a dedicated owner. Many workspaces do not qualify. They just don’t.
Argument against: “You can use Open with Explorer mode instead”
Yes, but you must do that every time you want to open a library in File Explorer. My users have reported this to be an unnecessary set of steps. It’s also only supported in Internet Explorer and Edge. Chrome and Firefox, which are very popular browsers, don’t offer this button.
Mapping the drive is the equivalent to having the library “favorited” in File Explorer, which avoids the need to keep opening a library¾which you either have to browse to or find in your browser favorites¾and clicking that button.
Look at it from this perspective: it’s at least 4 clicks to get the library opened in File Explorer, and that’s the best-case scenario.
- Open browser (one click if it’s on your task bar, two if it’s on your desktop, more if it’s in Start menu);
- Click favorite (one click if the link to your library is in your favorites bar, two if it’s in a favorites folder);
- Click Ribbon “Library” tab; and
- Click “Open with Explorer”.
Realistically, step 2 will only bring you to the site’s home page, so you’ll have to browse to the library through Site Contents (plus two clicks). If you’re using SharePoint Online, you’ve got to get through that login page, which is another two clicks. We’re talking upwards of ten clicks. In a world where people complain about one extra click.
Once your library is mapped, it’s two clicks: Open File Explorer, then click the drive. Perhaps a request to log in once in a while. Maybe even daily. But for a library you use regularly, saving those other eight clicks can bring some satisfaction.
Argument against: “I can’t trust users to set up the mapping right”
Absolutely true. The mapping setup is slightly technical, but if you follow step-by-step instructions, it should be fine assuming all the hiccups that could occur are avoided first. And after you’ve done it once, repeating the task isn’t hard.
Frankly, I’d be more worried about the company-issued PC, the system itself, or some other technical issue on the back end causing this not to work. Once the IT team figures out what’s wrong, they can document it and provide specific instructions that all users at the organization can use instead.
Argument against: “Just use the One Drive sync client to sync SP data”
The next generation sync client (NGSC) was recently updated to cover both OneDrive for Business and SharePoint Online. And sure, you can do that if you want.
But keep in mind that the content syncs. If you’re low on space on your PC, concerned about bandwidth issues for files you don’t actually need to be downloading, or worried about the time required to download the files, this might be an issue.
Plus you have to deal with conflicts and merges if you make changes offline; I know this is intended functionality, but I just feel queasy about offline editing sometimes.
That said, I still see reports online that the NGSC isn’t working exactly as intended. Even synced files on devices that are connected to the internet are not updating correctly. Also, NGSC only works for SharePoint Online at this point.
Argument against: “You’re stuck using the client app”
When talking about Office files, that’s absolutely true. If you’re accessing files via File Explorer, then Word docs, Excel spreadsheets, PowerPoint presentations, and OneNote notebooks will open in the client application (full-fledged installed version) on your PC rather than Office Online or Office Web Apps (the less complex browser versions of Office).
Because of that, depending on the version of your client app, a user may lose out on some co-authoring functionality.
No argument there. But if a user wants 100% co-authoring and browser editing, that user needs to know to use Office Online, accessible only via the browser. That’s a very simple training aspect that the IT person needs to make clear. Pointing that out is much easier than some of the other training/change management issues that drive mapping helps avoid.
Plus, it really doesn’t hurt to use the client app. It’s just not as slick, fast, or feature-rich when it comes to co-authoring. (But, then again, the client app is more feature-rich in other respects.)
Argument for: content gets moved to SharePoint
Drive mapping is simply a means to an end, which is to access content that’s in SharePoint. The response I heard from many IT folks saying, “Why not just give them shared drives?” misses the point of moving your content to SharePoint: keeping your content all in one place, getting the benefits of search, and, if you don’t have a robust disaster recover or backup/restoration plan for your shared drives, your SharePoint system may have that (it does if you’re using SharePoint Online).
If you drop a file into SharePoint (through the browser or File Explorer), you just got immediate DR. Your end game should be about protected, secure content in a centralized location, not necessarily the user experience nuances. I don’t care so much how users are accessing SharePoint, as long as they’re accessing… SharePoint.
Argument for: user adoption can be easier
If you give people SharePoint and dictate that they must use it the way you intend them to, the change management of that is going to be much more difficult than if you say, “Hey, SharePoint comes with really great features, many of which you won’t use on a daily basis, but they’ll be there when you need them. But for day-to-day operations, you can keep using this File Explorer thing because you’re used to it. Over time, though, I suggest you move more into the browser, especially since if you use another computer or device to access the content, the library(s) won’t be mapped.”
You’re essentially greasing the skids for easier buy-in for the new system and the change from a shared drive-centered environment to a SharePoint-centered environment.
From the user side
File Explorer is a familiar UI
People are comfortable with File Explorer. They know how to get around it. They’ve used it for literally decades now. It provides an easy path toward adoption by making use of a UI they’re already used to. And Microsoft has made improvements to it over the course of the last few versions of Windows.
Drag and drop actually works
The SharePoint Team at Microsoft made some significant improvements with SharePoint 2013 when they introduced drag-and-drop from File Explorer into SharePoint via the browser; things have gotten slightly better with 2016 and Online. But man does it leave you wanting: you can’t upload folders or subfolders, and you can’t move folders around in the browser.
You also can’t drag files from SharePoint in the browser to other SharePoint or non-SharePoint locations. For example, I can’t move/download a file from SharePoint to my Desktop by simply dragging it out of the browser. That would be nice functionality.
SharePoint Online’s modern document library experienced improved upon “Move” and “Copy” functions, which is great if you know where the destination site/library is in the site collection hierarchy. Not great if you need to poke around in a massive SharePoint network to find one measly destination library.
Even still, the easiest way to move a file is to open the source and destination libraries in Explorer mode and do a drag-and-drop from File Explorer to File Explorer. (The downside is you don’t retain version history; the destination library looks at the file as a brand-new file.)
And it’s even easier if these libraries happen to be mapped. Simply open them both in File Explorer and do the drag-and-drop.
Saving and opening files is much simpler
This is probably one of the biggest reasons I suggest drive mapping. Think about when you open a file in a program. Or when you save one. How do you “get” to the SharePoint library?
Sure, Office 2013 and 2016 has done a reasonably good job of making SharePoint a location to save to or open from. But, it’s still not great. When you open a Word doc from SharePoint, you go to SharePoint. Not the site, not the library, but this vague notion of a thing… called SharePoint.
Now, what if you’re saving a PSD file in Photoshop? Or a PDF in Acrobat? To effectively save or open a file, you have to know the address of the library. You have to copy the address to the library¾but only the part of the URL that you need, the rest can cause problems¾paste it in the open/save window, press Enter, wait for the contents to load, then open/save your file.
This is extremely difficult to train users to understand. Like, one of the hardest parts of SharePoint adoption from the very early stages. It’s an unnecessary bump in the road that leaves a really bad taste in users’ mouths.
If the library is mapped as a drive, you have immediate access to open and save your file directly in the open/save Explorer window that pops up. Talk about easier adoption for users.
I don’t promote using only File Explorer to access SharePoint. I use far too many libraries for there to be even enough drive letters to choose from. But I do use between five and ten drive letters at any given time depending on which libraries I use most.
Using the correct functions when I need them allows me to get the best of both worlds. Functionality is different in both arenas. SharePoint in the browser has plenty of drawbacks that File Explorer makes up for. And, of course, vice versa.
My recommendation is to use the UI that makes the most sense for the situation. And frankly, I find that for libraries used commonly, where you perform most day-to-day editing, collaborating, and working can and likely should be accessed via a mapped drive in File Explorer.