TROUBLESHOOTING 101 for 365 | SHAREPOINT - DOCUMENT RECOVERY
Author: Jonathan Stuckey
This article is another in the series of SharePoint Online trouble-identification, diagnostics and (in some cases) recovery. While not the most frequent issue, location and recovery of documents or list items, is one which for users' the training reduces to "here's the recycle bin".
While you don't need to know all the in's and out's of the underlying platform, basic triage and understanding of the implications of each is key tool in supporting organisations using SharePoint Online and Microsoft 365.
Please note: this article covers the possible causes and triage to narrow down root-cause of the issue, we have assumed that as a power-user or administrator you have relevant knowledge for recovering in each situation.
Problem statement
Common user problem of I can't find or see my document(s) - it was able to before...
Starting point
We have basic structures in SharePoint where the scope or possibilities of data-loss or access issues reduce at each step down the structure:
a site
a library (or list)
a folder*
content i.e. a document or item
* if your environment uses documentsets you should know this is just a folder with some smarts applied
Any time you get this kind of problem reported, it can be traced back to one of the following:
permissions and access rights
environmental or device issues
user training or behaviours
In the following sections we identify what and where can get to the bottom of the problem.
Permissions and access
Accessing content held in Microsoft 365, is governed by the permissions and controls on the repository it is held in. Invariably this is SharePoint Online (whether you know it or not). In fact, sharing in Microsoft Teams Channel, as link from email* or direct SharePoint or OneDrive for Business - you are just using SharePoint.
With these is it key to understand how a user's identity, Microsoft Team membership or SharePoint site access groups and memberships are nearly always derived from Azure Active Directory. AAD (or Entra as it is being re-branded to) underpins the Microsoft 365 services for Authentication and Authorization, and SharePoint Groups and Permission Levels deal with the content privileges and functions.
We recommend learning about how AAD, Microsoft 365 Groups and SharePoint Groups | Permission levels work before attempting to do ad hoc changes to permissions on content.
Unrecoverable issues
A number of issues can be caused by Microsoft's own services having failures (Incidents), or update-issues (Advisories), but one other common sources of [document | data-loss] stems from your device and / or hardware failures.
After triage, if you have identified a critical (unrecoverable) problem then it can well result in actual data-loss. Be aware you may not get the data back, unless your organisation or computer is fully backing up on regular basis. You should also get your device(s) checked for other underlying problems.
Triage
The following represent the most common issues for identification (and potential recovery). During a root-cause investigation you can work your way down the steps accordingly, but it is also useful to have the levels of increasing risk associated with uncovering later items - which could lead to archive restore or potentially even triggering disaster-recovery options
We have said this before, but the very first question when uncovering problem is to ask
did you (ever) previously have access to this item?
if so - when was the last time you could see/access it?
should you have access to this item?
Only if you get positive confirmation on the above, then the are a limited number of ways the user's stuff would not be in available in the library (or list):
1. Deletion (Recycle bin)
Ranking: no1 cause of this issue.
At some point a user has selected content in the folder and (accidentally) Deleted the item. Content will now be in the recycle bin.
If not in first stage recycle bin, there is an Admin level second stage recycle-bin for recovery inside 90-day period.
You can check – access site as site-collection administrator - go to Settings cog > Site Contents > Recycle (top-right)
2. Permissions
Ranking: no 2 most likely cause
The user does not have the rights to see the contents of the folder because permissions exclude them. This may be because they have (accidentally) removed their own permissions trying to lock an item down, or because someone else has restricted the item.
You can check – login using Global Admin or SharePoint admin – navigate to folders, right-click on one and open Manage Access – check permissions allow to user read (min)
INFO: If you cannot see the user's access, then you can always use Advanced permissions options and run the Check user permissions tool.
Validating access and permissions
Navigate to the SharePoint site
Check to see if you can actually access the specific container (e.g. Library, Folder)
If you can't, you should:
check the item's activity stream (assuming change was recent)
ask the Owner of the site (or Microsoft Team), about why (or if) users' permissions changed
raise a ticket with your (3rd line) support about access and permissions.
IMPORTANT: always get the site Owner to confirm that the user with the issue should have the rights identified - before adjusting permissions.
3. Copy | Move failure
Ranking: Unlikely to occur with less than 1000 items being moved | copied at once.
Moving content around can sometimes lead to location confusion or access issues. This can occur in following ways:
the user (or migration process) never copied or moved items in from the original location, or
a drag-n-drop move of documents did not complete and the item(s) being copied are still in original location;
or a select-all “Move” option did not complete and files didn’t migrate (as per Copy)
in these scenarios the user is looking in the wrong place.
You can check – access site as site-collection administrator - Settings cog > Site Contents > check folder details – tells you Qty of files and items in library. Do the numbers of expected items match-up with quantity in the original location?
If the user(s) have moved documents (or folders) - check also the original location library and recycle bin
INFO: SharePoint Move and Copy commands leave original intact until copy in target location returns success on commit, before deleting original and leaving in the source-location recycle bin
NOTE: the built-in "Move" command on a library or list has known issues with performance on large moves and the this can result in the process stalling or not completing correctly. See notes above for checking.
4. Retention and Disposal
Ranking: Unlikely. Only ever implemented using specific guidance and rules from IM specialist.
In most cases the tenancies are not setup with a Retention policy that has a default of “Delete” and the user's files. If a disposal policy has been setup up, and the users' items were labels/identified by the policy and the item exceeded the criteria for retention-period - then this could have occurred.
Most information management specialists do not setup R&D with default of Delete. Disposal rules are nearly always implemented using a Review action, never automatic, permanent delete.
You can check – as global admin, or SharePoint admin, go to Purview and check for Policy or Labels under “Data life-cycle management”
5. Office application crash
Ranking: Unlikely, but possible.
WARNING: the following scenario can result in non-recoverable data-loss
The user has had document open while synchronisation to device was offline, stopped or broken - and the application has crashed (or forcibly restarted) and the last-character save failed - losing local cached copy of the document.
This coupled with desktop synchronization failure could result in critical loss of document copy
You can check – options on the local device. As device or network administrator, access device and check:
Recycle bin for failed items which have been deleted automatically - unlikely, but possible recovery location, and
Office application temp area for dated temporary files which *may* be last local copy e.g. C:\Users\<userid>\AppData\Roaming\Microsoft\<OfficeAppName> - ...unlikely, but possible recovery option if the user has not restarted Office application since loss of item
NOTE: see also final logging options for no. 5.
6. Synchronisation failure
Ranking: Highly unlikely, but possible.
WARNING: the following scenarios result in catastrophic and non-recoverable data-loss
Windows and OneDrive for Business sync:
The user has had the library synchronised to their laptop or device using OneDrive Sync. At some-point synchronisation process has stopped / broke and either:
the user could have “deleted” troubled items to get sync working, or
the User/Internal IT may have re-built the user's machine and synchronised copy on the device was lost.
at this point synchronisation has lost items between device and SharePoint library, and original items have been "lost".
You can check – data synchronisation errors in the desktop "OneDrive" client UI. this is a limited interface. You can also raise a request to have the Unified Audit log checked for OneDrive Synchronisation issues.
NOTE: this assumes your tenancy has this configured, otherwise it is not an option.
On user's device check the EventViewer for Operating System event logs - Application logs - for indication of application failure, data or network issues; and System logs - for hardware issues.
Need help to develop your operational support? Give us a call
If you want to talk about getting understanding troubleshooting with Microsoft 365 and SharePoint, contact us at: hi@timewespoke.com
About the author: Jonathan Stuckey