aa

Author: Deland-Han

support/windows-server/remote/remote-desktop-service-currently-busy.md

@@ -14,111 +14,115 @@ This article provides guidance on troubleshooting the "Remote Desktop Service is
 
 ## Initial triage troubleshooting
 
-An important first test to perform is to access the affected target system via console (either physical console / locally, or, in case of a Virtual Machine, through the Hypervisor’s VM console.
+To begin troubleshooting, an important test is to access the affected computer by using the console (Either through a physical console locally, or, in the case of a virtual machine, through the Hypervisor's VM console.)
 
-It is not expected on this test that we will also get the error message “RDS Service is currently busy” since we are not accessing via RDP, but we can this way understand if we have other types of issue when performing the logon – such as a different error message, a slow logon or any other type of abnormal behavior.
-If so, this will strongly suggest we are facing another type of issue with the system, that is not RDP related, being RDP the victim of that unhealthy system state and retrieving the ” Remote Desktop Service is currently busy” upon connection.
-In this situation, we should address this issue as a non-RDP issue during a first troubleshooting approach.
+It is not expected to receive the "RDS Service is currently busy" error message during the test because we are not using RDP. The test help us find whether we have other types of issue during the logon. For example, a different error message, a slow logon or any other type of abnormal behavior.
+
+If any other issue is found, the "Remote Desktop Service is currently busy" error message might be caused by issue. We strongly suggest addressing the issue before troubleshooting RDP.
 
 > [!NOTE]
-> In case we are using Hyper-V console to access the system, make sure to use “Basic session”, since “Enhanced session” will rely on RDP protocol and we may receive the same “RDS is currently busy” message, as it will not be a “pure console” (no RDP involved) connection.
+> In case we are using Hyper-V console to access the computer, make sure to use **Basic session** to do the test. This is because **Enhanced session** relies on RDP and we might receive the same "Remote Desktop Service is currently busy" message.
 >
-> If we do understand the issue is non-RDP related – if it occurs as well via console – the situation shouldn’t be approached as an RDP issue. Still, some of the troubleshooting steps mentioned below, related to RDP related troubleshooting (e.g., RDP server memory issue) may still be valid to troubleshoot overall system performance issues.
+> If we find the issue occurs when using console, and confirmed that the issue is not RDP related, some of the troubleshooting steps in this article such as RDP server memory issue might still be help to troubleshoot the overall system performance issues.
 
 ## RDP server memory issue
 
-If restarting the system temporarily solves the issue until it returns, this may indicate a memory leak or other types of leaks (session leak, token leak, etc.).
+To troubleshoot this issue further, first try to restart the target computer.
+
+If restarting the computer temporarily solves the issue, but the issue reoccurs later, this might indicate a memory leak or other types of leaks, such as session leak, token leak and so on.
 
-Restart the “Remote Desktop Services” service. If it solves the issue, it may suggest it’s an issue related to this service, and we should also try to understand if the service is indeed consuming an unusual / abnormal amount of memory.
- This is also a potential workaround without having to restart the whole system.
+A potential workaround without restarting the whole system is to restart the Remote Desktop service. If it solves the issue, it might indicate an issue with the service. You need to verify whether the service is indeed consuming an unusual or abnormal amount of memory.
 
 > [!NOTE]
 > Restarting RDS service will disconnect all current users that are connected via RDP. The sessions will be maintained though, and users may reconnect to their sessions.
->
-> If we do understand the issue is non-RDP related – if it occurs as well via console – the situation shouldn’t be approached as an RDP issue. Still, some of the troubleshooting steps mentioned below, related to RDP related troubleshooting (e.g., RDP server memory issue) may still be valid to troubleshoot overall system performance issues.
 
-Monitor if there’s another service or process with an usual memory consumption. If so, restarting the service or killing the process is also a good troubleshooting step and possible workaround.
+### Memory leaks
 
-Leaks are often caused by third-party software. Without proper data capture and a support case opened with Microsoft, it is difficult to pinpoint the cause.
+Monitor if there's another service or process with unusual memory consumption. If so, restarting the service or killing the process is also a good troubleshooting step and possible workaround.
 
-Testing by gradually uninstalling different software and monitoring if the issue stops can be a good approach. Ensure all third-party software is updated.
+> [!NOTE]
+> Leaks are often caused by third-party software. Without proper data capture and a support case opened with Microsoft, it is difficult to pinpoint the cause.
+>
+> Testing by gradually uninstalling different software and monitoring if the issue stops can be a good approach. Also, ensure all third-party software is updated.
+>
+> If we confirm the issue does occur only via RDP, it is advisable to uninstall any third-party software that interacts with the RDP stack.
+
+### Session leaks
 
-If we confirm the issue does occur only via RDP, it is advisable to uninstall any third-party software that interacts with the RDP stack.
+Another common reason for this type of memory growing issue after system restart is session leaks, which is one of those situations where by looking at resource consumption (such as looking for high memory or CPU consumption in Task Manager) will not show anything obvious as the issue is occurring “under the hood” on the system.
 
-Another common reason for this type of “growing” issue after system restart is session leaks, which is one of those situations where by looking at resource consumption (such as looking for high memory or CPU consumption in Task Manager) will not show anything obvious as the issue is occurring “under the hood” on the system.
-There may be several different reasons for session leak but, again, it is very common it is caused by 3rd party software.
-In the particular case of session leak, is also very common that this is caused by security software (Anti-virus, EndPoint protection software, etc.) or other types of software that may interact with RDP user’s sessions.
+There may be several different reasons for session leak, but it is very common that the leak is caused by 3rd party software. Particularly, it is very commonly caused by security software (such as antivirus or endpoint protection software) or other types of software that may interact with RDP user sessions.
 
 > [!NOTE]
-> Stopping the software does not have the same effect as totally uninstalling it from the system, as there may still be modules loaded, hooks to the system’s components, etc.
+> Stopping the software does not have the same effect as totally uninstalling it from the system, because there may still be modules loaded, hooks to the system’s components, and so on.
 
-If the issue is temporarily solved with a system restart, monitor if a certain process is consuming an unusual amount of memory and if its memory consumption is growing over time.
+If the issue is temporarily solved with a system restart, monitor if a certain process is consuming an unusual amount of memory and if the memory consumption is growing over time.
 
 ## GPO troubleshooting
 
-Hardening on the system, configured via GPO, may also be a possible reason. Identifying and removing related GPOs (e.g., RDS related GPOs or hardening GPOs such as changes made to "User Rights Assignment" Security policies) is a good test while monitoring if the issue returns.
-If possible, try to remove all GPOs from the system without that causing technical or security implications, that would be a good test as well, to narrow down if it is a GPO causing it.
+Hardening on the system, configured via GPO, might also be a possible reason.
 
-We can also check the “GroupPolicy” event logs to try to understand if there may be any GPO failing to be processed or if there’s a global issue with GPService, which can also be reasons to trigger this behavior.
-
-## Data collection
+To troubleshoot the issue, identify and remove related GPOs to test and monitor if the issue reoccurs. For example, RDS related GPOs or hardening GPOs such as changes made to "User Rights Assignment" Security policies.
 
-Although we’ve discussed many possible reasons related to what may cause this type of issue, for this kind of situation it’s usually not possible to know what is causing the issue without proper data capture and complex analysis - even if we identify a certain process or service that consumes too much memory, we will unlikely know what the root cause is for that high memory consumption.
+If possible, try to remove all GPOs from the system without that causing technical or security implications. This solution is a good test to narrow down if it is a GPO causing the RDP issue.
 
-We will now discuss data that can be captured in advance before opening a support case with Microsoft’s support.
+We can also check the "GroupPolicy" event logs to understand if there may be any GPO failing to be processed, or if there’s a global issue with GPService. Both of them can be the cause of the RDP issue.
 
-### Traces capture using TSS tool
-
-Download the latest version of the TSS tool from [https://aka.ms/GeTSS](https://aka.ms/GeTSS)
-
-Extract it to the RDP client system (source) and RDP server (target)
+## Data collection
 
-> [!NOTE]
-> For scenarios of a full RDS deployment, although the system where the “RDS service is currently busy” is showing, is the most important system to capture the data in, we should capture the data in all systems of the deployment involved in the connection flow (which includes RD Connection Broker and RD Gateway).
+Even if we identify a certain process or service that consumes too much memory, we will unlikely know what the root cause is. For unresolved issues, data collection is critical for complex analysis. Here are steps for preparing data before contacting Microsoft support.
 
-Launch a PowerShell prompt on both systems and run the following commands, respectively:
+### Traces capture using TSS tool
 
-RDP Client:
+1. Download the latest version of the TSS tool from [https://aka.ms/GeTSS](https://aka.ms/GeTSS)
+2. Extract it to the RDP client computer (source) and the RDP server (target).
 
-```console
-.\TSS.ps1 -Scenario UEX_RDSCli
-```
+   > [!NOTE]
+   > In scenarios of a full RDS deployment, although the system displaying the "RDS service is currently busy" message is the most important for data capture, we should collect data from all systems involved in the connection flow, including the RD Connection Broker and RD Gateway.
 
-RDP Server(s):
+3. Launch a PowerShell prompt on both systems and run the following commands, respectively:
 
-```console
-*.\TSS.ps1 -Scenario UEX_RDSSrv*
-```
+   On RDP client:
 
-Wait for the message that states to “Reproduce the issue now”
+   ```console
+   .\TSS.ps1 -Scenario UEX_RDSCli
+   ```
 
-Reproduce the connection until we get the “RDS is currently busy” error
+   On RDP Server(s):
 
-Stop the traces at this stage, by pressing the requested key to do so
+   ```console
+   *.\TSS.ps1 -Scenario UEX_RDSSrv*
+   ```
 
-Gather the data from where the tool informs it was saved (usually “C:\MS_DATA”)
+4. Wait for the message that states to **Reproduce the issue now**.
+5. Reproduce the connection until we get the "Remote Desktop Service is currently busy" error.
+6. Stop the traces at this stage, by pressing the requested key.
+7. Collect the data from the location where the tool prompts.
+8. Gather the data from the location specified by the tool. (usually C:\MS_DATA).
 
 ### Full memory dump
 
-We should take the full memory dump at the time the system is in the affect state and while reproducing a RDP connection that will generate the “RDS is currently busy” error message.
+We should take a full memory dump when the system is in the affected state and while reproducing an RDP connection that generates the "Remote Desktop Service is currently busy" error message.
 
 > [!NOTE]
 > Keep the connection with the error “RDS is currently busy” open while taking the dump, i.e., don’t close this connection and take the dump while the error is still being displayed on the affected connection.
-Please note down what was the user account used to reproduce this connection.
 
-### Capture dump on a Hypervisor / Virtual Machine scenario
+Note down what was the user account used to reproduce this connection.
 
-- Take a snapshot to the Virtual Machine – with “full memory” option selected, if the Hypervisor provides this option - at the time the dump should be taken (as described above).
+#### Capture dump on a hypervisor or virtual machine scenario
+
+- Take a snapshot to the virtual machine with "full memory" option selected, if the hypervisor provides this option. At the time the dump is be taken (as described above).
 - Convert the snapshot to a full memory dump.
 
 > [!NOTE]
 > Each Hypervisor manufacturer uses different tools / methods to convert the snapshot to full dump. Please check on the support documentation of that Hypervisor vendor how to perform this conversion.
 
-### Capture dump on physical system
+#### Capture dump on physical system
+
+Follow the steps described on the following article:
 
-Please follow the steps described on the following article:
 [Generate a kernel or complete crash dump](https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/generate-a-kernel-or-complete-crash-dump)
 
 ### Possible additional data
 
-There are different types of data that can be captured according to the different situations we’ve discussed within this article (for example, when a specific process / service that has growing memory consumption, a specific WPR capture should be performed to capture heap memory consumption of that process), but Microsoft’s support will inform accordingly what additional data may need to be captured after the first analysis is done and according to the situation we are facing.
+There are different types of data that can be captured depending on the situations discussed in this article. For example, if a specific process or service shows growing memory consumption, a specific Windows Performance Recorder (WPR) capture should be performed to capture the heap memory consumption of that process. However, Microsoft support will inform you of any additional data that may need to be captured after the initial analysis, based on the situation we are facing.