Archive for the ‘Remote Desktop’ Category

COM-Schnittstelle bei Windows Remote Desktop oder Virtuellen Maschinen

24 Mai 2019

Wer eine physische COM-Schnittstelle auf einem anderen Rechner mittels Remote-Desktop verfügbar machen möchte, muss folgendes beachten.

Zuerst muss man im Remote Desktop die Optionen einblenden, um beim Register Lokale Ressourcen, unten bei “Lokale Geräte und Ressourcen”, die Weiter-Schaltfläche anklicken zu können. Dort aktiviert man nun den Eintrag Ports.
Alternativ kann man auch in der betreffenden RDP-Datei den Eintrag redirectcomports:i:0 auf 1 setzen und speichern.

Wer nun die Verbindung zum Remoterechner herstellt wird vielleicht gleich im Geräte-Manager nachschauen, ob die COM-Schnittstelle unter “Anschlüsse (COM & LPT)” auch auftaucht. Doch da herrscht gähnende Leere. Tja, der Geräte-Manager ignoriert den COM-Port großzügig.

Der Port ist aber trotzdem verfügbar und kann mittels Powershell-Eingabeaufforderung mit diesem Befehl aufgelistet werden:

[System.IO.Ports.SerialPort]::GetPortNames()

Gemeldet wird dann z. B. COM1.

Wenn man bei virtuellen Maschinen mehr machen möchte, muss man Named Pipes benutzen und kann so RS232-Hardware vom Host direkt einer virtuellen Maschine zur Verfügung stellen. Realisiert wird dies durch PipeToCOM: https://github.com/mcmlxxix/PipeToCom. Diese Lösung hat natürlich den Vorteil ohne Remote Verbindung auszukommen. Jetzt wird es aber wieder kompliziert, denn wenn man eine Generation 2 VM in einem Hyper-V hat, dann gibt es keine COM-Ports mehr. Man kann allerdings mittels Powershell und SET-VMComPort COM1 aktivieren und darüber den Pfad für die Pipe setzen.

Werbeanzeigen

Software für Hardware Token Provider auf Rechner über Remote Desktop zu installieren, ist keine gute Idee

3 März 2016

Wir befinden uns im Jahr 2016. Im Jahr 2006 erblickte Windows Vista die Welt und brachte damals für die Windowswelt nach Windows XP größere Veränderungen mit. Aber selbst heute bekommt man noch Auswirkungen von damals zu spüren, durch unsachgemäße Fehlermeldungen und faule Programmierer!

Aktuelles Beispiel, es sollte der SafeNet Authentication Client Version 9.0 installiert werden, damit ein Zertifikat auf einem USB eToken gespeichert werden kann.

Es wurden mehrere Rechner probiert jeweils mit Windows 7 SP1 und Windows 8.1 mit allen aktuellen Updates, auch 64-Bit und 32-Bit war dabei. Am Ende wurde auch die Installation nur in Englisch durchgeführt, wäre nicht das erste Mal, dass es nur so funktioniert. Aber jedes Mal kam es zu der Fehlermeldung:

There appears to be a problem with the Smart Card Resource Manager configuration on this computer. \nThe installation will be completed, but may not work correctly.\nPlease contact your System Administrator to solve the problem.

Wie die Meldung schreibt funktioniert danach die Sache einfach nicht.

Der Support verwies nur auf dieses Dokument und den Admin: https://kb.safenet-inc.com/kb/index?page=content&id=S438&actp=LIST_POPULAR

Wenn man sich die Log-Dateien anschaut, dann taucht in der eTCoreInst.LOG, welche sich im %TEMP%-Verzeichnis befindet dieser Eintrag auf:

(ThID:2360): Err in RMTable::snapshot, SCardEstablishContext fails, rv=0x8010001d
(ThID:2360): RMTable::snapshot: exit , rv=0x8010001d
(ThID:2360): Err in RMTable::listReaders, snapshot() fails, rv=0x8010001d
(ThID:2360): RMTable::listReaders: exit , rv=0x8010001d
(ThID:2360): Trace in snapshotScardDevice, Cannot list readers

