You don’t need to read this. It’s a saga of conflicting remote management schemes. It’s just here in case somebody has the same problem I had, cos the answer isn’t anywhere on the internet that I could find.

THE PROBLEM :

I have a win2k3 server that I can’t get at remotely. Now the consultants who look after the SQL db can’t get in, nor can I admin it from my couch at home.

Terminal Server isn’t installed, just remote access turned on under the system control panel. Used to happily take up to two concurrent Remote Desktop connections. We are a Netware shop, and I need this server to be in the tree to run Ingot (internet accounting, runs on Windows but integrates with Netware) The problems came when I upgraded the 2k3 server to the latest version of Zenworks Desktop Management Agent (4SP1 I think).

The problem *looks* like the symptoms in this MS KB article
http://support.microsoft.com/default.aspx?scid=kb;en-us;270588

“Terminal Services clients may not be able to connect to a Windows 2000-based computer that is running Terminal Services.

When you use the Terminal Services Configuration snap-in (Tscc.msc), the transport (RDP-Tcp) appears to be present and working. However, when you view the transport by using Terminal Services Manager (Tsadmin.exe), the RDP-TCP listener is reported as “Down 65536.” “

But the described causes (and fix) don’t apply.

I’m pretty sure it’s something to do with the Zenworks remote management stuff – after the ZW update, TermServices refused to load illegal module drishti.dll, which is the video driver interceptor for Zenworks. I’ve removed the entire ZenWorks agent, and now termServices thinks it starts, but won’t accept clients (same symptoms as above).

AND THE FIX :

Found the fix, with much trawling of Netware docs and a bit of poking about the registry.

The problem is twofold. I’m guessing that Zenworks Remote Management and Windows Terminal Services aren’t ready to co-exist on 2k3 server. That much I had worked out. But when I removed Zenworks, it left one little bit of trouble in the registry.

HKLM
,”SYSTEM\CurrentControlSet\Services\RDPDD\Device0″,”InstalledDisplayDrivers”,0×00010002,”Drishti
RDPDD”

Drishti being the Zenworks video interceptor thingy. Checked with Mark who confirmed that it should look like this :
HKLM
,”SYSTEM\CurrentControlSet\Services\RDPDD\Device0″,”InstalledDisplayDrivers”,0×00010002,”RDPDD”

Changed that, sent finance staff home early, rebooted the server, Remote Desktop is working again, and I can go back to admining from the comfy chair.