Posts Tagged ‘rdp’

Remotely Enable Remote Desktop in Windows 7 Professional

Friday, February 22nd, 2013

I recently needed to login to a computer on a LAN that did not have Remote Desktop enabled. Here are the high-level steps that I took.

If you search online, you will typically find references to a registry setting to enable RDP.

Specifically:

HKLM Hive  -> System -> CurrentControlSet -> Control -> Terminal Server > fDenyTSConnections  should be changed to zero.

See: http://pctech.blog.ca/2012/04/07/enable-remote-desktop-connection-in-windows-7-using-regedit-remotely-13444092/

That’s not sufficient in most cases.

You also typically need to allow Remote Desktop through the firewall. I did this using Sysinternals psexec tool to get a command prompt to the remote machine.

i.e. psexec \\remote-computer cmd.exe

Then running a netsh rule to enable RDP:
i.e. netsh firewall set service type = remotedesktop mode = enable

 

Also, I needed to add the user to the local computer’s Remote Access user’s group (not the exact name).

A reboot was required.

See:

netsh firewall rule:  http://technet.microsoft.com/en-us/library/cc736451(v=ws.10).aspx

psexec: http://technet.microsoft.com/en-ca/sysinternals/bb897553.aspx

Problems installing the RDP Patch in Windows XP?

Friday, March 16th, 2012

If you’re in IT, and you are responsible for some Windows computers, you should have heard of the upcoming critical security issue with Remote Desktop.  If not, read about it here or here or any number of articles on other tech sites in the last week.

We have several clients using RDP and Terminal Server in various configurations. Usually, we’ve set them up behind firewalls that block by IP address or custom ports that make them a little less vulnerable. We’ve begun the process of making sure that the Windows Updates are current on these machines, especially those that have Remote Desktop enabled and connected to the Internet on the standard port of 3389.

Today, I ran into a machine that just could not run Windows Updates for some reason, and hadn’t for about 3 months. I tried many potential solutions, in which I won’t go into detail.

This post is not about fixing Windows Updates. This is about installing the critical security patch for WinXP SP3 for the RDP issue before the exploits begin.

The work around in my case was to manually install the patch.

This is Microsoft’s official security bulletin, Microsoft Security Bulletin MS12-020 – Critical Vulnerabilities in Remote Desktop Could Allow Remote Code Execution (2671387). If you read to the bottom, you see links to pages specific to various vulnerable Microsoft OSs. This is the one for Windows XP – Security Update for Windows XP (KB2621440).  On that page is a download link to get the patch! Just download and run it.

Sure, the right thing to do is fix Windows Update on this particular computer; however, installing just this patch is far, far better than nothing.

Spoolsv.exe using lots of CPU on a Terminal Server

Friday, July 17th, 2009

I have this recurring problem at one client’s site.  The setup is a small Windows 2003 Terminal Server environment, with remote POS terminals over the Internet – I don’t like this arrangement for the many single points of failure (a couple ADSL lines, a couple routers, a couple switches, a single server, etc.), but that’s beyond the scope of this post.

This client is happens to be running BBL, AKA WinPOS, AKA, WinBPS, over Terminal Server.  I have no comment on the software itself, it’s the arrangement of using it over Terminal Server over the Internet that makes me nervous – no, I had no input into this setup.

A further complication, is that the printers that the software uses, Zebra, label/ticket printers, have poor drivers that I don’t believe to be TS compatible.  They sometimes get stuck when the remote session is closed.  This eventually screws up the Windows spooler service.

When this system stops working, new Remote Desktop sessions fail to start properly.  After logging into the server, I will check the processor usage in Task Manager.  If the spoolsvc.exe process is using a lot of processor time, this is what I do:

N.B. Follow at Your Own Risk.

Stop the spooler service (no one will be able to print, but they probably can’t already):

net stop spooler

Open RegEdit.exe and browse to this part of the registry:

HKLM\SYSTEM\CURRENTCONTROLSET\CONTROL\PRINT\PRINTERS\

At times, I’ll find dozens of stale Terminal Server printers listed.

Export the registry keys first, to make a backup, just in case.

Then delete the Terminal Server printers from that same part of the registery, do NOT delete the local printers.  These are the ones with the “…on MyComputer … in session…” within the printer name.

Deleting these has worked for this particular server several times to resolve the CPU hogging spooler service (spoolsv.exe)… but sometimes they can’t be deleted in RegEdit.

Grab a copy of RegDelNull by Systernals, it’s free as in beer.

Use RegDelNull.exe to remove some of the entries that would not delete manually – I’m looking at you Mr. Zebra Printer Driver.

Here’s what that looks like (anonymized, of course):

C:\Installs>regdelnull HKLM\System\CurrentControlSet\Control\Print\Printers -s

Note: In a recurrence of this problem, I had to run RegDelNull one step higher in the registry, I’m not sure why – i.e. HKLM\System\CurrentControlSet\Control\Print

RegDelNull v1.10 - Delete Registry keys with embedded Nulls Copyright (C) 2005 Mark Russinovich Sysinternals - www.sysinternals.com Null-embedded key (Nulls are replaced by '*'): HKLM\SYSTEM\CURRENTCONTROLSET\CONTROL\PRINT\PRINTERS\Zebra101 _ on MyComputer(from MyComputer2) in session 3\PrinterDriverData\Barcodes\(0x1701)*de 93

You get a prompt to fix the Null.  Say “Yes”.

Then go back up a few steps and delete the problematic printer from RegEdit.  With the null value gone, you can delete it.

Then restart the spooler service.

net start spooler

If this works, the spooler will start, it won’t use a suspicious amount of processor cycles, and the RDP connections will start working immediately – no reboots required.

Then go and find updated drivers.

I’d be glad to hear about a better solution… please comment below.