dA.oOZe

Hat keiner einen Tip für mich? Kann doch nicht sein dass ich der Einzige bin, der die Clientfirewall benutzt...

Moin Forum! Ich bin schon seit Tagen auf der Suche nach einer Lösung für folgendes Problem: Wir haben diverse Windows 2008 R2 Server in unserem Netz. Alle Server haben die lokale Firewall aktiviert. Wir verteilen einen gewissen Satz an Firewallregeln global über GPOs, müssen aber auch auf lokale Firewallregeln zurückgreifen können, daher sind beide Optionen aktiviert. Alle Server stellen Dateifreigaben in unserem Netz zur Verfügung. Allerdings sollen nur bestimmte Subnetze oder einzelne IPs auf die Freigaben zugreifen dürfen, was wir über Firewallregeln realisiert haben. Klappt auch alles prima. Die "Standard"-Regeln für Datei- und Druckerfreigaben sind deaktiviert, da uns diese nicht restriktiv genug sind. Stattdessen haben wir eigene Regelsätze etabliert. Wenn ich nun allerdings eine neue Dateifreigabe erstelle, oder das System einfach eine Zeit lang läuft und seinen Dienst verrichtet, werden die "Standard"-Regeln wieder aktiviert. Das ist natürlich unerwünscht, da es den Sinn einer Firewall ad absurdum führt, wenn das System für sich entscheidet, welche Firewallregeln aktiv sein sollen und welche nicht, und diese dann nach eigenem Gutdünken selber anpasst. Daher stellt sich mir jetzt die Frage, ob man Windows irgendwie abgewöhnen kann, sich selber um das Erstellen von Firewallregeln zu kümmern. Hat jemand einen guten Tipp für mich? Gruß, Malte

Ergänzend sei folgendes Problem erwähnt, welches bei uns nach Aufspielen des RDP-Clients 6.0 auftrat: Beim Versuch eines XP-Rechners, via ICA-Client auf einen W2K-TS + Citrix Metaframe 1.8 zuzugreifen, kommt keine Verbindung zustande. Der Client bekommt keine Fehlermeldung, es passiert einfach garnix. Der TS protokolliert einen Fehlercode 1004 ("Der Terminalserver kann keine Clientlizenz erteilen"). Wir konnten das Problem durch einspielen eines aktuelleren ICA-Clients lösen. Momentan ist bei uns nur die Buildversion 39151 freigegeben, damit funktioniert es aber. Somit sollten neuere Versionen ebenfalls funktionieren. Auf W2K-Rechnern tritt dieses Problem nicht auf.

Hi, danke für die Info. Sollte englisch als Universalsprache angesehen werden, ist das ja mal wieder an Arroganz nicht zu überbieten! Wozu hat MS eigentlich die Funktion der Sprachneutralität eingeführt? Gibt es eventuell einen Weg, dem Installer mitzuteilen, dass er etwas genauer auf die Sprachversionen achten soll? Eine zusätzliche Verteilsoftware kommt aus unterschiedlichen Gründen, auf die ich keinen Einfluss habe, leider nicht in Frage. Sollte es irgendwann doch mal soweit sein, werde ich Deinen Tip beherzigen. Bis dahin muss ich wohl mit zusätzlicher Verwaltungsarbeit durch weitere OUs leben.

Hi, was meinst Du mit "Softwaredistribution"? Die Software, die wir für die Verteilung nutzen oder die, die wir verteilen wollen? Für die Verteilung nutzen wir standard Gruppenrichtlinien im AD und damit verteilen wir diverse Softwarepakete an alle unsere Clientrechner. Diese Softwarepakete enthalten aber immer nur eine Sprachversion (englisch oder deutsch), daher kann ich intern auch keine Abfrage für unterschiedliche Sprachen basteln, zumal ich vom Erstellen von .MSI-Paketen sowieso nicht allzu viel Ahnung habe. Ich bin bisher einfach davon ausgegangen, dass, wenn ein MSI-Paket speziell für eine bestimmte Sprache entwickelt wurde, der Windows Installer so schlau ist, das Paket auch nur auf Rechnern mit der gleichen Betriebsystemsprache zu installieren. Bei sprachunabhängigen Paketen kann das dort ja auch explizit angegeben werden. Momentan scheint es mir so, als würde der Installer englisch als "Universalsprache" ansehen und das Paket blind überall installieren; bei deutschen Paketen wird die Sprache ja schliesslich beachtet...

