derWachert

Dukel technisch zwar richtig, allerdings erfolgt die Sessionaushandlung nun mal über die rpcproxy ;) Und da leider eben ohne Parameter. Daher hat man da leider null Chance tatsächlich technisch zu unterscheiden und richtig weiter zu leiten. Es klappt übrigens tatsächlich auch nicht einfach die eingehenden Anfragen einfach an beide Server weiter zu leiten da die Clients dann einmal ein "false" und einmal ein "true" zurück bekommen und es leider oftmals knallt bei den jeweiligen zugreifenden Clients.

Ich würde es schon wollen ;) Meine Variante wäre zweiter FQDN mit eigenem Zert. So bleibt man unabhängig. Allerdings will das leider nicht jeder der ein solches Problem in seiner Struktur hat, daher habe ich mir natürlich Gedanken gemach wie man es noch lösen könnte.

OWA ja, OWA nein! rds? Keinesfalls... RDP-over-HTTPS ruft die rpcproxy.dll auf, genauso wie OA und nein, beide verwenden nicht unterschiedliche Pfade, es ist exakt der gleiche und nicht zu unterscheiden, sonst bestünde das Problem doch gar nicht. Interessantes Niveau... alles lesen, dann meckern. Hab halt OWA anstatt OA geschrieben am Anfang. OWA hat natürlich nix mit RPC zu tun, OA hingegen schon. Deswegen muss man nicht gleich "den Dicken" makieren. Das ich Exchange und das Gateway nicht auf einem Server betreiben werde steht auch schon weiter oben, weils sinnfrei ist, danke das du es also nochmal wiederholst ^^ Über die sinnfreiheit eines solchen Unterfangens brauchen wir uns, denke ich, nicht unterhalten :D

Arghs... Natürlich Norbert... OA und nicht OWA... In der Konstellation wo ich das Problem gerne lösen würde ist es ein Exchange 2010.

Dazu müsste ich das RDP Gateway und den OWA, sprich Exchange, auf dem gleichen Server betreiben... ne :D niemals. Das widerspricht ja aller Vernunft. Da sich beide Dienste per rpcproxy authentifzieren, müsste ich einen zentralen IIS davor schalten der die Anfragen dann wiederum an den OWA oder das Gateway weiterleitet was jedoch nicht vernünftig lösbar ist (zumindest wüsste ich nicht pauschal wie, technisch sicherlich machbar). Es läuft, aufgrund des Aufwands der anderen Lösungen, wohl am ehesten darauf hinaus zumindest nen zweiten FQDN mit eigenem Zert zu verwenden. Dann wäre es ein Klacks die nötigen Configs zu setzen, z.B. in der Firewall davor. Was mich einfach immer wieder wundert wenn ich an diese Konstellation denke: Wieso zum Henker hat Microsoft die Parameter entfernt die früher noch an die rpcproxy Anfragen übergeben wurden? Damit wäre es per Reverse so kinderleicht die Requests zu unterscheiden, aber nöööööööööööööö...... ^^

Ihr habt jetzt beide den wichtigsten Fakt dabei vergessen: Man kann anhand der URL NICHT unterscheiden ob es sich um eine OWA oder eine RDP-over-HTTPS Anfrage handelt. Bei beiden Diensten wird lediglich die rpcproxy.dll aufgerufen, gänzlich OHNE Parameter. Ein Reverse Proxy fällt damit leider flach ;) Das war ja auch mein erster Gedanke, hilft allerdings nix :P Sagen wir der FQDN des SSL Zerts lautet test.lab.org, dann ist sowohl bei RDP-over-HTTPS sowie bei OWA der Aufruf für die Sessionaushandlung https://test.lab.org/rpcproxy.dll OHNE Parameter wie gesagt. Daher lässt sich eben anhand der URL nicht unterscheiden an welchen Server die Anfrage weiter geleitet werden müsste. Erst nach der Session Aushandlung könnte man zumindest die OWA Abfragen filtern, vorher allerdings nicht, und das ist der springende Punkt der mich verzweifeln lässt.