Recherchiert man damit etwas, stolpert man über diesen Artikel: https://blogs.msdn.microsoft.com/alejacma/2011/05/19/scardestablishcontext-fails-with-scard_e_no_service-error/

Da steht dann etwas von:

SCardEstablishContext API is returning that error because it gets an Access Denied error when trying toopen an event called “Global\Microsoft Smart Card Resource Manager Started” with OpenEvent API. The default security for that event on Vista and Windows 7 specifies that only SYSTEM, LOCAL SERVICE and INTERACTIVE users have access to it. NETWORK SERVICE or non-interactive users won’t be able to access the event.

OK, dann ist alles klar. Das ist ein aus XP-Zeiten geerbtes Problem. D. h. man muss physisch angemeldet sein, damit es funktioniert.

Alle obigen Versuche, wo es nicht klappte, wurden per Remote Desktop durchgeführt! Siehe da, einmal physisch am Rechner und schon funktionierte es!!

Gilt für alle, die Zertifikate von DigiSafe, GlobalSign, TrustZone, Entrust und wie sie alle heißen benutzen, welche die Hardware von Safenet einsetzen. Daneben gibt es auch noch Banken…

Noch ein interessanter Blogeintrag, wie man ein normales Zertifikat auf den USB Token bekommt kann: https://blogs.msdn.microsoft.com/ieinternals/2015/01/28/authenticode-in-2015/.

Beschränkungen beim Remote Desktop Dienst und Windows 10 umgehen

1 Dezember 2015

Ein schöner Artikel, welcher beschreibt, wie man die verschiedenen Beschränkungen des Remotedesktop unter Windows 10 umgehen kann. Damit kann man sogar Windows 10 Home per Remotedesktop ansprechen.

http://woshub.com/how-to-allow-multiple-rdp-sessions-in-windows-10/

In diesem Zusammenhang sei auch das RDP Wrapper Projekt auf Github genannt: https://github.com/binarymaster/rdpwrap

Passwörter ändern bei Remote-Desktop bzw. Terminalserversitzungen von Windows XP bis Windows 10

20 Juli 2015

Ein harmloses Thema aber dank der Genialität von Microsoft ein Thema, welches schnell ausarten kann. Zunächst einmal die Ausgangsbasis. Es geht darum den Windows Sicherheitsschirm zu bekommen, dass ist der, wenn man an einem physikalischen Rechner sitzt und STRG+ALT+ENTF drückt. Dort werden meistens diese Punkte angezeigt:

  • Computer sperren
  • Benutzer wechseln
  • Abmelden
  • Kennwort ändern
  • Task Manager starten

Jetzt das Problem: Bei einer Remotedesktopsitzung wird STRG+ALT+ENTF immer auf dem lokalen, also physikalischen Rechner ausgeführt und nicht in der Remotesitzung. Ergo kann der Benutzer sein Kennwort nicht selbständig ändern.

Zu Windows XP und Windows 7 Zeiten konnte man nun im normalen Startmenü in der rechten Spalte auf “Windows Sicherheit” klicken. Dieser Eintrag ist immer automatisch verfügbar sobald man sich in einer Remotedesktopsitzung befindet. Aber durch das verschwinden des Startmenü bei Windows 8 verschwand auch der Eintrag mit “Windows Sicherheit”. Selbst die ganzen nachfolgenden Updates zu Windows 8 mit Windows 8.1 Update Update usw. brachten keine Lösung. Auch Windows 10 mit Build 10240 kennt dazu keinen direkten Startmenüeintrag mehr.

Hier nun die möglichen Lösungen:

Variante 1)
Die einfachste Variante man drückt anstatt STRG+ALT+ENTF die Tastenkombination STRG+ALT+ENDE, also anstatt der Entfernen-Taste die Ende-Taste drücken. In den meisten Fällen sollte dies zum Erfolg führen.

Variante 2)
Alternativ kann man mit der Bildschirmtastatur arbeiten. Dazu ruft man OSK.EXE auf und _wichtig_ drückt auf seiner physikalischen Tastatur STRG+ALT und klickt dann auf dem OSK-Keyboard mit der Maus auf die ENTF-Taste.

Variante 3)
Man verwendet ein kleines Skript, üblicherweise Powershell:

Powershell  -command  "(New-Object -ComObject Shell.Application).WindowsSecurity()"

