The Curious Case of the Missing Documents – How one user fell foul of using “View in Explorer” to move content around in Sharepoint 2013

Maintaining the service we sometimes lose sight of how people interact with Sharepoint, and we know that some users really don’t like Sharepoint 2013’s user interface that much – and prefer to use a combination of WebDAV or “View in Explorer” to manage all their documents and interactions with Sharepoint.

Which is fine…until you start falling into the bad habit of assuming that Sharepoint is “just another file system” and that handy explorer / folder view of your document library behaves exactly like the explorer view of your hard drive or network attached storage.

It doesn’t – and in this particular curious case, a task was raised with us claiming that “Sharepoint ate my content”.

The first place we always look is the second stage recycle bin. If anything was deleted from Sharepoint it would show up in there, regardless of the method used to despatch those documents. Sure enough, the described documents were sitting in the second stage recycle bin – the document library they’d allegedly been scoffed from was indeed empty, no matter how I looked at it.

I sent the task back, recommending that the user restored the items from the second stage bin – and expected to hear no more about it. Strangely enough the ticket “boomeranged” pretty quickly and came back to me, with the user reporting an odd message that on attempting to restore the content, Sharepoint could not comply because “The content is already there”

Curiouser and curioser.

I then assumed that they’d done something like deleted the documents (in explorer view) and the documents were sitting in their local recycle bin on their machine, stuck in limbo between Sharepoint still retaining the database entries for those documents (more on that later) and the documents not actually being visible to anyone, even someone with the highest level of access to Sharepoint.

Of course, at the time had I known a bit more about what the user had done (as with most service desk requests to our service, the user usually won’t tell you how they use the service, you’re supposed to know that automatically) I could’ve guessed what happened.

You see, that business about Sharepoint not being a file system is very true – and it’s also misleading that the Explorer View (or WebDAV view) behaves for the most part like a file system until you start trying to do distinctly non-Sharepoint things with it. Like moving content around.

The user had (though the details are still scarce) obviously set up a couple of explorer views, and started dragging content around willy-nilly within their document library’s folder structure. So as far as Sharepoint was concerned, those documents were being COPIED not moved. The user obviously then deleted the original items from their original location (which is why they showed up in the recycle bin) but of course had also fallen foul of their library’s check in / check out settings. Essentially the documents were stuck in a ‘checked out’ form, and so there were actually two copies – ones that had been deleted but still existed on Sharepoint – hence the error message when trying to restore, and ones that had just been dragged and dropped (without paying attention to the check in requirements) to somewhere else within Sharepoint. So when I looked in the document library I couldn’t see anything – because the documents were actually sitting in the root folder for that library in a checked out state. I was looking in the wrong place, and the user was too!

One quick visit to the library’s settings page and the “Manage Documents Which Have No Checked In Version” menu item revealed the missing documents, sitting there in a checked out state blissfully unaware of the strange chain of events that had just happened. Once the user had taken ownership of the documents, they were back where they should have been and the problem was resolved.

Phew! This all sounds more complicated than it actually is but it did throw me a curve ball I wasn’t expecting, and it also shows that Sharepoint is actually very good at “not eating your homework” even when you push it in directions it isn’t expecting to go in.

Thank goodness that one didn’t involve a site collection restore (as they’re majorly painful to do and take ages).

Posted in Uncategorized | Tagged , , | Leave a comment

Search tips in Sharepoint Libraries

“Searching in Sharepoint doesn’t work” – I think this is probably the second most popular support task type right after permissions woes and yet seldom few folk actually understand how Sharepoint’s Enterprise Search works.

Let’s look at probably the most common example. Someone uploads a document to Sharepoint. Just drags the file into the document library. They don’t have any publication controls switched on, no versioning, no file check-in check out so there sits their file ready to be used.

They can see the file, they know it’s there, it has a name – but when they enter that name into search they see the all-too-familiar Sharepoint “No Results” search screen.

Of course, there’s a very good reason for this. In order for items to be searchable, they need to be crawled by Sharepoint’s Search Crawl Service first and that’s by no means an instantaneous thing. Although Nexus Sharepoint is set to continuously crawl content, how you search for that content once crawled can offer up varying levels of success.

