Sign in
 
HomepageWindows Server "8" Beta20082003LibraryForen
Windows Server-TechCenter > Windows Server Foren > Windows Server > Server 2008 R2, RemoteApp WebAccess (Internet)

Beantwortet Server 2008 R2, RemoteApp WebAccess (Internet)

    •  
      Freitag, 30. Oktober 2009 17:26
       
       
      Anmelden
      0
      Anmelden

      Hi,

      Habe RemoteApp unter Server 2008 R2 Enterprise aufgesetzt, dieser ist an unserer Domäne angemeldet (Server 2003).
      Läuft alles soweit, Anwendungen lassen sich im LAN über "https://server_name/rdweb" einwandfrei starten.
      Nun habe ich die Rolle RD Gatewayserver installiert, einige Konfigurationen durchgeführt, Zertifikat erstellt und importiert.
      RD-CAP und RD-RAP-Richtlinien erstellt und aktiviert. Port-Forwarding eingerichtet. Nun habe ich probiert auf die Seite übers Internet zu kommen, dies geht auch, kann mich mit dem Benutzer anmelden, sehe meine Anwendungen (Paint, Calc, Word ....).
      Wenn ich nun eine Anwendung starten möchte, kommt folgende Fehlermeldung:
      ______________________________

      "Getrennte RemoteApp"
      Der Remote-Computer wurde nicht gefunden. Wenden Sie sich wegen dieses Fehlers an den Helpdesk.
      ______________________________

      Vielleicht gibt es beim Gateway-Server noch was zu konfigurieren, sieht aber eigentlich ganz gut aus, kenne mich bezüglich des Gateway-Server noch nicht so gut aus.
      Hänge seit Tagen an dem Problem, so kurz vor dem Ziel :(

      Ich komme Ihr könnt mir helfen ;)

      MfG

      p.ascl

       

    Antworten

    • Donnerstag, 5. November 2009 22:38
       
       Beantwortet
      Anmelden
      0
      Anmelden

      Ich glaube, nach einer kurzen Hin- und Her Mailerei hat es wohl einigermaßen geklappt. Hier der relevante Teil, vielleicht hilft es später anderen weiter:

      Zum Thema Gateway:

      Also, wenn Du die RemoteApp-Webseite aus dem LAN erreichen kannst, ist es schon mal ziemlich gut. Ich würde folgende Schritte durchführen: (Ich nehme als Beispiel mal die öffentliche IP 11.11.11.1 und die private IP 192.168.100.5 für den Appserver/Sitzungshost)

      - Einstellen der externen DNS-Server: Die öffentlichen DNS-Server bekommen einen A-Eintrag mit der Adresse, an der die Webseite später extern anliegt. Natürlich verweist die IP auf euren externen Router / Gateway. Beispiel: Meine Domäne ist testlab.de. Ich erstelle also eine Subdomain "remoteapp" und hinterlege einen A-Eintrag "www" für die externe IP meiner öffentlichen Schnittstelle 11.11.11.1. Ziel ist es, den Internet-Client mit dem Aufruf am Browser: https://www.remoteapp.testlab.de/rdweb an meine öffentliche IP zu bringen.

      - Portforwarding: Jetzt stelle ich am Router/Gateway das Portforwarding ein: "Wenn ein Paket an der 11.11.11.1 mit dem Zielport 443 aufschlägt, leite es an die interne IP 192.168.100.5 weiter. Da im Augenblick vielleicht noch kein Zertifikat hinterlegt ist, wäre jetzt eine gute Idee, eins zu beantragen.

      - Beantragen oder Ausstellen eines Serverauthenifizierungszertifikats für die Remote-App Website: Es ist darauf zu achten, dass alle Clients die Zertifizierungsstelle, von der das Zertifikat stammt, auch in den vertrauenswürdigen Stammzertifizierungsstelle des lokalen Computers importiert haben! Entweder, Du beantragst ein kommerzielles Zertifikat, oder du stellst selbst welche aus und importierst die Root-CA manuell bei den Clients. WICHTIG: der Name muss genau so auf dem Zertifikat draufstehen, wie ihn der Client nachher abruft - also z.B. www.remoteapp.testlab.de Weitere Infos:

      http://www.lernschmiede.de/index.php/2009/02/eigenstandige-zertifizierungsstelle-aufsetzen/
      http://www.lernschmiede.de/index.php/2009/10/kostenfreie-zertifikate-teil-1/
      http://www.lernschmiede.de/index.php/2009/10/kostenfreie-zertifikate-teil2/

      Das Serverzertifikat hinterlegst Du im IIS bei der Remote-App-Website (Im Normalfall die Default Website) hinter dem Link "Bindungen" - siehe meine Links. Wenn alles gut gegangen ist, sollten Deine Clients jetzt die Website von außen ohne Fehlermeldung erreichen können. Wenn dies nicht der Fall ist, lohnt es sich gar nicht, mit dem RD-Gateway weiterzumachen.

      Wenn der Zugriff klappen sollte, und Du jetzt auf eine App klickst, passiert folgendes: der App-Server schaut nach, welcher Server die App hostet. Das wird auf der Registerkarte "Remotedesktop Sitzungshost Server" in den App-Einstellungen festgelegt. Wenn dort "appserver.testlab.LOCAL" steht, versucht der externe Client eine RDP-Verbindung zu "Appserver.testlab.local" aus dem Internet heraus aufzubauen. Das das schief geht, dürfte klar sein. Daher kommt jetzt der RD-Gateway ins Spiel:

      Der RD-Gateway tunnelt die RDP-Verbindung in HTTPS. D.h, der externe Client ruft die Remote-App immer noch per RDP auf, wird aber gezwungen, die Verbindung über einen RD-Gateway - und damit in HTTPS getunnelt - herzustellen. Der RD-Gateway packt die Pakete dann aus und schickt sie ganz normal zum App-Server. Das hat zwei Vorteile: Erstens, da der RD-Gateway Mitglied der Domäne ist, kennt er auch den Namen "appserver.testlab.local" und kann ihn ohne Probleme erreichen; zweitens, HTTPS kriegt man in der Regel durch alle Firewalls durch. Die nächsten Schritte sind also:

      - Installation des RD-Gateway: Die Rolle wird auf einem anderen Server installiert. (z.B. 192.168.100.10) Die TS-CAP legt fest, WER sich überhaupt am RD-Gateway authentifizieren darf, also alle zugriffsberechtigte Unternehmens-User, die von extern kommen. Die TS-RAP legt fest, welche Ressourcen diese Verbindung nutzen darf. Dazu erstellst Du im AD eine Gruppe, fügst den App-Server / Remotesitzungshost hinzu. Diese Gruppe fügst Du dann in die TS-RAP ein. Wir wollen ja nicht, dass sich die Userchen auf dem DC oder so rumtreiben :) Das Zertifikat kann ausgelassen werden, die Einrichtung kommt erst im nächsten Schritt.

      - Zertifikat und Portweiterleitung für den RD-Gateway: Im Endeffekt ist das Vorgehen das gleiche, wie vorhin beim SSL Zertifikat: Im externen DNS legst du z.B. eine neue Domäne an: rdgateway, darin einen Hosteintrag, der auf die öffentliche IP verweist, z.B. "www.rdgateway.testlab.de" ACHTUNG: Jetzt liegt es an Deinen Geräten: Unterstützt dein Router eine Portweiterleitung mit der gleichen IP und unterschiedlichen Hostheadern? Ich würde dringend raten, eine extra IP zu beschaffen, wenn noch keine da ist. Eine öffentliche IP kostet heutzutage einen Euro und es ist _wesentlich_ übersichtlicher! Ich wähle die öffentliche IP 11.11.11.2. Wenn ich also am Client im Internet "nslookup www.rdgateway.testlab.de" aufrufe, werde ich an die 11.11.11.2 weitergeleitet. Dort wartet eine von mir eingerichtete Weiterleitung, die "wenn eine Verbindung auf Port 443 aufschlägt, dann leite sie an 192.168.100.10 (RD-Gateway) weiter" ungefähr so aussieht.

      Jetzt erstelle oder beantrage ich ein Zertifikat mit GENAU diesem Anzeigenamen, SONST GEHT ES SCHIEF! Auf dem Zertifikat muss also "www.rdgateway.testlab.DE" draufstehen, auch wenn das Teil in Wirklichkeit im LAN steht. Wichtig ist ja, was der externe Client zu sehen bekommt und der kann nun einmal nur die öffentliche Adresse erreichen.

      Das Zertifikat kann jetzt via MMC in den lokalen Zertifikatsspeicher des COMPUTERS auf dem RDGateway importiert werden. Wichtig: der kleine goldene Schlüssel / privater Schlüssel muss dabei sein. Schlussendlich kann das Zertifikat in den Eigenschaften des RDGateway-Objekts im Registerreiter SSL-Zertifikate importiert werden. Dort muss alles grün sein.

      Abschluss-Konfiguration: In den Remote-App Einstellungen des Appservers im Register Remotedesktopgateway trage ich jetzt www.rdgateay.testlab.de ein.

      Das war's!

      Wenn ich jetzt in der Website auf eine App klicke, sieht der Appserver, dass ein Gatewayserver genutzt werden soll und gibt den Namen www.rdgateway.testlab.de zurück. Der Client baut eine Verbindung zum Gateway unter diesem Namen auf, prüft den Namen und die Root-CA im Zertifikat und verschlüsselt seine RDP-Pakete mit dem öffentlichen Schlüssel des Zertifikats. Der Gateway entpackt die Pakete mit seinem privaten Schlüssel wieder und schickt sie als stinknormale RDP-Verbindung zum Remote-App-Server.

      HTH

      lernschmiede.de
      • Als Antwort markiert p.ascl Samstag, 7. November 2009 15:46
      •  
       

    Alle Antworten

    • Freitag, 30. Oktober 2009 21:54
       
       
      Anmelden
      0
      Anmelden
      Moin Moin,


      Du kannst Die Verbindung in zwei Varianten herstellen:

      Klassisches Forwarding: Der Internetclient kommt über das Forwarding an der Website an. Wenn Du eine Applikation anklickst, gibt der Remotesitzungshost die Adresse zurück, an der die Applikation anliegt. Wenn im Remote App Manager in den RDP-Einstellungen als Server myappserver.domain.local eingetragen ist, kann der Internetclient damit nichts anfangen. Es sollte also ein im Internet auflösbarer FQDN zurückgegeben werden. Das bringt wiederum das Problem mit sich, dass interne Clients den Namen u.U. nicht mehr erreichen können. Dann müsste eine Zone im LAN angelegt werden, die auch die externen Einträge vorhält. Da die Verbindung auch nur eine RDP-Verbindung ist, muss zusätzlich auch noch der Port 3389 weitergeleitet werden, sonst dürfte die Verbindung fehlschlagen.

      Von daher kannst Du dem Client beim Aufruf der App den Remotedesktop-Gatewayserver direkt mitgegeben. Dazu muss der natürlich funktionieren. Hast Du schon eine klassische Verbindung zu einem TS via TS-Gateway hinbekommen? Der Gatewayserver kann direkt in den RemotApp-Einstellungen eingetragen werden. Dann hätte sich auch das Thema Namensauflösung erledigt.

      Du kannst ja mal beide Varianten antesten und zurückmelden, wie es gelaufen ist.

      Gruß,

      Michael

      lernschmiede.de
       
    • Samstag, 31. Oktober 2009 11:30
       
       
      Anmelden
      0
      Anmelden
      Hallo Michael,

      danke für deine Antwort,

      ich gebe ehrlich zu, das ist doch komplizierter als ich dachte.
      Deine zweite Variante erscheint mir deutlich sympatischer (jedoch probiere ich die erste bei späterer Gelegenheit mal aus).
      Ich habe mir deine klassische Konfiguration mal angeschaut und habe dort schon einige Verständnissprobleme.
      Ich habe nur einen Server, auf dem sind folgenden Rollen installiert:
      - Remotedesktop-Sitzungshost
      - Remotedesktop-Gateway und WebAccess
      Wie bereits oben beschrieben läuft der ganze Kram im LAN wunderbar.
      Ich habe die Gateway-Rolle installiert, mit relativ vielen Default-Settings.
      Im Gateway-Manager sieht alles Ok aus, keine Meldung etc., bei den Richtlinien sind die gewünschen Gruppen eingetragen.
      Wenn ich mich dann auf die Website einlogge kommt die Meldung wie oben, in dem Fall ist im RemoteApp-Manager die Einstellung "Gateway-Server automatisch" ermitteln" eingetragen.
      Wenn ich hier jedoch den Server selbst eintrage, (ist ja alles auf einem Server), und mich wieder auf der Seite einlogge kommt folgende Meldung:
      Der Computer kann keine Verbindung mit dem Remotecomputer herstellen, da die Remotedesktop-Gatewayserveradresse nicht erreichbar oder falsch ist.

      Vielleicht liegt es auch noch am Port-Forwarding, guck ich mir Montag nochmal genauer an.

      Habt Ihr sonst noch eine Idee wo mein vermutlich blöder Fehler liegt

      MfG

      p.ascl
       
    • Sonntag, 1. November 2009 19:11
       
       Vorgeschlagene Antwort
      Anmelden
      0
      Anmelden
      Moin Moin,

      also ich würde dringend anraten, den RD-Gateway vom Remotesitzungshost / App-Server zu trennen. Da sowohl der Gateway als auch die Website als HTTPS-Endpunkt dient, müssen die Beiden unterschiedliche Zertifikate zurückliefern. (extern.rdgateway.tld & extern.appweb.tld/rdweb) Das ist notwendig, da das Ansprechen von Extern _nur_ mit den korrekten Namen funktioniert. Das heißt im Umkehrschluss, dass auf einem Server zwei Webseiten vorgehalten werden müssten, da der Server pro Site nur ein Zertifikat zurückliefern kann. Ich habe das Kopieren der RDWeb-Site auf den gleichen Server mit ADSUTIL.vbs  getestet und bin kläglich gescheitert. Es könnte zumindest in Frickelei ausarten. (Vielleicht hat jmd. einen Link zum Thema)

      Wenn der Gateway als Rolle getrennt ist, funktioniert es einwandfrei - auch dann, wenn der RD-GW im LAN liegt, mit zwei unterschiedlichen Weiterleitungen. Habe es heute ausgetestet. Der korrekte RD-Gateway muss in den Einstellungen für Remote App-Bereitstellung im Register Remotedesktopgateway eingetragen werden. Falls Du es mit der Rollentrennung versuchen willst und nicht weiterkommst, kann ich Dir eine Stichpunktliste fertigmachen.

      Gruß,

      Michael
       
      lernschmiede.de
       
    • Sonntag, 1. November 2009 20:34
       
       
      Anmelden
      0
      Anmelden
      hi michael, danke für die super hilfe,

      würde es denn auch gehen, den rd-gateway in einer virtuellen maschine zu installieren, (host der virtuellen maschine bleibt der Remotesitzungshost), oder führt das auch schon zu problemen?. Kunden sind ja nicht immer dazu bereit sich mal eben einen zweiten physikalischen Server zu kaufen x).

      gruß

      p.ascl
       
    • Sonntag, 1. November 2009 20:44
       
       
      Anmelden
      0
      Anmelden
      Klaro, es sollte keine Probleme geben. Hatte ich vorhin schon daran gedacht, ich war nur zu faul, es aufzuschreiben. Wie gesagt: Nur ich habe es (mit einem Versuch) nicht hingekriegt und halte es auch nicht für besonders sinnvoll; d.h. noch lange nicht, das es nicht geht! Vielleicht kann noch jemand was beisteuern. Klopf Klopf...

      Gruß,

      Michael
      lernschmiede.de
       
    • Montag, 2. November 2009 18:42
       
       
      Anmelden
      0
      Anmelden
      Na gut, dann wollen wir mal auch was beisteuern :-)

      Hi,

      interessant wäre etwas über Eure Netztopologie zu erfahren. Welche FW usw.
      Grundsätzlich schliesse ich mich voll den Ausreden meines Vorgängers an. :-D

      Ergänzend noch ein bisschen Literatur : http://technet.microsoft.com/de-de/library/cc771530(WS.10).aspx


      >würde es denn auch gehen, den rd-gateway in einer virtuellen maschine zu installieren
      Juup, gerade dafür besonders gut geeignet und super wenn da drunter noch ein FailOver-Cluster
      mit Hyper-V2 liegt, oder
      [...]
      Vielleicht kann noch jemand was beisteuern. Klopf Klopf...
      [...]
      Gruß Ralph Andreas Altermann
       
    • Montag, 2. November 2009 21:12
       
       
      Anmelden
      0
      Anmelden
      Grundsätzlich schliesse ich mich voll den Ausreden meines Vorgängers an. :-D

      Soso, "Ausreden" also - das merke ich mir... ;)
      lernschmiede.de
       
    • Donnerstag, 5. November 2009 22:38
       
       Beantwortet
      Anmelden
      0
      Anmelden

      Ich glaube, nach einer kurzen Hin- und Her Mailerei hat es wohl einigermaßen geklappt. Hier der relevante Teil, vielleicht hilft es später anderen weiter:

      Zum Thema Gateway:

      Also, wenn Du die RemoteApp-Webseite aus dem LAN erreichen kannst, ist es schon mal ziemlich gut. Ich würde folgende Schritte durchführen: (Ich nehme als Beispiel mal die öffentliche IP 11.11.11.1 und die private IP 192.168.100.5 für den Appserver/Sitzungshost)

      - Einstellen der externen DNS-Server: Die öffentlichen DNS-Server bekommen einen A-Eintrag mit der Adresse, an der die Webseite später extern anliegt. Natürlich verweist die IP auf euren externen Router / Gateway. Beispiel: Meine Domäne ist testlab.de. Ich erstelle also eine Subdomain "remoteapp" und hinterlege einen A-Eintrag "www" für die externe IP meiner öffentlichen Schnittstelle 11.11.11.1. Ziel ist es, den Internet-Client mit dem Aufruf am Browser: https://www.remoteapp.testlab.de/rdweb an meine öffentliche IP zu bringen.

      - Portforwarding: Jetzt stelle ich am Router/Gateway das Portforwarding ein: "Wenn ein Paket an der 11.11.11.1 mit dem Zielport 443 aufschlägt, leite es an die interne IP 192.168.100.5 weiter. Da im Augenblick vielleicht noch kein Zertifikat hinterlegt ist, wäre jetzt eine gute Idee, eins zu beantragen.

      - Beantragen oder Ausstellen eines Serverauthenifizierungszertifikats für die Remote-App Website: Es ist darauf zu achten, dass alle Clients die Zertifizierungsstelle, von der das Zertifikat stammt, auch in den vertrauenswürdigen Stammzertifizierungsstelle des lokalen Computers importiert haben! Entweder, Du beantragst ein kommerzielles Zertifikat, oder du stellst selbst welche aus und importierst die Root-CA manuell bei den Clients. WICHTIG: der Name muss genau so auf dem Zertifikat draufstehen, wie ihn der Client nachher abruft - also z.B. www.remoteapp.testlab.de Weitere Infos:

      http://www.lernschmiede.de/index.php/2009/02/eigenstandige-zertifizierungsstelle-aufsetzen/
      http://www.lernschmiede.de/index.php/2009/10/kostenfreie-zertifikate-teil-1/
      http://www.lernschmiede.de/index.php/2009/10/kostenfreie-zertifikate-teil2/

      Das Serverzertifikat hinterlegst Du im IIS bei der Remote-App-Website (Im Normalfall die Default Website) hinter dem Link "Bindungen" - siehe meine Links. Wenn alles gut gegangen ist, sollten Deine Clients jetzt die Website von außen ohne Fehlermeldung erreichen können. Wenn dies nicht der Fall ist, lohnt es sich gar nicht, mit dem RD-Gateway weiterzumachen.

      Wenn der Zugriff klappen sollte, und Du jetzt auf eine App klickst, passiert folgendes: der App-Server schaut nach, welcher Server die App hostet. Das wird auf der Registerkarte "Remotedesktop Sitzungshost Server" in den App-Einstellungen festgelegt. Wenn dort "appserver.testlab.LOCAL" steht, versucht der externe Client eine RDP-Verbindung zu "Appserver.testlab.local" aus dem Internet heraus aufzubauen. Das das schief geht, dürfte klar sein. Daher kommt jetzt der RD-Gateway ins Spiel:

      Der RD-Gateway tunnelt die RDP-Verbindung in HTTPS. D.h, der externe Client ruft die Remote-App immer noch per RDP auf, wird aber gezwungen, die Verbindung über einen RD-Gateway - und damit in HTTPS getunnelt - herzustellen. Der RD-Gateway packt die Pakete dann aus und schickt sie ganz normal zum App-Server. Das hat zwei Vorteile: Erstens, da der RD-Gateway Mitglied der Domäne ist, kennt er auch den Namen "appserver.testlab.local" und kann ihn ohne Probleme erreichen; zweitens, HTTPS kriegt man in der Regel durch alle Firewalls durch. Die nächsten Schritte sind also:

      - Installation des RD-Gateway: Die Rolle wird auf einem anderen Server installiert. (z.B. 192.168.100.10) Die TS-CAP legt fest, WER sich überhaupt am RD-Gateway authentifizieren darf, also alle zugriffsberechtigte Unternehmens-User, die von extern kommen. Die TS-RAP legt fest, welche Ressourcen diese Verbindung nutzen darf. Dazu erstellst Du im AD eine Gruppe, fügst den App-Server / Remotesitzungshost hinzu. Diese Gruppe fügst Du dann in die TS-RAP ein. Wir wollen ja nicht, dass sich die Userchen auf dem DC oder so rumtreiben :) Das Zertifikat kann ausgelassen werden, die Einrichtung kommt erst im nächsten Schritt.

      - Zertifikat und Portweiterleitung für den RD-Gateway: Im Endeffekt ist das Vorgehen das gleiche, wie vorhin beim SSL Zertifikat: Im externen DNS legst du z.B. eine neue Domäne an: rdgateway, darin einen Hosteintrag, der auf die öffentliche IP verweist, z.B. "www.rdgateway.testlab.de" ACHTUNG: Jetzt liegt es an Deinen Geräten: Unterstützt dein Router eine Portweiterleitung mit der gleichen IP und unterschiedlichen Hostheadern? Ich würde dringend raten, eine extra IP zu beschaffen, wenn noch keine da ist. Eine öffentliche IP kostet heutzutage einen Euro und es ist _wesentlich_ übersichtlicher! Ich wähle die öffentliche IP 11.11.11.2. Wenn ich also am Client im Internet "nslookup www.rdgateway.testlab.de" aufrufe, werde ich an die 11.11.11.2 weitergeleitet. Dort wartet eine von mir eingerichtete Weiterleitung, die "wenn eine Verbindung auf Port 443 aufschlägt, dann leite sie an 192.168.100.10 (RD-Gateway) weiter" ungefähr so aussieht.

      Jetzt erstelle oder beantrage ich ein Zertifikat mit GENAU diesem Anzeigenamen, SONST GEHT ES SCHIEF! Auf dem Zertifikat muss also "www.rdgateway.testlab.DE" draufstehen, auch wenn das Teil in Wirklichkeit im LAN steht. Wichtig ist ja, was der externe Client zu sehen bekommt und der kann nun einmal nur die öffentliche Adresse erreichen.

      Das Zertifikat kann jetzt via MMC in den lokalen Zertifikatsspeicher des COMPUTERS auf dem RDGateway importiert werden. Wichtig: der kleine goldene Schlüssel / privater Schlüssel muss dabei sein. Schlussendlich kann das Zertifikat in den Eigenschaften des RDGateway-Objekts im Registerreiter SSL-Zertifikate importiert werden. Dort muss alles grün sein.

      Abschluss-Konfiguration: In den Remote-App Einstellungen des Appservers im Register Remotedesktopgateway trage ich jetzt www.rdgateay.testlab.de ein.

      Das war's!

      Wenn ich jetzt in der Website auf eine App klicke, sieht der Appserver, dass ein Gatewayserver genutzt werden soll und gibt den Namen www.rdgateway.testlab.de zurück. Der Client baut eine Verbindung zum Gateway unter diesem Namen auf, prüft den Namen und die Root-CA im Zertifikat und verschlüsselt seine RDP-Pakete mit dem öffentlichen Schlüssel des Zertifikats. Der Gateway entpackt die Pakete mit seinem privaten Schlüssel wieder und schickt sie als stinknormale RDP-Verbindung zum Remote-App-Server.

      HTH

      lernschmiede.de
      • Als Antwort markiert p.ascl Samstag, 7. November 2009 15:46
      •  
       
    • Samstag, 7. November 2009 15:51
       
       
      Anmelden
      0
      Anmelden
      danke nochmal für die super hilfe von michael,

      im prinzip wurde so alles umgesetzt, die server-zertifikate habe ich mit startssl erstellet, jedoch die cert-requests mit dem IIS-Manager. Alles funktioniert einwandfrei (Wichtig: Die Zertifikate müssen natürlich auch auf den ext. Clients im Zertifikatspeicher installiert werden (Vertrauenswürdige Stammzertifikate).
      Echt geile Sache dieses RemoteApp, wenn jemand noch fragen hat, kann ich natürlich auch gerne helfen

      MfG

      p.ascl
       
    • Mittwoch, 25. November 2009 10:41
       
       
      Anmelden
      0
      Anmelden

      Zu den RemoteApp habe ich noch eine Frage.

      Einige  Mittarbeiter haben bei uns ein Apple MacBook, wie könnte ich die Programme für diese User mit Windows Komponenten bereitstellen?

      Ich habe z.B. schon das RDP von Microsoft auf den Apple Installier und dann eine RDP Datei geöffnet. Leider wird dann nur die RDP Session geöffnet und nicht nur das Programm z.B. Word

      Seht ihr da eine Möglichkeit einen Apple mit einzubinden?

      Gruß
      Tobias

       
    • Mittwoch, 25. November 2009 19:05
       
       
      Anmelden
      0
      Anmelden
      puh, kann ich dir leider nicht weiterhelfen, da ich mit apple-books/mac´s noch nie gearbeitet habe, aber vielleicht weiß jemand anders etwas !? ....
       
    • Donnerstag, 26. November 2009 13:36
       
       
      Anmelden
      0
      Anmelden
      Hallo Tobias,

      Ich glaube Martin, aka Active Director ist ziemlich fit mit Mac in Windows Netzen. Ich habe nur das hier gefunden:

      http://social.technet.microsoft.com/forums/en-US/winserverTS/thread/c3015898-cde9-450c-b6d2-e1f031dcea8a/

      Unten ist ein Workaround beschrieben, aber echtes "Remote-App-Feeling" soll dabei nicht aufkommen. Kann aber aus der Praxis nichts dazu sagen.

      Gruß,

      Michael
      lernschmiede.de