Classify every site by its evidence of use before it joins a wave

Chapter 2 asked for usage as one line of the inventory: which sites were opened, by how many distinct people, over a known number of days. No single place on a farm holds those numbers. This chapter says what each signal establishes and what it cannot, so that the waves carry the sites people use and Chapter 26 receives the rest with evidence attached.

Which content is in use, by whom, and what does the evidence you have actually establish about the rest?

The decision this chapter leads to is a usage class for every site collection (active, dormant or abandoned), with its evidence, its window and the owner who confirmed it, recorded before it goes into a wave. Dormant and abandoned ones go to Chapter 26's dispositions first, not straight into a wave.

Which farms this chapter is for

A SharePoint Server 2016, 2019 or Subscription Edition farm whose content moves by attach to Subscription Edition (Chapter 23) or by copy into SharePoint Online (Chapters 8 and 9). Take every reading on the source, before its databases go read-only: most of this evidence exists nowhere else.

Six signals, and what each one establishes

Sources for the table: list field schema, site properties, modified dates on site contents, view usage reports, usage analytics reports, analytics processing, Set-SPUsageDefinition, audit settings, IIS log settings and Get-SPSite, all checked on 6 November 2026.

Readers' names come from the audit log and the IIS logs; Modified By names only the last writer, and the analytics count people without keeping them: "no user information is stored as a result of the data processing" (analytics processing, above).

Read the writes first

Every change stamps the content, but on 2016 the date shown for sites, lists and libraries "may also be updated by system events"; 2019 added LastItemUserModifiedDate "to track changes that are the result of the user events" (modified dates on site contents, above). That note names 2019 and SharePoint Online; on Subscription Edition the script shows whether the property answers, and an empty column means it is not there, not that nobody wrote.

# Reads the source farm; changes nothing. Run in the SharePoint Management Shell.
$day = Get-Date -Format "yyyy-MM-dd"
Write-Host "Saving each usage definition and its retention to usage-definitions-$day.txt"
Get-SPUsageDefinition | Format-List * | Out-File ".\usage-definitions-$day.txt"
Write-Host "Saving every site's last-modified dates and its site collection's storage to site-writes-$day.csv"
Get-SPSite -Limit All | ForEach-Object {
    $storage = $_.Usage.Storage
    $_ | Get-SPWeb -Limit All |
        Select-Object Url, LastItemModifiedDate, LastItemUserModifiedDate, @{ n = "Storage"; e = { $storage } }
} | Export-Csv ".\site-writes-$day.csv" -NoTypeInformation

Keep -Limit All: by default Get-SPSite stops at 200 site collections (Get-SPSite, above), and the first 200 look exactly like a farm.

Reads leave fewer traces

A read stamps nothing in the content; it exists only where an instrument was watching.

Popularity Trends come from the analytics processing component of search, and only where a farm administrator configured usage collection (plan for site maintenance, checked on 6 November 2026). By default, an item's views count only when it "was viewed a minimum of three times within the past 24 hours" (usage analytics reports, above). Monthly unique users are "the sum of unique users per day", so one person on twenty days counts twenty. And the reports "are only available for Document Libraries and Product Catalog lists" (view usage reports, above): a process run in other lists can be busy and absent.

The usage database keeps usage data for 14 days unless somebody changed it, and 31 at most: this month, never a year.

The audit log records, for each event selected, the user, the item, the event and its time; the events include "Opening or downloading documents, viewing items in lists, or viewing item properties" (audit settings, above). It holds nothing from before an event was selected, and with trimming on and no retention set, "all audit log entries are deleted at the end of the month". On 2016 and 2019, pages "can't be audited"; Microsoft's article stops at 2019, and we do not know whether Subscription Edition differs. An information management policy can also audit a library (checked on 6 November 2026).

IIS logs record every request a web server answers, by default with "the name of the authenticated user" and the user agent (IIS log settings, above). They reach back only as far as somebody kept them, and Microsoft's storage guidance notes that "many users turn off logging completely" (managing IIS log file storage, checked on 6 November 2026). Collect them from every server that answers users and count distinct user names per site per month: Chapter 2's number, over a known window.

