Link to home
Start Free TrialLog in
Avatar of Hooznext
Hooznext

asked on

ISA 2004 W/Remote Desktop Configured Suddenly not working

Hello experts, here's my situation: Windows 2003 SP1 Standard with ISA 2004 Standard SP2. I have remote desktop administration configured and was working properly, I could remote in from authorized workstations and my VPN connection from outside the office.

I rebooted the server and suddenly remote desktop will not work. I have verified Security Policy is enabled, service is running from monitoring tab, also terminal services is enabled on server with admin group allowed. Firewall policy rules are in place and look fine, I had this issue once before and was fiddling around and got it working but honestly have no idea what it was I did to fix it as nothing looked wrong.

I am running out of ideas and would like to hear from anyone on this as I haven't found anything online to this point to help me.
Avatar of Keith Alabaster
Keith Alabaster
Flag of United Kingdom of Great Britain and Northern Ireland image

Hi there.

You are running sp2 so I assume you have also installed the post sp2 rollup patch? If not, get it from here. Its a MUST really and fixes a number of irritating issues.
http://support.microsoft.com/kb/930414

open the isa gui, select monitoring - logging - click on start query
Try the rdp connection again, what do you see in the log?

Is the TS on the ISA box itself? If so, did you amend the ISA system policy and update the remote management group to include the addresses that were allowed to use rdp onto ISA?
If its not on ISA, can you rdp from ISA to the TS box successfully?

keith
Also, as the remote access is so quick to set up, just remove the publishing rule for the rdp, apply the policy and re-add it again. Just make sure you allow it for both external and vpn clients.
Avatar of Hooznext
Hooznext

ASKER

Keith, I don't think it is an access rule preventing me due to the results in logging I am receiving.

I'm not sure if I have applied the roll up but will do so. I created a new rule allowing access and applied it and tried to connect. In logging I am seeing the connection initiate and then get closed, the rule name displayed is not the rule I set up so I assume it is the system policy, it says something along the lines of 'Allow remote administration via terminal services...'. A short time after the connection is initiated it is then closed, it attempts the connection 2 or 3 times on each NIC card for the ISA server then on the remote end I receive an error just like remote desktop is not enabled on the server.

There is nothing in the logging about it being denied or blocked so it makes me think there is something else I am missing.
Can you explain what you mean by tries on each nic? The publishing rule should be applied to the external interface only.
Sorry Keith, my laptop died this weekend and I was out of town.

First, I have not published the server to the untrust network, it must be accessed from one of our internal VLAN's or through a VPN connection.

When I am internal and attempt to remote desktop into the ISA server in the logging screen I will see the connection initiated from my IP address on the same VLAN as my workstation then it will say the connection is closed. It attempts to do this twice on my workstation VLAN. Then the connection is initiated from my IP on the NIC of ISA that is on our Server VLAN, same results, then it attempts the same on our Perimeter VLAN, then it finally attempts on the external network. The destination IP is always a valid IP for a NIC on the ISA server, it always shows the connection is initiated then closed in a normal fashion but it occurs usually within 1-2 seconds of when the connection is initiated. It never says the connection is denied or simialr.

When it initiates the connection in the 'Rule Name' column it says something like 'Allow remote administration....' which is not one of my firewall policy rules so I believe this is the configuration I have in place allowing me to connect.

One the remote workstation I am attempting to login with, it tries to connect, waits for a period of time then gives me an error just like remote desktop is not enabled on the server.
ASKER CERTIFIED SOLUTION
Avatar of Keith Alabaster
Keith Alabaster
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Keith,

I have already done this. I had remote desktop working fine from both internal VLAN's and VPN connections. The other day I restarted the server and since then the remote connections no longer work. I have verified I have the system policy setup to allow connections, I also have firewall policies in place to allow RPD traffic to the ISA server and I have made sure the remote desktop is enabled in the My Computer Properties. It was working for nearly 11 months since the server was brought online and suddenly stopped after a restart. I had this happen one other time in this network and honestly have no idea what I did to get it going again, I began verifying my setup and configuration and deleted and created access policies and after some tinkering like that it suddenly began working again. But I cannot put my finger on anything in particular I did to change the configuration from prior to the restart.

Thanks for the help though, I have found nothing useful online and am not sure where to go from here. If I cannot find anything in the next day or so I will call Microsoft and get thier help and post the results if it comes to that.
If you change your rule to being rdp to a different, internal device (not the ISA box), does it work OK?

What message do you get on the client when rdp connection is attempted to the ISA box?
I am able to remote into any server or workstation internally and from the VPN EXCEPT ISA. When I attempt to connect on the client side it gives me a pop up window that says:

Title Bar is: Remote Desktop Disconnected
Message Body:
This computer cannot connect to the remote computer.

Try connecting again. If the problem continues, contact the owner if the remote computer or your network administrator.

About 8 or 9 months ago, I had an issue on a site that was quite similar and it required a registry change in hklm from a 1 to a 0 or the other way round.

Trying to find it now, I got it from Google originally
....
Can't find it... Is that definitely the full error message? I can't find that listed under MSDN as a standard error message for RDP either.
Yes that is the full message, I would post a screen shot if I could, but...

The message is in an alert box with an 'OK' and 'Help' button, I click help and it is basically useless, describes what a remote connection is and such.

I have done a little more checking and found an event log entry on the ISA server that reads:

'Reporting queued error: faulting application beremote.exe, version 10.1.5629.20, faulting module bedssql2.dll, version 10.1.5629.13, fault address 0x0001f814.'

No idea if this is related but saw the beremote.exe and thought it may merrit some looking into, there are no event logs on the client machine that relate to the issue, I didn't expect any but was hoping it maybe wrote something there to assist me.

Never mind, it appears to be something with our back up agent.
I think thats Backup Exec
OK, after working with Microsoft on this...We rebooted the server several times and it is now working. They were unable to offer an explination that was concrete but I was told the most likely cause was the Terminal Services Service was left in an innappropriate state which caused it to hang upon restart. It's odd because I've only had this issue with a server running ISA, but it is now working, I have rebooted the server at least 6 times since then and each time it comes up and is working properly. I am sorry I could not put an answer here that was of some value but the condition no longer exists and we did nothing to the configuration of the server or ISA.

Keith thanks for the help!
Thank you for the points and the update on your findings.
Regards
keith