For your freshly uploaded item, are you searching by name? File name? Title? Another metadata column? By Author? By a keyword?

From the library itself? At the site level? At the site collection level?

As you can see, there are many ways to search and more importantly many ways to REFINE your search that may seem counter-intuitive to just sticking in a search term and hitting the magnifying glass button – but refining searches and ensuring your content has actually been crawled and search-indexed is vitally important.

Back to our example. If you fill in both name AND title fields in your document’s properties you’ve instantly bumped up your item’s search ranking and likely visibility by 50%.

In picture libraries, filling out the Keywords column will also raise your item’s search profile – and also searching by columns specifically (for example, to search the keywords field in a picture library, it’s as simple as putting “keywords:yoursearchterm” in the search box) you are again refining your search and improving your chances of a successful hit. Using wildcards can also help so putting a * before or after a search term will offer up more results.

Above all, bear in mind that everything in Sharepoint’s back end servers happens on a schedule. Search crawling is continuous, but full crawls also happen twice a day (we can’t make them any more frequent than this purely because one full crawl across all our content would not complete before the next one was due) so every 12 hours for a full crawl ensures that items are not missed if changed or added in between shorter incremental crawls.

Searching is just one way to find content, but improving the categorisation and organisation of content can also help your users get to exactly what they need to find. Naming conventions, managed metadata term stores and filtered list views are also powerful tools to consider when thinking about the structure of your site.

As with permissions, file sizes and other perceived “quirks” of Sharepoint, bear in mind that Sharepoint works very differently to your local file system on your PC and if you consider that everything in Sharepoint has to be hauled out of a series of back-end databases, this might go some way to explain why ‘instantaneous’ rarely happens in the world of Sharepoint.

Posted in Uncategorized | Leave a comment

The sticky subject of Sharepoint Permissions

Without a doubt, one of the biggest support headaches with Sharepoint revolve around access controls and permissions. The most frequently raised tickets in HEAT are permissions issues, and we see so many sites where a Site Collection Administrator has inherited a collection with permissions that are a granular hot mess of directly attributed access, or poorly structured groups.

With Sharepoint 2013, rather than becoming simpler (as we’d expected), things seem to have become even more complicated as the new “Share” links scattered throughout SP2013 sites have our users even more confused than before.

To that end, we’ve developed some back-end scripts to interrogate a site collection’s permissions for all items, libraries, lists, subsites and sites (out of hours, unfortunately – purely because the scripts are fairly intensive and rattle through an entire site collection to gather the permissions report).

Running the permissions matrix script against a couple of site collections showed that the following ‘bad habits’ are commonplace in most sites where users have had issues.

  1. Hitting the ‘Share’ button or link in the wrong place. Quite often a user was given access to a site, with no access whatsoever to the content under it (unless that content was inheriting permissions from the parent site).
  2. Flipping this on its head, plenty of instances where permissions were granted to a single item, with no permissions granted at the parent object (a site, a list, a library – all with unique permissions of their own).
  3. Scant use of groups. Sharepoint sites come with three groups on initial setup, in some cases site owners or administrators had bypassed using those groups AT ALL and had just made more work for themselves by controlling permissions to the nth degree at the item level instead.
  4. Reliance on outdated or incomplete Active Directory groups when assigning unit-level permissions within Sharepoint.

In the latest feedback surrounding the Office 365 Project, we’ve again seen the criticism levelled at Sharepoint that permissions are not intuitive, and that sites are difficult to set up and effectively “lock down” in cases where there’s a requirement to limit access to sensitive data, or make assurances that only certain users will see certain content. Aside from the support documentation already provided, what would users like to see when it comes to permissions help, support or training? Please leave a comment below as your feedback on issues like this can help us understand and shape the service’s support requirements more effectively.

Posted in Uncategorized | Leave a comment

Welcome to Sharepoint Shenanigans

Welcome to Sharepoint Shenanigans, a Nexus Team blog covering various aspects of the Nexus Sharepoint Service and sharing a few tips, knowledge items and annoyances along the way. Posts will also cover the Nexus Exchange Service as that’s also a major part of my role in IT Services.


Posted in Uncategorized | 1 Comment