Removed future tense and fixed a few words to boost acrolinx score and improve freshness.

Author: Heidilohr

articles/virtual-desktop/troubleshoot-agent.md

@@ -3,7 +3,7 @@ title: Troubleshoot Azure Virtual Desktop Agent Issues - Azure
 description: How to resolve common Azure Virtual Desktop Agent and connectivity issues.
 author: sefriend
 ms.topic: troubleshooting
-ms.date: 04/19/2023
+ms.date: 04/21/2023
 ms.author: sefriend
 manager: clarkn
 ---
@@ -15,7 +15,7 @@ The Azure Virtual Desktop Agent can cause connection issues because of multiple
  - Problems with updates.
  - Issues with installing during the agent installation, which disrupts connection to the session host.
 
-This article will guide you through solutions to these common scenarios and how to address connection issues.
+This article guides you through solutions to these common scenarios and how to address connection issues.
 
 > [!NOTE]
 > For troubleshooting issues related to session connectivity and the Azure Virtual Desktop agent, we recommend you review the event logs on your session host virtual machines (VMs) by going to **Event Viewer** > **Windows Logs** > **Application**. Look for events that have one of the following sources to identify your issue:
@@ -36,7 +36,7 @@ To resolve this issue, start the RDAgent boot loader:
 
 1. In the Services window, right-click **Remote Desktop Agent Loader**.
 
-1. Select **Start**. If this option is greyed out for you, you don't have administrator permissions and will need to get them to start the service.
+1. Select **Start**. If this option is greyed out for you, you don't have administrator permissions. You need to get those permissions in order to start the service.
 
 1. Wait 10 seconds, then right-click **Remote Desktop Agent Loader**.
 
@@ -88,7 +88,7 @@ On your session host VM, go to **Event Viewer** > **Windows Logs** > **Applicati
 
 To resolve this issue, check that you can reach the two endpoints referred to as *BrokerURI* and *BrokerURIGlobal*:
 
-1. Open Registry Editor. 
+1. Open Registry Editor. 
 
 1. Go to **HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RDInfraAgent**. 
 
@@ -101,25 +101,25 @@ To resolve this issue, check that you can reach the two endpoints referred to as
 
 1. Open another tab in the browser and enter your value for *BrokerURIGlobal* in the address bar and add */api/health* to the end, for example `https://rdbroker.wvd.microsoft.com/api/health`.
 
-1. If your network isn't blocking the connection to the broker, both pages will load successfully and will show a message stating  **RD Broker is Healthy**, as shown in the following screenshots:
+1. If your network isn't blocking the connection to the broker, both pages should load successfully and show a message stating  **RD Broker is Healthy**, as shown in the following screenshots:
 
    > [!div class="mx-imgBorder"]
    > ![Screenshot of successfully loaded broker uri access](media/broker-uri-web.png)
 
    > [!div class="mx-imgBorder"]
    > ![Screenshot of successfully loaded broker global uri access](media/broker-global.png)
  
-1. If the network is blocking broker connection, the pages will not load, as shown in the following screenshot. 
+1. If the network is blocking broker connection, the pages won't load, as shown in the following screenshot. 
 
    > [!div class="mx-imgBorder"]
    > ![Screenshot of unsuccessful loaded broker access](media/unsuccessful-broker-uri.png)
 
    > [!div class="mx-imgBorder"]
    > ![Screenshot of unsuccessful loaded broker global access](media/unsuccessful-broker-global.png)
 
-   You will need to unblock the required endpoints and then repeat steps 4 to 7. For more information, see [Required URL List](safe-url-list.md).
+   You must unblock the required endpoints and then repeat steps 4 to 7. For more information, see [Required URL List](safe-url-list.md).
 
