Monthly Archives: May 2013

Remote Desktop Disconnected, unable to connect Windows 2003 Server via RDP

I ran into this problem after doing a successful recovery of server which failed miserably. Was able to ping and RDP was enabled and listening on the right port number etc, but kept getting the error when trying to RDP into the 2003 server.

“The client could not connect to the remote computer. Remote connections might not be enabled or the computer might be too busy to accept new connections. It is also possible that network problems are preventing your connection.”

The Resolution:

To resolve the problem make sure that the correct network adapter is bound to RDP-TCP connection. To do this, follow these steps:
1. On the server, logon to the server locally (not using Remote Desktop/Terminal Client).
2. Click Start, Run, type “tscc.msc /s” (without qutation marks and click OK.
3. In the Terminal Services Configuration snap-in double-click Connections, then RDP-Tcp in the right pane.
4. Click the Network Adapter tab, select the correct network adapter and click OK.
5. Make sure that you can establish an RDP connection to the server.

Alternative resolution steps.
Use these steps only if you can not perform local logon to the affected server.
WARNING: Using Registry Editor incorrectly may cause serious problems that may require you to reinstall your operating system. Use Registry Editor at your own risk and only after making backup of full Registry and the keys you are going to change. Please see More Information section for registry backup and restore information.
1. Start Registry Editor (Regedt32.exe).

2. Click File\Connect network Registry. Enter computer name or IP address and click OK. Firewalls between your computer and the affected server may prevent successfull connection. Remote Registry service should be running on the server.

3. Navigate to the following registry key (path may wrap):

4. Under this key are one or more keys for the globally unique identifiers (GUIDs) corresponding to the installed LAN connections. Each of these GUID keys has a Connection subkey. Open each of the GUID\Connection keys and look for the Name value. Choose the connection you want Terminal Services to use.

5. When you have found the GUID\Connection key that contains the Name setting that matches the name of your LAN connection, write down or otherwise note the GUID value.

6. Then navigate to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\lanatable. Using the GUID you noted in step 5 select subkey. Note it’s LanaId.

7. Navigate to the following value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\LanAdapter. Change it’s data to the value you noted in step 6. If you want RDP to listen on all LAN adapters enter value of 0.


nsebin.def files filling up C:\Windows\Temp folder; norman scan engine update issue in Microsoft Forefront

Recently bumped into problem where an exchange 2010 server was running low in disk space on the C drive.  After checking all aspects like exchange database location, log files, shadow copies and page file, in the end it was the C:\Windows\temp folder, there were a bunch of tmp files with the name nsebin.def files similar to below but too many in numbers

nsebin.def.xxxx.temp file

nsebin.def.xxxx.temp file

A quick Google search led me to this post on technet:

This problem is due to a recent bug on the Norman Scan Engine update which surfaced around 25/4/2013 following which older nsebin.def files weren’t removed and hence the build up. One can certainly imagine what this might do to a 40Gb System drive partition as each of these of files were around 320Mb and downloaded twice a day if you have forefront downloading automatically for you.

The solution as of now is to delete the nsebin.def files as and when you get low on space, there is no need to restart any services for this, just get in there and DELETE, do not delete the nse_temp files.

As there is no fix yet, as suggest on the post, disable the Norma Scan engine and update schedules as below in Forefront:

Disable Norman Scan engine and update schedule

Disable Norman Scan engine and update schedule

One has also suggested rebuilding the Norman Engine folder to get Forefront to automatically fix this, but this hasnt worked for me, but you are welcome to try.

Rebuild Norman Engine Folder:

To do this locate the Norman folder C:\Program Files (x86)\Microsoft Forefront Protection for Exchange Server\Data\Engines\x86\Norman  or on a different drive where you installed forefront and rename the folder to Norman.old

Rename Norman folder

Rename Norman folder

Once done renaming, open the forefront console and force an update by going to Policy Management > Global Settings > Advanced Options > Update Scheduling section,  right click the Norman engine there and select update now.

Update norman engine

Update norman engine

You should now see a new Norman folder created, but the problem is the old def files are still there.

MS is still working on this and I will update this post when I find out that my problem has been fixed.

update 13/5/13: Still nothing from MS, I have left Norman scan engine and update schedule disabled.

update: 15/5/13: MS have released a fix, if you have disabled the scheduled update, enable it.