Helpforsure

Microsoft Windows Experts

Remote Desktop Service cannot be restarted if Keep-Alive feature is enabled October 9, 2011


If the RDP Keep-Alive feature is enabled on a Windows Server 2008 (or Windows Server 2008 R2) server, manually stopping the Remote Desktop Services service (Windows Server 2008 R2) or Terminal Services service (Windows Server 2008) will leave the server in an unstable state: restarting the service will not re-enable RDP functionality, and the server will hang during shutdown.

The keep-alive thread is started by the Remote Desktop Services (Terminal Services) service if Keep-Alive is enabled, however it runs in Kernel mode and can therefore not be terminated automatically when the service stops.

So let’s not attempt to stop or restart the Remote Desktop Services (Terminal Services) service if the RDP keep-alive mechanism is enabled.

When Keep-Alive is enabled and the Remote Desktop Services (Terminal Services) service is stopped, its svchost.exe process will remain in the Task list, even though the service is reported to have stopped correctly.  When the service is started again, a new svchost.exe will be started however the server will not accept incoming RDP connections due to inconsistency in the TermDD driver state.

The Keep-Alive feature can be enabled by Group Policy:

 Windows Server 2008 R2:

 Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections

 Configure Keep-Alive Connection Interval

Windows Server 2008:

 Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Connections

 Configure Keep-Alive Connection Interval

 To configure directly in the registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]

“KeepAliveInterval”=dword:00000001

“KeepAliveEnable”=dword:00000001

 

HowTo: Perform an In-Place Upgrade on Windows Vista, Windows 7, Windows Server 2008 & Windows Server 2008 R2 October 7, 2011


An in-place upgrade is the final alternative before you have to reinstall the operating system.
Note: It takes the same amount of time to do the upgrade as to reinstall the operating system. Also, some of your customized Windows settings may be lost through this process.

Performing a repair installation will restore the current Windows installation to the version of the installation DVD. This also requires the installation of all updates that are not included on the installation DVD.

Note: Performing a repair installation will not damage files and applications that are currently installed on your computer.

To perform a repair installation of Windows Vista, Windows Server 2008, Windows 7 or Windows Server 2008 R2, follow these steps:

  1. Close all the running applications.
  2. Insert the Windows Vista, Windows Server 2008, Windows 7 or Windows Server 2008 R2 DVD in the computer’s DVD drive.
  3. In the Setup window, click Install Now.

    Note: If Windows does not automatically detect the DVD, follow these steps:

    1. Click Start, and then type Drive:\setup.exe in the Start Search box.
      Note: The Drive placeholder is the drive letter of the computer’s DVD drive.
    2. In the Programs list, click Setup.exe.
    3. In the Setup window, click Install Now.
  4. Click Go online to obtain the latest updates for installation (recommended).
  5. Type the CD key if you are prompted to do this.
  6. Select the operating system in “Install Windows” page you want to Upgrade or Inplace.
  7. Click Yes to accept the Microsoft Software License Terms.
  8. On the Which type of installation do you want? screen, click Upgrade.
  9. When the installation is complete, restart your computer.
 

Windows XP Virtual Machines exhibiting degraded performance & high CPU utilization with Hyper-V & VDI April 16, 2011


I came across and issue where a customer had a VDI deployment of Windows XP machines running on Windows Server 2008 R2 Hyper-V servers. The problem was that while performance of the virtualized desktops was fine on one of the Hyper-V machines, it was not so good on the other.

In checking the performance of the Windows XP VM’s, it was found that CPU usage was significantly higher on the ones running on the problem server that the other. Perfmon showed the higher CPU usage, but was not conclusive as to a specific process causing the issue.

As we were looking for performance difference on VM’s running on the two different Hyper-V hosts, we collected Performance Monitor logs for the various Hyper-V counters. From these, we saw that the counter Hypervisor Virtual Processor\APIC TPR Accesses/sec was a flat line on the good performing server, but had a lot of ups and downs on the problem server.

TPR stands for Task Priority Register. It turns out that Windows XP and prior operating systems do very frequent access to the APIC TPR, which puts a bit more overhead on the hypervisor. Essentially, when the IRQL is raised, it immediately accesses the processor’s local APIC to set the interrupt mask. This prevents it from being pre-empted by a lower IRQL interrupt. And now, when the IRQL needs to be lowered, we need to access the local APIC again.

However, in Windows Server 2003 and later operating systems, we implement a concept known as Lazy IRQL. With this, when the IRQL is raised, the HAL keeps a note of the raised IRQL within a structure of it’s own. Now, if the processor gets a lower priority interrupt, the OS checks this with the locally stored IRQL and only then accessed the APIC to set the interrupt mask. In the newer versions of Windows, the duration for which an Interrupt Service Request (ISR) actually needs to run is very low. However this is not the case with Windows XP and earlier operating systems. An APIC TPR request must occur for every IRQL raise and also subsequent lowering. This additional overhead is small on an individual scale, but can add up quickly, and was in fact what was causing the VM’s to be slower. Now, this explains the poor performance for the Windows XP VM’s on one of the servers, but what about the other server that had good performance? Both of these servers were superficially identical, and were even running the same model of Intel processor.

Well, it turns out that Intel has a technology called vTPR that is designed to work around this type of issue. However, this technology is not present in all of their CPU models. Even though the processors in both servers were the same model, the stepping revision was not. The server exhibiting the performance issue had a stepping revision of B3, whereas the other server had a stepping of G0. It turns out that the processor with the stepping of B3 did not implement vTPR, but the one with stepping G0 did.

So, how do we work around the initial issue? Unfortunately there is not a simple software trick to get around this. The solution to this issue would be to either replace the processor with one which implements vTPR, or to upgrade the guest operating systems to something which supports Lazy IRQL; I recommend Windows 7. More info on Intel vTPR can be found in the this document.