Folgende Konstellation. Netzwerk mit einer statischen DSL IP, keine Option auf weitere IPs. In der Struktur läuft u.a. eine TS-Farm mit einem entsprechenden Gateway dazwischen. Ebenfalls läuft dort ein Exchange mit aktiviertem OWA OA. Nun kommen sowohl das Gateway als auch der Exchange mit offenen 443 Ports für den jeweiligen Zugriff auf die Dienste. Besteht, wie früher mal mit einem ISA, die Möglichkeit unter 2k8R2 oder 2k12 einen Webserver "davor" zu schalten welcher den Traffic entsprechend sortiert sodass die RDP->HTTPS Pakete zum RDP-Gateway und die OWA OA Anfragen zum OWA OA Server weitergeleitet werden? Mit URL Catchern kann man da leider nicht mehr arbeiten da bei beiden die exakt gleich /proxyxy.dll angefragt wird, sowohl RDP->HTTPS als auch OWA OA wenn es um die Sessionaushandlung geht. Bislang konnte mir da niemand weiter helfen, ich kann mir aber nicht vorstellen das NIEMAND das Problem hat? Ich könnte natürlich über DNS Namen arbeiten, was man ja auch muss bezüglich SSL, die dann auf das gleiche Ziel leiten, was ist jedoch wenn die Struktur vorgibt das eben nur ein DNS Name und damit ein SSL Zert verwendet wird? Ich kann mir eben nicht vorstellen das, im Gegensatz zu 2k3-2k8 die Anfragen nicht mehr unterschieden werden können. Damals gab es hinter den proxyxy.dll noch Parameter womit man eindeutig zuordnen konnte ob es eine RDP-Gateway Anfrage oder eben eine OWA OA Anfrage war. Das ist weggefallen... welcher ****** sich das bei MS auch immer ausgedacht hat ^^

WIR BRAUCHEN SYSTEMADMINISTRATOREN! Wir sind ein EDV-Systemhaus in Karlsruhe und betreuen Endkunden sowie Firmen- und Großkunden in ganz Deutschland sowie darüber hinaus. Das derzeitige Team von über 20 Leuten sucht zusätzliche IT-Fachkräfte zur Unterstützung im Bereich Systemadministration. Zu dem Systemhaus gehört ein örtliches Ladengeschäft am Stadtrand von Karlsruhe mit der größten Notebook Auswahl in der gesamten Region. Damit nicht genug, wird das ganze durch 2 Onlineshops für Notebooks, Netbooks, Tablets, PC-Hardware und vieles mehr abgerundet. Im Ladengeschäft steht ein Service Point für PC und Notebook Reparaturen zur Verfügung. Kein Einschicken zum Hersteller notwendig. Wir sind unter anderem zertifizierte Partner für Sony, Samsung und Toshiba. Generell werden aber Geräte aller Hersteller instand gesetzt. Etwas das wohl kein anderes Systemhaus in Deutschland bieten kann: Wir sind auch ein Segwaypoint! (mit über 20 hauseigenen Fahrzeugen!) Nähere Informationen dazu findet man unter segwaypoint-karlsruhe.de Schneller und angenehmer kommt man in Karlsruhe nicht zu einem Kunden, weder mit dem Auto, noch mit den öffentlichen Verkehrsmitteln ;) Keine Bange, für schlechtes Wetter stehen auch ausreichend Firmenwagen für die Mitarbeiter bereit :p Was wir bieten: Überdurchschnittliches Gehalt 40 Stunden Woche Firmenwagen Segway Nutzung Schulungen und Fortbildungen Zertifizierungen für Mitarbeiter Dynamisches Team mit jeder Menge Spaß garantiert Was wir suchen: IT-Systemadministratoren / Fachinformatiker. Es muss nicht zwingend eine abgeschlossene Ausbildung vorliegen insofern ausreichend gute Kenntnisse vorhanden sind, z.B. in den Bereichen: Microsoft Windows Server Domänen (Exchange, Datenbanken, Clients) Netzwerke Firewall Lösungen (Astaro / Sophos) Monitoring Automatisierung Linux Virtualisierung (VMware,HyperV,KVM,etc...) (nicht alle auf einmal notwendig aber irgendeines der Themen sollte sitzen ;)) Wir betreuen vom einfachen Endkunden bis hin zu internationalen Unternehmen so ziemlich alles. Vom einfachen PC der als Server dient bis hin zu Hochverfügbarkeitslösungen mit mehreren IBM BladeCenter oder IBM Flex System Einrichtungen ist alles dabei. Der Job ist also sehr abwechslungsreich und bringt jede Woche neue spannende Dinge mit sich. Unsicher? Einfach vorab ein Praktikum machen und reinschnuppern. Der Zeitraum sollte mit mindestens 2 Wochen, eher 1 Monat eingeplant werden. Bewerbungen könnt ihr direkt an bewerbung@net-factory.de schicken. Enthalten sein sollte eine PDF Datei mit: Anschreiben (inkl. Gehaltsvorstellung) Lebenslauf Skills Zeugnisse und Zertifzierungen Mit freundlichen Grüßen Alexander W.H. Wachert Technikleiter / Kundenservice NetFactory Gesellschaft für Netzwerklösungen mbH Durmersheimerstr. 159 76189 Karlsruhe www.net-factory.de | Google Maps