Microsoft Windows Experts

You may not be able to connect to published RemoteApp when connecting via RD Web through RD Gateway. November 2, 2011

When you try to open a Remote App via RD Gateway, you may get the following errors:

“You may not be able to connect to your remote apps when connecting remote apps on RD Web through RD Gateway.”

or “The logon attempt failed”.

While the default logon page for RD Web Access indicates “Domain\user name” for the user name field, using only the user name works fine. However, this works fine as long as your not using RD Gateway and Single Sign-On, then the either of the above error messages will occur when trying to start a RemoteApp.

The catch is when RD Gateway and Single Sign-On are being used, you must supply the domain as part of the user name (domain\user name), else the SSO-feature will break.



Windows Server 2003 (x86) Role based Performance Tuning October 16, 2011

The three typical significant roles that I encounter servers in are:

  •  File Server
  •  Domain Controller
  •  Terminal Server


There are obviously a large number of other roles such as IIS, Exchange, Hyper-V host, etc. but for each of these I think they are outnumbered vastly by the above roles so I am going to cover those – hopefully with the details of what the changes do, you can determine whether to test altering them on your other servers.


And yes, we are focusing mainly on x86 (32-bit) servers here – once you go 64-bit a lot of these changes become irrelevant as they ceiling is raised implicitly with the extra address space.


Get your priorities right


On the context menu of My Computer, click Properties

On the System Properties window presented, select the Advanced tab, click the Settings button under Performance

On the Performance Options window presented, select the Advanced tab

Here you will see Adjust for best performance of:

– Programs

– Background services


What this setting influences is the quantum used for thread execution – how much time they get to run on a processor without interruption from threads at the same or lower priority.


For programs to appear more responsive to the user, a shorter quantum is preferred, so more context switching occurs.

Server services prefer to run without being bothered with so many context switches, so prefer a longer quantum.


A Terminal Server hosts user sessions and has many processes directly accessed by interactive users, so should have the Programs radio button selected.

A file server or DC on the other hand has little direct user interaction, so we want to extend the quantum and optimize for Background services.


The other radio button selection relating to Memory Usage toggles LargeSystemCache off (tune for programs) and on (tune for system cache) – the default is enabled on Windows Server SKUs, but again Terminal Servers can be considered “multiple user desktop” servers and so would prefer to have the workstation default, to tune for programs instead.


Dipping in the pool

For all roles, it can be useful to have the Memory Manager more aggressive when it comes to trimming paged pool allocations – by default this occurs at the 80% watermark, but this can lead to the server being unable to satisfy requests before it gets round to cleaning up – so to reduce this watermark to 60% will make the housekeeping kick in earlier:

Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

Name: PoolUsageMaximum


Data: 60 (decimal)


For Terminal Servers it is useful to have a paged pool that is as big as possible, while an algorithm at startup determines the size of the paged pool region we do have the option to indicate that we would like it to be given preference (at the cost of Page Table Entries, PTEs):

Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

Name: PagedPoolSize


Data: ffffffff (hexdecimal)

(This is the same setting that we recommend to make if you are getting Srv 2020 events after trying the more aggressive trimming tweak above.)


Giving to the givers (File Server & DC specific)

When it comes to file servers and DCs specifically, we want to tune for the Server (LanmanServer) service to get some love as they will be receiving many SMB connections, this can be done through some registry tweaks:

Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Name: MaxWorkItems


Data: 65535 (decimal)

65,535 is the maximum you can set, and this value specifies the number of receive buffers that the Server service can allocate at any time – the default is a calculation made based on system resources during startup, so we are influencing this decision to suit our needs.


These values set the minimum and maximum number of preallocated connection objects respectively:

Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Name: MinFreeConnections


Data: 128 (decimal)


Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Name: MaxFreeConnections


Data: 1024 (decimal)

(This is the same setting that we recommend to make if you are getting Srv 2022 events.)


Terminal station (Terminal Server specific)

Terminal Servers act and should be treated more as “very busy clients” than servers – think about the probably of concurrent AD user logons, roaming or mandatory profile copying, files opened across the network, applications making connections to mail or database servers, and so on.


