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.
 

QuickTip: File on a Windows 2008 or Vista system is owned by trusted installer and can’t be replaced or modified

Filed under: Misc — helpforsure @ 12:06 am
Tags: , , , , , ,

In Windows 2008 Server or Windows Vista, Various Files are by default owned by the ‘Trusted Installer’ account. The administrator may have read only access to these files.At various times, you may be instructed by Microsoft Support to replace versions of these protected files.
In addition, various configuration files are owned by the Trusted installer and you may need to make modification to these files to enable tracing or make other configuration changes. If you manually take ownership of the files, you will not be able to restore the default configuration since the GUI doesn’t display the account ‘trusted installer’ in the owner dialog. It is highly recommended that after making the needed changes, you restore the ACLs to their previous default configuration. The proper procedure for this is to first backup the ACLs using icacls and then later restore the ACLs back on the file(s) once the operation is complete.
These ACL’s can be backed up by typing the following command at the command prompt (use an elevated command prompt if UAC is enabled by right clicking a cmd.exe shortcut and choosing ‘run as administrator’)

icacls %windir%\system32\CustomApp.exe /save C:\BackedUpACLs.txt

After this you should take ownership of the file and modify the permissions. This will allow you to replace the file (after making a copy of it first) or make the needed modifications.

When you are finished making your changes and are ready to return the permissions to the default, you can use the following command to restore the ACLs that you previously backed up. This will allow Trusted Installer to become the owner of the file again.

icacls c:\windows\system32\ /restore c:\BackedUpACLs.txt

This file is text based and can be viewed with the following command:
notepad c:\MyBackedUpACLs.txt

Note: You may use wildcards, but keep in mind that it’ll fail if you haven’t taken ownership of all of the files that match your wildcard mask and changed the permissions to grant yourself control. In other words, if you back all of the executables in System32 with the following command:

icacls %windir%\system32\*.exe /save c:\BackedUpACLs.txt

Then, you would have to take ownership of ALL of the .exe files which ‘trusted installer’ owned and change thier permissions to grant your logged in account rights to the file. This is because the restore operation will attempt to restore ALL of the .exe’s that matched your wildcard mask. If it finds a file that it cannot access, the entire opreation will stop and the files that normally would have worked will never be reached.

 

HowTo: Disable Internet Protocol version 6 (IPv6) components in Windows Vista & 2008, Windows 7 & 2008 R2 and Windows Small Business Server 2008 & 2011 April 27, 2011


This article describes step-by-step instructions for how to disable certain Microsoft Internet Protocol version 6 (IPv6) components in Windows Vista & 2008, Windows 7 & 2008 R2 and Windows Small Business Server 2008 & 2011. To disable IPv6 components, you must be logged on to the computer as a member of the Administrators group.

 To disable certain IPv6 components yourself, follow these steps:

Launch Registry Editor and modify DisabledComponents key located under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\

 Note: If it’s not available, you must create it.

Name: DisabledComponents

Type: DWORD (32-bit) Value

Type any one of the following values to configure the IPv6 protocol:

  • Type 0 to enable all IPv6 components(Note: The value “0” is the default setting.)
  • Type 0xffffffff to disable all IPv6 components, except the IPv6 loopback interface. This value also configures Windows Vista to use Internet Protocol version 4 (IPv4) instead of IPv6 in prefix policies.
  • Type 0x20 to use IPv4 instead of IPv6 in prefix policies.
  • Type 0x10 to disable native IPv6 interfaces.
  • Type 0x01 to disable all tunnel IPv6 interfaces.
  • Type 0x11 to disable all IPv6 interfaces except for the IPv6 loopback interface.

Note: Using a value other than 0x0 or 0x20 will cause the Routing and Remote Access service to fail after this change goes into effect.

You must restart your computer for these changes to take effect.

 

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.

 

Three ways to configure WinRM listeners. January 26, 2011


Configure WinRM Listeners through Quick Configure.

1.      Configuration HTTP listener and other actions to enable this machine for remote management:

winrm qc

2.      Configuration HTTPS listener and other actions to enable this machine for remote management:

winrm qc –transport:https (more…)