update screenshot, edits

windows/deployment/update/update-compliance-v2-prerequisites.md

@@ -45,7 +45,6 @@ Update Compliance only provides data for the standard Desktop Windows client ver
 Update Compliance supports Windows client devices on the following channels:
 
 - General Availability Channel
-- Long-term Servicing Channel (LTSC).
 - Update Compliance *counts* Windows Insider Preview devices, but doesn't currently provide detailed deployment insights for them.
 
 ### Diagnostic data requirements
@@ -75,9 +74,13 @@ For more information about what's included in different diagnostic levels, see [
 ### Permissions
 
 - To edit and write queries, we recommend the [Log Analytics Contributor](/azure/role-based-access-control/built-in-roles#log-analytics-contributor) role.
-
 - To read and only view data, we recommend the [Log Analytics Reader](/azure/role-based-access-control/built-in-roles#log-analytics-reader) role.
 
+When you use the [Microsoft admin center software updates (preview) page](update-status-admin-center.md) with Update Compliance, the following permissions are also recommended:
+   - To configure settings for the **Software Updates** page: [Global Admin role](/microsoft-365/admin/add-users/about-admin-roles)
+   - To view the **Software Updates** page: [Global Reader role](/microsoft-365/admin/add-users/about-admin-roles)
+
+
 ### Log Analytics regions
 
 Update Compliance can use a Log Analytics workspace in the following regions:

windows/deployment/update/update-compliance-v2-schema-ucclient.md

@@ -11,7 +11,7 @@ author: mestew
 ms.author: mstewart
 ms.collection: M365-analytics
 ms.topic: reference
-ms.date: 05/31/2022
+ms.date: 06/06/2022
 ---
 
 # UCClient

windows/deployment/update/update-compliance-v2-schema-ucupdatealert.md

@@ -11,7 +11,7 @@ author: mestew
 ms.author: mstewart
 ms.collection: M365-analytics
 ms.topic: reference
-ms.date: 05/31/2022
+ms.date: 06/06/2022
 ---
 
 # UCUpdateAlert

windows/deployment/update/update-compliance-v2-schema.md

@@ -36,4 +36,4 @@ The table below summarizes the different tables that are part of the Update Comp
 | [**UCClientUpdateStatus**](update-compliance-v2-schema-ucclientupdatestatus.md) |  Device record |  Update Event that combines the latest client-based data with the latest service-based data to create a complete picture for one device (client) and one update. |
 | [**UCServiceUpdateStatus**](update-compliance-v2-schema-ucserviceupdatestatus.md) | Service record  | Update Event that comes directly from the service-side. The event has only service-side information for one device (client), and one update, in one deployment. This event has certain fields removed from it in favor of being able to show data in near real-time.  |
 | [**UCUpdateAlert**](update-compliance-v2-schema-ucupdatealert.md) | Service and device records  |  Alert for both client and service update. Contains information that needs attention, relative to one device (client), one update, and one deployment (if relevant). Certain fields may be blank depending on the UpdateAlert's AlertType field; for example, ServiceUpdateAlert will not necessarily contain client-side statuses.  |
-| [**UCDeviceAlert**] (update-compliance-v2-schema-ucdevicealert.md)| Service and device record  |  These alerts are activated as a result of an issue that is device-specific. It isn't specific to the combination of a specific update and a specific device. Like UpdateAlerts, the AlertType indicates where the Alert comes from (ServiceDeviceAlert, ClientDeviceAlert). For example, an EndOfService alert is a ClientDeviceAlert, as a build no longer being serviced (EOS) is a client-wide state. Meanwhile, DeviceRegistrationIssues in WUfB DS will be a ServiceDeviceAlert, as it's a device-wide state in the service to not be correctly registered.  |
+| [**UCDeviceAlert**](update-compliance-v2-schema-ucdevicealert.md)| Service and device record  |  These alerts are activated as a result of an issue that is device-specific. It isn't specific to the combination of a specific update and a specific device. Like UpdateAlerts, the AlertType indicates where the Alert comes from (ServiceDeviceAlert, ClientDeviceAlert). For example, an EndOfService alert is a ClientDeviceAlert, as a build no longer being serviced (EOS) is a client-wide state. Meanwhile, DeviceRegistrationIssues in WUfB DS will be a ServiceDeviceAlert, as it's a device-wide state in the service to not be correctly registered.  |