Resultant Set of Policy (RSoP) is useful for troubleshooting, but it can impact performance during “normal” operation, so it can be turned off by enabling the following group policy:

Computer Configuration / Administrative Templates / System / Group Policy / Turn off Resultant Set of Policy


Post-SP1 hotfix from KB319440 (rolled into SP2) gives control of buffering group policy reads which can improve logon times if concurrent logons are causing blocking operations when users are trying to access the same policies:

Path: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

Name: BufferPolicyReads


Data: 1


There is a Workstation (LanManWorkstation) service tweak which increases the number of concurrent outbound network calls:

Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

Name: MaxCmds


Data: 2048 (decimal)


Also network related, this tweak makes Explorer more responsive by cutting down on the (metadata) information queries made when browsing network shares, especially those with many, many files or folders:

Path: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Policies\Explorer

Name: NoRemoteRecursiveEvents


Data: 1

Name: NoRemoteChangeNotify


Data: 1

(This tweak can be pushed out to clients in a large environment as it applies to Explorer more than the concurrent user nature of Terminal Services.)


This is a very brief start at looking at what performance gains you might see on busy servers, or environments with slow/latent networks, or file servers with hundreds of thousands of files being browsed by multiple users.


Any of the registry values can be looked up on MSDN or TechNet if you’re interested in the “official” descriptions of what they do.

And as always, note any changes you make to server configurations and back up beforehand.


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]




Windows cannot connect to the printer. Operation failed with error 0x0000007e

Recently we started experiencing a strange issue with connecting to printers on Windows-7 x64 based client boxes, we were getting the following error every time we try to connect a printer:

Windows cannot connect to the printer.

Operation failed with error 0x0000007e.

So, 64-bit Windows 7 installed, we checked all was okay. Oops… x64 windows needs x64 printer drivers. 64-bit drivers added to the Server 2003 x86 based Print server, the client machines would download the driver (we were using the HP Universal print driver PCL 6) but then fail with the following error when trying to connect to the printer:

Windows cannot connect to the printer.

Operation failed with error 0x0000007e.

So we tried PCL5. No luck. None of the HP drivers would work. Googling the error showed lots of people in the same position – with 64-bit Windows Vista or Windows 7 and a 32-bit print server. The only suggested workaround is to add the printer manually to a workstation as a local printer, and picking up the driver from a CD or download that way (not from the print server).

So… in comes Process Monitor. Not long before the dreaded error message, spoolsv.exe looks in a registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\Servers\[SERVERNAME]\Printers\{0000-guid-of-printer-00}\CopyFiles\BIDI\Module that tells it to go find (system32) spool\DRIVERS\W32X86\3\hpcpn081.dll. This doesn’t exist, hence the ‘module not found’ error 7e. The driver installation does, interestingly, copy a newer hpcpn104.dll into this directory. Getting warmer!

Copying hpcpn081.dll from \\PRINTSERVER\print$\x64\3 to c:\windows\system32\spool\drivers\w32x86\3… printer installs successfully! So, why is it copying the wrong dll? Well, a short dig through the server’s registry reveals a key similar to the one on the client, in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\[PRINTERNAME]\CopyFiles\BIDI. The “Module” value points to spool\DRIVERS\W32X86\3\hpcpn104.dll. Change this to hpcpn081.dll and hey presto, all is fixed.

No having to deploy drivers to all machines or send the desktop teams round… just tweak this value for each of your stubborn printers!

Just go to your print server and change

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\[PRINTERNAME]\CopyFiles\BIDI\Module

from hpcpn104.dll to hpcpn081.dll

Hope it helps…



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.


How to find which process initiated a wmiprvse.exe October 6, 2011

Filed under: WMI — helpforsure @ 11:54 pm
Tags: , , , ,

In many cases we have noticed issues with Wmiprvse.exe. the issue could be anything- from CPU spike to high memory consumption. The main problem in such cases is to find out the process that initiated the wmiprvse.exe, taking a dump of the concerned wmiprvse.exe process will also not help.

The best way to figure out this process is as under.

Go to Start -Run – Wbemtest

connect to root\cimv2 namespace and launch the following Query

select * from msft_providers where HostProcessIdentifier = PID

where PID is the process Id of the wmiprvse.exe.