initsol
asked on
Firewall blocking RDP due to old nonexisting GPO?
Hi there,
I have a Windows 2008 SP2 Server configured as DC, IIS, WSUS.
Before there was a SBS2003 and the Windows 2008 SP2 was our 2nd DC.
We installed a 2008 R2 Server as new DC, degraded the SBS, migrated Exchange to 2010 and raised the domain function level to 2008.
The new GPO templates (ADML and ADMX) are located on sysvol.
The problem is, that on the 2008 SP2 Server, a firewall rule exists which blocks RDP. Windows says it's configured by a group policy.
But we don't have a policy to prohibit RDP, just one the activates it for 3 special subnets.
I ran GPResult /H on the server itseld and use the gpo management tool on the 2008 R2 to check which policies are used and wich ones are declined.
There is no rule blocking RDP!
gpresult on the server itself shows one error:
"Eins der folgenden Elemente wurde erwartet, <text>, <decimalTextBox>, <textBox>, <checkBox>, <comboBox>, <dropdownList>, <listBox>, stattdessen wurde <multiTextBox> gefunden. Datei \\my-domain.local\sysvol\m y-domain.l ocal\Polic ies\Policy Definition s\de-DE\te rminalserv er-Server. adml, Zeile 198, Spalte 60
Bei der Analyse ist ein unbekannter Fehler aufgetreten (Fehler = 0x87400001): -2025848831 (0x87400001) Datei \\my-domain.local\sysvol\m y-domain.l ocal\Polic ies\Policy Definition s\terminal server-Ser ver.admx, Zeile 9, Spalte 41"
Do you have any idea?
I have a Windows 2008 SP2 Server configured as DC, IIS, WSUS.
Before there was a SBS2003 and the Windows 2008 SP2 was our 2nd DC.
We installed a 2008 R2 Server as new DC, degraded the SBS, migrated Exchange to 2010 and raised the domain function level to 2008.
The new GPO templates (ADML and ADMX) are located on sysvol.
The problem is, that on the 2008 SP2 Server, a firewall rule exists which blocks RDP. Windows says it's configured by a group policy.
But we don't have a policy to prohibit RDP, just one the activates it for 3 special subnets.
I ran GPResult /H on the server itseld and use the gpo management tool on the 2008 R2 to check which policies are used and wich ones are declined.
There is no rule blocking RDP!
gpresult on the server itself shows one error:
"Eins der folgenden Elemente wurde erwartet, <text>, <decimalTextBox>, <textBox>, <checkBox>, <comboBox>, <dropdownList>, <listBox>, stattdessen wurde <multiTextBox> gefunden. Datei \\my-domain.local\sysvol\m
Bei der Analyse ist ein unbekannter Fehler aufgetreten (Fehler = 0x87400001): -2025848831 (0x87400001) Datei \\my-domain.local\sysvol\m
Do you have any idea?
Have you taken al ook in the policy template file mentioned in the error? \\my-domain.local\sysvol\m y-domain.l ocal\Polic ies\Policy Definition s\terminal server-Ser ver.admx, Zeile 9 And what's on line 9?
There could be a local group policy object interfering as well, On the terminal server type gpedit.msc and check it out. Otherwise setting a new policy for the ts allowing the settings and setting it to enforce should solve the problem.
There could be a local group policy object interfering as well, On the terminal server type gpedit.msc and check it out. Otherwise setting a new policy for the ts allowing the settings and setting it to enforce should solve the problem.
ASKER
Thanks for your fast answers!
@strivoli: I changed the port to 3390, restarted the server, connected via RDP on port 3390, put a rule to the firewall to allow 3390 incoming on tcp and activated the firewall.
That works. So, it is the port :)
@Vilken: I can't find an error on line 9. It says "<string id="TS_APP_COMPATIBILITY_H elp">Steue rt die Einstellungen zur Anwendungskompatibilität auf einem Remotedesktopsitzungs-Host server</st ring>"
I already checked local policy. Sorry, forgot to mention.
I'll give enforcing the existing policy a try, but I don't think it'll work if I remove the enforcement afterwards.
@strivoli: I changed the port to 3390, restarted the server, connected via RDP on port 3390, put a rule to the firewall to allow 3390 incoming on tcp and activated the firewall.
That works. So, it is the port :)
@Vilken: I can't find an error on line 9. It says "<string id="TS_APP_COMPATIBILITY_H
I already checked local policy. Sorry, forgot to mention.
I'll give enforcing the existing policy a try, but I don't think it'll work if I remove the enforcement afterwards.
ASKER
I just notice that remotemanagement (NP incoming), remotemanagement (rpc incoming) and remotemanagement (rpc-epmap) are blocked as well.
So if I enable the firewall, I can't use my RSAT on my Windows 7 computer
So if I enable the firewall, I can't use my RSAT on my Windows 7 computer
Have you check the default domain policy so that the settings arent coming from within that? Sometimes admins configure everything within that policy :/
The settings for windows firewall are located at:
Computer Configuration, Policies, Administrative Templates, Network, Network Connections, Windows Firewall, Domain Profile
The settings for windows firewall are located at:
Computer Configuration, Policies, Administrative Templates, Network, Network Connections, Windows Firewall, Domain Profile
ASKER
yes, multiple times. Nothing configured there
If you move the ts server to another newly created ou and run gpupdate /force on the ts server do you still get the settings?
ASKER
@Vilken: that's interesting
I moved the DC (2008 SP2) to another (new) OU and triggered gpupdate /force -> RDP works
I moved him back, gpupdate /force -> no more RDP
But the oder DC (2008 R2) works fine!
One again I checked the GPO's -> no blocking anywhere.
Ok, time for try and error:
Removed the a self-made Server-GPO from the ou - gpupdate /force -> no RDP
moved Server-GPO back
removed "SBS-Überwachgungsrichtlin ie" - gpupdate /force -> RDP works !!
The deny rules are now removed from the firewall with advanced settings.
When I now try to use RSAT from my Windows 7 -it doesn't work. No error - just waiting...
---
wait - it just stopped working :-/
---
a lot of try and error: asigning the gpo's to the new ou - removing them step by step - a lot of gpupdate /force
---
summary:
when I'm adding my Server-GPO which allows certain subnets access via RDP it works for a view minutes , then stops working
.
Since I've got no more ideas:
I'll now try to create a new GPO under Server 2008R2 with the same settings and replace the old with the new one
I moved the DC (2008 SP2) to another (new) OU and triggered gpupdate /force -> RDP works
I moved him back, gpupdate /force -> no more RDP
But the oder DC (2008 R2) works fine!
One again I checked the GPO's -> no blocking anywhere.
Ok, time for try and error:
Removed the a self-made Server-GPO from the ou - gpupdate /force -> no RDP
moved Server-GPO back
removed "SBS-Überwachgungsrichtlin
The deny rules are now removed from the firewall with advanced settings.
When I now try to use RSAT from my Windows 7 -it doesn't work. No error - just waiting...
---
wait - it just stopped working :-/
---
a lot of try and error: asigning the gpo's to the new ou - removing them step by step - a lot of gpupdate /force
---
summary:
when I'm adding my Server-GPO which allows certain subnets access via RDP it works for a view minutes , then stops working
.
Since I've got no more ideas:
I'll now try to create a new GPO under Server 2008R2 with the same settings and replace the old with the new one
Hi, That's strange but atleast u've verified that there are policies being applied that affect the servers firewall settings. You may need to now allow remote administration in the firewall on the ts server for it to work properly again.
ASKER
I just saw that the 2008R2 Server has the same deny rules in the firewall, but there rdp and rpc work!
That's confusing....
That's confusing....
I guess all you can do is find the policy cuasing the settings, and then go through it checking all policys and filtering by state, enable to not defined to disabled. Wish i could be to more help here.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Gotta love that space, glad you got it working :)
ASKER
Found the solution ourselves
This would tell us, with no doubt, it is the port being blocked or something else.