Hi, danke für die Antwort. Mit nem WMI Filter hatte ich es auch schon versucht. Lief auf prima bis auf das Problem der Mischumgebung, also doch wieder hinfällig. Das Einrichten neuer OUs steht bei mir aufm Zettel, aber nur als letzte Lösung, da es noch einen erheblichen Rattenschwanz an Verwaltungsaufgaben nach sich zieht, die ich gerne vermeiden möchte ;) Vielleicht hat ja sonst noch jemand ne Idee. Bin für jeden Vorschlag dankbar!

Servus! Bei mir in der Firma werden seit kurzem diverse PCs eingesetzt, auf denen eine englische Version von Windows XP bzw. Windows 2000 installiert ist (die sind für indische Kollegen, eine Umstellung auf ein deutsches Betriebsystem fällt also aus). Das Problem ist jetzt, daß unsere Softwareverteilung damit auf die Nase fällt. Wir verteilen diverse Standardsoftware via AD, was bisher auch super funktionierte. Da es sich bei dieser Standardsoftware um die deutsche Sprachversionen handelt (ist auch explizit in den MSI-Paketen eingetragen) werden diese auf den englischen PCs nicht installiert, was auch durchaus gewollt ist. Jetzt könnte man ja durchaus auf die brauchbare Idee kommen, zusätzlich zur deutschen die englische Version der Software bereit zu stellen, doch da fangen die Probleme an: Nach zusätzlicher Bereitstellung der englischen Version wird diese - und NUR diese - brav auf allen englischen Systemen installiert - bingo. Dummerweise wird sie aber auch auf allen deutschen Systemen installiert - zusätzlich zur deutschen Version. Die Sprachversionen der Pakete sind sowohl in der "template summary property" als auch der "ProductLanguage property" des MSI-Paketes auf 1031 (deutsch) bzw. 1033 (englisch) eingestellt, die Pakete wurden so bereit gestellt, dass die Sprache NICHT ignoriert werden soll. Ich habe schon diverse Foren, KB-Artikel und die MSDN nach diesem Problem durchsucht, leider erfolglos. Wäre schön, wenn ich hier geholfen werden würde...

Moin. Da ich hier leider keine Antwort erhalten habe, musste ich mich wohl oder übel selber langwierig mit dem Problem auseinander setzen. Die Lösung war allerdings durchaus trivial: Microsoft stellt unter KB896427 einen Patch bereit, der das von mir beschriebene Problem löst, auch wenn die Problembeschreibung von MS ein wenig anders aussieht. Wie auch immer, Problem behoben...

...hoch...

Hallo, wie haben einen neuen Fileserver unter W2K3_R2 aufgesetzt. Seitdem haben einige Clients folgendes merkwürdiges Phänomen beim Zugriff auf einige Freigaben: Der Zugriff auf die Freigabe als solches funktioniert einwandfrei, auch der Zugriff auf die meisten Unterordner funktioniert problemlos. Auf einige Unterordner kann jedoch nicht zugegriffen werden und der Explorer gibt folgenden Fehler aus: "Der angegebene Server kann den angeforderten Vorgang nicht ausführen". Leider gibt es dazu keinerlei weitere Einträge im Eventlog, weder auf dem Client noch auf dem Server (alle Überwachungsoptionen sind aktiviert). Die Berechtigungen sind alle ok, wir haben sogar testweise Vollzugriff für jeden (Freigabe + NTFS) eingerichtet - leider kein Erfolg. Das merkwürdige an der Sache ist, dass, wenn der Zugriff via Laufwerksbuchstaben erfolgt, obige Fehlermeldung ausgespuckt wird, wenn der gleiche User aber direkt auf den UNC-Pfad zugreift, funktioniert alles. Auf dem Server ist Windows Server 2003 Access-based Enumeration installiert, aber für die betroffene Freigabe nicht aktiviert. Wir konnten das Problem mittlerweile so weit eingrenzen, dass wir sagen können, dass es ein Clientproblem sein muss: Von bestimmten Rechnern hat der Benutzer keinen Zugriff, auf anderen geht es einwandfrei, sowohl über ein verbundenes Laufwerk als auch über den UNC-Pfad. Von den Rechnern, auf denen der Benutzer keinen Zugriff bekommt, kann auch niemand anderes auf das Verzeichnis zugreifen, selbst wenn er es vorher von einem anderen Rechner konnte. Server: Windows 2003 R2 mit installierten Fileserver Verwaltungstools aus dem R2 sowie Windows Server 2003 Access-based Enumeration Domäne: Windows 2003 AD Clients: Windows 2000 + XP (Problem tritt bei beiden Versionen auf) Kennt irgend jemand dieses Problem und am besten auch eine Lösung?