Damit wird auch der Windows Sicherheitsbildschirm angezeigt. Allerdings funktioniert dieses Skript nur, wenn man sich in einer Remotedesktopsitzung befindet. Im normalen Betrieb aufgerufen passiert einfach nichts.

https://msdn.microsoft.com/en-us/library/windows/desktop/gg537748(v=vs.85).aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1

Variante 4)
Seit Windows 8 hat sich ja alles auf die modernen Apps verlagert was bei Tablets auch Sinn macht, denn wer hat schon STRG+ALT-Tasten an seinem Tablet? Deshalb gibt es bei Windows 8 und nachfolgend unter PC-Einstellungen->Konten->Anmeldeoptionen die Möglichkeit sein Kennwort zu ändern. Unter Windows 10 geht man dazu auf Einstellungen->Konten->Anmeldeoptionen.

Eine weitere Variante für Commandliner ab Windows 10 ist der Aufruf von:

start ms-settings:signinoptions

Man kann auch im hypermodernen Edgebrowser in der URL-Zeile direkt ms-settings:signinoptions eingeben und landet dann in der Einstellungsseite. Nur Cortana versteht das noch nicht, irgendwie komisch…

 

So das war der kleine Ausflug in der Geschichte der Passwortänderungen für die Benutzer. Hier noch hilfreiche Links zum Thema:

http://superuser.com/questions/492856/how-can-i-send-a-ctrlaltdelete-through-remote-desktop-in-windows-8

https://social.technet.microsoft.com/forums/windowsserver/en-US/2b67fa96-707b-47c4-90f5-c3a087ba16a9/how-do-i-change-password-when-connected-to-remote-desktop

Hier noch Links zum Thema ms-settings: http://winaero.com/blog/how-to-open-various-settings-pages-directly-in-windows-10/ sowie https://msdn.microsoft.com/en-us/library/windows/apps/xaml/dn741261.aspx und wo es herkommt: https://msdn.microsoft.com/en-us/library/windows/apps/jj662937(v=vs.105).aspx

Auf virtuelle Maschinen eines Microsoft Hyper-V Server 2012 R2 mittels FreeRDP zugreifen

8 Januar 2014

Mit der aktuellen, umsonst verfügbaren Version des Microsoft Hyper-V Server 2012 R2 kann man mittels Powershell per Commandline mittlerweile fast jeden Bereich administrieren. Das einzig störende ist, wenn man Netzwerkkartenprobleme hat oder Schwierigkeiten hat einen Windows 8.1 Client für die Remoteadministration anzubinden. Powershell ist zwar mächtig, allerdings ist es manchmal hilfreich, wenn man direkt auf eine virtuelle Maschine zugreifen und diese direkt steuern kann.

Es gab zwar schon länger käufliche Lösungen, wie den 5Nine Manager, aber es gibt noch eine bessere Lösung: FreeRDP! Dank der Offenlegung des RPD-Protokolls seitens Microsoft, gibt es keine großen Geheimnisse mehr zur Implementierung. Hier das Projekt: http://www.freerdp.com/ und alles steht feinsäuberlich im Source auf Github. Es gibt sogar Unterstützung für Mac, Linux, Android sowie iOS. Was will man mehr.

Am einfachsten um FreeRDP unter Hyper-V nutzen zu können, verwendet man die 3MB-Variante von cloudbase.it http://www.cloudbase.it/using-freerdp-to-connect-to-the-hyper-v-console/, dort findet man unten diesen Downloadlink: http://www.cloudbase.it/downloads/FreeRDP_powershell.zip. Die Version ist explizit für die 2012 R2 Version freigegeben.

Von der FreeRDP-Geschichte abgesehen, gilt es auch die anderen Dinge von Cloudbase in Richtung OpenStack an sich zu beachten!

Schwarzer Bildschirm bei Remote Desktop

13 Dezember 2013

Schon seit Wochen nervt mich eine Besonderheit meiner ach so schönen Windowswelt. Den Taugenichtsen von MS war es mal wieder langweilig und da dachten sie sich: Hey, machen wir doch einen Bug ins neue RDP-Protokoll 8.1 rein!

