-# Create change history reports for SharePoint sites

-You can create change history reports in the [SharePoint admin center](get-started-new-admin-center.md) to review SharePoint site property changes made within the last 180 days.

-Create up to five reports for a given date range and filter by sites and users. You can download the report as a .csv file to view the site property changes.

-> [!TIP]

-> You can export data for up to 180 days with a change history report depending on the user license. The report may contain data for users that go back 180 days as well as data for others that donΓÇÖt. Since the type of user license isnΓÇÖt shown on the report, it may appear as if data is missing for some users.

-> [!NOTE]

-> Admins assigned the [global reader role](/microsoft-365/admin/add-users/about-admin-roles?view=o365-worldwide&preserve-view=true%3Do365-worldwide) do not have the permissions to create or delete a report but can download to review the changes.

-1. To create a change history report, go to the **Change history** page and select **Create new report**.

-2. A panel appears where you can specify the type of information you want to include in your change history report. Select **Create report** to generate a new report.

-3. The new report is listed on the change history page. Select the report to open the change history report panel and monitor its status.

-4. Once the report is created, select **Download report** to export the data as a .csv file. The **Create a copy** button allows you to create more reports with similar parameters.

- :::image type="content" source="media/4-change-history-report-downloaded.png" alt-text="Screenshot of a change report downloaded as .csv file.":::

-> The report will take hours to generate depending on the search criteria selected when creating the report.

-You can create new reports, delete, and refresh their statuses from the change history page. This page can only show five reports at a time. The best practice is to delete a previous report before creating a new one.

-## Related articles

-To identify and remediate overshared content in SharePoint, follow these best practices:

-### Step 2: Identify inactive sites, then restrict access or delete

