Erneuern der RDP-Terminal Server Zertifikate
Hallo Zusammen,
ich arbeite mit einem Windows Server 2016, der als Remotedesktop Server genutzt wird und verschiedene Programme bereitstellt.
Auf diesem sind die folgenden RDS Rollen installiert.
RD-Verbindungsbroker, RD-Sitzungshost, RD-Gateway, RD-Lizenzierung, Web Access für Remotedesktop
Damit alles läuft, wurden bisher Zertifikate genutzt, die über den RDS Server generiert wurden.
Da wir aber eine CA in der Domain haben, würde ich die Zertifikate gerne über diese beziehen.
Dazu habe ich eine Frage, die mir Google bisher leider nicht beantworten konnte.
Bisher waren die Generierten Zertifikate immer nur ein Jahr gültig und mussten danach erneuert werden.
Das hat zur Folge, dass auch alle Mitarbeiter die .rdp Dateien einmal im Jahr neu herunterladen mussten.
Bei der Gültigkeitsdauer von einem Jahr würde ich gerne bleiben, jedoch habe ich bei Zertifikaten, die von der CA ausgestellt wurden die Möglichkeit diese zu erneuern.
Kann ich die Zertifikate so konfigurieren, dass nach dem erneuern die .rdp Dateien ihre Gültigkeit behalten und nicht neu heruntergeladen werden müssen?
Ich lese mich gerade in das Thema und bin über jede Hilfe und jeden Hinweis dankbar.
Grüße Gladop
ich arbeite mit einem Windows Server 2016, der als Remotedesktop Server genutzt wird und verschiedene Programme bereitstellt.
Auf diesem sind die folgenden RDS Rollen installiert.
RD-Verbindungsbroker, RD-Sitzungshost, RD-Gateway, RD-Lizenzierung, Web Access für Remotedesktop
Damit alles läuft, wurden bisher Zertifikate genutzt, die über den RDS Server generiert wurden.
Da wir aber eine CA in der Domain haben, würde ich die Zertifikate gerne über diese beziehen.
Dazu habe ich eine Frage, die mir Google bisher leider nicht beantworten konnte.
Bisher waren die Generierten Zertifikate immer nur ein Jahr gültig und mussten danach erneuert werden.
Das hat zur Folge, dass auch alle Mitarbeiter die .rdp Dateien einmal im Jahr neu herunterladen mussten.
Bei der Gültigkeitsdauer von einem Jahr würde ich gerne bleiben, jedoch habe ich bei Zertifikaten, die von der CA ausgestellt wurden die Möglichkeit diese zu erneuern.
Kann ich die Zertifikate so konfigurieren, dass nach dem erneuern die .rdp Dateien ihre Gültigkeit behalten und nicht neu heruntergeladen werden müssen?
Ich lese mich gerade in das Thema und bin über jede Hilfe und jeden Hinweis dankbar.
Grüße Gladop
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6767747927
Url: https://administrator.de/contentid/6767747927
Ausgedruckt am: 22.11.2024 um 13:11 Uhr
24 Kommentare
Neuester Kommentar
Wenn du deine User so trainierst, dass sie den Web Access nutzen, hast du genau dieses Problem nicht.
Genau da liegt ja der Vorteil von Terminalanwendungen, man muss eben nicht jedesmal am Client rum murksen.
Ich glaube wenn das Zertifikat abgelaufen ist kommt lediglich ne Warnmeldung die der User bestätigen muss. Wenn man da den Haken setzt "Nicht erneut nach Verbindung mit diesem Computer fragen" sollte das alles ohne jegliche Nachfragen ablaufen.
Genau da liegt ja der Vorteil von Terminalanwendungen, man muss eben nicht jedesmal am Client rum murksen.
Ich glaube wenn das Zertifikat abgelaufen ist kommt lediglich ne Warnmeldung die der User bestätigen muss. Wenn man da den Haken setzt "Nicht erneut nach Verbindung mit diesem Computer fragen" sollte das alles ohne jegliche Nachfragen ablaufen.
Die rdp-Dateien werden mit dem neuen Zertifikat signiert, somit werden die alten bei Zertifikatswechsel ungültig.
Was Du machen kannst: trainiere die Nutzer, das Startmenü zu nutzen (die verteilten Anwendungen werden dort eingebunden) - dort sind immer die aktuellen RDP-Dateien dahinter.
Oder: verteile Desktopverknüpfungen auf die rdp-Dateien oder deren Ordner - auch die sind dann immer aktuell.
Was Du machen kannst: trainiere die Nutzer, das Startmenü zu nutzen (die verteilten Anwendungen werden dort eingebunden) - dort sind immer die aktuellen RDP-Dateien dahinter.
Oder: verteile Desktopverknüpfungen auf die rdp-Dateien oder deren Ordner - auch die sind dann immer aktuell.
Moin @Gladop,
alle RDS Verwaltungsrollen auf dem Sessionhost selber ... das übersehe ich jetzt lieber mal.
Sehr gute Idee. Einfach Zertifikat von der CA ausstellen lassen, am besten ein Wildcard und dieses auf dem RDS Server einspielen und das RDS Zertifikat selbst bitte auch tauschen.
Siehe auch.
https://learn.microsoft.com/en-us/answers/questions/576621/update-certif ...
Bitte was, das währe mir komplett neu, dass man nach dem Austausch der RDS Zertifikate auch die .rdp Dateien der User korrigieren müsste.
Was die Serverzertifikate angeht, so kannst du diese auch locker auf 5 oder 10 Jahre setzen. 😉
Musst halt deine MS-CA vorher dazu bringen Zertifikate mit einer Gültigkeitsdauer von >2 Jahren auszustellen, aber das ist recht schnell erledigt.
Einfach auf der CA eine CMD als Administrator starten und den folgenden Befehl reinklopfen.
Danach CA durchbooten und schon kann diese Zertifikate mit einer Gültigkeitsdauer von bis zu 10 Jahren erstellen. 🤪
Wie schon geschrieben, das eine hat mit dem anderen normalerweise nichts zu tun.
Beste Grüsse aus BaWü
Alex
ich arbeite mit einem Windows Server 2016, der als Remotedesktop Server genutzt wird und verschiedene Programme bereitstellt.
Auf diesem sind die folgenden RDS Rollen installiert.
RD-Verbindungsbroker, RD-Sitzungshost, RD-Gateway, RD-Lizenzierung, Web Access für Remotedesktop
Auf diesem sind die folgenden RDS Rollen installiert.
RD-Verbindungsbroker, RD-Sitzungshost, RD-Gateway, RD-Lizenzierung, Web Access für Remotedesktop
alle RDS Verwaltungsrollen auf dem Sessionhost selber ... das übersehe ich jetzt lieber mal.
Damit alles läuft, wurden bisher Zertifikate genutzt, die über den RDS Server generiert wurden.
Da wir aber eine CA in der Domain haben, würde ich die Zertifikate gerne über diese beziehen.
Da wir aber eine CA in der Domain haben, würde ich die Zertifikate gerne über diese beziehen.
Sehr gute Idee. Einfach Zertifikat von der CA ausstellen lassen, am besten ein Wildcard und dieses auf dem RDS Server einspielen und das RDS Zertifikat selbst bitte auch tauschen.
Siehe auch.
https://learn.microsoft.com/en-us/answers/questions/576621/update-certif ...
Bisher waren die Generierten Zertifikate immer nur ein Jahr gültig und mussten danach erneuert werden.
Das hat zur Folge, dass auch alle Mitarbeiter die .rdp Dateien einmal im Jahr neu herunterladen mussten.
Das hat zur Folge, dass auch alle Mitarbeiter die .rdp Dateien einmal im Jahr neu herunterladen mussten.
Bitte was, das währe mir komplett neu, dass man nach dem Austausch der RDS Zertifikate auch die .rdp Dateien der User korrigieren müsste.
Bei der Gültigkeitsdauer von einem Jahr würde ich gerne bleiben, jedoch habe ich bei Zertifikaten, die von der CA ausgestellt wurden die Möglichkeit diese zu erneuern.
Was die Serverzertifikate angeht, so kannst du diese auch locker auf 5 oder 10 Jahre setzen. 😉
Musst halt deine MS-CA vorher dazu bringen Zertifikate mit einer Gültigkeitsdauer von >2 Jahren auszustellen, aber das ist recht schnell erledigt.
Einfach auf der CA eine CMD als Administrator starten und den folgenden Befehl reinklopfen.
certutil -setreg ca\ValidityPeriodUnits 10
Danach CA durchbooten und schon kann diese Zertifikate mit einer Gültigkeitsdauer von bis zu 10 Jahren erstellen. 🤪
Kann ich die Zertifikate so konfigurieren, dass nach dem erneuern die .rdp Dateien ihre Gültigkeit behalten und nicht neu heruntergeladen werden müssen?
Wie schon geschrieben, das eine hat mit dem anderen normalerweise nichts zu tun.
Beste Grüsse aus BaWü
Alex
@MysticFoxDE
Gruß,
Dani
Was die Serverzertifikate angeht, so kannst du diese auch locker auf 5 oder 10 Jahre setzen. 😉
setzt natürlich voraus, dass das Zertifikat der CA noch solange gültig ist. Wenn dieses in 5 Jahren ausläuft, sind maximal 4 Jahre möglich.Wenn du deine User so trainierst, dass sie den Web Access nutzen, hast du genau dieses Problem nicht.
Alternativ das Mapping über den Weebfeed nutzen. Damit werden die Application des RDS ins Startmenü des Clients eingetragen.Gruß,
Dani
Moin @Dani,
@MysticFoxDE
ist überhaupt kein Beinbruch.
Einfach auf der Zertifizierungsstelle unter C:\Windows eine "CAPolicy.inf" mit dem folgenden Inhalt erstellen.
Danach den Zertifikatsserver neu starten oder
Dann noch das Zertifizierungsstellenzertifikat erneuern und schon ist der Fisch geputzt. 😉
Beste Grüsse aus BaWü
Alex
@MysticFoxDE
Was die Serverzertifikate angeht, so kannst du diese auch locker auf 5 oder 10 Jahre setzen. 😉
setzt natürlich voraus, dass das Zertifikat der CA noch solange gültig ist. Wenn dieses in 5 Jahren ausläuft, sind maximal 4 Jahre möglich.ist überhaupt kein Beinbruch.
Einfach auf der Zertifizierungsstelle unter C:\Windows eine "CAPolicy.inf" mit dem folgenden Inhalt erstellen.
[Version]
Signature= "$Windows NT$"
[certsrv_server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
AlternateSignatureAlgorithm=0
ForceUTF8=1
Danach den Zertifikatsserver neu starten oder
net stop certsvc
net start certsvc
Dann noch das Zertifizierungsstellenzertifikat erneuern und schon ist der Fisch geputzt. 😉
Beste Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Moin @Dani,
@MysticFoxDE
ist überhaupt kein Beinbruch.
Einfach auf der Zertifizierungsstelle unter C:\Wwindows eine "CAPolicy.inf" mit dem folgenden Inhalt erstellen.
Danach den Zertifikatsserver neu starten oder
Dann noch das Zertifizierungsstellenzertifikat erneuern und schon ist der Fisch geputzt. 😉
Beste Grüsse aus BaWü
Alex
Moin @Dani,
@MysticFoxDE
Was die Serverzertifikate angeht, so kannst du diese auch locker auf 5 oder 10 Jahre setzen. 😉
setzt natürlich voraus, dass das Zertifikat der CA noch solange gültig ist. Wenn dieses in 5 Jahren ausläuft, sind maximal 4 Jahre möglich.ist überhaupt kein Beinbruch.
Einfach auf der Zertifizierungsstelle unter C:\Wwindows eine "CAPolicy.inf" mit dem folgenden Inhalt erstellen.
[Version]
Signature= "$Windows NT$"
[certsrv_server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
AlternateSignatureAlgorithm=0
ForceUTF8=1
Danach den Zertifikatsserver neu starten oder
net stop certsvc
net start certsvc
Dann noch das Zertifizierungsstellenzertifikat erneuern und schon ist der Fisch geputzt. 😉
Beste Grüsse aus BaWü
Alex
Der Mann hat's einfach drauf!
Meine Hochachtung, weil Du immer sauguten Tipps hier lang kommst und sachlich bleibst!
Liebe Grüße aus'm Saarland
Andreas
Moin @Gladop,
Hier können die User nur auf OK klicken und die RDP-Verbindung schließt sich.
ähm, warum verwendest du überhaupt signierte RDP Dateien?
Sprich, keine Signatur = kein Stress damin. 😉
Könnte es zu einem Problem werden, wenn wir den Server so weiter betreiben?
(Abgesehen von der Skalierbarkeit)
das ist eher Betriebs.- und auch Sicherheitstechnisch nicht ratsam.
Alleine durch die WebAccess Rolle auf diesem Server ist auch z.B. ein IIS installiert. Sprich, wenn sich ein Remot-User auf diesem RDS Server was einfängt, dann hat der Schädling diverse Dinge die er durch die Zusätzlichen Rollen auch angreifen kann. 😔
Beste Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Wenn die Signatur abgelaufen ist, kommt die Meldung "Die digitale Signatur dieser RDP-Datei kann nicht bestätigt werden. Die Remoteverbindung kann nicht hergestellt werden."Bisher waren die Generierten Zertifikate immer nur ein Jahr gültig und mussten danach erneuert werden.
Das hat zur Folge, dass auch alle Mitarbeiter die .rdp Dateien einmal im Jahr neu herunterladen mussten.
Bitte was, das währe mir komplett neu, dass man nach dem Austausch der RDS Zertifikate auch die .rdp Dateien der User korrigieren müsste.Das hat zur Folge, dass auch alle Mitarbeiter die .rdp Dateien einmal im Jahr neu herunterladen mussten.
Hier können die User nur auf OK klicken und die RDP-Verbindung schließt sich.
ähm, warum verwendest du überhaupt signierte RDP Dateien?
Sprich, keine Signatur = kein Stress damin. 😉
Zitat von @MysticFoxDE:
alle RDS Verwaltungsrollen auf dem Sessionhost selber ... das übersehe ich jetzt lieber mal.
Über den RDS werden zwei Programme bereitgestellt, die sehr empfindlich sind, was kurze Verbindungsabbrüche angeht. Daher vor allem für Usern gedacht, die bei Kunden über LTE + VPN arbeiten.alle RDS Verwaltungsrollen auf dem Sessionhost selber ... das übersehe ich jetzt lieber mal.
Könnte es zu einem Problem werden, wenn wir den Server so weiter betreiben?
(Abgesehen von der Skalierbarkeit)
das ist eher Betriebs.- und auch Sicherheitstechnisch nicht ratsam.
Alleine durch die WebAccess Rolle auf diesem Server ist auch z.B. ein IIS installiert. Sprich, wenn sich ein Remot-User auf diesem RDS Server was einfängt, dann hat der Schädling diverse Dinge die er durch die Zusätzlichen Rollen auch angreifen kann. 😔
Beste Grüsse aus BaWü
Alex
Zitat von @Gladop:
Aber der Web Access funktioniert doch so, dass er den Usern eine .RDP Datei zum Download anbietet, die dann gestartet werden muss um die Verbindung aufzubauen.
Gibt es dazu eine alternative Konfiguration?
Aber der Web Access funktioniert doch so, dass er den Usern eine .RDP Datei zum Download anbietet, die dann gestartet werden muss um die Verbindung aufzubauen.
Gibt es dazu eine alternative Konfiguration?
Wenn du mit dem Edge arbeitest öffnen sich diese RDP Dateien automatisch. Du bekommst nur mit z.B. Firefox/Chrome oder anderen Browsern eine RDP Datei zum download angeboten.
Die Dateien werden aber für jeden Download neu generiert - d.h. Änderungen die du an der Config machst sind dann quasi beim nächsten "Start" der Anwendung in "der RDP Datei enthalten".
Deswegen sagte ich ja, ein riesen Vorteil, statt mit lokalen RDP Files rum zu kaspern. Und wenn ein User meint er müsste nur mit den RDP Files hantieren und es "klappt dann was nicht - sorry, kein Support. Er solls über den Web Access machen".
Moin Dani,
und was soll das ausserhalb der Azure & Co Wolke den wirklich bringen?
Ich habe übrigens auch noch nie von einem Angriff gehört, der durch die Manipulation einer RDP Datei zustande gekommen ist.
Und jetzt fall bitte nicht tot um, aber in einem anständig gesicherten Intranet, würde ich selbst die RDS Verschlüsselung deaktivieren. 🤪
In einem Intranet ist heutzutage eh alles geswitcht, sprich, ein "mitlauschen" ist hier alleine schon dadurch nicht ganz so einfach. Und von extern werden die RDP Verbindungen hoffentlich über ein VPN Tunnel geöffnet und hier wird durch den Tunnel eh schon verschlüsselt. 😉
Und am Ende des Tages müssen wir Admins die verschlüsselten Verbindungen meist eh wieder mühselig aufbrechen, um sicherzustellen, dass auch über diese kein Unsinn getrieben wird. 😭🙃
Beste Grüsse aus BaWü
Alex
ähm, um (un)gewollte Manipulationen zu erkennen und evtl. revidierte Zertifikate auch entsprechend die Nutzer zu schützen.
und was soll das ausserhalb der Azure & Co Wolke den wirklich bringen?
Ich habe übrigens auch noch nie von einem Angriff gehört, der durch die Manipulation einer RDP Datei zustande gekommen ist.
Und jetzt fall bitte nicht tot um, aber in einem anständig gesicherten Intranet, würde ich selbst die RDS Verschlüsselung deaktivieren. 🤪
In einem Intranet ist heutzutage eh alles geswitcht, sprich, ein "mitlauschen" ist hier alleine schon dadurch nicht ganz so einfach. Und von extern werden die RDP Verbindungen hoffentlich über ein VPN Tunnel geöffnet und hier wird durch den Tunnel eh schon verschlüsselt. 😉
Und am Ende des Tages müssen wir Admins die verschlüsselten Verbindungen meist eh wieder mühselig aufbrechen, um sicherzustellen, dass auch über diese kein Unsinn getrieben wird. 😭🙃
Beste Grüsse aus BaWü
Alex
Das Thema ist mit dem Setzen einer einzigen GPO erledigt: https://ryanmangansitblog.com/2019/11/14/windows-virtual-desktop-configu ...
Warum Signieren im LAN:
Weil man sonst auch Warnmechanismen abschalten muss, die auch außerhalb des LANs nicht mehr wirken würden, zum Beispiel. Sollte allein Grund genug sein.
Oder weil ich als Nutzer gern wüsste, wer das RDP-File erzeugt hat, da ich nicht jedesmal prüfen will, was drin steht. Durch die Weiterleitung lokaler Laufwerke kann man ja Gefahren erzeugen, ebenso durch das Abgreifen von Credentials.
Warum Signieren im LAN:
Weil man sonst auch Warnmechanismen abschalten muss, die auch außerhalb des LANs nicht mehr wirken würden, zum Beispiel. Sollte allein Grund genug sein.
Oder weil ich als Nutzer gern wüsste, wer das RDP-File erzeugt hat, da ich nicht jedesmal prüfen will, was drin steht. Durch die Weiterleitung lokaler Laufwerke kann man ja Gefahren erzeugen, ebenso durch das Abgreifen von Credentials.
Moin @DerWoWusste,
solange die RDP Datei intern erstellt wurde und keinen Download-Flag hat, wirst du von keinem aktuellen Windows beim Ausführen dieser, irgend eine Warnmeldung sehen. 😉
Ein Nutzer der den Inhalt der RDP Datei verifiziert ... der ist echt gut. 😂🤣😂🤣
Bitte die Kirche im Dorf lassen, danke.
Beste Grüsse aus BaWü
Alex
Weil man sonst auch Warnmechanismen abschalten muss, die auch außerhalb des LANs nicht mehr wirken würden, zum Beispiel. Sollte allein Grund genug sein.
solange die RDP Datei intern erstellt wurde und keinen Download-Flag hat, wirst du von keinem aktuellen Windows beim Ausführen dieser, irgend eine Warnmeldung sehen. 😉
Oder weil ich als Nutzer gern wüsste, wer das RDP-File erzeugt hat, da ich nicht jedesmal prüfen will, was drin steht. Durch die Weiterleitung lokaler Laufwerke kann man ja Gefahren erzeugen, ebenso durch das Abgreifen von Credentials.
Ein Nutzer der den Inhalt der RDP Datei verifiziert ... der ist echt gut. 😂🤣😂🤣
Bitte die Kirche im Dorf lassen, danke.
Beste Grüsse aus BaWü
Alex
solange die RDP Datei intern erstellt wurde und keinen Download-Flag hat, wirst du von keinem aktuellen Windows beim Ausführen dieser, irgend eine Warnmeldung sehen. 😉
Das kannst du ja gerne behaupten. Anleitungen, die eine seamless remoteapp experience ohne Warnmeldungen verwirklichen, behaupten das Gegenteil. Es geht hier nicht um eine normale RDP-Datei, sondern um eine, welche eine Remoteapp startet. Dieser Artikel beschreibt es. Spring dort zur StelleIf you do not sign your RemoteApps then Web SSO will not work (you will get multiple credential prompts) and you will get a pop-up like the one shown in Figure 5. Notice that there is no option to not receive the warning in the future; you will get this each time you open an unsigned RemoteApp.
Das gilt auch heute noch in allen supporten OS'.
Moin @DerWoWusste,
das behaupte ich nicht nur, das kann ich dir auch jederzeit beweisen und oder du testest es einfach mal selbst aus. 😉
Kleiner Tipp, teste einfach beides mal aus, dann weist du für die Zukunft wem du eher vertrauen kannst. 🦊🤪
Ähm, du weist aber schon, dass sich das eine "innerlich" lediglich in einer oder zwei Zeilen von dem anderen unterscheidet?
Kann ich so nicht bestätigen und so gut wie jeder unserer Kunden betreibt eine oder mehrere RDS Farmen. 😁
Nix immer anderen glauben, die Wahrheit selber herausfinden du musst. 😉
Beste Grüsse aus BaWü
Alex
Das kannst du ja gerne behaupten.
das behaupte ich nicht nur, das kann ich dir auch jederzeit beweisen und oder du testest es einfach mal selbst aus. 😉
Anleitungen, die eine seamless remoteapp experience ohne Warnmeldungen verwirklichen, behaupten das Gegenteil.
Kleiner Tipp, teste einfach beides mal aus, dann weist du für die Zukunft wem du eher vertrauen kannst. 🦊🤪
Es geht hier nicht um eine normale RDP-Datei, sondern um eine, welche eine Remoteapp startet.
Ähm, du weist aber schon, dass sich das eine "innerlich" lediglich in einer oder zwei Zeilen von dem anderen unterscheidet?
Dieser Artikel beschreibt es. Spring dort zur Stelle
If you do not sign your RemoteApps then Web SSO will not work (you will get multiple credential prompts) and you will get a pop-up like the one shown in Figure 5. Notice that there is no option to not receive the warning in the future; you will get this each time you open an unsigned RemoteApp.
Das gilt auch heute noch in allen supporten OS'.Kann ich so nicht bestätigen und so gut wie jeder unserer Kunden betreibt eine oder mehrere RDS Farmen. 😁
Nix immer anderen glauben, die Wahrheit selber herausfinden du musst. 😉
Beste Grüsse aus BaWü
Alex
Alex, ich verwalte mehrere TS, die RemoteApps hosten (Server 2016/2019 und 2022) und setze auch hin und wieder neue Testsysteme dafür auf - selbst ausprobiert wurde das schon häufig.
Setze ich einen Server 2022 TS (Session-based-deployment) auf, wird für die Website https://ts22.dom.local/RDWeb automatisch ein self-signed Zertifikat erstellt, während für die RemoteApps zunächst kein Zertifikat benutzt wird.
Startet der Client (hier von Win11/10/Server22 alle gleiches Verhalten) von rdweb aus die RemoteApp, dann kommt das schon beschriebene Bild:
Könntest Du deine Behauptung
Setze ich einen Server 2022 TS (Session-based-deployment) auf, wird für die Website https://ts22.dom.local/RDWeb automatisch ein self-signed Zertifikat erstellt, während für die RemoteApps zunächst kein Zertifikat benutzt wird.
Startet der Client (hier von Win11/10/Server22 alle gleiches Verhalten) von rdweb aus die RemoteApp, dann kommt das schon beschriebene Bild:
Könntest Du deine Behauptung
solange die RDP Datei intern erstellt wurde und keinen Download-Flag hat, wirst du von keinem aktuellen Windows beim Ausführen dieser, irgend eine Warnmeldung sehen
nachvollziehbarer erklären? Vielleicht redest Du über etwas anderes?
Moin @DerWoWusste,
diese Warnmeldung kommt daher zustande, weil du die RDP Datei aus einem Browser heraus ausgeführt hast.
Siehe ersten Satz in der Warnmeldung ...
Zudem stuft der Client die Quelle wahrscheinlich nicht als vertrauenswürdig ein und bringt daher den Warnhinweis.
Hast du denn den Host "ts22.dom.local" vorher per Zonenzuweisung zu "Intranet" oder "Vertrauenswürdige Sites" zugewiesen?
Beste Grüsse aus BaWü
Alex
Startet der Client (hier von Win11/10/Server22 alle gleiches Verhalten) von rdweb aus die RemoteApp, dann kommt das schon beschriebene Bild:
Könntest Du deine Behauptung
Könntest Du deine Behauptung
solange die RDP Datei intern erstellt wurde und keinen Download-Flag hat, wirst du von keinem aktuellen Windows beim Ausführen dieser, irgend eine Warnmeldung sehen
nachvollziehbarer erklären? Vielleicht redest Du über etwas anderes?diese Warnmeldung kommt daher zustande, weil du die RDP Datei aus einem Browser heraus ausgeführt hast.
Siehe ersten Satz in der Warnmeldung ...
Zudem stuft der Client die Quelle wahrscheinlich nicht als vertrauenswürdig ein und bringt daher den Warnhinweis.
Hast du denn den Host "ts22.dom.local" vorher per Zonenzuweisung zu "Intranet" oder "Vertrauenswürdige Sites" zugewiesen?
Beste Grüsse aus BaWü
Alex
Moin.
MIt dem Browser allein ist das nicht zu regeln.
Wenn Du diese RDP-Dateien aus dem Dateiexplorer öffnest, kommt ebenso
Da kann man nun den Haken "nicht mehr fragen" setzen, ja, aber man kann es auch einfach signieren.
Oder wie wolltest Du ohne Warnungen auskommen? Leg Deine getesteten Schritte doch einmal dar, die Dich zu deiner Aussage gebracht haben.
MIt dem Browser allein ist das nicht zu regeln.
Wenn Du diese RDP-Dateien aus dem Dateiexplorer öffnest, kommt ebenso
Da kann man nun den Haken "nicht mehr fragen" setzen, ja, aber man kann es auch einfach signieren.
Oder wie wolltest Du ohne Warnungen auskommen? Leg Deine getesteten Schritte doch einmal dar, die Dich zu deiner Aussage gebracht haben.
Moin @DerWoWusste,
gib mir damit übers WE Zeit.
Habe gerade eine XGS an der Backe, die alle Webseitenaufrufe komischerweise als "none" Klassifiziert und nach 2-3 Aufrufen schafft die es dann doch die richtige Kategorisierung zu finden. 😭
Beste Grüsse aus BaWü
Alex
Oder wie wolltest Du ohne Warnungen auskommen? Leg Deine getesteten Schritte doch einmal dar, die Dich zu deiner Aussage gebracht haben.
gib mir damit übers WE Zeit.
Habe gerade eine XGS an der Backe, die alle Webseitenaufrufe komischerweise als "none" Klassifiziert und nach 2-3 Aufrufen schafft die es dann doch die richtige Kategorisierung zu finden. 😭
Beste Grüsse aus BaWü
Alex