mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 19:03:46 +00:00
import of requested new topic material
This commit is contained in:
@ -250,6 +250,7 @@
|
|||||||
##### [Step 2: Resolve issues](upgrade/upgrade-readiness-resolve-issues.md)
|
##### [Step 2: Resolve issues](upgrade/upgrade-readiness-resolve-issues.md)
|
||||||
##### [Step 3: Deploy Windows](upgrade/upgrade-readiness-deploy-windows.md)
|
##### [Step 3: Deploy Windows](upgrade/upgrade-readiness-deploy-windows.md)
|
||||||
##### [Additional insights](upgrade/upgrade-readiness-additional-insights.md)
|
##### [Additional insights](upgrade/upgrade-readiness-additional-insights.md)
|
||||||
|
##### [Targeting a new operating system version](upgrade/upgrade-readiness-target-new-OS.md)
|
||||||
### [Monitor Windows Updates with Update Compliance](update/update-compliance-monitor.md)
|
### [Monitor Windows Updates with Update Compliance](update/update-compliance-monitor.md)
|
||||||
#### [Get started with Update Compliance](update/update-compliance-get-started.md)
|
#### [Get started with Update Compliance](update/update-compliance-get-started.md)
|
||||||
#### [Use Update Compliance](update/update-compliance-using.md)
|
#### [Use Update Compliance](update/update-compliance-using.md)
|
||||||
|
@ -0,0 +1,49 @@
|
|||||||
|
---
|
||||||
|
title: Upgrade Readiness - Targeting a new operating system version
|
||||||
|
description: Explains how to run Upgrade Readiness again to target a different operating system version or bulk-approve all apps from a given vendor
|
||||||
|
ms.prod: w10
|
||||||
|
author: jaimeo
|
||||||
|
ms.date: 05/22/2018
|
||||||
|
---
|
||||||
|
|
||||||
|
# Targeting a new operating system version
|
||||||
|
|
||||||
|
After you've used Upgrade Readiness to help deploy a given version of Windows 10, you might want to use it again to help deploy a newer version of Windows 10. When you change the target operating system version (as described in [Use Upgrade Readiness to manage Windows upgrades](use-upgrade-readiness-to-manage-windows-upgrades#target-version.md), the app states (Importance, AppOwner, UpgradeDecision, TestPlan and TestResult) are not reset. Follow this guidance to preserve or reset these states as needed:
|
||||||
|
|
||||||
|
## TestResults
|
||||||
|
|
||||||
|
If you want to preserve the TestResults from the previous operating system version testing, there is nothing you need to do.
|
||||||
|
|
||||||
|
If you want to reset them, click any of the rows in the **Prioritize Application** blade (described in [Upgrade Readiness - Step 1: Identify important apps](upgrade-readiness-identify-apps.md)). This will take you to the **Log Search** user experience. Replace the query in that window with the following query:
|
||||||
|
|
||||||
|
`search in (UAApp) IsRollup == true and RollupLevel == "Granular" and TestResult <> "Not started"`
|
||||||
|
|
||||||
|
After a short period of time, you will see the "user input" perspective render, which will let you bulk-edit the results. Select the check box in the table header, click the **bulk edit** button, and then set the **TestResult** to *Not started*. Leave all other fields as they are.
|
||||||
|
|
||||||
|
## UpgradeDecision
|
||||||
|
|
||||||
|
If you want to preserve the UpgradeDecision from the previous operating system version testing, there is nothing you need to do.
|
||||||
|
|
||||||
|
If you want to reset them, keep these important points in mind:
|
||||||
|
|
||||||
|
- Make sure to *not* reset the **Ready to upgrade** decision for the "long tail" of apps that have importance of **Ignore** or **Low install count**. Doing this will make it extremely difficult to complete the Upgrade Readiness workflow.
|
||||||
|
- Decide which decisions to reset. For example, one option is just to reset the decisions marked **Ready to upgrade** (in order to retest those), while preserving states of apps marked **Won't upgrade**. Doing this means you won't lose track of this previous marking. Or you can reset everything.
|
||||||
|
|
||||||
|
To do this, type the following query in **Log Search**:
|
||||||
|
|
||||||
|
`search in (UAApp) IsRollup == true and RollupLevel == "Granular" and Importance <> "Ignore" and Importance <> "Low install count"`
|
||||||
|
|
||||||
|
>[!NOTE]
|
||||||
|
>You can also append `'and UpgradeDecision="Ready to upgrade"'`, for example, if you just want to reset apps that were previously marked **Ready**.
|
||||||
|
|
||||||
|
After a short period of time, you will see the "user input" perspective render, which will let you bulk-edit the results. Select the check box in the table header, click the **bulk edit** button, and then set the **UpgradeDecision** to *Not reviewed*. Leave all other fields as they are.
|
||||||
|
|
||||||
|
|
||||||
|
## Bulk-approving apps from a given vendor
|
||||||
|
|
||||||
|
You can bulk-approve all apps from a given vendor (for example, Microsoft) if there are no known compatibility issues. To do this, type the following query in **Log Search**:
|
||||||
|
|
||||||
|
`search in (UAApp) IsRollup == true and RollupLevel == "Granular" and AppVendor has "Microsoft" and UpgradeAssessment=="No known issues" and UpgradeDecision<>"Ready to upgrade"`
|
||||||
|
|
||||||
|
After a short period of time, you will see the "user input" perspective render, which will let you bulk-edit the results. Select the check box in the table header, click the **bulk edit" button**, and then set the **UpgradeDecision** to *Ready to upgrade*. Leave all other fields as they are.
|
||||||
|
|
Reference in New Issue
Block a user