-Reduce your surface area for potentially overshared content by identifying SharePoint sites that have been inactive for a long time. See how you can easily do that via the [Inactive Site Policies](/sharepoint/site-lifecycle-management#create-an-inactive-site-policy) in SharePoint Advanced Management.

-SharePoint Server uses One Customer Voice (OCV) as our 1st-party solution to collect customer feedback from the farm administrators. Your feedback goes directly to our engineers and helps us shape the future of SharePoint Server and services for our users.

-## To disable OCV feedback for current Farm Administrator

- 2. Use the following cmdlet to disable the OCV for current admin:

- Disable-OCVForUser -UserSid $user.Sid

-This `$user` is obtained from Step 1.

- Enable-OCVForUser -UserSid $user.Sid

- Disable-OCVForFarm

- Enable-OCVForFarm

- ```

-

-

-

-

-

-

-In the previous article in this series, [How to add refiners to your search results page in SharePoint Server](how-to-add-refiners-to-your-search-results-page.md), we showed you how to add and configure refiners for your classic search results page. In this article you'll learn:

-You are delighted to see there is much information out there about skiing, but in this case, you are just looking for great ski pictures. This is where search verticals can be used.

-On the same search results page, you click **IMAGES**, and in an instant your screen is filled with images of people in colorful clothing, racing down white slopes while bathing in sunshine from a clear blue sky. Wow!

-When you click **IMAGES**, you are using a search vertical. Bing has five search verticals: **WEB**, **Images**, **VIDEOS** **Maps**, and **NEWS**.

-When users click one of these search verticals, it will in fact move to a new page. For example, the default search results page, the **Everything** search vertical, uses the **results.aspx** page.

-When a user clicks on the **People** search vertical, they navigate to the **peopleresults.aspx** page.

-The difference between these pages is how the **Search Results Web Part** is configured. To be specific: the Web Parts are configured to use different *result sources* .

-This is how we defined the *Art result source* .

-In our lists, we use the site column *Content Type* to specify the different media files. For example, all images have the value *Art* for *Content Type* .

-5. Click **Create**.

-6. On the **Site Settings** page, click **Search Settings**.

-7. On the **Search Settings** page, in the **Configure Search Navigation** section, click **Add Link**.

- In our scenario, we entered *Art* .

-10. Click **OK** to close the **Navigation Link** dialog.

-11. On the **Search Settings** page, in the **Configure Search Navigation** section, select the search verticals that you don't want to display, and then click **Delete**.

-12. Click **OK** to save all changes.

-14. On your search results page, click on your newly created search vertical, and verify that the URL is the same as you specified in step 4.

- In our scenario, we clicked *Art* , and verified that the URL was *\<site\>/articles/Pages/art.aspx* . We also noticed that 13 search results were displayed.

-16. In the Web Part tool page, click **Change query**. This opens a dialog.

-18. Click **OK** and save the page.

- In our scenario, we added two more search verticals, *Video* and *Interop* . And with that, we had completed the Search Center set up.

-OpenID Connect (OIDC) 1.0 is a modern authentication protocol that seamlessly integrates applications and devices with the identity and authentication management solutions to keep pace with the

-evolving security and compliance needs of your organization.

-SharePoint Server Subscription Edition now supports OIDC 1.0 authentication protocol. With this new capability, you can now set up an OIDC-enabled `SPTrustedIdentityTokenIssuer` that works with a remote identity provider to enable OIDC authentication.

-When you configure OIDC with Microsoft Entra ID, you need the following resources:

-1. Browse to the [Entra ID admin portal](https://entra.microsoft.com/), and log in with an account with the Global Administrator role.

-1. Save the **Directory (tenant) ID** value, as the tenant ID will be used in subsequent steps. Also save the **Application (client) ID,** which we'll use as **DefaultClientIdentifier** in the SharePoint setup.

-1. After you register the application, go to the **Authentication** tab, select the **ID tokens** check box and select **Save**.

-1. Go to the **API permissions** tab and click Add a Permission. Choose **Microsoft Graph**, then **Delegated permissions.** Select the add **email** and **profile** permissions, and click **Add permissions.**

-1. Go to the **Token configuration** tab and click **Add optional claim**. For each token type (ID, Access, SAML), add **email**, and **upn** claims.

-1. Also on the **Token configuration** tab, click **Add groups claim**. Security Groups is the most common, but the group types you select depends on which types of groups you want to use to give access to the SharePoint web application. See [Configure groups optional claims](/entra/identity-platform/optional-claims#configure-groups-optional-claims) and Configure group claims for applications by using Microsoft Entra ID for more information.

-In this step, you'll need to modify the SharePoint Server farm properties. Start the SharePoint Management Shell as a Farm Administrator, and run the following script:

-> [!NOTE]

-> Read the instructions mentioned in the following PowerShell script carefully. You will need to enter your own environment-specific values in certain places.

-# Setup farm properties to work with OIDC

-# If you have multiple SharePoint servers in the farm, you need to export certificate by using Export-PfxCertificate and import the certificate to all other SharePoint servers in the farm by using Import-PfxCertificate.

-# After the certificate is successfully imported to SharePoint Server, we will need to grant access permission to certificate's private key.

-# Grant your app pool account permission to the private key

-# Please replace the <web application pool account> with real application pool account of your SharePoint web application

-# Update the farm properties to use the Nonce cert

-$f = Get-SPFarm

-$f.Farm.Properties['SP-NonceCookieCertificateThumbprint']=$cert.Thumbprint

-$f.Farm.Properties['SP-NonceCookieHMACSecretKey']='seed'

-$f.Farm.Update()

- - By using the metadata endpoint, a lot of parameters you need in 'Configure SharePoint to trust Microsoft Entra ID as the OIDC provider manually' can be automatically retrieved by metadata endpoint.

-

-In this step, you create a `SPTrustedTokenIssuer` that will store the configuration that SharePoint needs to trust Microsoft Entra OIDC as the OIDC provider. Start the SharePoint Management Shell as a Farm Administrator, and run the following script to create it:

-|ImportTrustCertificate | Imports a list of X509 Certificates, which will be used to validate `id_token` from OIDC identifier. If the OIDC identity provider (IDP) uses more than one certificate to digital sign the `id_token`, import these certificates and SharePoint will then validate `id_token` by matching the digital signature generated by using these certificates. |

-| ClaimsMappings | A `SPClaimTypeMapping` object, which will be used to identify which claim in the `id_token` will be regarded as identifier in SharePoint. |

-| RegisteredIssuerName | Specifies the issuer identifier, which issues the `id_token`. It will be used to validate the `id_token`. |

-| SignoutUrl | Specifies the sign-out endpoint of the OIDC identity provider. |

-| DefaultClientIdentifier | Specifies the `client_id` of SharePoint server, which is assigned by OIDC identity provider. This will be validated against aud claim in `id_token`. |

-| ResponseTypesSupported | Specifies the response type of IDP, which can be accepted by this token issuer. It can accept two strings: `id_token` and `code id_token`. If this parameter isn't provided, it will use `code id_token` as default. |

-By using the metadata endpoint provided by the OIDC identity provider, some of the configuration will be retrieved from the OIDC provider metadata endpoint directly, including:

-|ImportTrustCertificate | A certificate that will be used to validate `id_token` from OIDC identifier. |

-| ClaimsMappings | A `SPClaimTypeMapping` object, which will be used to identify which claim in the `id_token` will be regarded as identifier in SharePoint. |

-| DefaultClientIdentifier | Specifies the `client_id` of SharePoint server, which is assigned by OIDC identity provider. This will be validated against aud claim in `id_token`. |

-In this step, you'll configure a web application in SharePoint to be federated with the Microsoft Entra OIDC, using the `SPTrustedIdentityTokenIssuer` created in the previous step.

- 2. Follow [Create a web application in SharePoint Server](/sharepoint/administration/create-a-web-application) to create a new web application enabling HTTPS/Secure Sockets Layer (SSL) named SharePoint - OIDC on contoso.local.

-In this step, you'll create a team site collection with two administrators: One as a Windows administrator and one as a federated (Microsoft Entra ID) administrator.

-Once the site collection is created, you will be able to sign-in using either the Windows or the federated site collection administrator account.

-In the [previous step](#step-3-configure-sharepoint-to-trust-the-identity-provider), you've already created an OIDC `SPTrustedIdentityTokenIssuer` by using `New-SPTrustedIdentityTokenIssuer` PowerShell cmdlet. In this step, you'll use the following PowerShell cmdlet to create a claim provider, which uses the User Profile Application service to search and resolve users and groups in the People Picker and specifies to use the OIDC `SPTrustedIdentityTokenIssuer`:

-| TrustedTokenIssuer | To be specified as the OIDC `SPTrustedIdentityTokenIssuer` created in the [previous step](#step-3-configure-sharepoint-to-trust-the-identity-provider), which will use this claim provider. This is a new parameter the user needs to provide when the type of the claim provider is `Microsoft.SharePoint.Administration.Claims.SPTrustedBackedByUPAClaimProvider`. |

-| Default | As we've created a claim provider by using this cmdlet, this cmdlet can only work with `SPTrustedIdentityTokenIssuer` and `Default` parameter must be set to false so that it wonΓÇÖt be used by any other authentication method assigned to the web application by default. |

-| -IsOpenIDConnect | Required when `SPTrustedIdentityTokenIssuer` is OIDC `SPTrustedIdentityTokenIssuer`. Without this parameter, OIDC `SPTrustedIdentityTokenIssuer` configuration will fail. |

- During the synchronization, you must pick which unique identity property in the source will be mapped to the `SPS-ClaimID` property in the UPSA. We suggest using **Email** or **User Principal Name** for the `SPS-ClaimID`. The corresponding **IdentifierClaim** value needs to be set when token issuer is created from the [New-SPTrustedIdentityTokenIssuer](/powershell/module/sharepoint-server/new-sptrustedidentitytokenissuer) cmdlet.

- For AD Import synchronization, **Central Administration > Application Management > Manage service applications > User Profile Service Application > Manage User Properties** will allow administrators to edit the `SPS-ClaimID` to indicate which property in the source identity provider should be synchronized to `SPS-ClaimID`. (The display name of this property is **Claim User Identifier** and it can be customized to other display names by the administrator.) For example, if email is to be used as the `SPS-ClaimID`, **Claim User Identifier** should be set to **Email**.

- 1. For AD Import synchronization, `SID` will be synchronized automatically without additional setup from the source identity provider to the SharePoint UPSA.

-1. Set the feature release ring to **Early release** for your farm to make this feature available in the SharePoint Server Subscription Edition version 23H2. For more information, see

-[Feature release rings](../administration/feature-release-rings.md).

-2. Enable a web application to allow custom branding by setting the **SuiteNavAllowCustom** web application-level property to **true**. This property must be set to **true** for any of the other properties to take effect.

-3. Set all the options, as shown in the following command-syntax example:

-