Das Phänomen äußert sich folgendermaßen: Man baut ganz normal eine Remote-Desktop-Verbindung auf, man arbeitet damit, sogar über Tage hinweg. Alles läuft normal. Aber irgendwann ist das Remote-Fenster im Weg und man legt es auf die Taskleiste. Wenn man es später wieder hochhohlen will, kann es passieren, dass anstatt des Remote-Desktops nur ein schwarzer Fensterinhalt präsentiert wird. Der Witz dabei ist, wenn man das auf die Taskleiste legen und wieder hochholen mehrmals exerziert, dann ist irgendwann das Fenster da. Manchmal hilft auch die Verbindung zu trennen und neu aufzubauen aber leider nicht immer.

Abgenervt ohne Ende, weil es gefühlt, die letzten Tage immer schlimmer wurde, mal im Internet gefahndet. Siehe da, dieser Artikel: http://social.technet.microsoft.com/Forums/de-DE/31b681c5-3658-45a5-8158-a0a0f967c4a2/rdp-screen-goes-black-after-successful-remote-login. Da sind ähnliche Dinge beschrieben STRG+ALT+Ende-Tastenkombination soll helfen. OK, ausprobiert. Bingo! Es erscheint immer das Auswahlfenster, wo man den Computer sperren kann, den Taskmanager aufrufen kann usw. Klickt man nun hier abbrechen, erscheint der Desktop in alter Pracht. Laut den Eintragungen gibt es das Problem schon länger, aber ich behaupte es ist bei mir erst, seit RDP 8.1 ein Thema.

Remote Desktop Fehlermeldung: Die Verbindung kann nicht aufrechterhalten werden, da die Identität des Remotecomputers nicht überprüft werden konnte.

7 Juni 2013

Wer die Fehlermeldung

Die Verbindung kann nicht aufrechterhalten werden, da die Identität des Remotecomputers nicht überprüft werden konnte.

beim Versuch eine Remotedesktopverbindung aufzubauen, der wundert sich zunächst. Zunächst wurden die Remotedesktop-Einstellungen überprüft. Hier kann üblicherweise beim Register “Leistung” unter Serverauthentifizierung eingestellt werden, dass die Verbindung unter einem gewissen Sicherheitsstandard nicht hergestellt werden soll.

Allerdings klappte bei obiger Meldung die Verbindung immer noch nicht, obwohl “Verbinden und keine Warnungen anzeigen” ausgewählt war.

Was tun? Durch Zufall wurde entdeckt, dass sich der Remote-Rechner sowie der Zielrechner in der Zukunft befanden! Genau 25 Minuten voraus. So wie es sich momentan darstellt, scheint dies der ausschlaggebende Punkt gewesen zu sein. Nachdem die Uhrzeit der Systeme korrekt gesetzt wurde, klappte die Verbindung. Allerdings bleibt noch ein Restzweifel, weil einer der beiden Rechner gleichzeitig wegen Update einspielen neu gestartet wurde. Die involvierten Rechner waren mit Windows Vista SP2 eingerichtet.

Bei Verwendung des Remote Desktop unter Windows erscheint ständig eine Zertifikatswarnmeldung obwohl man bereits das Zertifikat installiert hat

26 August 2012

Wenn man mit den Standardeinstellungen eine Verbindung zum Remotedesktop eines anderen Windows-Rechners aufbaut der nicht in derselben Domäne sitzt, wird man mit Warnhinweisen traktiert. An sich ist die Sache ja gut, nur leider führt die Art wie die Dialoge reagieren zu dem Ergebnis, dass die Anwender genervt sind und im Zweifel ihre Sicherheitseinstellungen reduzieren um zum Ziel zu kommen.

Hier sind die Masken (noch Win7) schön dargestellt und die Situation gut beschrieben: http://serverfault.com/questions/7653/remote-desktop-keeps-asking-me-to-accept-a-certificate

Blöd an der Sache ist, dass selbst wenn man sagt, man möchte das Zertifikat installiert bekommen, dass es dann beim nächsten Aufruf wieder nicht klappt. Das verwirrt und sorgt für die Konditionierung, dass einfach immer alles weggeklickt wird, Hauptsache es funktioniert irgendwie. Aber das kann es nicht sein!

