38
Windows Server 2016 Firewallregel lässt sich nicht ändern
Hallo Kollegen,
Windows 2016 DC, AD, DNS, DHCP
In der Domäne ist das SMB Protokoll 445 TCP durch eine Regel blockiert.
Die Regel die den Port blockiert ist Remoteverwaltung (NP eingehend), aktiviert, Domäne, alle Blockieren.
Ändern/deaktivieren/löschen geht nicht...
Bisher gibt es außer der default Domain Policy nur 3 weitere GPo. Die aber alle nicht die Regel beinhalten.
Zu finden müsste die Regel sein unter Computerkonfiguration/Richtlinien/Windows Einstellungen/Sicherheitseinstellungen/Windows Firewall/Windows Firewall mit erw Sicherheit/Eingehende Regeln
Auch per Powershell kann ich die Regel anzeigen lassen aber nicht löschen/ändern/deaktivieren.
Bin gerade etwas Ratlos, wo ich die Regel ändern oder löschen kann
Kann mir jemand helfen?
Danke Jörg
Windows 2016 DC, AD, DNS, DHCP
In der Domäne ist das SMB Protokoll 445 TCP durch eine Regel blockiert.
Die Regel die den Port blockiert ist Remoteverwaltung (NP eingehend), aktiviert, Domäne, alle Blockieren.
Ändern/deaktivieren/löschen geht nicht...
Bisher gibt es außer der default Domain Policy nur 3 weitere GPo. Die aber alle nicht die Regel beinhalten.
Zu finden müsste die Regel sein unter Computerkonfiguration/Richtlinien/Windows Einstellungen/Sicherheitseinstellungen/Windows Firewall/Windows Firewall mit erw Sicherheit/Eingehende Regeln
Auch per Powershell kann ich die Regel anzeigen lassen aber nicht löschen/ändern/deaktivieren.
Bin gerade etwas Ratlos, wo ich die Regel ändern oder löschen kann
Kann mir jemand helfen?
Danke Jörg
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 476458
Url: https://administrator.de/forum/windows-server-2016-firewallregel-laesst-sich-nicht-aendern-476458.html
Ausgedruckt am: 27.12.2024 um 00:12 Uhr
38 Kommentare
Neuester Kommentar
Hallo Jörg,
hast du wirklich alle GPOs durchgeschaut? Wenn nein, nochmals Augen reiben und nochmals durchschauen, wenn sonstig kein Tool die Regeln setzen kann muss das da sein.
Viele Grüße,
Christian
hast du wirklich alle GPOs durchgeschaut? Wenn nein, nochmals Augen reiben und nochmals durchschauen, wenn sonstig kein Tool die Regeln setzen kann muss das da sein.
Viele Grüße,
Christian
Hi,
vllt ein ungewöhnlicher Ansatz aber mal in die Registry geschaut?
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
vllt ein ungewöhnlicher Ansatz aber mal in die Registry geschaut?
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
Hallo Christian,
das dachte ich auch.
Wenn ich mit der Powershell mit die Firewallregel anzeige ist sie da, wenn ich sie dann ändern oder löschen will wird der Befehl ohne (Fehler)Meldung ausgeführt und die Regel ist noch Da.
Diese Regeln gibts in der gpmc
Alle sind sie im Bereich Firewall/Eingehende Regeln leer
Die Remotediesnteverwaltung habe ich vorhin hinzugefügt und sie ist ebenfalls leer.
Dies ist die Regel, die ich nicht ändern oder löschen kann
Ich finde leider nicht die Einstellung die ich ändern muss.
Sorry, ist ein System, dass ich übernommen habe und muss mich da noch reinfinden
das dachte ich auch.
Wenn ich mit der Powershell mit die Firewallregel anzeige ist sie da, wenn ich sie dann ändern oder löschen will wird der Befehl ohne (Fehler)Meldung ausgeführt und die Regel ist noch Da.
Diese Regeln gibts in der gpmc
Die Remotediesnteverwaltung habe ich vorhin hinzugefügt und sie ist ebenfalls leer.
Dies ist die Regel, die ich nicht ändern oder löschen kann
Ich finde leider nicht die Einstellung die ich ändern muss.
Sorry, ist ein System, dass ich übernommen habe und muss mich da noch reinfinden
Hallo Bitboy,
danke für den Input,
hab ich gefunden
Ist wohl die mittlere. Da finde ich aber Action=Allow
das bedeutet doch, dass diese Regel den Port 445 eingehend auf TCP öffnet?!
Oder verstehe ich das falsch???
Jörg
danke für den Input,
hab ich gefunden
das bedeutet doch, dass diese Regel den Port 445 eingehend auf TCP öffnet?!
Oder verstehe ich das falsch???
Jörg
Ein Schrittchen weiter,
Es gibt die Regel "2mal"
Einmal für Alle und einmal für Domäne und letztere blockiert
Es gibt die Regel "2mal"
Einmal für Alle und einmal für Domäne und letztere blockiert
Da du die Regel per Powershell gesetzt hast, häng mal ein
-Profile Domain
an den Befehl.
-Profile Domain
an den Befehl.
nee, hab ich nicht.
Oder ich hab keine Ahnung wie es der Kollege von früher gemacht hat.
die die ich angelegt habe, da ist aber die Regel nicht enthalten, habe ich mit der gpmc angelegt.
Mir würde sehr helfen, wenn ich einen Tipp bekommen könnte wo/wie ich die Regel finden kann!?
Oder wie ich die betreffende löschen kann. Mit der Powershell hats nicht geklappt.
Syntax ok, es kommt keine Fehlermeldung, aber anschließend ist sie nicht gelöscht
Oder ich hab keine Ahnung wie es der Kollege von früher gemacht hat.
die die ich angelegt habe, da ist aber die Regel nicht enthalten, habe ich mit der gpmc angelegt.
Mir würde sehr helfen, wenn ich einen Tipp bekommen könnte wo/wie ich die Regel finden kann!?
Oder wie ich die betreffende löschen kann. Mit der Powershell hats nicht geklappt.
Syntax ok, es kommt keine Fehlermeldung, aber anschließend ist sie nicht gelöscht
Moin,
drei Anmerkungen meinerseits:
Gruß,
Dani
drei Anmerkungen meinerseits:
- Die Gruppenrichtlinie, die du in den Screenshots markiert hast, hast du bearbeitet? Die gilt natürlich nur für Server welche als Domain Controller agieren.
- Die Gruppenrichtlinie Default Domain Controllers Policywird bis auf wenige Ausnahmen nie, nie, nie verändert/ergänzt. Zu den Ausnahmen gehören die Windows-Firewall Regeln nicht.
- Bevor du nun wie wild an den Servern "rumspielst" und evtl. Dinge änderst, die zu Instabilität oder Ausfällen sorgen, erst einmal analyiseren. Wenn du Windows-Firewall Regeln manuell nicht verändern kannst, gibt es zwei Gründe. A) Der Benutzer, unter dem du das versuchst, hat auf dem betroffenen System keine administrativen Rechte. B) Es wird pe Gruppenrichtlinie erzwungen. Welche Gruppenrichtlinie dafür verantwortlich ist, kannst einfach herausfinden. Auf dem betroffenen Server einfach die Befehle rsop.msc und gpresult /r ausführen. Danach solltest du mehr wissen...
Oder ich hab keine Ahnung wie es der Kollege von früher gemacht hat.
Da ist die liebe Dokumentation wieder auf der Strecke gelieben. Manche Unternehmen lernen es erst, wenn es zu spät ist oder teuer wird. Gruß,
Dani
Hi Dani,
- die Default Domain Controller Policy habe ich nicht geänder und hab das auch nicht vor. Das zumindest ist klar (war nur vom umsortieren markiert)
- ich bin mit dem domadmin angemeldet, der sollte doch genügend rechte haben?
- spielen ist nicht!-)
- bei gpresult /r bekomme ich
Angewendete Gruppenrichtlinienobjekte
--------------------------------------
Default Domain Policy
und die beinhaltet nicht die Regel
- bei gpresult /z bekomme ich
Angewendete Gruppenrichtlinienobjekte
--------------------------------------
Default Domain Controllers Policy
Default Domain Policy
WMI-Verwaltung-zulassen
Folgende herausgefilterte Gruppenrichtlinien werden nicht angewendet.
----------------------------------------------------------------------
Richtlinien der lokalen Gruppe
Filterung: Nicht angewendet (Leer)
Und auch bei den 3en finde ich die Regel, die es blockiert nicht. Die habe ich mir ja schon in der Verwaltungskonsole angeschaut
Gruß Jörg
- die Default Domain Controller Policy habe ich nicht geänder und hab das auch nicht vor. Das zumindest ist klar (war nur vom umsortieren markiert)
- ich bin mit dem domadmin angemeldet, der sollte doch genügend rechte haben?
- spielen ist nicht!-)
- bei gpresult /r bekomme ich
Angewendete Gruppenrichtlinienobjekte
--------------------------------------
Default Domain Policy
und die beinhaltet nicht die Regel
- bei gpresult /z bekomme ich
Angewendete Gruppenrichtlinienobjekte
--------------------------------------
Default Domain Controllers Policy
Default Domain Policy
WMI-Verwaltung-zulassen
Folgende herausgefilterte Gruppenrichtlinien werden nicht angewendet.
----------------------------------------------------------------------
Richtlinien der lokalen Gruppe
Filterung: Nicht angewendet (Leer)
Und auch bei den 3en finde ich die Regel, die es blockiert nicht. Die habe ich mir ja schon in der Verwaltungskonsole angeschaut
Gruß Jörg
Guten Morgen,
noch ein Gedanke.
Kann ich mir anzeigen lassen wo (welcher User) die Regel konfiguriert ist/hat?
Z.B. per powershell oder sonstwie
Suche da grade die "Nadel im Heuhaufen" wo ich die Regel ändern kann
Wünsche einen sonnigen Tag
Jörg
noch ein Gedanke.
Kann ich mir anzeigen lassen wo (welcher User) die Regel konfiguriert ist/hat?
Z.B. per powershell oder sonstwie
Suche da grade die "Nadel im Heuhaufen" wo ich die Regel ändern kann
Wünsche einen sonnigen Tag
Jörg
Moin,
afaik gibts da kein Log für wer wann welche regel geändert hat.
Was passiert denn wenn du die Regel per Powershell ändern möchtest?
afaik gibts da kein Log für wer wann welche regel geändert hat.
Was passiert denn wenn du die Regel per Powershell ändern möchtest?
Hallo zurück,
danke für die Infos.
Bin einen deutlichen Schritt weiter.
Habe festgestellt, das die DCs sich nicht (richtig) synchronisieren!
Die Regel kommt vermutlich vom anderen DC?!
Das muss ich mir jetzt erstmal anschauen.
Neue Baustelle...
Per Powershell wird der Befehl einfach "ohne Kommentar" ausgeführt und die Regel ist noch da.
Das Log, da habe ich noch nicht nach gesucht. Vermutlich nein
danke für die Infos.
Bin einen deutlichen Schritt weiter.
Habe festgestellt, das die DCs sich nicht (richtig) synchronisieren!
Die Regel kommt vermutlich vom anderen DC?!
Das muss ich mir jetzt erstmal anschauen.
Neue Baustelle...
Per Powershell wird der Befehl einfach "ohne Kommentar" ausgeführt und die Regel ist noch da.
Das Log, da habe ich noch nicht nach gesucht. Vermutlich nein
Firewall Problem die Fortsetztung,
Gestern habe ich festgestellt, dass die Replikation zwischen den DCs nicht klappt.
Der Ursache bin ich auf die Spur gekommen. Die lokale Firewall der DCs blockieren die Kommunikation. Vermutlich auch weil der Port 445 und 135 domänenweit blockiert wird.
Nachdem ich die Firewall deaktiviere klappts mit der Replikation.
So,
dann habe ich versucht die Firewallregeln
Per Powershell zu löschen
Firewall Regel, die Blockieren anzeigen durch
Get-NetFirewallRule -Action block -Enabled True -Direction Inbound
Hmm, die Regel wird im GUI angezeigt, aber nicht via powershell!? Oder habe ich da einen Fehler eingebaut?
Eine Firewallregel Port 0815 Domänenweit blockieren erzeugt
Nochmal die Get-NetFirewallRule -Action block -Enabled True -Direction Inbound anzeigen
Und siehe da die 0815 Regel wird angezeigt und die anderen 3, die ich nicht löschen kann NICHT!?
Dann deaktiviere ich einfach die Regel.
Disable-NetFirewallRule -Action Block -Enabled True -Direction Inbound
Hmm hat geklappt.
Keine mehr da (in der Powershell)
Dann schauen wir uns das in der GUI nochmal an.
Siehe da, die Test0815 Regel ist deaktivert, aber nicht die, die ich eigentlich löschen will!!
So, wenn ich jetzt Remove-NetFirewallRule -Action block -Direction Inbound ausführe, müssten eigentlich alle 4 Regeln gelöscht werden
Die Test0815 ist gelöscht, die 3 anderen nicht…
Die Regeln gibt’s übrigens domänenweit.
Nochmal zu den Einzelheiten der Regeln, die sich nicht löschen lassen
Und der Administrator / Domadmin darf die Regel nicht ändern!
Noch Ideen?
Oder Tipps, wer uns da bei der Lösung helfen kann?
Genervte Grüße Jörg
Gestern habe ich festgestellt, dass die Replikation zwischen den DCs nicht klappt.
Der Ursache bin ich auf die Spur gekommen. Die lokale Firewall der DCs blockieren die Kommunikation. Vermutlich auch weil der Port 445 und 135 domänenweit blockiert wird.
Nachdem ich die Firewall deaktiviere klappts mit der Replikation.
So,
dann habe ich versucht die Firewallregeln
Firewall Regel, die Blockieren anzeigen durch
Get-NetFirewallRule -Action block -Enabled True -Direction Inbound
Eine Firewallregel Port 0815 Domänenweit blockieren erzeugt
Dann deaktiviere ich einfach die Regel.
Disable-NetFirewallRule -Action Block -Enabled True -Direction Inbound
Keine mehr da (in der Powershell)
Dann schauen wir uns das in der GUI nochmal an.
So, wenn ich jetzt Remove-NetFirewallRule -Action block -Direction Inbound ausführe, müssten eigentlich alle 4 Regeln gelöscht werden
Die Test0815 ist gelöscht, die 3 anderen nicht…
Die Regeln gibt’s übrigens domänenweit.
Nochmal zu den Einzelheiten der Regeln, die sich nicht löschen lassen
Noch Ideen?
Oder Tipps, wer uns da bei der Lösung helfen kann?
Genervte Grüße Jörg
HI,
der Hinweis dass diese Einstellung vom Systemadministrator gesetzt wird lässt weiter darauf schließen, dass die Regel von einer GPO kommt.
Alternativ könntest mal prüfen ob irgendwelche 3rd Party Sachen installiert sind die da eventuell rumpfuschen.
Zuletzt mal den umgekehrten Weg versuchen: GPO erstellen die explizit den TRaffic zulässt und schauen ob die angewendet wird.
Grüße
der Hinweis dass diese Einstellung vom Systemadministrator gesetzt wird lässt weiter darauf schließen, dass die Regel von einer GPO kommt.
Alternativ könntest mal prüfen ob irgendwelche 3rd Party Sachen installiert sind die da eventuell rumpfuschen.
Zuletzt mal den umgekehrten Weg versuchen: GPO erstellen die explizit den TRaffic zulässt und schauen ob die angewendet wird.
Grüße
Hi Bitboy,
danke für Deine Idee.
Die GPos einthalten NICHT die Regeln.
Eine Test GPo,a cuh mit dem selben Port, wird angewendet, nur steht die Block Regel höher und wirkt dadurch weiterhin.
Question
Sie können nicht über Ihren eigenen Beitrag abstimmen.
Die Regelquelle ist "Lokale Gruppenrichtlinienenstellung"
UND lässt sich leider nicht ändern/löschen/etc. so als wenn sie nicht existiert.
Tut sie aber, da sie wirkt und in der GUI angezeigt wird.
Mit der Poweshell, ist es wie als wenn sie nicht vorhanden ist.
Als Thitparty Produkt sehe ich egentlich nichts, außer Symntec Endpoint Protection...
Noch Ideen?
Jörg
danke für Deine Idee.
Die GPos einthalten NICHT die Regeln.
Eine Test GPo,a cuh mit dem selben Port, wird angewendet, nur steht die Block Regel höher und wirkt dadurch weiterhin.
Question
Sie können nicht über Ihren eigenen Beitrag abstimmen.
Die Regelquelle ist "Lokale Gruppenrichtlinienenstellung"
UND lässt sich leider nicht ändern/löschen/etc. so als wenn sie nicht existiert.
Tut sie aber, da sie wirkt und in der GUI angezeigt wird.
Mit der Poweshell, ist es wie als wenn sie nicht vorhanden ist.
Als Thitparty Produkt sehe ich egentlich nichts, außer Symntec Endpoint Protection...
Noch Ideen?
Jörg
Schon in die lokale Sicherheitsrichtlinie geschaut ob da die Regeln definiert sind?
secpol.msc
Hab ich,
unter "Lokale Gruppenrichtlinienenstellung"
Aber auch in der gpdit.msc unter Richtlinie/Computer/Windows/Sicherheit/Windows Firewall/Windows Firewall mit erw/Eingehende Regeln ist KEINE definiert.
auch nichts
Ich bin ratlos
Jörg
unter "Lokale Gruppenrichtlinienenstellung"
Aber auch in der gpdit.msc unter Richtlinie/Computer/Windows/Sicherheit/Windows Firewall/Windows Firewall mit erw/Eingehende Regeln ist KEINE definiert.
auch nichts
Ich bin ratlos
Jörg
Im Endpoint Protection was definiert?
Hallo zurück,
da gehe ich nicht von aus.
Wir haben den Kunden übernommen und ich hoffe wir bekommen auf den Manager mit Hilfe des Supports Morgen (Supporttermin) Zugriff.
Das ist meine letzte Hoffnung.
Leider auch da kein funktionierendes Passwort und die restore Mail geht wohl ins nirvana...
Herzlichen Gruß
Jörg
da gehe ich nicht von aus.
Wir haben den Kunden übernommen und ich hoffe wir bekommen auf den Manager mit Hilfe des Supports Morgen (Supporttermin) Zugriff.
Das ist meine letzte Hoffnung.
Leider auch da kein funktionierendes Passwort und die restore Mail geht wohl ins nirvana...
Herzlichen Gruß
Jörg
Hallo All,
in den letzten tagen haben wir
das Problem mit dem Zugriff auf die Symantec Verwaltungskonsole gelöst und die Verwaltung läuft wieder.
Festgestellt habe ich auch, dass die Firewallregeln (von Symantec) nicht funktionieren konnten. Diese habe ich erstmal auf default umgestellt und so die Funktion in der Domain wiederherstellen können.
Soweit so gut.
Nur leider kann ich die 3 oben beschriebenen (domänenweiten) Windows Firewall Regeln noch immer nicht löschen oder ändern.
Wenn ich einen Client oder Server aus der Domäne nehme ist die Regel auch weg. Wird also in der Domäne verteilt und hat nichts mit AV oder lokaler Regel zu tun.
Mir gehen die Ideen aus das Problem zu lösen.
Hat jemand noch Vorschläge?
Herzlichen Gruß
Jörg
in den letzten tagen haben wir
das Problem mit dem Zugriff auf die Symantec Verwaltungskonsole gelöst und die Verwaltung läuft wieder.
Festgestellt habe ich auch, dass die Firewallregeln (von Symantec) nicht funktionieren konnten. Diese habe ich erstmal auf default umgestellt und so die Funktion in der Domain wiederherstellen können.
Soweit so gut.
Nur leider kann ich die 3 oben beschriebenen (domänenweiten) Windows Firewall Regeln noch immer nicht löschen oder ändern.
Wenn ich einen Client oder Server aus der Domäne nehme ist die Regel auch weg. Wird also in der Domäne verteilt und hat nichts mit AV oder lokaler Regel zu tun.
Mir gehen die Ideen aus das Problem zu lösen.
Hat jemand noch Vorschläge?
Herzlichen Gruß
Jörg
Hallo zusammen. Gestern ist und genau das selbe bei einigen unserer Windows Clients aufgefallen. Diese drei Firewall-Regeln sind da und können nicht gelöscht oder bearbeitet werden. Angeblich kommen die von Administrator, aber keine GPO stellt diese ein.
Powershell und netsh finden diese Regeln gar nicht erst. Daher kann man auch nicht versuchen die dadurch zu löschen.
Da durch eine der Regeln der Port 445 und durch eine andere der Port 135 geblockt werden, vermuten wir in dieses Regeln die Verursacher eines SCCM-Softwarecenter Problems das wir haben.
Nun bin ich hier auf diesen Beitrag gestoßen und dacht ich schreibe einfach mal. Vielleicht gibt es ja schon neue Erkenntnisse. Ich persönlich vermute in zwischen WIndows Defender Endpointprotection vom SCCM als übeltäter, finde aber keinen entsprechenden Punkt.
Vielleicht hat ja noch jemand eine Idee.
Viele Grüße
Nils
Powershell und netsh finden diese Regeln gar nicht erst. Daher kann man auch nicht versuchen die dadurch zu löschen.
Da durch eine der Regeln der Port 445 und durch eine andere der Port 135 geblockt werden, vermuten wir in dieses Regeln die Verursacher eines SCCM-Softwarecenter Problems das wir haben.
Nun bin ich hier auf diesen Beitrag gestoßen und dacht ich schreibe einfach mal. Vielleicht gibt es ja schon neue Erkenntnisse. Ich persönlich vermute in zwischen WIndows Defender Endpointprotection vom SCCM als übeltäter, finde aber keinen entsprechenden Punkt.
Vielleicht hat ja noch jemand eine Idee.
Viele Grüße
Nils
Guten Morgen NilsAcht,
sitze gerade auch wieder dran.
Magst Du Dich mal bei mir melden?
sitze gerade auch wieder dran.
Magst Du Dich mal bei mir melden?
Klar, wie?
Grade festgestellt,
dass die Firewall-Regeln verschwunden sind, wenn der Testclient aus der Domäne genommen wird und wieder auftauchen wenn wieder Domänenmitglied.
UND
Als Regelquelle wird die Lokale Gruppenrichtlinieneinstellung genannt?!
Das widerspricht sich doch?
Noch ne Idee?
Jörg
dass die Firewall-Regeln verschwunden sind, wenn der Testclient aus der Domäne genommen wird und wieder auftauchen wenn wieder Domänenmitglied.
UND
Als Regelquelle wird die Lokale Gruppenrichtlinieneinstellung genannt?!
Das widerspricht sich doch?
Noch ne Idee?
Jörg
Moin.
Wenn die hier auf Deaktiviert gesetzt sind kommt das geschilderte Verhalten und der Defender verhindert das Ändern.
Wenn diese Policies in deinen GPOs nicht direkt sichtbar sind, gehe in den SYSVOL-Ordner und checke die GPOs in den Dateien manuell nach, bei älteren Policies kann es mal vorkommen das diese über die MMC nicht sichtbar sind.
Zusätzlich mit rsop.msc am Client die gesetzten Policies prüfen.
Gruß
Wenn die hier auf Deaktiviert gesetzt sind kommt das geschilderte Verhalten und der Defender verhindert das Ändern.
Wenn diese Policies in deinen GPOs nicht direkt sichtbar sind, gehe in den SYSVOL-Ordner und checke die GPOs in den Dateien manuell nach, bei älteren Policies kann es mal vorkommen das diese über die MMC nicht sichtbar sind.
Zusätzlich mit rsop.msc am Client die gesetzten Policies prüfen.
Gruß
Ich habe die Einstellungen gemacht und diese werden auch angewendet. Leider habe ich immer noch die drei Regeln die ich nicht löschen kann.
Jörg und ich habe den Vormittag mal geschaut und leider nicht sehr viel mehr neues raus gefunden. Die Regel scheint von einer GPO zu kommen, aber ein GPResult zeigt diese nicht an. Außerdem scheint diese GPO den Zugriff im Domänen-Profil zu erlauben, tut sie aber nicht.
Jörg und ich habe den Vormittag mal geschaut und leider nicht sehr viel mehr neues raus gefunden. Die Regel scheint von einer GPO zu kommen, aber ein GPResult zeigt diese nicht an. Außerdem scheint diese GPO den Zugriff im Domänen-Profil zu erlauben, tut sie aber nicht.
Dann beherzige mal meinen Rat manuell in die GPOs im Sysvol reinzuschauen.
Sorry aber da steige ich nicht durch. Wonach genau soll ich denn dort schauen?
Nach Regeln die so nicht selbst in den GPOs ersichtlich sind. Du machst also einen Abgleich mit denen in der GUI sichtbaren Policies.
Denn Policies müssen nicht zwingend alle in der GUI sichtbar sein wenn derjenige eigene ADMX Templates verwendet hat.
Deswegen auch mein Hinweis zu rsop.msc am Client, in der alle einzelnen Einstellungen ersichtlich sind. Genauso wie im GPO-Cache am Client.
Denn Policies müssen nicht zwingend alle in der GUI sichtbar sein wenn derjenige eigene ADMX Templates verwendet hat.
Deswegen auch mein Hinweis zu rsop.msc am Client, in der alle einzelnen Einstellungen ersichtlich sind. Genauso wie im GPO-Cache am Client.
Auch auf die Gefahr hin, dass ich sehr dumm dar stehe: Im Sysvol Ordner sehe ich nur GUIDs als Ordnernamen. Klar kann ich mich da überall durch klicken, dauert mir aber zu lange.
Kann ich die Ordnernamen irgendwie auflösen?
Kann ich die Ordnernamen irgendwie auflösen?
Klar, in der GPMC Rechtsklick auf die GPO Eigenschaften, da steht die GUID, oder per Powershell : Get-GPO
Get-GPO -All | ft DisplayName,ID
So, GPO auf dem Server eingestellt. Diese wird auch auf dem Client angewandt. Dennoch kann ich nicht an den Firewall Regeln ändern. Leider ist die Firewall abschalten oder den Softwarecenter Client auf 700 Rechner per Hand zu aktualisieren keine Option.
Gibt es noch andere Ideen?
Gibt es noch andere Ideen?
Solltest du aber nicht machen.
Wie gesagt, wenn derjenige der da hantiert hat eigene ADMX Templates z.B. mit einem speziellen Registry-Eintrag genutzt hat, siehst du das nicht in der GUI!!!
Gibt es noch andere Ideen?
S.o. Auf ein Ergebnis warten wir noch.
Dennoch kann ich nicht an den Firewall Regeln ändern.
Deswegen manuell die GPOs prüfen, wie ist das denn jetzt verlaufen?? Jetzt sag nicht "keine Zeit". Wenn man noch nicht mal diese Grundlegende Aktion durchgeht um sicherzustellen das nicht doch etwas unter der GUI durchrutscht ist alles andere vertane Zeit!Wie gesagt, wenn derjenige der da hantiert hat eigene ADMX Templates z.B. mit einem speziellen Registry-Eintrag genutzt hat, siehst du das nicht in der GUI!!!
oder den Softwarecenter Client auf 700 Rechner per Hand zu aktualisieren keine Option.
Wofür gibt's SoftwaredeploymentGibt es noch andere Ideen?
Ich habe die lokalen GPOs überprüft. Aber der GPMC (den ist erst mit den RSAT Tools nachinstallieren musste) zeigt mir nur die Serverrichtlinien. Auch der Powershell-Befehl (welchen ich erst ausführen konnte, nachdem ich den GPMC installiert habe) zeigt mir noch die Serverrichtlinien an. Daher habe ich die Policy einmal auf dem Server eingestellt und an meinen Client verteilt.
Wenn das der flasche Weg war, würde ich mich über eine genauere Erklärung freuen, da ich leider in dem ganzen Thema GPO nicht so bewandert bin.
Und das pushen des Clients über SCCM (Softwaredeployment) geht ja nicht, da durch die Regel der Port 445 geblockt wird. Und ein Block reicht um alle Allows dieses Ports aufzuheben.
Wenn das der flasche Weg war, würde ich mich über eine genauere Erklärung freuen, da ich leider in dem ganzen Thema GPO nicht so bewandert bin.
Und das pushen des Clients über SCCM (Softwaredeployment) geht ja nicht, da durch die Regel der Port 445 geblockt wird. Und ein Block reicht um alle Allows dieses Ports aufzuheben.
Du solltest die Richtlinien im Sysvol checken nicht nur am Client.
.
Aber der GPMC (den ist erst mit den RSAT Tools nachinstallieren musste) zeigt mir nur die Serverrichtlinien.
Logisch! Geh an den Server und nutze mal dort die GPMC. Wenn ihr keinen Domänenweiten Central-Store für die Templates nutzt unterscheiden sich die Templates am Server und am Client.Auch der Powershell-Befehl (welchen ich erst ausführen konnte, nachdem ich den GPMC installiert habe) zeigt mir noch die Serverrichtlinien an.
Auch logisch, deswegen alles erst mal am Server machen.Daher habe ich die Policy einmal auf dem Server eingestellt und an meinen Client verteilt.
Trial & Error geht aber kostet nur noch mehr Zeit und beseitigt nicht die Ursache.Und das pushen des Clients über SCCM (Softwaredeployment) geht ja nicht, da durch die Regel der Port 445 geblockt wird. Und ein Block reicht um alle Allows dieses Ports aufzuheben.
Es gibt auch andere Methoden per GPO .
So, nach ein paar Tagen ohne Versuche sind die Regeln nun auf Allow gesetzt. Leider kann ich mir nicht erklären warum. Auf meinem Client habe ich viel versucht, aber es ist auch auf Clients aktiv, die drei Wochen nicht eingeschaltet waren. Oder auf denen nichts geändert wurde.
Bei mir lag das Problem darin, dass in der GPO in der RDP-Richtlinie "Windows-Firewall: Eingehende Remotedesktopausnahmen zulassen" einen Eintrag im Bereich "Unerbetene eingehende Meldungen von diesen IP-Adressen zulassen:" als IP-Liste hatte.
Hier dürfen KEINE Leerzeichen zwischen den Einträgen sein.
Also "192.168.2.1,192.168.2.254" und nicht "192.168.2.1, 192.168.2.254" (Leerzeichen nach dem Komma).
Nachdem ich alle Leerzeichen gelöscht hatte und bei den Clients ein "gpupdate /force" durchgeführt habe, konnte ich mich wieder per RDP verbinden.
Wer denkt denn bitteschön an so etwas?
Zumal aus einer Allow-Regel durch das Leerzeichen eine Deny-Regel wird, die sich auf den Clients auch nicht löschen lässt.
Ich hoffe, dass dies bei dem ein oder anderen auch hilft!
Hier dürfen KEINE Leerzeichen zwischen den Einträgen sein.
Also "192.168.2.1,192.168.2.254" und nicht "192.168.2.1, 192.168.2.254" (Leerzeichen nach dem Komma).
Nachdem ich alle Leerzeichen gelöscht hatte und bei den Clients ein "gpupdate /force" durchgeführt habe, konnte ich mich wieder per RDP verbinden.
Wer denkt denn bitteschön an so etwas?
Zumal aus einer Allow-Regel durch das Leerzeichen eine Deny-Regel wird, die sich auf den Clients auch nicht löschen lässt.
Ich hoffe, dass dies bei dem ein oder anderen auch hilft!
@MasterPhlox: habe heute 4 Stunden verbracht nach diesem sch*§$s Fehler zu suchen.
Dein Hinweis mit den Leerzeichen war dann endlich des Rätsels Lösung.
Vielen Dank dafür !
Dein Hinweis mit den Leerzeichen war dann endlich des Rätsels Lösung.
Vielen Dank dafür !
