Understand Forage Exceptions and Unread Files

Purpose: see what could not be read, why, and who can act on it.

1. Open Records, then Exceptions. The figures at the top show documents lost, split into those caused by the document itself or by a copy SharePoint holds that was already damaged, those caused by Forage or the source, and how many are waiting to be tried again.
2. In What to fix, each cause is one row, ranked by documents lost, with its kind, how many documents and sites it affects, whether it is still happening, and What happens next: whether it will be tried again or needs someone to act.
3. Read What the kinds mean to see who can act on each kind: the document itself, the copy SharePoint holds (damaged before Forage fetched it), the source, the infrastructure, Forage itself, or a limit set by policy.
4. Press Evidence on a row to list the documents behind that cause under Show me the evidence. Narrow by stage and by time, click a row to open the document, and export the current page of the list.
5. Under Where it is, see which sites lost documents.
6. To find one file, search for it with Read or not set to Not read, and open it: the Document window says why its content was not read.

Good to know: a passing problem, such as a dropped connection, a SharePoint error or a read that ran out of time, gets three quick tries and then two more a day apart before Forage gives up on the file. Forage also looks again every week at files it gave up on, and picks one up again if it has since been restored, archived or moved. A file that cannot be read because of the document itself, such as a password or encryption, or because the copy SharePoint holds was already damaged before Forage fetched it, is labelled as such so nobody chases it as a fault. It stays searchable by its name and folder.

See what each page shows for the rest of the Records section, and limitations for what Forage does not do.

Questions go to sales@smikar.com.