Was passiert hier effektiv? Wenn man die Installation des Zertifikats dem System überlässt, wird das Zertifikat beim aktuellen Benutzer abgespeichert und zwar unter den Zwischenzertifizierungsstellen. Damit das Zertifikat seiner Bedeutung gerecht werden kann, muss es aber im Computerkonto unter Vertrauenswürdige Stammzertifizierungsstellen enthalten sein. Warum das so ist? Keine Ahnung, aber ich spekuliere mal darauf, dass auch bestimmte Dienste (Netzwerk) zur Absicherung der Verbindung benutzt werden und diesen das Zertifikat vom Benutzer nicht zur Verfügung steht.

Lösung unter Windows 8 und Server 2012
Windows 8 und Windows Server 2012 bringen eine Verbesserung der Situation. War seither beim Importassistent immer nur die Installation des Zertifikats beim aktuellen Benutzer möglich, erscheint nun nach Auswahl von “Zertifikat installieren” zuallererst die Rückfrage nach dem Speichertort, wo man zwischen “Aktueller Benutzer” und “Lokaler Computer” wählen kann. Leider ist aber der Rest des Assistenten genauso unübersichtlich wie früher. D. h. am Ende des Importvorgangs ist nicht klar wo das Zertifikat gelandet ist!

Denn das dumme daran ist, dass das Zertifikat nicht im Speicher der Vertrauenswürdigen Stammzertifizierungsstellen gespeichert wird, auch wenn man den lokalen Computer zuerst ausgewählt hat. Wie vor Windows 8 wird es, bei Verwendung der Vorgabe den Zertifikatsspeicher automatisch zu wählen, im Speicher der Zwischenzertifizierungsstellen gespeichert! Ob Bug oder Feature kommt noch hinzu, dass das Zertifikat nicht nur beim lokalen Computer landet sondern auch noch beim aktuellen Benutzer. Beim Testen wurde bereits Windows 8 RTM verwendet!

Das Zertifikat wird also nur sauber gespeichert wenn man “Lokalen Computer”, “Alle Zertifikate in folgendem Speicher speichern” und als Speicherort “Vertrauenswürdige Stammzertifizierungsstellen” auswählt.

Lösung für Windows 7, Server 2008 R2 und davor
Man kann nun mittels MMC und dem Zertifikats-Snapin einmal das Computerkonto und den Zertifikatsspeicher des aktuellen Benutzer öffnen und dann das betreffende Zertifikat vom einen Speicher in den anderen verschieben. Lästig aber ist so.

Remote Desktop, Teamviewer oder Netviewer Alternative: Chromes Remoting Viewer

23 Mai 2012

Die Verbreitung von Google Chrome nimmt weiter zu und wird ständig mit neuen Versionen versorgt. Letztes Jahr hat eine neue Funktion Einzug gehalten: Remote Desktop.

Wer sich wundert, wenn er bei chrome://plugins auf einmal einen Remoting Viewer angezeigt bekommt, dann ist das wieder ein Teil der Bestrebung, dass Google sein eigenes Betriebssystem ChromeOS verbreiten möchte.

Es hat bereits Böse Kommentare gegeben, wie So ein Plugin einfach standardmäßig aktiv sein kann: https://productforums.google.com/forum/#!msg/chrome/pu8izeLwqew/D7xCjDb7LncJ

Hier die aktuelle offizielle Beschreibung, was geht und wo es noch Probleme gibt: https://support.google.com/chrome/bin/answer.py?hl=de&answer=1649523

Die eigentliche Chrome-App gibt es hier: https://chrome.google.com/webstore/detail/gbchcmhmhahfdphkhkmpf
mihenigjmpp/details

Die Sache muss man unbedingt mal näher beobachten, denn es müsste theoretisch eine einfache Plattformübergreifende Fernwartung möglich sein. Die Verbindung der betreffenden Rechner wird über eine zwölfstellige Nummer ermöglicht, also auch für Normalbenutzer anwendbar.

RDP Sitzungen aufzeichnen

27 Oktober 2011

Ein geniales Programm um auf anderen Rechnern RDP-Sitzungen aufzeichnen zu können: http://www.observeit-sys.com/