PowerShell script failing when retrieving storage details for large SharePoint site

Question

PowerShell script failing when retrieving storage details for large SharePoint site

CHANDRAMOHAN, Anish 0

Hi,

I am running a PowerShell script to retrieve storage usage of files and folders from a SharePoint site that are older than January 1, 2024.

The site is around 2TB, the execution fails.

Has anyone encountered such issues when processing very large SharePoint sites? If so, are there recommended approaches or best practices for handling such large document libraries or sites with significant storage?

Any guidance would be appreciated.

2 answers

Your answer

Answer 1

Steven-N 21,805 Microsoft External Staff Moderator

Hi CHANDRAMOHAN, Anish

Thank you for reaching out to Microsoft Q&A forum

As far as I know, processing a 2TB SharePoint site via PowerShell requires a strategic approach. Standard item-by-item iteration (like using a standard Get-PnPListItem or Get-PnPFolderItem without strict optimization) will almost certainly fail due to a combination of SharePoint API throttling (HTTP 429 Too Many Requests),...

However, to better assist you, could you please provide the following additional information:

Which PowerShell cmdlet are you using to retrieve the storage details for the large SharePoint site?
What is the exact error message you see when the execution fails? You may provide a screenshot if available (please make sure to hide any personal information).

Best regards

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Steven-N 21,805 Reputation points Microsoft External Staff Moderator

2026-03-10T14:15:03.78+00:00

Hi CHANDRAMOHAN, Anish

It has been a while and I am writing to see how things are going with this issue.

Have you had a chance to check the replies provided?

Any update would be appreciated
CHANDRAMOHAN, Anish 0 Reputation points

2026-03-11T10:03:25.6333333+00:00

Hi Steven,

Thank you for your response.

I have attempted using SharePoint Online Management Shell, CSOM, and Microsoft Graph approaches to retrieve file metadata (File Name, Path, and Size) from the document libraries and export it to CSV for analysis.

However, when running against this site, the execution fails before completing. In some cases, the process stops with an exception such as:

Exception calling "ExecuteQuery" with "0" argument(s)

In other attempts, the process completes but returns no data, likely due to throttling or request limits when processing a very large number of items.

Any recommendations for handling metadata retrieval from very large SharePoint Online libraries would be greatly appreciated.

Thanks.
Steven-N 21,805 Reputation points Microsoft External Staff Moderator

2026-03-11T14:31:57.2533333+00:00
Hi CHANDRAMOHAN, Anish

In this context, you can try the below approaches to see if it can help you:

Use paging/batching instead of enumerating everything at once For CSOM/PowerShell, page through items using ListItemCollectionPosition (batch-by-batch) rather than loading the full library in a single query. This pattern is commonly used to avoid mid-run failures during large exports.

For CSOM specifically: replace ExecuteQuery with ExecuteQueryWithIncrementalRetry Microsoft guidance calls out using ExecuteQueryWithIncrementalRetry (instead of ExecuteQuery) to handle throttling properly in CSOM-based solutions.

Prefer Microsoft Graph “delta” for scalable inventory (especially recurring exports) Use driveItem delta to enumerate the library in pages (via @odata.nextLink) and then use @odata.deltaLink for subsequent runs to retrieve only changes, rather than re-scanning the entire library.

Regards

Answer 2

For very large SharePoint Online sites and libraries, a direct, custom PowerShell crawl of all items often runs into timeouts, throttling, or memory limits, especially around the 2 TB scale. For storage and age analysis, use the built‑in version storage reporting and analysis tooling instead of enumerating every file manually.

Recommended approach for large sites:

Use the built‑in version storage usage report jobs

Install and use the SharePoint Online Management Shell.
Connect as a SharePoint Administrator.

For a whole site or OneDrive, submit a background report job:

     New-SPOSiteFileVersionExpirationReportJob -Identity $siteUrl -ReportUrl $reportUrl

Track its progress:

     Get-SPOSiteFileVersionExpirationReportJobProgress -Identity $siteUrl -ReportUrl $reportUrl

For a specific library in that large site:

     New-SPOListFileVersionExpirationReportJob -Site $siteUrl -List $libName -ReportUrl $reportUrl
     Get-SPOListFileVersionExpirationReportJobProgress -Site $siteUrl -List $libName -ReportUrl $reportUrl

These jobs run on the service side and are designed to handle large sites and libraries more reliably than client‑side scripts.

Analyze the generated report instead of live-enumerating content
- The report is delivered as a CSV file to the location specified by -ReportUrl.
- Use the provided analysis script (PowerShell 7) to process the report locally:
```
     . "<path to AnalyzeReportFile.ps1>" –ReportLocalFilePath "<path to the file version expiration What-If report .csv file>"
```
- The script outputs:
  - Current Expiration Schedule (time‑series of versions and size expired)
  - Target Expiration Schedule (if testing different expiration dates)
  - Files with fewer than 10 versions after immediate deletion
- From this CSV, filter by date (e.g., versions or files older than 2024‑01‑01) and aggregate storage usage without putting load on SharePoint during the query.
Use the reports to remediate storage and metadata pressure
- Large sites often hit metadata/storage limits due to many versions and duplicates.
- Use the report to identify:
  - Old versions that can be expired.
  - Libraries or folders with heavy version bloat.
- Then adjust versioning and clean up old versions/duplicates in lists and libraries to reduce storage and metadata usage.
General best practices for very large document repositories
- Prefer service‑side reporting (as above) over client‑side full crawls.
- Consider structuring content so that individual site collections and libraries stay within practical operational bounds (even though SharePoint supports very large libraries, performance and manageability are better when content is logically partitioned).
- For extremely large or business‑critical sites, treat them as “very large sites” and plan/monitor them explicitly, as recommended for large‑scale repositories.

Using the version storage report jobs plus offline CSV analysis is the supported pattern for handling storage/age analysis at multi‑TB scale and avoids the failures seen with direct PowerShell enumeration.

References:

Share via

PowerShell script failing when retrieving storage details for large SharePoint site

2 answers

Your answer