Set aside what is not a person

Every instrument records processes as faithfully as people. Set these aside before you count:

• The crawler, signed in as the default content access account or as an account a crawl rule names (crawl account, checked on 6 November 2026).
• Sync apps. On 2019 and Subscription Edition, a OneDrive sync app that cannot reach the push notification service polls the server "roughly every two minutes looking for changes", authenticated as its user (configure syncing, checked on 6 November 2026): a person's name all day, with nobody reading.
• Backup, reporting and monitoring products, and integrations, whose accounts come from their owners and from the integrations Chapter 22 found in these same logs.

What cannot be attributed stays unattributed, and counts on neither side.

Silence is a reading of the instruments

No signal is not no use. It is no signal, and the first question is why: Microsoft explains an empty audit report as "audit logs weren't enabled or there was no data to show" (audit settings, above). Every signal on a farm was switched on by somebody, on a date. Before it is evidence of use, it is evidence of what was being watched. For each site, establish that each instrument was on, covered it, and kept enough to span the window.

The window is a convention, written down with its reason as Chapter 6 asks. We would make it twelve months at least, year end included, and longer where the owner names a longer cycle: a site that serves the year-end close or the annual audit looks dormant for eleven months and is indispensable in the twelfth. Content under a legal hold may never be read; its value is the obligation, as Chapter 26 recognises. Of the reads, only the analytics reports and kept audit or IIS logs reach back a year; last-modified dates reach further but see only writes. Where nothing covers the window, the class is not established.

What survives the move

Export every reading: little of it is the destination's to keep.

• An attach to Subscription Edition carries the content databases, and with them the "audit logs" they hold (database types). The usage database is not among those that upgrade, and the Analytics Reporting database, which "stores the results of usage analytics", is optional (services upgrade overview); with a new, empty index, search analytics data "cannot be fully retained" (upgrade service applications), all three checked on 6 November 2026. Chapter 10 records that choice.
• A copy into SharePoint Online can carry a site's "audit settings" (SPMT settings); we do not know of a Microsoft tool that carries the farm's audit entries or usage history. The destination's log starts with the copy: when a source file is newer, SPMT's system account deletes the destination file and "logs the deletion in the audit log" (SPMT FAQ), both checked on 6 November 2026.
• IIS logs stay on the old servers.

Archive the exports beside the verification record Chapter 9 keeps before decommissioning: after that day, they are the only account of how the estate was used.

Classify, then let the owner confirm

Put the class on the site collection, the unit Chapter 26 decides; a dormant subsite in an active site collection is a note for its owner. The thresholds are yours; the evidence each class needs is not.

Then take the class to the owner, with the evidence. Chapter 13's administrator list names them; where there is nobody, the owner of Chapter 6's ownership rule answers. The farm's site use confirmation, which emails owners "to see if they consider their site active" (plan for site maintenance, above), records replies, not use. We would not let a dormant site collection into a wave because moving it looked easier than asking.

Out of scope

Search is Chapter 11; dispositions are Chapter 26, archiving first Chapter 27, and measuring use after the move Chapter 40. Tools that parse IIS logs, SharePoint Online's usage reports and Purview auditing are not covered. Logs that name people may be personal data, kept as whoever owns data protection decides; we would report counts per site, not names.

Before you continue

• Each instrument is recorded: on or off, since when, which sites it covered, how long it keeps data
• Every site's last-modified dates were read on the source and dated; no write was counted as a read
• Crawl, sync, backup, reporting and integration accounts were set aside before counting
• The window covers the business cycle, year end included, and is written down with its reason
• Every site collection is active, dormant or abandoned on recorded evidence, or not established and in no wave
• Each class was confirmed by the owner, or by the owner of the ownership rule where there is none
• No dormant or abandoned site collection reached a wave without a Chapter 26 disposition
• The exports are archived beside the verification record

Download chapter 14 (PDF)Same text, same tables, same sources as this page.