-1. If this does not resolve your issue, make sure that you do not have any group policies with ciphers that block the agent to broker connection. Azure Virtual Desktop uses the same TLS 1.2 ciphers as [Azure Front Door](../frontdoor/concept-end-to-end-tls.md#supported-cipher-suites). For more information, see [Connection Security](network-connectivity.md#connection-security).
+1. If this doesn't resolve your issue, make sure that you don't have any group policies with ciphers that block the agent to broker connection. Azure Virtual Desktop uses the same TLS 1.2 ciphers as [Azure Front Door](../frontdoor/concept-end-to-end-tls.md#supported-cipher-suites). For more information, see [Connection Security](network-connectivity.md#connection-security).
 
 ## Error: 3703
 
@@ -273,7 +273,7 @@ To resolve this issue, first reinstall the side-by-side stack:
 
 1. Restart your session host VM.
 
-1. From a command prompt run `qwinsta.exe` again and verify the *STATE* column for **rdp-tcp** and **rdp-sxs** entries is **Listen**. If not, you will need to [re-register your VM and reinstall the agent](#your-issue-isnt-listed-here-or-wasnt-resolved) component.
+1. From a command prompt run `qwinsta.exe` again and verify the *STATE* column for **rdp-tcp** and **rdp-sxs** entries is **Listen**. If not, you must [re-register your VM and reinstall the agent](#your-issue-isnt-listed-here-or-wasnt-resolved) component.
 
 ## Error: Session host VMs are stuck in Unavailable state
 
@@ -315,12 +315,12 @@ Your session host VMs may be at their connection limit and can't accept new conn
 
 To resolve this issue, either:
 
-- Decrease the max session limit. This ensures that resources are more evenly distributed across session hosts and will prevent resource depletion.
+- Decrease the max session limit. This ensures that resources are more evenly distributed across session hosts and prevent resource depletion.
 - Increase the resource capacity of the session host VMs.
 
 ## Error: Operating a Pro VM or other unsupported OS
 
-The side-by-side stack is only supported by Windows Enterprise or Windows Server SKUs, which means that operating systems like Pro VM aren't. If you don't have an Enterprise or Server SKU, the stack will be installed on your VM but won't be activated, so you won't see it show up when you run **qwinsta** in your command line.
+The side-by-side stack is only supported by Windows Enterprise or Windows Server SKUs, which means that operating systems like Pro VM aren't. If you don't have an Enterprise or Server SKU, the stack installs on your VM but isn't activated, so you won't see it show up when you run **qwinsta** in your command line.
 
 To resolve this issue, [create session host VMs](expand-existing-host-pool.md) using a [supported operating system](prerequisites.md#operating-systems-and-licenses).
 
@@ -345,15 +345,15 @@ To resolve this issue:
 
 ## Your issue isn't listed here or wasn't resolved
 
-If you can't find your issue in this article or the instructions didn't help you, we recommend you uninstall, reinstall, and re-register the Azure Virtual Desktop Agent. The instructions in this section will show you how to reregister your session host VM to the Azure Virtual Desktop service by:
+If you can't find your issue in this article or the instructions didn't help you, we recommend you uninstall, reinstall, and re-register the Azure Virtual Desktop Agent. The instructions in this section show you how to reregister your session host VM to the Azure Virtual Desktop service by:
 
 1. Uninstalling all agent, boot loader, and stack components.
 
-1. Removing the session host from the host pool.
+2. Removing the session host from the host pool.
 
-1. Generating a new registration key for the VM.
+3. Generating a new registration key for the VM.
 
-1. Reinstalling the Azure Virtual Desktop Agent and boot loader.
+4. Reinstalling the Azure Virtual Desktop Agent and boot loader.
 
 Follow these instructions in this section if one or more of the following scenarios apply to you:
 
@@ -377,7 +377,7 @@ Before reinstalling the agent, boot loader, and stack, you must uninstall any ex
 1. Uninstall the following programs, then restart your session host VM:
 
    > [!CAUTION]
-   > When uninstalling **Remote Desktop Services SxS Network Stack**, you'll be prompted that *Remote Desktop Services* and *Remote Desktop Services UserMode Port Redirector* should be closed. If you're connected to the session host VM using RDP, select **Do not close applications** then select **OK**, otherwise your RDP connection will be closed.
+   > When uninstalling **Remote Desktop Services SxS Network Stack**, you'll be prompted that *Remote Desktop Services* and *Remote Desktop Services UserMode Port Redirector* should be closed. If you're connected to the session host VM using RDP, select **Do not close applications** then select **OK**, otherwise your RDP connection won't work.
    > 
    > [!div class="mx-imgBorder"]
    > ![Screenshot showing prompt that Remote Desktop Services and Remote Desktop Services UserMode Port Redirector should be closed](media/uninstall-remote-desktop-services-sxs-network-stack.png)

articles/virtual-desktop/troubleshoot-statuses-checks.md

@@ -3,29 +3,29 @@ title: Azure Virtual Desktop session host statuses and health checks
 description: How to troubleshoot the failed session host statuses and failed health checks
 author: jakejohnson-21
 ms.topic: troubleshooting
-ms.date: 04/19/2023
+ms.date: 04/21/2023
 ms.author: jakejohnson
 manager: rkiran
 ---
 # Azure Virtual Desktop session host statuses and health checks
 
-The Azure Virtual Desktop Agent regularly runs health checks on the session host. The agent assigns these health checks various statuses that include descriptions of how to fix common issues. This article will tell you what each status means and how to act on them during a health check.
+The Azure Virtual Desktop Agent regularly runs health checks on the session host. The agent assigns these health checks various statuses that include descriptions of how to fix common issues. This article tells you what each status means and how to act on them during a health check.
 
 ## Session host statuses
 
 The following table lists all statuses for session hosts in the Azure portal each potential status. *Available* is considered the ideal default status. Any other statuses represent potential issues that you need to take care of to ensure the service works properly.
 
 >[!NOTE]
->If an issue is listed as "non-fatal," the service can still run with the issue active. However, we recommend you resolve the issue as soon as possible to prevent future issues. If an issue is listed as "fatal," then it will prevent the service from running. You must resolve all fatal issues to make sure your users can access the session host.
+>If an issue is listed as "non-fatal," the service can still run with the issue active. However, we recommend you resolve the issue as soon as possible to prevent future issues. If an issue is listed as "fatal," then it prevents the service from running. You must resolve all fatal issues to make sure your users can access the session host.
 
 | Session host status | Description | How to resolve related issues |
 |---------------------|------|------|  
-|Available| This status means that the session host passed all health checks and is available to accept user connections. If a session host has reached its maximum session limit but has passed health checks, it will still be listed as “Available." |N/A| 
+|Available| This status means that the session host passed all health checks and is available to accept user connections. If a session host has reached its maximum session limit but has passed health checks, it's still listed as “Available." |N/A| 
 |Needs Assistance|The session host didn't pass one or more of the following non-fatal health checks: the Geneva Monitoring Agent health check, the Azure Instance Metadata Service (IMDS) health check, or the URL health check. You can find which health checks have failed in the session hosts detailed view in the Azure portal. |Follow the directions in [Error: VMs are stuck in "Needs Assistance" state](troubleshoot-agent.md#error-vms-are-stuck-in-the-needs-assistance-state) to resolve the issue.|  
-|Shutdown| The session host has been shut down. If the agent enters a shutdown state before connecting to the broker, its status will change to *Unavailable*. If you've shut down your session host and see an *Unavailable* status, that means the session host shut down before it could update the status, and doesn't indicate an issue. You should use this status with the [VM instance view API](/rest/api/compute/virtual-machines/instance-view?tabs=HTTP#virtualmachineinstanceview) to determine the power state of the VM. |Turn on the session host. | 
+|Shutdown| The session host has been shut down. If the agent enters a shutdown state before connecting to the broker, its status changes to *Unavailable*. If you've shut down your session host and see an *Unavailable* status, that means the session host shut down before it could update the status, and doesn't indicate an issue. You should use this status with the [VM instance view API](/rest/api/compute/virtual-machines/instance-view?tabs=HTTP#virtualmachineinstanceview) to determine the power state of the VM. |Turn on the session host. | 
 |Unavailable| The session host is either turned off or hasn't passed fatal health checks, which prevents user sessions from connecting to this session host. |If the session host is off, turn it back on. If the session host didn't pass the domain join check or side-by-side stack listener health checks, refer to the table in [Health check](#health-check) for ways to resolve the issue. If the status is still "Unavailable" after following those directions, open a support case.|
 |Upgrade Failed| This status means that the Azure Virtual Desktop Agent couldn't update or upgrade. This doesn't affect new nor existing user sessions. |Follow the instructions in the [Azure Virtual Desktop Agent troubleshooting article](troubleshoot-agent.md).| 
-|Upgrading| This status means that the agent upgrade is in progress. This status will be updated to “Available” once the upgrade is done and the session host can accept connections again.|If your session host has been stuck in the "Upgrading" state, then [reinstall the agent](troubleshoot-agent.md#error-session-host-vms-are-stuck-in-upgrading-state).|
+|Upgrading| This status means that the agent upgrade is in progress. This status updates to “Available” once the upgrade is done and the session host can accept connections again.|If your session host is stuck in the "Upgrading" state, then [reinstall the agent](troubleshoot-agent.md#error-session-host-vms-are-stuck-in-upgrading-state).|
 
 ## Health check
 
@@ -38,14 +38,14 @@ The health check is a test run by the agent on the session host. The following t
 | Integrated Maintenance Data System (IMDS) reachable | Verifies that the service can't access the IMDS endpoint. | If this check fails, it's semi-fatal. There may be successful connections, but they won't contain logging information. To resolve this issue, you'll need to reconfigure your networking, firewall, or proxy settings. |
 | Side-by-side (SxS) Stack Listener | Verifies that the side-by-side stack is up and running, listening, and ready to receive connections. | If this check fails, it's fatal, and users won't be able to connect to the session host. Try restarting your virtual machine (VM). If this doesn't work, contact Microsoft support. |
 | UrlsAccessibleCheck | Verifies that the required Azure Virtual Desktop service and Geneva URLs are reachable from the session host, including the RdTokenUri, RdBrokerURI, RdDiagnosticsUri, and storage blob URLs for Geneva agent monitoring. | If this check fails, it isn't always fatal. Connections may succeed, but if certain URLs are inaccessible, the agent can't apply updates or log diagnostic information. To resolve this, follow the directions in [Error: VMs are stuck in the Needs Assistance state](troubleshoot-agent.md#error-vms-are-stuck-in-the-needs-assistance-state). |
-| TURN (Traversal Using Relay NAT) Relay Access Health Check | When using [RDP Shortpath for public networks](rdp-shortpath.md?tabs=public-networks#how-rdp-shortpath-works) with an indirect connection, TURN uses User Datagram Protocol (UDP) to relay traffic between the client and session host through an intermediate server when direct connection isn't possible. | If this check fails, it's not fatal. Connections will revert to the websocket TCP and the session host will enter the "Needs assistance" state. To resolve the issue, follow the instructions in [Disable RDP shortpath on managed and unmanaged windows clients using group policy](configure-rdp-shortpath.md?tabs=public-networks#disable-rdp-shortpath-on-managed-and-unmanaged-windows-clients-using-group-policy). |
-| App attach health check | Verifies that the [MSIX app attach](what-is-app-attach.md) service is working as intended during package staging or destaging. | If this check fails, it isn't fatal. However, certain apps will stop working for end-users. |
+| TURN (Traversal Using Relay NAT) Relay Access Health Check | When using [RDP Shortpath for public networks](rdp-shortpath.md?tabs=public-networks#how-rdp-shortpath-works) with an indirect connection, TURN uses User Datagram Protocol (UDP) to relay traffic between the client and session host through an intermediate server when direct connection isn't possible. | If this check fails, it's not fatal. Connections revert to the websocket TCP and the session host enters the "Needs assistance" state. To resolve the issue, follow the instructions in [Disable RDP shortpath on managed and unmanaged windows clients using group policy](configure-rdp-shortpath.md?tabs=public-networks#disable-rdp-shortpath-on-managed-and-unmanaged-windows-clients-using-group-policy). |
+| App attach health check | Verifies that the [MSIX app attach](what-is-app-attach.md) service is working as intended during package staging or destaging. | If this check fails, it isn't fatal. However, certain apps stop working for end-users. |
 | Domain reachable | Verifies the domain the session host is joined to is still reachable. | If this check fails, it's fatal. The service won't be able to connect if it can't reach the domain. |
 | Domain trust check | Verifies the session host isn't experiencing domain trust issues that could prevent authentication when a user connects to a session. | If this check fails, it's fatal. The service won't be able to connect if it can't reach the authentication domain for the session host. |
 | FSLogix health check | Verifies the FSLogix service is up and running to make sure user profiles are loading properly in the session. | If this check fails, it's fatal. Even if the connection succeeds, the profile won't load, forcing the user to use a temporary profile instead. |
 | Metadata service check | Verifies the metadata service is accessible and returns compute properties. | If this check fails, it isn't fatal. |
-| Monitoring agent check | Verifies that the required monitoring agent is running. | If this check fails, it isn't fatal. Connections will still work, but the monitoring agent will either be missing or running an earlier version. |
-| Supported encryption check | Checks the value of the SecurityLayer registration key. | If the key's value is 0, the check will fail and is fatal. If the value is 1, the check will fail but be non-fatal. |
+| Monitoring agent check | Verifies that the required monitoring agent is running. | If this check fails, it isn't fatal. Connections still work, but the monitoring agent is either missing or running an earlier version. |
+| Supported encryption check | Checks the value of the SecurityLayer registration key. | If the key's value is 0, the check fails and is fatal. If the value is 1, the check fails but is non-fatal. |
 | Agent provisioning service health check | Verifies the provisioning status of the Azure Virtual Desktop agent installation. | If this check fails, it's fatal. |
 | Stack provisioning service health check | Verifies the provisioning status of the Azure Virtual Desktop Stack installation. | If this check fails, it's fatal. |
 | Monitoring agent provisioning service health check | Verifies the provisioning status of the Monitoring agent installation | If this check fails, it's fatal. |