+> - The standard version of this feature is currently available to organizations that have no more than 10,000 total SharePoint sites and OneDrive accounts combined.

+> - Advanced Tenant Rename is available to organizations that have less than 100,000 total sites, available with SharePoint Advanced Management. See [Advanced Tenant Rename](change-your-sharepoint-domain-name.md#advanced-tenant-rename).

+| Search and Delve | The search index will take a while to reflect new URL changes. | None. As a benchmark, sites with under 100,000 documents will often be updated in 3 days. For sites with over 100,000 documents, the updates can take a few weeks depending on traffic. |

+| InfoPath forms | Forms that use a SharePoint connection as a data source don't work. | Reconnect these forms to SharePoint. |

+| Microsoft Forms | Forms that have the option to upload attachments in responses don't work. | Remove the upload button and add it again in the form. |

+| OneDrive | The Quick access links in OneDrive and SharePoint don't work. | No action is available. |

+| Power Automate | Some regular flows do not work after the rename. | As part of the rename operation, updates to Power Automate are attempted but a small subset may fail due to service issues. For any flows identified that do not work, manually update the URL. |

+| Power BI | Power BI reports using SharePoint connections as a data source don't work. | Before changing your domain name, download the Power BI reports that are using SharePoint connections as a data source as a .pbix file. After you change the domain name, edit the connections in the Power BI Desktop app and republish the report. <br> Power BI reports that aren't created or maintained in the Power BI Desktop app will need to be recreated. |

+| Project Online | References to PWA sites in Project Online at https://project.microsoft.com don't work. | In Project Online at https://project.microsoft.com, change the URL of the PWA sites under Settings > My PWA Site. |

+| Project Online | Custom Excel Reports that use Microsoft Project Data connections as a data source don't work. | These reports need to be reconnected. |

+| Project Pro | The app don't work until you update the URL of the PWA site. | Before changing your domain name, make sure that all projects that are checked out in Project Pro are checked in. After you change the domain name, change the URL of the PWA site under File > Info > Manage Accounts. |

+| SharePoint hub sites | Sites registered as hub sites don't work. | Unregister and register the affected sites as hub sites in the SharePoint admin center after the rename. |

+| Teams on the web and Teams desktop app | On the Files tab, any folders added with the "Add cloud storage" (which point to another SharePoint site) don't work.| Remove and re-add the folders. |

+| Teams on the web and Teams desktop app | Document libraries added as a tab don't work. | Remove and re-add the tab. |

+| Locked sites and OneDrive accounts | Any site or OneDrive that has been locked (the LockState is NoAccess) can't be renamed. | Before changing your domain name, review any sites and OneDrive accounts that are locked to determine if the lock should be removed. [Lock and unlock sites](manage-lock-status.md)|

+## Advanced Tenant Rename

+If you have over 10,000 total sites in your organization or want to have greater control over the rename operation, you can consider Advanced Tenant Rename. It supports changing the SharePoint domain on tenants with up to 100,000 total sites currently and has the ability for admins to prioritize up to 4,000 sites in their organization for early execution within the overall rename. This allows for select business-critical or high-visibility sites to complete first and reduce any risk or concerns with its impact on daily operations.

+Advanced Tenant Rename is a part of SharePoint Advanced Management.

+### Prerequisites

+Advanced Tenant Rename can currently only support tenants meeting the following conditions:

+- You must have SharePoint Advanced Management licenses purchased for all users in your organization.

+- Your organization has <100,000 total sites.

+- Your organization doesnΓÇÖt have Microsoft365 Multi Geo enabled.

+- Your organization doesnΓÇÖt use government clouds, including GCC, GCC High and DoD.

+- Your organization doesnΓÇÖt use vanity domains (from the earlier MTE offering).

+### Prioritizing sites

+With Advanced Tenant Rename, you can prioritize up to 4,000 sites for early execution. This can include both OneDrive and SharePoint sites, excluding root sites (e.g., contoso.sharepoint.com, contoso-admin.sharepoint.com, contoso-my.sharepoint.com).

+Prioritized sites would be picked up for processing first, among all the sites in your organization. This allows them the opportunity to complete their renames sooner. You can make the most of this by planning your tenant rename to start at the beginning of a low impact period (weekends, holidays, etc.) and prioritize those sites that you believe are going to be important to have accessible at the start of the next business day.

+To manage prioritization, you can make use of the following PowerShell cmdlets.

+- [Set-SPOTenantRenameSitePrioritization](/powershell/module/sharepoint-online/set-spotenantrenamesiteprioritization) ΓÇô This allows you to prioritize the specified site for early execution.

+- [Remove-SPOTenantRenameSitePrioritization](/powershell/module/sharepoint-online/remove-spotenantrenamesiteprioritization) ΓÇô This allows you to remove prioritization for the specified site.

+- [Get-SPOTenantRenameSitePrioritization](/powershell/module/sharepoint-online/get-spotenantrenamesiteprioritization) ΓÇô This allows you to view the current list of prioritized sites.

+> [!NOTE]

+> The PowerShell cmdlets for prioritization should be used once the tenant rename has been scheduled. Changes to the list of prioritized sites will be supported up to 2 hours before the scheduled start time of the rename. Once the rename starts, further changes will not be accepted.

+2. Add your [new .onmicrosoft.com domain using the Domains page in the M365 Admin Center](/microsoft-365/admin/setup/add-or-replace-your-onmicrosoftcom-domain#add-a-new-onmicrosoftcom-domain).

+ > - Do not use the "Add domain" option directly present in the Domains page, since that does not create a .onmicrosoft.com domain. Use the steps in the link above to correctly create one.

+ > - Do not make this domain your fallback domain.

+3. Go back to the Domains page and check that the newly added .onmicrosoft.com domain appears in a 'Healthy' state.

+To cancel a rename before it starts, you can run `Stop-SPOTenantRename`. [More info about this cmdlet](/powershell/module/sharepoint-online/start-spotenantrename)

+## Step 3: Prioritize sites (premium)

+If you had purchased SharePoint Advanced Management licenses for all users at the time of scheduling your rename, it would be automatically considered an Advanced Tenant Rename, with the ability to prioritize sites.

+You can prioritize individual sites using the Set-SPOTenantRenameSitePrioritization cmdlet. For example, to prioritize a site _ΓÇÿprojectxΓÇÖ_, you should run the following command:

+`Set-SPOTenantRenameSitePrioritization -SiteUrl https://contoso.sharepoint.com/sites/projectx`

+If you have already identified the list of sites youΓÇÖd want prioritized and want to perform the Set operation in bulk, you can populate them in a CSV file and then use PowerShell to import it and iteratively execute the cmdlets. The file should just have a single column with title as ΓÇÿSiteUrlΓÇÖ, and every subsequent row should be the full URL of the desired site.

+Example:

+`Import-Csv <Path> | ForEach-Object {Set-SPOTenantRenameSitePrioritization -SiteUrl $_.SiteUrl}`

+> [!NOTE]

+> If you attempt this with a file that has the entire 4,000 sites in it, the complete execution of this cmdlet can take approximately 4-6 hours. If you want shorter waiting times, we recommend splitting your list of sites up and performing this in batches.

+To view the list of sites prioritized currently, run the following command:

+`Get-SPOTenantRenameSitePrioritization`

+And if you want to remove prioritization for a site, you can run the Remove-SPOTenantRenameSitePrioritization cmdlet. For example, to remove prioritization for the ΓÇÿprojectxΓÇÖ site, you should run the following command:

+`Remove-SPOTenantRenameSitePrioritization -SiteUrl https://contoso.sharepoint.com/sites/projectx`

+Prioritizing a site is not a guarantee that it will be completed first. There are several factors that can affect processing times, and multiple site renames are processed in parallel. Prioritized sites have a higher chance of completing first.

+## Step 4: Monitor the status of the rename

+You can get the status of the rename by running `Get-SPOTenantRenameStatus`. Make sure you open a new PowerShell window to sign in again. The date and time shown with this command is in UTC time (but will follow the local format of the system where the cmdlet is run). [More info about Get-SPOTenantRenameStatus](/powershell/module/sharepoint-online/get-spotenantrenamestatus)

+To verify success of the rename operation, review the status of the rename operation, and the count of renamed sites in comparison to total sites. The count of sites that can't be renamed to the new domain will be shown in the **Attention Required** field. To get more information on these sites, run `Get-SPOSiteRenameState` and pass the RenameJobID listed in the tenant rename status as the ParentOperationID, and the desired status (Success/Failed/Suspended). If you want to export these results to a CSV file, you can use the `Export-Csv` cmdlet.

+## Step 5: Review features and settings after the rename

+ Title: "Version history limits for document library and OneDrive overview (Preview)"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "This article provides guidance on how version history limits are applied at organization, site, library or OneDrive user account level."

+# Overview of version history limits for document libraries and OneDrive (Preview)

+> [!NOTE]

+> Document library version controls at tenant and site level and the new automatic and manual expiration version history limits are currently in preview and are subject to changes. The feature is currently rolling out and might not yet be fully available to all organizations. Before you begin, read the [Version History preview terms and conditions](https://microsoftapc.sharepoint.com/:w:/t/SharePointVersionTrimmingPreviewProgram/EXThSk2EYAZAmr7wACpcFG0BfPgI6GxQ8rFjJ1Sui9pS6Q?e=AQsfwM).

+Version history limits control how versions are stored in a SharePoint document library or OneDrive account. Limits can be set at organization, site, library or OneDrive user account level allowing admins and site owners the ability to better manage content recovery and auditing requirements. Global and SharePoint admins in Microsoft 365 can set version history limits at the organization level. These settings apply universally to all new libraries, whether on existing or new SharePoint sites, and on default libraries on new OneDrive sites. Site owners can overwrite organization-level version settings by [configuring version settings for sites](site-version-limits.md) they own. Site owners can overwrite organization or site settings by [configuring version settings for libraries and lists](https://support.microsoft.com/en-us/office/enable-and-configure-versioning-for-a-list-or-library-1555d642-23ee-446a-990a-bcab618c7a37) they own.

+The following table summarizes the various ways of managing version history limits on your document libraries:

+| Area | How does it work? |

+|:--|:--|

+| **Set default version history limits for new document libraries created in your organization** | Default organization version history limits are set on all new document libraries created across existing and new SPO sites. |

+| **Set site or library level version history limits** | If needed, site admins can break inheritance from the default organization limits for an individual site or library. |

+| **Report on version storage on a site** | Run a report to analyze version storage use of existing versions, understand how a version limit works before configuring limits, or analyze the impact of trimming existing versions before scheduling trim job. |

+| **Trim existing versions** | Site admins can choose to trim existing versions by queuing a timer job to execute the trimming. |

+## How Version history limits are applied

+Version history limits are applied in the following ways:

+- **Default organization limits:** Organization default settings are applied to all new libraries created on sites that don't have site level settings configured.

+- **Site limits:** It is possible to break inheritance for a site by configuring version history limits for the site. When version limits are configured on a site, the settings are applied to all new libraries created on the site.

+- **Library limits:** It is possible to break inheritance at library level to define version limits for files stored in the library.

+In the following example, default organization limits are applied to new libraries created on marketing and sales sites as these sites do not have site level limits applied. Legal site has site level limits applied and broken inheritance from the organization defaults. Libraries created in the legal site follow the limits applied at the legal site level.

+The following figure shows the workflow of applying a version limit on new document libraries. When a new library is created, site level setting check is performed. If no site setting is defined, the organization default setting is applied to new libraries.

+## Types of version limits

+There are two version history settings that admins can use to configure version limits for all new libraries created in their organization:

+### Automatic Setting

+Automatic setting is recommended for optimized version storage. It combines the data recovery benefits that version history offers while optimizing for its storage. For admins, this setting offers the most optimal storage option without having to estimate the version count or age limits needed to meet the diversified need of their end users.<br>

+### Manual setting

+The manual setting allows admins to set count limits on the number of major versions or to set expiration and count limits. When this option is selected, the admins can configure it in the following ways.

+- **Major version limit with expiration period**: Versions are deleted after exceeding either the set number of major versions or after the set period of time. For example, if you configure a library to store 500 major versions with a 365-day expiration, the system stores no more than 500 versions, and automatically deletes any version older than 365 days.

+- **Major version limits with no expiration period**: Versions are deleted after they exceed the set number of major versions. For example, if a library is configured to store 500 major versions, no more than 500 versions is stored for each file or item.

+The UI doesn't allow a value less than 100 major versions or less than 30 days expiration time limits to be set, but it's possible to set the system to store fewer versions using public APIs. For reliability, any value less than 100 versions or less than 30 days expiration time limit isn't recommended and can result in the user activity causing an inadvertent data loss.

+> [!NOTE]

+> If time version history limits are configured on a library, the file version expiration date is stamped on a version at creation time. The expiration date set on a file version is determined from the SnapshotDate of the version which is the date a version became a historical version. The SnapshotDate might be estimated if the version was snapshotted before January 1, 2023.

+## Version storage behavior

+Version storage in SharePoint is determined by several factors including limits configured on a library, user deletion activity, or retention policies. The following table enumerates the various scenarios and expected version storage behavior:

+The following table enumerates the scenarios and the expected version storage behavior:

+| Scenario | Version Trimming Behavior |

+|:--|:--|

+| User deletes versions from the version history of a file. | When a user deletes a version from the version history of a file, the deleted version is moved to the site's recycle bin and can be recovered for a period. For more information, see [Restore items in the recycle bin that were deleted from SharePoint or Teams](https://support.microsoft.com/en-us/office/restore-items-in-the-recycle-bin-that-were-deleted-from-sharepoint-or-teams-6df466b6-55f2-4898-8d6e-c0dff851a0be). |

+| Versions exceed settings applied on the document library. | When versions exceed the limits set at the library, versions matching the criteria are marked for permanent deletion. This version deletion workflow bypasses the normal recycle bin and the deleted versions can't be recovered from recycle bin.|

+| Timer job scheduled to trim existing versions on a library or site. | Versions deleted using scheduled jobs are permanently deleted. This version deletion workflow bypasses the normal recycle bin and deleted versions can't be recovered from recycle bin.|

+| Version storage on items that are subject to retention policy or on an eDiscovery hold. | For items that are subject to a retention policy (or an eDiscovery hold), the versioning limits for the document library are ignored. This exemption continues until the retention period of the document is reached (or the eDiscovery hold is released). For more information, see [How retention works with document versions](/purview/retention-policies-sharepoint). |

+|Trimming existing versions on sites that are Read Only (locked sites). |Trimming of expired versions on sites that are under retention or are on hold is suspended until the site is unlocked. |

+|Versions deletion on items with retention labels applied. | Versioning limits are honored on items with retention labels when the content isn't subject to a retention policy (or an eDiscovery hold). Versions matching the limit criteria are automatically deleted to accommodate new versions, but users are still prevented from deleting versions. |

+| Version deletion on items marked as records. | Version deletion on documents marked as records is blocked. For more information, see [Use record versioning in SharePoint or OneDrive](/purview/record-versioning). |

+## Auditing versioning events

+Audit events are available on the Microsoft Purview compliance portal to help you monitor version history activities. Audit events are logged for the following activities:

+- Changes made to organization version history limits.

+- Changes made to site version history limits.

+- Changes made to library version history limits.

+- User deletes versions from the version history of a file.

+ Title: "FAQs for versions history limits"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "Learn frequently asked questions for versions."

+# FAQs

+## What happens to versions that are deleted, have expired, or exceeded the count limits?

+When a user [deletes a previous version of an item or a file in SharePoint (microsoft.com)](https://support.microsoft.com/en-us/office/delete-a-previous-version-of-an-item-or-file-in-sharepoint-45edfb0d-8b43-4f07-ac6a-ab4ac169d5aa#__bkmkrecycle), SharePoint moves versions into the recycle bin. Users are able to [restore deleted versions from the site collection recycle bin (microsoft.com)](https://support.microsoft.com/en-us/office/restore-deleted-items-from-the-site-collection-recycle-bin-5fa924ee-16d7-487b-9a0a-021b9062d14b).

+Versions trimmed by the Automatic setting or when a version's age exceeds the manual time limits, are tagged for permanent deletion. They aren't available for restoration from the recycle bin once purged.

+> [!NOTE]

+> Background timer jobs permanently purge expired versions and this process may take a couple of days from the actual expiration date.

+Versions that exceed count limits are gradually trimmed when the file is updated. Each file update triggers approximately 20 version deletions until the count limits are met.

+## How do legal holds or retention policies impact version deletions or expirations?

+When a site is on hold or a document with versions is subject to retention settings, the configured retention setting determines the retention of versions. In other words, the retention setting always wins, whether it's a deletion or hold policy. [Learn about retention for SharePoint and OneDrive](/microsoft-365/compliance/retention-policies-sharepoint?view=o365-worldwide#how-retention-works-with-document-versions&preserve-view=true).

+## What happens when organization level or library level version settings are updated?

+When **organization-level version settings are updated**, the new settings are applied to all new libraries created since the change was made. The new settings don't apply to existing libraries or versions already created.

+When **library-level version expiration setting is updated**, the new expiration limit is applied to newly created versions only. Take an example of a library with version expiration settings updated from **Never Expire** to **Expire after six months**. The newly created versions are set to expire after six months with no impact on previously created versions.

+When **library-level count limits are updated**, if existing versions exceed the new count limit, then those versions are gradually trimmed when the file is updated. Take an example of a library with count limits set to 500 versions, was reduced to 300 versions. If you had a file with 500 versions, every time a user updates the file, the oldest 20 versions are purged until you are at the right number of versions.

+## How will automatic setting impact ability to restore a library or OneDrive?

+When **Automatic setting** is selected, users have access to a maximum of 500 versions created within the last 30 days enabling the user to [Restore a shared library](https://support.microsoft.com/en-us/office/restore-a-shared-library-317791c3-8bd0-4dfd-8254-3ca90883d39a) or [Restore your OneDrive](https://support.microsoft.com/en-us/office/restore-your-onedrive-fa231298-759d-41cf-bcd0-25ac53eb8a15).

+ Title: "Set version limits for a document library(Preview)"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "This article provides guidance on how admins can set version limits for a document library."

+# Set version limits for individual document library (Preview)

+The default version history limits for new document libraries are set by either the organization-level limits or the site-level limits. If the site has its own version history limit, it means the site breaks inheritance from the organization. However, to meet specific content requirements, site admins can decide to [configure versioning for a library](https://support.microsoft.com/en-us/office/enable-and-configure-versioning-for-a-list-or-library-1555d642-23ee-446a-990a-bcab618c7a37).

+Here's a summary of the expected behavior when document libraries version expiration or count limits are updated:

+- **When library level version expiration setting is updated**, the new expiration limit is applied to newly created versions only. Take an example of a library with version expiration settings updated from **Never Expire** to **Expire after six months**. New version created is set to expire after six months with no impact on versions that is already created.

+- **When library level count limits are updated**, if existing versions exceed the new count limit, then those versions are gradually trimmed when the file is updated. Consider a library where the version count limit is initially set to 500 versions but is later reduced to 300 versions. In this scenario, if there's a file with 500 versions, each time a user updates the file, the system gradually purges the oldest 20 versions with each new version creation until the total number of versions aligns with the updated limit of 300. It's crucial to note that when count limits are lowered, the process of version deletion occurs gradually, with up to 20 versions being removed for every new version created.

+## Manage version history limits for a library using PowerShell

+Follow these steps to manage version history limits for a site by using PowerShell.

+1. [Download the latest SharePoint Online Management Shell](https://go.microsoft.com/fwlink/p/?LinkId=255251).

+ > [!NOTE]

+ > If you installed a previous version of the SharePoint Online Management Shell, go to Add or remove programs and uninstall **SharePoint Online Management Shell**.

+1. Connect to SharePoint as a [Global Administrator or SharePoint Administrator](/sharepoint/sharepoint-admin-role) in Microsoft 365. To learn how, see [Getting started with SharePoint Online Management Shell](/powershell/sharepoint/sharepoint-online/connect-sharepoint-online).

+2. Run one of the following commands to manage version history limits on a library:

+| **Action** | **PowerShell Command** |

+| | |

+| View version history limits set on a library | `Get-SPOListVersionPolicy -Site $siteUrl -List $libName` |

+| Set Automatic version history limits on a library | `Set-SPOListVersionPolicy -Site $siteUrl -List $libName -EnableAutoExpirationVersionTrim $true` |

+| Set Manual limits with count and time parameters on a library | `Set-SPOListVersionPolicy -Site $siteUrl -List $libName`<br>`-EnableAutoExpirationVersionTrim $false`<br>`-MajorVersions <delete major versions exceeding limit>`<br>`-MajorWithMinorVersions <delete minor versions exceeding limit>`<br>`-ExpireVersionsAfterDays <delete versions exceeding time limit set in days>`|

+| Set Manual limits with count with no expiration limit on a library | `Set-SPOListVersionPolicy -Site $siteUrl -List $libName`<br>`-EnableAutoExpirationVersionTrim $false`<br>`-MajorVersions <delete major versions exceeding limit>`<br>`-MajorWithMinorVersions <delete minor versions exceeding limit>`<br>`-ExpireVersionsAfterDays 0` |

+## Learn More

+For more information, check out the following resources:

+- Manage version history limits for a library using Set-SPOListVersionPolicy

+ Title: "Plan version storage for document libraries(Preview)"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "This article provides guidance on how to plan version storage for your organization."

+# Plan version storage on document libraries (Preview)

+The Version limits you configure need to meet your organizationΓÇÖs recovery objectives and optimize on version storage. In the following sections, we call out the options and decisions that you as an administrator should consider when setting up version limits for your organization:

+## Determine default version limits for your organization

+Before you decide the default version history limits for your organization, you need to consider your **organizationΓÇÖs recovery objective** and **version storage usage targets**. You need to evaluate your needs with the **version restore options available to your users** and **storage usage** of the three version storage modes supported by SharePoint.

+|Select this option:|If you want to:|Benefits|

+||||

+|**Automatic** (Recommended) |Automatically apply optimal storage of versions based on its age and restore probability.<br> With this setting, users have access to most of the recently created versions.<br> As versions age, fewer older versions are stored. No other input is required from admins.| **Storage Use:** Automatic setting is the recommended setting that offers users' access to high value versions while optimizing storage consumption from versions.<br> <br> **Versions Restore Options:** This setting ensures version history at key timestamps is always available for restore even on file with no new file edits.|

+|**Manual** with Major Version Limit and Expiration Period set| Store versions only until the configured expiration period and within the configured major versions count limits.<br> With this setting, users have access to all versions within the count and expiration period.|**Storage Use:** This setting is the best option for ensuring the lowest quota impact from version storage as it trims versions that are older than the configured expiration.<br> <br> **Versions Restore Options:** When an expiration limit is set, it's possible for files with no recent edits to have all their versions trimmed if the updated version policy dictates that. For example, if a file doesn't get edited in six months and a six-month version expiration policy is in place, then all that fileΓÇÖs versions are deleted.|

+|**Manual** with **Major Version Limits and No Time** set| Always store the configured count of versions regardless of version age. Users have access to all the versions within the count limit.| **Storage Use:** This setting can lead to high quota consumption from versions if you have a high ratio of heavily edited files or if you set the limits too high. <br><br> **Version Restore Options:** This setting is the best option for storing a set number of versions offering you predictable version storage behavior. |

+The following image depicts the restore options and the storage use for each setting:

+**Example Scenario**

+Take an example of a file where 500 versions were created in May, June, and July. LetΓÇÖs compare the versions available under each version limits:

+- **Manual limits: 500 major versions with expiration of 60 days:** No more than 500 versions are stored and any version older than 60 days are also deleted. On this file, all versions are eventually deleted as the versions age.

+- **Manual limits: 500 major versions with no limits:** All versions within the count limit of 500 continue to be stored.

+- **Automatic limits: Under automatic settings** intermittent older versions are trimmed over time, resulting in 96% version storage reduction in six months period compared to count limits. Users always have access to a set of versions even when there's no new file edit activity.

+

+## Understand version storage under automatic limits

+When this option is selected, SharePoint employs an algorithm* behind the scenes. This algorithm deletes (thins out) intermittent older versions that are least likely to be needed, while preserving sufficient high-value versions. More versions in the recent past and fewer further back in time - in case restores are required. The algorithm is based on the design principle that the restore value of a version degrades as the version ages and offers end users' access to most of the recently created versions with fewer older versions.

+In other words, SharePoint thins out low-value versions on your behalf to reduce the impact of versions on your quota consumption while maintaining your ability to recover from file deletion/corruption events. In addition, this method better protects you than does a count limit setting from a ransomware attack that creates many versions that would fill up your version queue.

+*The algorithm behind automatic version history limits is based on the design principle that restore value of a version that degrades as the version ages. When Automatic limit is selected, SharePoint deletes (thins out) intermittent older versions that are least likely to be used, while preserving sufficient high-value versions. This ensures users have access to more versions in the recent past and fewer farther back in time in case restores are required.

+Version storage under Automatic setting is determined by the following algorithm:

+As versions are created, users have access to the following versions:

+- **All versions** created within 500 count limit in first 30 days.

+- **Hourly versions** (versions created at the top of the hour) between 30 to 60 day period.

+- **Daily versions** (versions created at the beginning of each day) between 60 to 180 day period.

+- **Weekly versions** (versions created at the beginning of the week) beyond 180 days or more are available indefinitely until the maximum 500 count limit has reached.

+The service trims the intermediate versions as the above milestones are reached.

+Take an example of file with a consistent version creation pattern between the months of June until January. Under Automatic setting, intermittent versions are purged as the versions age resulting in ~94% reduction in version storage used compared to applying count limits only.

+## Determine right count or expiration version limits

+In considering which limits to set, we recommend a balanced approach:

+- Setting count limits too high or setting expiration limits for longer duration or never expiring, stores most versions created, offering users most of versions to restore from. However, a high proportion of actively edited files can result in versions using a high storage.

+- Setting count or expiration limits that are too low can result in data loss due to unrecoverable changes impacting your userΓÇÖs ability to undo unwanted changes, and other recovery scenarios.

+The following diagram shows an example of an HR Hub site with eight associated sites:

+Among these eight associated sites:

+- Five sites Diversity and Inclusion, Education Credits, Talent Acquisition, Training, and Employee Benefits inherit the HR Hub site permission settings. These five sites have the same permissions the HR Hub site has.

+ Title: "Set default organization version limits (Preview)"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "This article provides guidance on how admins can set default organization version limits for new document libraries and OneDrive accounts."

+# Set default organization version limits for new document libraries and OneDrive accounts (Preview)

+Organization-level version settings define the default version storage limits that apply on all new document libraries created across all existing or newly created SharePoint sites and new OneDrive Accounts. This setting allows admins to define the global default version history limits that apply across the organization to ensure consistent version storage use and restore options.

+**Example Scenario**

+Take an example of Contoso with an existing marketing site with a set of libraries set to 500 major version limits. When the admin updates the organization version limits to 'Automatic' library, version limits for document libraries are set in the following ways:

+- **Library version limits on existing marketing site**: Version limits on all new libraries created in the marketing site are set to the organization limits of Automatic. Version limits on existing libraries remain unchanged that is, limits aren't updated to Automatic.

+- **Library version limits on new legal site**: When a new legal site is created, version limits on all libraries created on the legal site are set to the organization version limits.

+> [!IMPORTANT]

+> - Changes made to organization-level version history limits apply to new SharePoint libraries and OneDrive user accounts created since the change was made. The changes can take upto 24 hours to be reflected on new libraries created.

+> - Changes made to organization-level version history limits don't update the history limits on existing document libraries. You can [update settings on existing libraries on individual site](document-library-version-history-limits.md#version-storage-behavior) or libraries. The ability to apply version history limits to existing document libraries at the organization level is not supported.

+> - Changes made to the organization-level version history limits will not trim existing version history to the new limits. To delete existing versions, you can [trim existing versions from a site, library or OneDrive](library-version-limits.md#manage-version-history-limits-for-a-library-using-powershell). The ability to trim existing versions at the organization level is not supported.

+> - Default Version History limits for your organization is set to Manual version history limits with 500 major version count limit and no expiration.

+> - Organization-level Document Library version limit settings can be used to configure version settings on libraries only ([List template Base Type = 1](/openspecs/sharepoint_protocols/ms-wssts/8bf797af-288c-4a1d-a14b-cf5394e636cf)). List version settings, creation of major and minor versions, or content approval workflows need to be [configured at individual library or list level](https://support.microsoft.com/en-us/office/enable-and-configure-versioning-for-a-list-or-library-1555d642-23ee-446a-990a-bcab618c7a37).

+> - If your organization is configured for multi-geo, the Organization level version history levels can be set for each geo.

+## Manage version history limits for your organization

+This article describes how global and SharePoint admins in Microsoft 365 can change the default version history limits for all new SharePoint document libraries and OneDrive accounts created in the organization.

+On the version history limits, SharePoint Admin Setting page uses the Organization Level Version History Limits to set global default version history limits that are universally applied to all newly created document libraries in the organization.

+## Set automatic version history limits for the organization

+1. Go to **Settings** in the [SharePoint admin center](/sharepoint/sharepoint-admin-role), and sign in with an account that has [administrator permissions](/sharepoint/sharepoint-admin-role) for your organization.

+1. SelectΓÇ»**Version History limits**.

+1. Select **Automatically**.

+1. Select **Save** and **Confirm** to apply the changes to all new libraries created.

+To set Automatic version history limits for all new document libraries created in your organization using PowerShell, run the following command:

+```PowerShell

+Set-SPOTenant-EnableAutoExpirationVersionTrim $true

+```

+## Set manual version count limits with no expiration

+1. Go to **Settings** in the [SharePoint admin center](/sharepoint/sharepoint-admin-role), and sign in with an account that has [administrator permissions](/sharepoint/sharepoint-admin-role) for your organization.

+1. SelectΓÇ»**Version history limits**.

+1. SelectΓÇ»**Manually**.

+1. Enter a value between 100 and 50,000 in the **Number of major versions** box.

+1. Set the **Delete versions after this period of time** drop-down option to '**Never**.' This setting ensures that no expiration is stamped on versions.

+1. Select **Save** and **Confirm** to apply the changes to all new libraries created.

+## Set manual version count and expiration storage limits

+To set count and expiration limits for all new document libraries created in your organization using SharePoint admin center:

+1. Go to **Settings** in the [SharePoint admin center](/sharepoint/sharepoint-admin-role), and sign in with an account that has [administrator permissions](/sharepoint/sharepoint-admin-role) for your organization.

+1. Select **Version history limits**.

+1. Select **Manually**.

+1. Enter a value between 100 and 50,000 in the **Number of major versions** box.

+1. Select one of the preset values for **Delete versions after this period of time** drop-down option. or

+1. To enter a custom value for **Delete versions after**, select the custom value from the dropbox and enter value greater than 30 days in the **Days** box and **Save**.

+1. Select **Save** and **Confirm** to apply the changes to all new libraries created.

+To set count and expiration limits for all new document libraries created in your organization using PowerShell, run the following command:

+```PowerShell

+Set-SPOTenant

+-EnableAutoExpirationVersionTrim $false

+-MajorVersionLimit<int>

+-ExpireVersionsAfterDays<0>

+```

+## Review organization version storage limits

+To review the default version history limits for all new document libraries using SharePoint admin center:

+1. Go to **Settings** in the [SharePoint admin center](/sharepoint/sharepoint-admin-role), and sign in with an account that has [administrator permissions](/sharepoint/sharepoint-admin-role) for your organization.

+1. Select **Version history limits**.

+To review the default version history limits for all new document libraries using PowerShell, run the following command:

+```PowerShell

+Get-SPOTenant | select EnableAutoExpirationVersionTrim, ExpireVersionsAfterDays,MajorVersionLimit

+```

+## Learn More

+For more information, check out the following resources:

+- [Manage Version History Limits for your Organization using Set-SPOTenant](/powershell/module/sharepoint-online/set-spotenant)

+ Title: "Change version history limits for a Site (Preview)"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "This article provides guidance on how admins can set version history limits on individual sites."

+# Set version limits for a site (Preview)

+By default, organization level settings define the version history limits that are applied to all new document libraries created in a site. However, to meet specific content needs, admins can choose to set distinct version history limits on individual sites. This way, users can break the inheritance from organization limits on an individual site.

+Version history limits for an individual site can be managed in the following ways:

+| Version history limits option | Description |

+|:--|:--|

+|**Apply site-level version history limits to all new and existing document libraries in a Site:** |To achieve a consistent version storage policy for a site, you can choose to **set a limit to universally apply to all libraries** in the site. Using this option, the Version history limit set on site-level is applied to all the new document libraries created in the site and creates a background request to asynchronously process the update on existing document libraries.|

+|**Apply site-level Version history limits to only new document libraries created in a Site:**|To avoid impacting the settings on existing libraries, you can **set a version history limit only for new libraries**. Using this option, the Version history limits set on site-level are only applied to new document libraries created in the site. There are no changes made to the limits on the existing document libraries or on libraries that aren't enabled for versioning in the site.|

+|**Apply version history limits to existing document libraries only in a Site:**|You can update the limits **only on existing document libraries** on a site without setting a site level version history setting for new document libraries. Using this option creates a background request to asynchronously process the update on existing document libraries while allowing the new document libraries created in the site to inherit the organization level version history limits.|

+|**Clear existing limits set on a Site:** |You can **clear the existing limits on a site** to allow new document libraries created in the site to follow organization level limits.<br> **Note:** Clearing a setting on a Site applies only to new document libraries created on the site and doesn't impact the settings on existing doc libraries or trim existing versions.|

+**Example scenario**

+Take an example of Contoso, where the default organization Version history limits is configured to Automatic setting and no version limits are initially applied on marketing and legal sites. To meet business needs, the admin can decide to apply 'Manual' setting on legal site, thus breaking inheritance of legal site with the organization default version setting.

+The following is the version storage for Contoso:

+- **Version storage behavior on marketing site**: Since no limits are configured for marketing site, all new document libraries created within marketing site collection inherit the organization default setting of automatic.

+- **Version storage on legal site**: Since the legal site has manual settings configured, all new libraries created within the legal site have the manual settings applied.

+> [!IMPORTANT]

+> - Site level Version history limits can be set using PowerShell cmdlets only.

+> - Setting site level Version history limits doesn't trim existing versions to meet the new limits. Additional steps are needed to [trim existing versions on a site or library.](library-version-limits.md#manage-version-history-limits-for-a-library-using-powershell)

+> - Requests to update the limits on existing libraries are processed asynchronously by a background job, which can take up to 24 hours to process. You can use PowerShell to check the progress of the job.

+> - Cancelling an in-progress job stops the update on libraries that were not processed. This action doesn't revert the change for document libraries where the settings update was already processed.

+## Manage Version history limits for a site using PowerShell

+Follow these steps to manage Version history limits for a site by using PowerShell.

+1. [Download the latest SharePoint Online Management Shell](https://go.microsoft.com/fwlink/p/?LinkId=255251).

+ > [!NOTE]

+ > If you installed a previous version of the SharePoint Online Management Shell, go to Add or remove programs and uninstall **SharePoint Online Management Shell**.

+1. Connect to SharePoint as a [Global Administrator or SharePoint Administrator](/sharepoint/sharepoint-admin-role) in Microsoft 365. To learn how, see [Getting started with SharePoint Online Management Shell](/powershell/sharepoint/sharepoint-online/connect-sharepoint-online).

+2. Run one of the following commands to manage version history limits on your site:

+| **Action** | **PowerShell Command** |

+| | |

+| View the version history limits set on a site | Get-SPOSite -Identity $siteUrl \| fl Url, EnableAutoExpirationVersionTrim, ExpireVersionsAfterDays, MajorVersionLimit |

+| Set Automatic version history limits on a site. | To set Automatic Version History Limits for all libraries on a site:<br><br>`Set-SPOSite -Identity $siteUrl`<br>`-EnableAutoExpirationVersionTrim $true`<br><br>Append `-ApplyToNewDocumentLibraries` parameter to apply only to new document libraries on the site:<br><br>`Set-SPOSite -Identity $siteUrl`<br>`-EnableAutoExpirationVersionTrim $true`<br>`-ApplyToNewDocumentLibraries` <br><br>Append `-ApplyToExistingDocumentLibraries` to apply only to existing document libraries on a site:<br><br>`Set-SPOSite -Identity $siteUrl`<br>`-EnableAutoExpirationVersionTrim $true`<br>`-ApplyToExistingDocumentLibraries` |

+| Set Manual limits with Count and time parameters on a site. | To set Manual limits with Count and time parameters for all libraries on a site:<br><br>`Set-SPOSite -Identity $siteUrl`<br>`-EnableAutoExpirationVersionTrim $false`<br>`-MajorVersions <delete major versions exceeding limit>`<br>`-MajorWithMinorVersions <delete minor versions exceeding limit>`<br>`-ExpireVersionsAfterDays <delete versions exceeding time limit set in days>`<br><br>Append `-ApplyToNewDocumentLibraries` parameter to apply only to new document libraries on the site:<br><br>`Set-SPOSite -Identity $siteUrl`<br>`-EnableAutoExpirationVersionTrim $false`<br>`-MajorVersions <delete major versions exceeding limit>`<br>`-MajorWithMinorVersions <delete minor versions exceeding limit>`<br>`-ExpireVersionsAfterDays <delete versions exceeding time limit set in days>`<br>`-ApplyToNewDocumentLibraries` <br><br>Append `-ApplyToExistingDocumentLibraries` to apply only to existing document libraries on a site:<br><br>`Set-SPOSite -Identity $siteUrl`<br>`-EnableAutoExpirationVersionTrim $false`<br>`-MajorVersions <delete major versions exceeding limit>`<br>`-MajorWithMinorVersions <delete minor versions exceeding limit>`<br>`-ExpireVersionsAfterDays <delete versions exceeding time limit set in days>`<br>`-ApplyToExistingDocumentLibraries` |

+| Set Manual count with no expiration limit on a site. | To set Manual limits with Count limits set the `-ExpireVersionsAfterDays` parameter to `0:`<br><br>`Set-SPOSite -Identity $siteUrl`<br>`-EnableAutoExpirationVersionTrim $false`<br>`-MajorVersions <delete major versions exceeding limit>`<br>`-MajorWithMinorVersions <delete minor versions exceeding limit>`<br>`-ExpireVersionsAfterDays 0` <br><br>Append `-ApplyToNewDocumentLibraries` parameter to apply only to new document libraries on the site:<br><br>`Set-SPOSite -Identity $siteUrl`<br>`-EnableAutoExpirationVersionTrim $false`<br>`-MajorVersions <delete major versions exceeding limit>`<br>`-ExpireVersionsAfterDays 0`<br>`-ApplyToNewDocumentLibraries` <br><br>Append `-ApplyToExistingDocumentLibraries` to apply only to existing document libraries on a site:<br><br>`Set-SPOSite -Identity $siteUrl`<br>`-EnableAutoExpirationVersionTrim $false`<br>`-MajorVersions <delete major versions exceeding limit>`<br>`-ExpireVersionsAfterDays 0`<br>`-ApplyToExistingDocumentLibraries` |

+| Clear the existing version history limits set on a site and inherit Organization version limits on new document libraries created on the site. | `Set-SPOSite -Identity $siteUrl -InheritVersionPolicyFromTenant` |

+| Cancel in progress update job|`Remove-SPOSiteVersionPolicyJob -Identity $siteUrl` |

+## Track progress of settings update on existing libraries on a site

+Version limits on all new libraries created in the site are immediately applied. Settings on existing libraries are asynchronously updated using a background job.

+Run the following command **to track progress of settings update job**.

+```PowerShell

+Get-SPOSiteVersionPolicyJobProgress -Identity $siteUrl

+```

+The following table enumerates the various progress status that can be reported when attempting to update the version settings for existing libraries in a site collection:

+| **Status** | **Description** |

+| | |

+| NoRequestFound | There are no requests on the site to set or update version settings on existing document libraries. |

+| New | The update request is New and is not processed yet. |

+| InProgress | The update request is processed and the settings update request is in progress. |

+| CompleteSuccess | The update request is completed successfully. |

+| CompleteWithFailure | The update request is completed, but setting update on some document libraries has failed. |

+## Learn More:

+- [Tutorial: Manage Version history limits for a Site, Library, or OneDrive account (Preview)](tutorial-manage-version-limits.md)

+- Manage Version history limits for a Site using [**Set-SPOSite**](/powershell/module/sharepoint-online/set-sposite)

+- Review progress of settings update on existing libraries in a Site using Get-SPOSiteVersionPolicyJobProgress

+- Cancel an in-progress settings update job using Remove-SPOSiteVersionPolicyJob

+ Title: "Terms and Conditions"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "Learn the terms and conditions for versions."

+# Microsoft SharePoint Version History Limits Public Preview Terms and Conditions

+**Effective Date: March 2024**

+**'Customer'** means the Enterprise customer that uses these Preview Features.

+**By using these Preview Features, you accept these Terms and Conditions and all rights and obligations within**.**If you do not agree to these Terms and Conditions, DO NOT use the Preview Feature.** These Terms and Conditions govern the use of the Preview Feature offerings as described in the following sections.

+'Feedback' is all suggestions, comments, feedback, ideas, or know how, in any form, that Customer provides to Microsoft. It doesn't include sales forecasts, financial results, future release scheduled, marketing plans and high-level product plans or feature lists for anticipated products.

+**MICROSOFT OFFERINGS:**

+**Version History Limits ('Preview Feature')** is a new functionality where there are two version control modes ΓÇô **Automatic mode** that consider important factors like a versionΓÇÖs age and restore probability to offer more intelligent version pruning options & **Manual mode** that allows Admins to set Version Expiration and Count limits on the versions created. Version history settings for Document Libraries can be set at Organization, Site, or individual library level allowing admins and site owners the ability to better manage content recovery and auditing requirements.

+**THE PREVIEW FEATURE IS PROVIDED 'AS-IS,' 'WITH ALL FAULTS,' AND 'AS AVAILABLE.'** Microsoft provides no performance guarantee for the Feature Preview (including accompanying URLs provided for embedded or unauthenticated viewing) and Customer bear the risk of using it. As this is a Preview, *We recommend you to try this feature in a nonproduction tenant environment*.

+No SLA applies to this Feature Preview.

+## LICENSE

+If Customer provides Feedback, Customer grants to Microsoft, without charge, the nonexclusive License to make, modify, distribute, or otherwise commercialize the Input as part of any Microsoft offering.

+This License doesn't extend to any technologies that may also be necessary to make or use any offering or portion thereof that incorporates the Feedback. These technologies aren't themselves expressly part of the Feedback (for example, enabling technologies).

+## LENGTH OF OBLIGATIONS; DISCLOSURE

+**Preview Period.** The Preview Period continues in effect until 30 days after Commercial General Availability of the Preview Features, but no longer than 1 year from the effective date. Customer may terminate their use of the Preview Features at any time. Terminating use of the Preview Feature doesn't change any of the rights, licenses granted, or duties made while the Preview Period is in effect. Termination is defined as:

+1. The CompanyΓÇÖs termination of use of the Preview Feature and/or.

+1. The Preview Period ends.

+**Effects upon Termination by company.** Once terminated by company, version history configurations remain, no reversions of the configurations happen automatically. Company has the ability to change version history.

+This Agreement can't be extended. Microsoft may also choose not to make the Preview Features commercially available.

+## REPRESENTATIONS AND LIMITATIONS

+**Input.** Customer represents that it doesn't provide any Feedback that:

+1. Violates any copyright or trade secret claim or right of any third party;

+1. It has reason to believe violates any patent claim or right of any third party; or

+1. Is subject to an excluded license.

+**Authority.** Customer represents it has all rights and authority necessary to be legally bound to these Terms and Conditions and grant the rights described therein for itself and its affiliates.

+**Limitations.** All information, materials, and feedback are provided 'as-is' and Microsoft bears the risk of using them. Customer gives no express warranties, guarantees, or conditions as to its Feedback. To the extent permitted under local law, Customer excludes the implied warranties of merchantability, fitness for a particular purpose, title, and noninfringement as to its Input.

+## LIMITATIONS ON AND EXCLUSIONS OF REMEDIES AND DAMAGES

+Except as described in this document, the only remedy for claims relating to these Terms and Conditions is for Customer to terminate its use of the Preview Feature. Neither Party can recover any damages, including direct, consequential, lost profits, special, punitive, indirect, or incidental damages from the other. This limitation applies:

+1. To claims for breach of contract, breach of warranty, guarantee or condition, strict liability, negligence, or other tort to the extent permitted by applicable law.

+1. Even if one of us knew or should have known about the possibility of the damages.

+The limitations in this section don't apply to claims arising from or with any infringement, misuse, or misappropriation by one of us of the otherΓÇÖs intellectual property rights.

+ Title: "Trim existing versions on site, library, or OneDrive(Preview)"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "This article provides guidance on how to trim existing versions from site, library, or OneDrive account."

+# Trim existing versions from site, library, or OneDrive(Preview)

+> [!CAUTION]

+> Versions deleted using trimming jobs are permanently deleted. This deletion workflow bypasses the normal recycle bin retention and deleted versions cannot be recovered.

+As a global or SharePoint admin in Microsoft 365, you can queue a job to trim existing versions on a site, library, or OneDrive user account to reduce the version storage footprint of your site. You can also align existing version storage with updated version history limits by scheduling a job to trim existing versions or align existing version storage with updated Version history limits.<br> There are several things you need to consider before you decide to trim existing Version history on a site or library. Version availability is critical for recovery scenarios like undoing unwanted changes. Versions deleted using trimming jobs are permanently deleted and can't be recovered from recycle bin.

+| **Phase** | **Recommended Actions** |

+| | |

+| Prepare | **Evaluate your recovery objectives and target version storage use:** Determine the right trim mode and trim scope that you need to meet your organizationΓÇÖs recovery objectives.<br><br>**Review Impact:** Before committing to trim existing versions, you have the option to review the impact of the purge action by running a ΓÇÿWhat-ifΓÇÖ analysis operation of the selected trim mode on the specified scope. |

+| Queue Job | Once you're ready to commit to a trim job, you can queue a version trimming job to asynchronously delete versions matching the criteria specified in the trim mode within a site, library, or OneDrive user account. |

+| Track Progress | You can track the progress of all queued jobs to review the progress made in trimming versions. |

+## Review impact by running ΓÇÿWhat-ifΓÇÖ analysis

+Before committing to trim existing versions, you can review the impact of the purge action by running a ΓÇÿWhat-ifΓÇÖ analysis operation. Running a ΓÇÿWhat-ifΓÇÖ operation will follow these steps:

+- **Generate a Version Storage usage report for a site or library**: This report can support multiple uses including, version storage use analytics or to gain key insights on the impact of applying different trimming settings.

+- **Run ΓÇÿWhat-IfΓÇÖ analysis** by setting different trimming modes to preview the changes and analyze the user and storage savings impact of applying one of the trimming modes to the version storage report csv file.

+> [!IMPORTANT]

+> Depending on the size of the site or library, the job can take a few days to complete. Check the progress of the job until the status returns as ΓÇ£completedΓÇ¥.

+## Version trim modes

+Version trimming workflows allow you to select and apply one of the trimming modes for scheduling a trim job on a site, document library, or OneDrive account.

+**Manual expiration trim mode:** Evaluates the age of versions and deletes versions matching the expiration criteria.

+**Example:** In the example below, a trim job is queued to trim versions older than 60 days. On August 31, the job is picked up and it starts permanently deleting versions older than 60 days as of August 31.

+ :::image type="content" source="media/version-history/manual-expiration-trim-table.png" lightbox="media/version-history/manual-expiration-trim-table.png" alt-text="Diagram of manual expiration.":::

+> [!IMPORTANT]

+> Known limitations of manual expiration mode

+> 1. The expire trim mode doesn't delete versions created in the last 30 days. This means your input can't be less than 30 days.

+> 1. The expire trim mode always deletes all versions that were created before January 1, 2023. If you want to trim versions, you can't keep any older than that. This means the value you use for the `DeleteBeforeDays` parameter should result in date after January 1, 2023.

+**Manual count limit trim mode:** Deletes the oldest versions exceeding the specified count limit.

+**Example:** In the example below, a trim job is queued to delete versions that exceed 50 major version counts. On August 31, the job starts permanently deleting older versions that exceed the 50 major version count limit as of August 31.

+ :::image type="content" source="media/version-history/manual-count-limit-trim-table.png" lightbox="media/version-history/manual-count-limit-trim-table.png" alt-text="Diagram of manual count limit.":::

+**Automatic trim mode:** Applies Automatic algorithm to delete existing versions. Depending on the version age, the job will permanently delete versions or set expiration time according to the automatic version storage algorithm.

+> [!TIP]

+> Review the [tutorial to run impact analysis of of setting automatic version history limits](tutorial-run-what-if-analysis.md#run-impact-analysis-of-setting-automatic-version-history-limits) to understand version deletion and expiration criteria.

+## Queue trim job and track progress

+The version trimming workflow uses a job to asynchronously delete versions matching the criteria specified in the trim mode.

+To queue the trim job, you need to determine the scope for version deletion and the trim mode to set the criteria for existing version deletion. You can delete old file versions based on version age, count limits, or automatic algorithm for all document libraries in a site or for a specific document library.  

+Once you're ready to commit to the trim, you can queue the job to asynchronously delete versions matching the trim mode criteria. You'll be able to monitor the progress of committed trim jobs to keep track of the deletion progress.

+## Trim existing versions using PowerShell

+Follow these steps to trim existing versions using PowerShell.

+1. [Download the latest SharePoint Online Management Shell](https://go.microsoft.com/fwlink/p/?LinkId=255251).

+ > [!NOTE]

+ > If you installed a previous version of the SharePoint Online Management Shell, go to Add or Remove programs and uninstall **SharePoint Online Management Shell**.

+1. Connect to SharePoint as a [Global Administrator or SharePoint Administrator](/sharepoint/sharepoint-admin-role) in Microsoft 365. To learn how, see [Getting started with SharePoint Online Management Shell](/powershell/sharepoint/sharepoint-online/connect-sharepoint-online).

+2. Run one of the following commands to trim the existing versions:

+| **Action** | **PowerShell Command** |

+| | |

+| Queue a trim job to expire versions | **Expire versions on a site:**<br><br>`New-SPOSiteFileVersionBatchDeleteJob -Identity $siteUrl -DeleteBeforeDays <days>`<br><br>**Expire versions on a library:**<br><br>`New-SPOListFileVersionBatchDeleteJob -Site $siteUrl -list $libName -DeleteBeforeDays <days>` |

+| Queue a trim job to delete versions exceeding the specified count limit | **Delete versions exceeding count limits from a site:**<br><br>`New-SPOSiteFileVersionBatchDeleteJob -Identity $siteUrl -MajorVersionLimit <delete major versions exceeding limit> -MajorWithMinorVersionsLimit <delete minor versions exceeding limit>`<br><br>**Delete versions exceeding count limits from a library:**<br><br>`New-SPOListFileVersionBatchDeleteJob -Site $siteUrl -list $libName -MajorVersionLimit <delete major versions exceeding limit> -MajorWithMinorVersionsLimit <delete minor versions exceeding limit>` |

+| Queue trim job to delete versions using the estimated automatic trimming algorithm | **Apply automatic logic to trim existing versions from a Site:**<br><br>`New-SPOSiteFileVersionBatchDeleteJob -Identity $siteUrl -Automatic`<br><br>**Apply automatic logic to trim existing versions from a library:**<br><br>`New-SPOListFileVersionBatchDeleteJob -Site $siteUrl -List $libName -Automatic` |

+| Stop further processing of an in-progress trim job<br><br>**Note:** Once the cmdlet executes successfully, all new asynchronous version deletion is stopped. Stopping a trim job doesn't impact versions that are permanently deleted when the job was in progress. | **To stop processing an in-progress site level trim job:**<br><br>`Remove-SPOSiteFileVersionBatchDeleteJob -Identity $siteUrl`<br><br>**To stop processing an in-progress library level trim job:**<br><br>`Remove-SPOListFileVersionBatchDeleteJob -Site $siteUrl -List $libName` |

+| Get the status for a file version trimming job | **To get status of a site level trimming job:**<br><br>`Get-SPOSiteFileVersionBatchDeleteJobProgress -Identity $siteUrl`<br><br>**To get status of a library level trimming job:**<br><br>`Get-SPOListFileVersionBatchDeleteJobProgress -Site $siteUrl -List $libName` |

+## Learn More

+For more information, check out the following resources:

+- [Tutorial: Generate Version Usage Report](tutorial-generate-version-usage-report.md).

+- [Tutorial: Run 'What-If' analysis](tutorial-run-what-if-analysis.md).

+- [Tutorial: Queue Trim Job](tutorial-queue-a-trim-job.md).

+ Title: "Tutorial: Generate and analyze version usage report (Preview)"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "This article provides guidance on how to generate and analyze version usage report for SharePoint Site."

+# Tutorial: Generate and analyze version usage report for SharePoint site (Preview)

+By understanding version storage on a site, you can better optimize the Version history settings to meet your organizationΓÇÖs recovery objectives and manage storage costs.

+This tutorial shows how you can generate a version storage usage report and analyze it to better understand the version storage footprint of the site. The report can also be used to [run ΓÇÿwhat-ifΓÇÖ analysis](tutorial-run-what-if-analysis.md) of applying different version limits or trimming existing versions.

+In this tutorial we cover how to:

+- Generate version storage usage report file for site or library.

+- Check progress of report generation.

+- Understand the report file.

+- Analyze version storage use using Excel or PowerShell.

+In later tutorials, review how you can run impact analysis on the generated CSV report.

+## Before you begin

+1. Identify the SharePoint site, OneDrive account, or document library whose version storage usage you want to understand.

+2. Choose a location within the SharePoint document library that you want to save the report to.

+1. [Download the latest SharePoint Online Management Shell](https://www.microsoft.com/en-us/download/details.aspx?id=35588).

+> [!NOTE]

+> 1. The report file is generated within the report location specified.

+> 2. The report location must be within a SharePoint document library itself.

+> 3. There cannot be a file with the same name as the report in the document library.

+## Generate version usage report for sites or library

+You can generate a report on the current version storage use on a site by running the `New-SPOSiteFileVersionExpirationReportJob` command or on a library by running the `New-SPOListFileVersionBatchDeleteJob` command.

+In the example below, a job is queued to generate a site-scoped report at the report location, `https://contoso.sharepoint.com/SharedDocuments/SiteReport.csv`.

+```PowerShell

+New-SPOSiteFileVersionExpirationReportJob -Identity https://contoso.sharepoint.com/sites/site1 -ReportUrl "https://contoso.sharepoint.com/sites/sites1/reports/MyReports/VersionReport.csv"

+```

+In the example below, a job is queued to generate a library-scoped report at the report location, `https://contoso.sharepoint.com/SharedDocuments/SiteReport.csv`.

+```PowerShell

+New-SPOListFileVersionExpirationReportJob -Site https://contoso.sharepoint.com/sites/site1 -List "Documents" -ReportUrl "https://contoso.sharepoint.com/sites/sites1/reports/MyReports/VersionReport.csv"

+```

+## Check progress on the report generation

+Use the `Get-SPOListFileVersionExpirationReportJobProgress` command to track the progress of report generation request.

+The example below shows how you can check if your **site scoped report** is fully populated and ready to be analyzed.ΓÇ»

+```PowerShell

+Get-SPOSiteFileVersionExpirationReportJobProgress -Identity https://contoso.sharepoint.com/sites/site1 -ReportUrl "https://contoso.sharepoint.com/sites/sites1/reports/MyReports/VersionReport.csv"

+```

+The example below shows how you can check if your **library scoped report** is fully populated and ready to be analyzed.

+ΓÇ»

+```PowerShell

+Get-SPOListFileVersionExpirationReportJobProgress -Site https://contoso.sharepoint.com/sites/site1 -List "Documents" -ReportUrl "https://contoso.sharepoint.com/sites/sites1/reports/MyReports/VersionReport.csv"

+```

+The cmdlet will return a response in JSON format. The returned json response has a key named status. Refer to the table below for one of the following expected values:ΓÇ»

+| JSON Status Response | Explanation |

+| | |

+| ΓÇ£completedΓÇ¥ | The job has successfully completed and the report is fully populated. |

+| ΓÇ£in_progressΓÇ¥ | There is an active job. The report is partially populated. |

+| ΓÇ£no_report_foundΓÇ¥ | There are no active jobs populating the specified file. |

+| ΓÇ£failed, error message:ΓÇ¥ | The job to generate the report has failed due to the error message. |

+## Understand version report file

+The generated report is in CSV format with each row corresponds to a file version.

+HereΓÇÖs an example of file version expiration report and its column breakdown.

+The first row is the header with the column identifiers containing File Version Identifiers, Version Metadata information, and expiration timestamp. Compact columns are denoted with ΓÇ£.CompactΓÇ¥ post-fix that wonΓÇÖt repeat values if two consecutive rows have the same value. The other rows represent file versions, where each row represents a single version.

+LetΓÇÖs go through the first file version displayed in this report.

+- File version identifiers: `WebId`, `DocId`, `MajorVersion`, and `MinorVersion` uniquely identify each version in your SharePoint site.

+- Version metadata identifiers:`WebUrl` indicates the version in `https://contoso.sharepoint.com`, and `FileUrl` indicates that the file for this version is located at DocLib/MyDocument.docx. In other words, it is in a Document Library called `DocLib`, while the file is in the root folder of `DocLib` and is named MyDocument.docx.

+- `Size` indicates that the version takes 92,246 bytes of storage.

+- The next two columns, `ModifiedBy_UserId` and `ModifiedBy_DisplayName` indicate that the user Michelle Harris (with user ID 6) has created this version.

+- `LastModifiedDate` indicates that the versionΓÇÖs content was last modified on March 13, 2023, at 22:36:09 UTC. `SnapshotDate` displays that the version became a historical version on March 20, 2023, at 16:56:51 UTC. `IsSnapshotDateEstimated` shows that `SnapshotDate` is the actual snapshot date.

+- Expiration schedule identifiers:`CurrentExpirationDate` indicates that this version is currently set to never expire. `AutomaticPolicyExpirationDate` shows that under the automatically expire policy, this version is also set to never expire. `TargetExpirationDate` indicates that if we follow this schedule for trimming, we would set this version to never expire.

+LetΓÇÖs look at the third version.

+The `WebId` and `DocId` values are empty because these columns are compact columns, denoted by *.Compact* post-fix, it means they should have values. If we look for the last nonempty above that row, we find `WebId` as `4c7a58c1-01f2-4fa3-a730-44081a44f689`, and `DocId` as `18c3e09c-b5be-48e7-a754-7a2ce53e0999`.

+We can also see that the `TargetExpirationDate` is set for April 19, 2023, at 18:08:53 UTC. It means if we trim based on this schedule, we would be setting the expiration date for this version to that time. However, at the time this documentation was written, it passed April 19, 2023. Instead of setting the version to expire, the document is deleted immediately.

+> [!NOTE]

+> All date times are represented in the round-trip format. For more information, see [Standard date and time format strings - .NET | Microsoft Learn](/dotnet/standard/base-types/standard-date-and-time-format-strings)

+## Analyze version storage for sites

+After configuring the `TargetExpirationDate` values for your report, you can choose to perform deeper analysis to see the impact of the trimming before running an actual trim. You can perform this analysis independently, or alternatively, we provide two recommended options for your analysis.

+### Option one: Analyze the report using Excel

+Open the shared Excel workbook **AnalyzeReportFile_Template.xlsx**. You can find the following worksheets in it.

+- **Configuration**: Use this worksheet to set the date range for generating the different report views.

+- **Dataset**: This worksheet is the raw dataset imported from the report file. Various reporting summary views are constructed from this dataset.

+- **Preset Reports**: Here's a list of preset views that can be used to understand the impact of applying the selected setting on versions stored in the site:

+ - **Summary**: Analyze the current state of version storage for this site and deleted version distribution under the new settings.

+ - **Impacted Users**: Review the users whose versions would be impacted under the new settings.

+ - **Version Count**: A table and graph showing the numbers of versions that will be available over time under the current schedule and the number of versions that will be available under the new schedule.

+ - **Size of Versions Expired**: Compare the size of versions that will be deleted over time under the current schedule and the number of versions that will be available under the new schedule.

+ - **File Level Analysis**: Review file level version deletions under the new settings.

+Populate the workbook by following these steps:

+1. On the **Configuration** worksheet, enter the full path to the What-If report file in **Cell B3**.

+2. If you want to change the date range of graphs in **Number of Versions Available** worksheet, or **Size of Versions Expired** worksheet, change the corresponding values in Cells B6, B7, B10, and/or B11. It's optional.

+3. At the top of Excel, select the **Data** tab, and in the Ribbon, select the **Refresh All** button.

+4. On the **Calculations** worksheet, autofill the **Number of Versions** and **Number of Versions Remaining After Deletion** columns.

+5. On the **Impacted Users** worksheet, autofill the **Number of Versions Will be Deleted** column.

+All worksheets should now be up to date. You can check the information you're interested in.

+### Option two: Analyze the report using PowerShell

+1. Save the script as a file named **AnalyzeReportFile.ps1.**

+```PowerShell

+# save this file as AnalyzeReportFile.ps1

+Param(

+ [Parameter(Mandatory=$true)][string] $ReportLocalFilePath,

+ [Parameter(Mandatory=$false)][int]$ShowFilesWithFewerThanNVersions=10,

+ [Parameter(Mandatory=$false)][DateTime]$TimelineStartDate=[DateTime]::Now,

+ [Parameter(Mandatory=$false)][int]$TimelineStepDays=10,

+ [Parameter(Mandatory=$false)][int]$TimelineNumSteps=10

+)

+function Import-Dataset($DatasetFilePath)

+{

+ $Dataset = Import-CSV $DatasetFilePath

+ $Columns = $Dataset `

+ | Get-Member -MemberType 'NoteProperty' `

+ | Select-Object -ExpandProperty Name

+ $CompactColumns = $Columns | Where-Object { $_ -Match ".Compact" }

+

+ $Timer = [Diagnostics.Stopwatch]::StartNew()

+ for ($RowIndex = 0; $RowIndex -lt $Dataset.Count; $RowIndex++)

+ {

+ if ($RowIndex -gt 0)

+ {

+ $PrevRow = $Dataset[$RowIndex-1]

+ }

+ $Row = $Dataset[$RowIndex]

+

+ foreach ($ColName in $Columns)

+ {

+ if ([string]::IsNullOrEmpty($Row.$ColName))

+ {

+ if (($ColName -in $CompactColumns) -and ($RowIndex -gt 0))

+ {

+ $Row.$ColName = $PrevRow.$ColName

+ }

+ else

+ {

+ $Row.$ColName = $null

+ }

+ }

+ }

+

+ $Row."WebId.Compact" = [Guid]$Row."WebId.Compact"

+ $Row."DocId.Compact" = [Guid]$Row."DocId.Compact"

+ $Row."MajorVersion" = [Int32]$Row."MajorVersion"

+ $Row."MinorVersion" = [Int32]$Row."MinorVersion"

+ $Row."WebUrl.Compact" = [String]$Row."WebUrl.Compact"

+ $Row."FileUrl.Compact" = [String]$Row."FileUrl.Compact"

+ $Row."Size" = [Int64]$Row."Size"

+ $Row."ModifiedBy_UserId.Compact" = [Int32]$Row."ModifiedBy_UserId.Compact"

+ $Row."ModifiedBy_DisplayName.Compact" = [String]$Row."ModifiedBy_DisplayName.Compact"

+ $Row."LastModifiedDate" = [DateTime]$Row."LastModifiedDate"

+ $Row."SnapshotDate" = [DateTime]$Row."SnapshotDate"

+ $Row."IsSnapshotDateEstimated" = [bool]$Row."IsSnapshotDateEstimated"

+ $Row."CurrentExpirationDate" = [System.Nullable[DateTime]]$Row."CurrentExpirationDate"

+ $Row."AutomaticPolicyExpirationDate" = [System.Nullable[DateTime]]$Row."AutomaticPolicyExpirationDate"

+ $Row."TargetExpirationDate" = [System.Nullable[DateTime]]$Row."TargetExpirationDate"

+ $Percent = [Math]::Ceiling(100 * $RowIndex / $Dataset.Count)

+ Write-Progress `

+ -Activity "Reading dataset" `

+ -Status "$Percent% Complete ($($RowIndex + 1) / $($Dataset.Count) rows):" `

+ -PercentComplete $Percent `

+ -SecondsRemaining $(($Dataset.Count - ($RowIndex + 1)) / (($RowIndex + 1) / $Timer.Elapsed.Totalseconds))

+ }

+ $Timer.Stop()

+ return $Dataset

+}

+function Get-NumVersionExpiresByDate($Dataset, $ColName, $DateCutoff)

+{

+ $VersionsExpired = $Dataset | Where-Object { ($null -ne $_.$ColName) -and ($_.$ColName -le $DateCutoff) }

+ $IsTodayStr = ""

+ If ((Get-Date).Date -eq ($DateCutoff).Date)

+ {

+ $IsTodayStr = "*"

+ }

+ return [PSCustomObject]@{

+ Today = $IsTodayStr

+ Date = $DateCutoff

+ NumberOfVersionsAvailable = $Dataset.Count - $VersionsExpired.Count

+ NumberOfVersionsExpired = $VersionsExpired.Count

+ SizeOfVersionsExpiredInBytes = ($VersionsExpired | Measure-Object Size -Sum).Sum

+ }

+}

+function Get-FilesWithFewerThanNVersions($Dataset, $NumVersions)

+{

+ $AvailableVersionsByFile = $Dataset `

+ | Where-Object { ($null -eq $_.TargetExpirationDate) -or ($_.TargetExpirationDate -gt [DateTime]::Now) } `

+ | Group-Object -Property WebId.Compact, DocId.Compact

+ $AvailableFilesWithNotEnoughVersions = @{}

+ # Files with some versions left but not enough

+ $AvailableVersionsByFile `

+ | Where-Object Count -lt $NumVersions `

+ | ForEach-Object { $AvailableFilesWithNotEnoughVersions[$_.Name] = $_.Count }

+ # Files with 0 versions left

+ $Dataset `

+ | Group-Object -Property WebId.Compact, DocId.Compact `

+ | Where-Object { $AvailableVersionsByFile.Name -notcontains $_.Name } `

+ | ForEach-Object { $AvailableFilesWithNotEnoughVersions[$_.Name] = 0 }

+ # Stitch all of the data together

+ return $Dataset `

+ | Group-Object -Property WebId.Compact, DocId.Compact `

+ | Where-Object Count -ge $NumVersions `

+ | Where-Object { $AvailableFilesWithNotEnoughVersions.Contains($_.Name) } `

+ | ForEach-Object `

+ {

+ $fileUrl = $_.Group[0]."WebUrl.Compact" + "/" + $_.Group[0]."FileUrl.Compact"

+ $numberOfVersionsAvailableBeforeTrim = $_.Count

+ $numberOfVersionsAvailableAfterTrim = $AvailableFilesWithNotEnoughVersions[$_.Name]

+ $numberOfVersionsTrimmed = $numberOfVersionsAvailableBeforeTrim - $numberOfVersionsAvailableAfterTrim

+ [PSObject]::new() |

+ Add-Member -PassThru -NotePropertyMembers ([Ordered]@{

+ FileUrl = $fileUrl

+ NumberOfVersionsAvailableBeforeTrim = $numberOfVersionsAvailableBeforeTrim

+ NumberOfVersionsAvailableAfterTrim = $numberOfVersionsAvailableAfterTrim

+ NumberOfVersionsTrimmed = $numberOfVersionsTrimmed

+ })

+ } `

+ | Sort-Object -Property NumberOfVersionsAvailableAfterTrim

+}

+function Get-MostImpactedUsers($Dataset)

+{

+ $VersionsExpired = $Dataset | Where-Object { ($null -ne $_.TargetExpirationDate) -and ($_.TargetExpirationDate -le [DateTime]::Now) }

+ return $VersionsExpired `

+ | Group-Object -Property ModifiedBy_UserId.Compact `

+ | Select-Object `

+ @{ L = "UserId"; E = { $_.Group[0]."ModifiedBy_UserId.Compact" } }, `

+ @{ L = "UserDisplayName"; E = { $_.Group[0]."ModifiedBy_DisplayName.Compact" } },

+ @{ L = "NumberOfVersionsTrimmed"; E = { $_.Count } } `

+ | Sort-Object -Property NumberOfVersionsTrimmed -Descending

+}

+$Dataset = Import-Dataset -DatasetFilePath $ReportLocalFilePath

+$CurrentExpirationSummaryTable = @()

+$TargetExpirationSummaryTable = @()

+$Timer = [Diagnostics.Stopwatch]::StartNew()

+for ($Step = 0; $Step -lt $TimelineNumSteps; $Step++)

+{

+ $DateCutOff = $TimelineStartDate.AddDays($TimelineStepDays * $Step)

+ $CurrentExpirationSummaryTable += `

+ Get-NumVersionExpiresByDate -Dataset $Dataset -ColName CurrentExpirationDate -DateCutoff $DateCutOff

+ $TargetExpirationSummaryTable += `

+ Get-NumVersionExpiresByDate -Dataset $Dataset -ColName TargetExpirationDate -DateCutoff $DateCutOff

+}

+$Timer.Stop()

+Write-Host "===========================" -ForegroundColor Yellow

+Write-Host "Current Expiration Schedule" -ForegroundColor Yellow

+Write-Host "===========================" -ForegroundColor Yellow

+$CurrentExpirationSummaryTable | Format-Table -Autosize | Out-String | Write-Host

+Write-Host "Total elapsed seconds: $($Timer.Elapsed.TotalSeconds / 2)" -ForegroundColor Green

+Write-Host

+Write-Host "==========================" -ForegroundColor Yellow

+Write-Host "Target Expiration Schedule" -ForegroundColor Yellow

+Write-Host "==========================" -ForegroundColor Yellow

+$TargetExpirationSummaryTable | Format-Table -Autosize | Out-String | Write-Host

+Write-Host "Total elapsed seconds: $($Timer.Elapsed.TotalSeconds / 2)" -ForegroundColor Green

+Write-Host

+Write-Host "================================" -ForegroundColor Yellow

+Write-Host "Files with Fewer Than $ShowFilesWithFewerThanNVersions Versions" -ForegroundColor Yellow

+Write-Host "================================" -ForegroundColor Yellow

+$Timer = [Diagnostics.Stopwatch]::StartNew()

+Get-FilesWithFewerThanNVersions -Dataset $Dataset -NumVersions $ShowFilesWithFewerThanNVersions | Format-Table -Autosize | Out-String | Write-Host

+$Timer.Stop()

+Write-Host "Total elapsed seconds: $($Timer.Elapsed.TotalSeconds)" -ForegroundColor Green

+Write-Host

+Write-Host "==============" -ForegroundColor Yellow

+Write-Host "Users Impacted" -ForegroundColor Yellow

+Write-Host "==============" -ForegroundColor Yellow

+$Timer = [Diagnostics.Stopwatch]::StartNew()

+Get-MostImpactedUsers -Dataset $Dataset | Format-Table -Autosize | Out-String | Write-Host

+$Timer.Stop()

+Write-Host "Total elapsed seconds: $($Timer.Elapsed.TotalSeconds)" -ForegroundColor Green

+Write-Host

+```

+2. Open PowerShell 7 and run the following command, replacing the placeholder values with the appropriate values.

+```PowerShell

+. ΓÇ£<path to AnalyzeReportFile.ps1>ΓÇ¥ ΓÇôReportLocalFilePath ΓÇ£<path to the file version expiration What-If report .csv file>ΓÇ¥

+```

+3. The output displays four tables:

+- **Current Expiration Schedule:** this table contains a time-series summary for your versions as they are. It has the following columns:

+ 1. **Date**: the first column represents the date.

+ 1. **NumberOfVersionsAvailable**: the number of versions available on that date under the current schedule.

+ 1. **NumberOfVersionsExpired**: the number of versions expired on that date under the current schedule.

+ 1. **SizeOfVersionsExpiredMB**: the size of versions expired on that date under the current schedule.

+- **Target Expiration Schedule:** this table is the same as Current Expiration Schedule but reflects the updated schedule instead. This table is only helpful if you want to test out different expiration scenarios by changing the **TargetExpirationDate** column in the file version expiration report.

+- **Files with Fewer Than 10 Versions:** a list of the URLs, and the number of versions before and after the deletion for those files whose number of versions is fewer than 10 after immediate deletion (but was more than 10 before the immediate deletion).

+- **Users Impacted:** the users whose versions would be immediately deleted.

+Optionally, you can adjust the parameters:

+- `TimelineStartDate`: the starting date for Table 1 and 2 above.

+- `TimelineStepDays`: the number of days in between rows for Table 1 and 2 above.

+- `TimelineNumSteps`: the number of rows to calculate for Table 1 and 2 above.

+- `ShowFilesWithFewerThanNVersions`: the threshold for the number of versions in Table 3 above.

+ Title: "Tutorial: Manage version history limits on a site, library, or OneDrive account (Preview)"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "This article provides guidance on how to manage Version history limits for a site, library, or OneDrive account."

+# Tutorial: Manage version history limits for a site, library, or OneDrive account (Preview)

+In this tutorial, you will learn how to manage the version history limits for a site, document library, or OneDrive account. You will learn how to:

+- Set Version history limits settings on the site.

+- Stop an in-progress settings update job.

+## Before you begin

+- Review your **organizationΓÇÖs recovery objectives** and **version storage use quota targets** along with the **site-specific version storage needs** to evaluate if a break of inheritance of version settings at site, library, or OneDrive account level is needed.

+- If needed **run an impact analysis** with the desired setting, to understand the impact the new setting would have using current version storage usage patterns.

+- For site version settings, evaluate the scope of document libraries that should be updated. Depending on business need, you can choose one of the following:

+ - Update new libraries only without impacting existing library settings.

+ - Update existing libraries only and inherit organization default settings for new libraries.

+ - Update both existing and all new libraries for consistent version storage at the site level.

+## Set version limits for a site

+You can set version limits on a site by running the [**Set-SPOSite**](/powershell/module/sharepoint-online/set-sposite) command to break inheritance from the organization version history limits.

+- Use the `ΓÇôApplyToNewDocumentLibraries` parameter to apply the changes only to new libraries created in the site.

+- Use the `ΓÇôApplyToExistingDocumentLibraries` to only update the Version history limits on existing libraries on a site. Any new library created inherits the default organization limits.

+### Example: Apply automatic version history limits to all document libraries on a site

+Run the following commands to **apply Automatic setting** to all document libraries on a site.

+```PowerShell

+Set-SPOSite -Identity https://contoso.sharepoint.com/sites/site1 -EnableAutoExpirationVersionTrim $true

+```

+### Example: Apply automatic version history limits to new document libraries on a site

+In the following example, Automatic Version history limits are applied to all new document libraries created on the site. The settings on existing libraries will not be impacted.

+

+```PowerShell

+ Set-SPOSite -Identity https://contoso.sharepoint.com/sites/site1 -EnableAutoExpirationVersionTrim $true -ApplyToNewDocumentLibraries

+```

+### Example: Apply manual setting with count and time version history limits to existing libraries only on a site

+In the following example, Version history limits of all existing libraries on a site are updated to Manual Version history limits.

+```PowerShell

+Set-SPOSite -Identity https://contoso.sharepoint.com/sites/site1 -EnableAutoExpirationVersionTrim $false -MajorVersionLimit 500 -ExpireVersionsAfterDays 30 -ApplyToExistingDocumentLibraries

+```

+## Cancel an in-progress request to update version history limits on existing libraries

+If required, you can cancel the update job that is currently `<InProgress>` using the `Remove-SPOSiteVersionPolicyJob`.

+> [!NOTE]

+> Cancelling the job doesn't revert the change for document libraries where the update is already processed.

+In the example below, the in-progress job to update settings on site will be stopped.

+```PowerShell

+Remove-SPOSiteVersionPolicyJob -Identity https://contoso.sharepoint.com/sites/site1

+```

+## Learn More

+- Track progress of version settings update request for existing document libraries on a site using [Get-SPOSiteVersionPolicyJobProgress](/powershell/module/sharepoint-online/get-spositeversionpolicyjobprogress).

+- Cancel further processing of version settings update on existing document libraries on the site collection using [Remove-SPOSiteVersionPolicyJob](/powershell/module/sharepoint-online/remove-spositeversionpolicyjob).

+ Title: "Tutorial: Queue a trim job(Preview)"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "This article provides guidance on how to queue a trim job for a site or document library."

+# Tutorial: Queue a trim job for a site or document library(Preview)

+In this tutorial, you'll learn how to trim existing versions from a site or library by queuing a trim job using PowerShell. You'll learn how to:

+- Queue a job to trim versions from a site.

+- Queue a job to trim versions from a library.

+- Check progress of your trim job.

+- Stop an in-progress trim job.

+## Before you begin

+Versions deleted by a trim job are permanently deleted and can't be recovered from the recycle bin. We recommend you prepare by performing the following actions:

+- Review your **organizationΓÇÖs recovery objectives** and **version storage usage quota targets** to help determine the trim action and scope needed to meet your requirements.

+

+- If needed, [run an impact analysis](tutorial-run-what-if-analysis.md) to understand the trimming impact.

+- Determine the **scope of** version deletion. You can create jobs to delete old file versions for all document libraries in a site or for a specific document library.

+- Determine the **trim mode** you want to apply on existing versions. You can choose to delete based on version age, count limit, or based on the automatic algorithm.

+## Queue a job to trim versions on site

+You can queue a job to trim versions for all document libraries in the site collection using the `New-SPOSiteFileVersionBatchDeleteJob` PowerShell command.

+- Use the `-<DeleteBeforeDays>` parameter to specify the age criteria you wish to apply for deleting versions. Versions older than the specified days are deleted asynchronously in batches in the upcoming days.

+- Use the `<MajorVersionLimit>` to specify the count limit of major versions to store. Oldest versions exceeding the specified count are deleted asynchronously in batches in the upcoming days.

+- Use the `<Automatic>` parameter to apply Automatic setting trimming logic on existing file versions.

+### Example: Queue a job to trim versions based on age for all libraries on a site

+In the example below, the job is queued to trim versions that are older than 180 days old for all document libraries in the site collection `https://contoso.sharepoint.com/sites1`.

+```PowerShell

+New-SPOSiteFileVersionBatchDeleteJob -Identity https://contoso.sharepoint.com/sites/site1 -DeleteBeforeDays 360

+```

+### Example: Queue a job to trim oldest versions exceeding the specified count limit on a site

+In the example below, the job is queued to trim oldest versions that exceed 100 major version count limit for all document libraries in the site collection `https://contoso.sharepoint.com/sites/site1`.

+```PowerShell

+New-SPOSiteFileVersionBatchDeleteJob -Identity https://contoso.sharepoint.com/sites/site1 -MajorVersionLimit 100 -MajorWithMinorVersionsLimit 0

+```

+### Example: Queue a job to trim versions based on the automatic logic on a site

+In the example below, the job is queued to trim versions based on the Automatic algorithm for all document libraries in the site collection `https://contoso.sharepoint.com/sites/site1`.

+```PowerShell

+New-SPOSiteFileVersionBatchDeleteJob -Identity https://contoso.sharepoint.com/sites/site1 -Automatic

+```

+## Queue a job to trim versions on a document library

+You can queue a job to trim versions from a particular document library in the site collection using the `New-SPOListFileVersionBatchDeleteJob` PowerShell command.

+- Use the `<DeleteBeforeDays>` parameter to specify the age criteria you wish to apply for deleting versions. Versions older than the specified days are asynchronously in batches in the upcoming days.

+- Use the `<MajorVersionLimit>` to specify the count limit of major versions to store. Oldest versions exceeding the specified count are deleted asynchronously in batches in the upcoming days.

+- Use the `<Automatic>` parameter to apply Automatic setting trimming logic on existing file versions.

+### Example: Queue a job to trim versions based on age on a single library on a site

+To delete versions that are older than 360 days in document library 'Documents' in the site collection `https://contoso.sharepoint.com`.

+```PowerShell

+New-SPOListFileVersionBatchDeleteJob -Site https://contoso.sharepoint.com/sites/site1 -List "Documents" -DeleteBeforeDays 360

+```

+## Track progress of a trim job

+You can track progress of the trim job using the `Get-SPOSiteFileVersionBatchDeleteJobProgress` cmdlet.

+In the following example, the cmdlet reports the progress of the trim job for `https://contoso.sharepoint.com/sites/site1`

+```PowerShell

+Get-SPOSiteFileVersionBatchDeleteJobProgress -Identity https://contoso.sharepoint.com/sites/site1

+```

+## Stop an in-progress trim job

+If needed, you can cancel an in-progress trim job. Once the cmdlet executes successfully, the in-progress job is stopped and no further deletions happen.

+> [!NOTE]

+> Stopping a trim job doesn't revert versions that have already been deleted.

+### Example: Stop a site trim job

+To stop an in-progress trim job from additional version trimming on the site collection `https://contoso.sharepoint.com/sites/site1`:

+```PowerShell

+Remove-SPOSiteFileVersionBatchDeleteJob -Identity https://contoso.sharepoint.com/sites/site1

+```

+### Example: Stop a library trim job

+To stop an in-progress trim job from additional version trimming in document library 'Documents' in site collection `https://contoso.sharepoint.com/sites/site1`:

+```PowerShell

+Remove-SPOListFileVersionBatchDeleteJob -Site https://contoso.sharepoint.com/sites/site1 -List "Documents"

+```

+ Title: "Tutorial: Run 'What-If' analysis (Preview)"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "This article provides guidance on how to run 'What-If' analysis on version storage report file."

+# Tutorial: Run 'What-If' analysis on version storage report file (Preview)

+In this tutorial, we discuss how to leverage provided scripts and excel examples to understand the impact of applying either automatic or manual limits on version storage or impacted users. You will learn how to: :

+- Run impact analysis of setting Automatic limits.

+- Run impact analysis of expiring versions older than specified days.

+- Run impact analysis of storing version within specified count limits.

+## Before you begin

+In the previous tutorial, you had generated a version storage usage report. This tutorial assumes that the report generation job has successfully completed and the report is fully populated.<br>

+Start by downloading the report file to your local computer. Use the scripts provided below to apply the desired setting on the file and analyze the impact.

+## Run impact analysis of setting automatic version history limits

+Here's an example of PowerShell script you could apply to generate a What-If Report file that applies the **Automatic Expiration** policy on the report file `C:\Report.csv`.ΓÇ»

+```PowerShell

+# save this file as ScheduleUpdate_Auto.ps1

+param (

+  [Parameter(Mandatory=$true)][string]$ImportPath,

+  [Parameter(Mandatory=$true)][string]$ExportPath

+)

+$Schedule = Import-Csv -Path $ImportPath 

+$Schedule | 

+  ForEach-Object { 

+    $_.TargetExpirationDate = $_.AutomaticPolicyExpirationDate

+  } 

+$Schedule | 

+  Export-Csv -Path $ExportPath -UseQuotes AsNeeded -NoTypeInformation

+```

+## Run impact analysis of setting manual expiration limits

+Here's an example of PowerShell script to generate a What-If Report file. It applies **Manual Expiration** with expire-after days set to **30** on the report file `C:\Report.csv`.ΓÇ»

+```PowerShell

+# save this file as ScheduleUpdate_ExpireAfter.ps1

+param (

+  [Parameter(Mandatory=$false)][string]$ImportPath,

+  [Parameter(Mandatory=$false)][string]$ExportPath,

+  [Parameter(Mandatory=$false)][double]$ExpireAfter

+)

+function StringToDateTime($Value) { return [string]::IsNullOrEmpty($Value) ? $null : [DateTime]::ParseExact($Value, "yyyy-MM-ddTHH:mm:ssK", $null) }

+function DateTimeToString($Value) { return $null -eq $Value ? "" : $Value.ToString("yyyy-MM-ddTHH:mm:ssK") }  

+$Schedule = Import-Csv -Path $ImportPath 

+$Schedule | 

+  ForEach-Object { 

+    $SnapshotDate = StringToDateTime -Value $_.SnapshotDate

+    $TargetExpirationDate = $SnapshotDate.AddDays($ExpireAfter)

+    $_.TargetExpirationDate = DateTimeToString -Value $TargetExpirationDate

+  } 

+$Schedule | 

+  Export-Csv -Path $ExportPath -UseQuotes AsNeeded -NoTypeInformation

+```

+## Run impact analysis of setting manual count limits

+Here's an example of PowerShell script to generate a What-If report file. It applies a **Manual with Count Limits** policy with major version limit set to **50** on the report file `C:\Report.csv`.

+```PowerShell

+# save this file as ScheduleUpdate_Count.ps1

+param (

+  [Parameter(Mandatory=$true)][string]$ImportPath,

+  [Parameter(Mandatory=$true)][string]$ExportPath,

+  [Parameter(Mandatory=$true)][int]$MajorVersionLimit

+)

+$Report = Import-Csv -Path $ImportPath 

+$PreviousWebId = [Guid]::Empty

+$PreviousDocId = [Guid]::Empty

+$PreviousWebUrl = [string]::Empty

+$PreviousFileUrl = [string]::Empty

+$PreviousModifiedByUserId = [string]::Empty

+$PreviousModifiedByDisplayName = [string]::Empty

+$FileToVersions = @{}

+foreach ($Version in $Report)

+{  

+  $WebId = [string]::IsNullOrEmpty($Version."WebId.Compact") ? $PreviousWebId : [Guid]::Parse($Version."WebId.Compact")

+  $DocId = [string]::IsNullOrEmpty($Version."DocId.Compact") ? $PreviousDocId : [Guid]::Parse($Version."DocId.Compact")

+  $WebUrl = [string]::IsNullOrEmpty($Version."WebUrl.Compact") ? $PreviousWebUrl : $Version."WebUrl.Compact"

+  $FileUrl = [string]::IsNullOrEmpty($Version."FileUrl.Compact") ? $PreviousFileUrl : $Version."FileUrl.Compact"

+  $ModifiedByUserId = [string]::IsNullOrEmpty($Version."ModifiedBy_UserId.Compact") ? $PreviousModifiedByUserId : $Version."ModifiedBy_UserId.Compact"

+  $ModifiedByDisplayName = [string]::IsNullOrEmpty($Version."ModifiedBy_DisplayName.Compact") ? $PreviousModifiedByDisplayName : $Version."ModifiedBy_DisplayName.Compact"

+  $PreviousWebId = $WebId

+  $PreviousDocId = $DocId

+  $PreviousWebUrl = $WebUrl

+  $PreviousFileUrl = $FileUrl

+  $PreviousModifiedByUserId = $ModifiedByUserId

+  $PreviousModifiedByDisplayName = $ModifiedByDisplayName

+  if (($PreviousWebId -eq [Guid]::Empty) -or ($WebId -eq [Guid]::Empty) -or 

+    ($PreviousDocId -eq [Guid]::Empty) -or ($DocId -eq [Guid]::Empty))

+  {

+    throw "Compact column error."

+  }

+  $Version."WebId.Compact" = $WebId

+  $Version."DocId.Compact" = $DocId

+  $Version."WebUrl.Compact" = $WebUrl

+  $Version."FileUrl.Compact" = $FileUrl

+  $Version."ModifiedBy_UserId.Compact" = $ModifiedByUserId

+  $Version."ModifiedBy_DisplayName.Compact" = $ModifiedByDisplayName

+   

+  if ($null -eq $FileToVersions[$DocId]) 

+  {

+    $FileToVersions[$DocId] = [System.Collections.Generic.PriorityQueue[Object, Int32]]::new()

+  }

+  $VersionsQueue = $FileToVersions[$DocId]

+  $VersionNumber = [Int32]::Parse($Version.MajorVersion) * 512 + [Int32]::Parse($Version.MinorVersion)

+  $VersionsQueue.Enqueue($Version, -$VersionNumber)

+}

+$Schedule = [System.Collections.Generic.List[Object]]::new()

+foreach ($FilesAndVersions in $FileToVersions.GetEnumerator())

+{

+  $VersionsQueue = $FilesAndVersions.Value

+  $NumMajorVersionsSeen = 0

+  while ($VersionsQueue.Count -gt 0)

+  {

+    $Version = $VersionsQueue.Dequeue()

+    if ($NumMajorVersionsSeen -ge $MajorVersionLimit) {

+      $Version.TargetExpirationDate = [DateTime]::new(2000, 1, 1).ToString("yyyy-MM-ddTHH:mm:ssK")

+    }

+     

+    if ([int]::Parse($Version.MinorVersion) -eq 0) { $NumMajorVersionsSeen++ }

+    $Schedule.Add($Version)

+  }

+}

+$Schedule | 

+  Export-Csv -Path $ExportPath -UseQuotes AsNeeded -NoTypeInformation

+```

+- (EnableODIgnoreFolderListFromGPO) [Exclude specific kinds of folders from being uploaded](use-group-policy.md#exclude-specific-kinds-of-folders-from-being-uploaded)

+### Exclude specific kinds of folders from being uploaded

+This setting lets you enter keywords to prevent the OneDrive sync app (OneDrive.exe) from uploading certain folders to OneDrive or SharePoint. You can enter complete names, such as "Projects" or use the asterisk (*) as a wildcard character to represent a series of characters.

+If you enable this setting, the sync app doesn't upload new folders that match the keywords you specified. New folders that match the keywords won't be uploaded.

+No errors appear for the skipped folders, and the folders remain in the local OneDrive folder.

+The OneDrive sync app must be restarted after this setting is enabled for the setting to take effect.

+If you disable or don't configure this setting, all synced folders will be uploaded.

+Enabling this policy creates a list of strings under the following path:

+`HKLM\SOFTWARE\Policies\Microsoft\OneDrive\EnableODIgnoreFolderListFromGPO`

+This setting lets you enter keywords to prevent the OneDrive sync app (OneDrive.exe) from uploading certain files to OneDrive or SharePoint. You can enter complete names, such as "setup.exe", or use the asterisk (\*) as a wildcard character to represent a series of characters, such as \*.pst. Keywords aren't case-sensitive.

+ Title: "Set version limits on OneDrive using PowerShell(Preview)"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "This article provides guidance on how an admin can set the version limits on OneDrive for a specific user using PowerShell."

+# Change version limits on OneDrive using PowerShell (Preview)

+By default, organization version history settings are applied to all new OneDrive accounts. As a global or SharePoint admin in Microsoft 365, you can set the version limits on OneDrive storage for a specific user.

+Follow these steps to manage Version history limits for a site by using PowerShell.

+1. [Download the latest SharePoint Online Management Shell](https://go.microsoft.com/fwlink/p/?LinkId=255251).

+ > [!NOTE]

+ > If you installed a previous version of the SharePoint Online Management Shell, go to Add or remove programs and uninstall **SharePoint Online Management Shell**.

+1. Connect to SharePoint as a [Global Administrator or SharePoint Administrator](/sharepoint/sharepoint-admin-role) in Microsoft 365. To learn how, see [Getting started with SharePoint Online Management Shell](/powershell/sharepoint/sharepoint-online/connect-sharepoint-online).

+2. Run one of the following commands to manage Version history limits for a specific user:

+| **Action** | **PowerShell Command** |

+| | |

+| View the version history limits set for a user | Get-SPOSite -Identity $siteUrl \| fl Url, EnableAutoExpirationVersionTrim, ExpireVersionsAfterDays, MajorVersionLimit |

+| Set automatic Version history limits for a user | `Set-SPOSite -Identity $siteUrl -EnableAutoExpirationVersionTrim $true` |

+| Set manual limits with count and time parameters for a user | `Set-SPOSite -Identity $siteUrl`<br>`-EnableAutoExpirationVersionTrim $false`<br>`-MajorVersions <delete major versions exceeding limit>`<br>`-MajorWithMinorVersions <delete minor versions exceeding limit>`<br>`-ExpireVersionsAfterDays <delete versions exceeding time limit set in days>` |

+| Set manual limits with count with no expiration limit for a user | To set manual limits with count limits set the `-ExpireVersionsAfterDays parameter` to 0:<br><br>`Set-SPOSite -Identity $siteUrl`<br>`-EnableAutoExpirationVersionTrim $false`<br>`-MajorVersions <delete major versions exceeding limit>`<br>`-MajorWithMinorVersions <delete minor versions exceeding limit>`<br>`-ExpireVersionsAfterDays 0` |

+| Clear the existing Version history limits for a user<br><br>**Note:** Clearing a setting for a user applies to new versions created on files stored on the userΓÇÖs OneDrive account and doesn't trim existing versions. | `Remove-SPOSiteVersionPolicyJob -Identity $siteUrl` |

+## Learn More

+[Change a specific user's OneDrive storage space](change-user-storage.md)

+ Title: "About version history (Preview)"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "This article provides guidance on version history feature that enables a user to easily view or restore a file's earlier version."

+# Version history overview (Preview)

+The Version History feature is an integral part of MicrosoftΓÇÖs 365 built-in data protection in SharePoint and OneDrive. An item or file's version history lets a user see or restore to a previous version, helpful for undoing unintended changes, whether accidental or due to malicious activities like ransomware. It also ensures auditability to meet an organization's legal and audit requirements.

+Users can use version history to:

+- **View a previous version**: Users can view a previous version without overwriting their current version. During a review of the version history within a Microsoft Office document, such as a Word or Excel file, versions can be compared to determine what the differences are.

+- **Restore to a previous version**: If a user makes a mistake in a current version, the current version gets corrupted, or if they simply like a previous version better, they can replace the current version with a previous one. The restored version becomes the new current version. Learn more [Restore a previous version of an item or file in SharePoint](https://support.microsoft.com/en-us/office/restore-a-previous-version-of-an-item-or-file-in-sharepoint-f66dbda0-81f4-4d1e-b08c-793265c58934).

+- **Track history of a file or item**: Users can use version history to see when a file or an item was changed and identify who made the changes.

+ Title: "Generate version storage usage report for a site(Preview)"

+recommendations: true

+audience: Admin

+f1.keywords:

+- NOCSH

+ms.localizationpriority: medium

+search.appverid:

+- SPO160

+- SPS150

+- MET150

+description: "This article provides guidance on how to generate version storage use report for a site."

+# Generate version storage usage report for a SharePoint site (Preview)

+As a global or SharePoint admin in Microsoft 365, you can request an inventory of the versions on a site, library, or file, which can be used for various scenarios:

+- Review current version storage used by existing versions.

+- Understand how a version limit impacts new versions by applying the desired limits on existing versions before configuring limits.

+- Analyze the impact of trimming existing versions before scheduling a trim job.

+> [!NOTE]

+> Additional reporting options are available withΓÇ»[Microsoft Graph Data Connect](/graph/data-connect-datasets#onedrive-and-sharepoint-online).

+When you run the report, a background timer job is scheduled to generate a CSV file of every file version on a given SharePoint site. The CSV file is saved to the location of your choice on the site. If you don't want site members to see the report, consider creating a folder with different permissions where only site owners can access the report.

+> [!IMPORTANT]

+> The file version report generation job completes asynchronously over the next few days. The time it takes for the report to complete depends on the size of your library or site. For smaller sites or libraries, it takes over 24 hours to complete. For larger ones, it takes a few days to complete.

+>

+> While the job is being processed, you can see the report file being gradually populated. Do not update the file during this time. It will cause the job to fail. Check the progress of the report generation to confirm that the report is fully populated and ready to process.

+>

+> If you wish to cancel an in-progress report generation, you may simply delete the report file.

+## Report format

+The file version expiration report is in Comma-Separated Values (CSV) format. Each row corresponds to a file version and it contains the following columns:

+| **File Version Identifiers:** | Description |

+|:--|:--|

+|`WebId`|The unique identifier of the web and is a compact column ¹.|

+|`DocId`|The unique identifier of the document and is a compact column.|

+|`MajorVersion`|The major version number of the file version.|

+|`MinorVersion`|The minor version number of the file version.|

+| **File Version Information:** | Description |

+|:--|:--|

+|`WebUrl`|The SharePoint Url to the web and is a compact column.|

+|`FileUrl`|The web relative Url to the file and is a compact column.|

+|`Size`|The size of the version in bytes.|

+|`ModifiedBy_UserId`|The identifier of the user who created this version and is a compact column.|

+|`ModifiedBy_UserDisplayName`|The display name of the user who created this version and is a compact column.|

+|`LastModifiedDate`|The time when the version was last modified.|

+|`SnapshotDate`|The time when the version became a historical version.|

+|`IsSnapshotDateEstimated`|If this identifier is set to true, then the `SnapshotDate` is a best-effort estimation. The `SnapshotDate` might be estimated if the version was snapshot before January 1, 2023.|

+| **Expiration Schedule information:** | Description |

+|:--|:--|

+|`CurrentExpirationDate`|Time when the version will expire as it currently stands.|

+|`AutomaticPolicyExpirationDate`|Time when the version would be expiring if an automatic expiration policy were to be retroactively applied, estimated on a best-effort basis.|

+|`TargetExpirationDate`|Is populated to the same value as `CurrentExpirationDate`. This column is useful for any What-If analysis and batch-updating the expiration dates.|

+¹ Compact columns are columns that won't repeat values if two consecutive rows have the same value. It puts empty string for the repeated records. The header for these columns have "Compact" postfix.

+## How to generate site version storage usage report for site, OneDrive or library

+Follow these steps to manage version history limits for a site by using PowerShell.

+1. [Download the latest SharePoint Online Management Shell](https://go.microsoft.com/fwlink/p/?LinkId=255251).

+ > [!NOTE]

+ > If you installed a previous version of the SharePoint Online Management Shell, go to Add or remove programs and uninstall **SharePoint Online Management Shell**.

+1. Connect to SharePoint as a [Global Administrator or SharePoint Administrator](/sharepoint/sharepoint-admin-role) in Microsoft 365. To learn how, see [Getting started with SharePoint Online Management Shell](/powershell/sharepoint/sharepoint-online/connect-sharepoint-online).

+2. Run one of the following commands to generate a version storage usage report:

+| **Action** | **PowerShell Command** |

+| | |

+| Generate a version storage usage report for a site or OneDrive account | `New-SPOSiteFileVersionExpirationReportJob -Identity $siteUrl -ReportUrl $reportUrl` |

+| Track progress of the job to generate report for a site or OneDrive account | `Get-SPOSiteFileVersionExpirationReportJobProgress -Identity $siteUrl -ReportUrl $reportUrl` |

+| Generate a version storage usage report for a library | `New-SPOListFileVersionExpirationReportJob -Site $siteUrl -List $libName -ReportUrl $reportUrl` |

+| Track progress of the job to generate report for a library | `Get-SPOListFileVersionExpirationReportJobProgress -Site $siteUrl -List $libName -ReportUrl $reportUrl` |

+## Learn More

+1. [Tutorial: Generate Version Usage Report (Preview)](tutorial-generate-version-usage-report.md)

+1. [Tutorial: Run 'What-If' Analysis](tutorial-run-what-if-analysis.md)