Programme nahtlos einbinden

Es gibt Situationen, in denen man bestimmte Programme nicht direkt in seinem Betriebssystem installieren möchte. Denkbare Gründe hierfür wären, dass man spezielle Einstellungen oder sogar Betriebssysteme benötigt, aber auch Testzwecke, sei es, um selbst geschriebene Programme unter anderen Umgebungen zu testen, oder die Programme selbst zu testen. Dafür eigenen sich virtuelle Maschinen hervorragend. Solche sind schnell eingerichtet, lassen sich problemlos auf bestimmte Zustände zurücksetzen. Der einzige Nachteil ist, dass sie sich nicht nahtlos in das bestehende System einbinden. Das stimmt so auch nicht – so bietet beispielsweise VMWare den Unity-Mode an, der der Sache schon sehr nahe kommt.

Das funktioniert auch unter Linux-Distributionen und dem VMWare Player

Ich möchte aber einen anderen Weg darstellen, der es ermöglicht nur bestimmte Programme in das System zu integrieren, ohne dass der Benutzer etwas davon mitbekommt, dass er eigentlich mit einer VM arbeitet. 

Vorbereitung: Installation von VMWare

Als erstes benötigen wir dazu VMWare Workstation, Server oder Player und ein entsprechend eingerichtete Virtuelle Maschinen. Damit möchte ich mich nicht näher aufhalten, da es einerseits wirklich sehr einfach ist diese zu installieren und einzurichten, und andererseits gibt es dazu im Internet sicherlich mehrere tausend Anleitungen.

Seamless – Möglichkeiten

Vorbereitung – unnötige Programme entfernen

Da es Ziel ist nur ein oder mehrer ausgewählte Programm in der VM laufen zu lassen, können einige der in der Standardversion installierten Softwarepakete gleich wieder deinstalliert werden. Dies muss nicht zwangsweise erfolgen, sofern man eh genug Platz hat. In Bezug auf Performance sind keine spürbaren Verbesserungen zu erwarten. Jedenfalls kann man folgende Programme deinstallieren (Einstellungen – Systemsteuerung – Software – Windows Komponenten hinzufügen/entfernen):

• MSN Explorer
• Outlook Express
• Windows Media Player
• Spiele (Zubehör und Dienstprogramme)
• Windows Messenger

Es gibt im Internet genügend Anleitungen, wie man XP noch viel schlanker machen kann, aber darauf möchte ich jetzt nicht eingehen, das ist fast eine eigene Wissenschaft für sich. Unter Stichworten wie MiniXP oder dergleichen suchen. Ein Test, wie weit man mit den Hardwareanforderungen heruntergehen kann findet sich unter [Link]. Ein leicht bereinigtes Windows XP kommt bei mir auf folgende Werte:

Wie man sieht sind die Anforderungen wirklich minimalst, was zur Folge hat, dass auch bei mehreren parallel laufenden Systemen kaum eine Belastung des Hauptsystems entsteht. Auch die Festplattenbelegung hält sich – angesichts der heutigen Festplattengrößen und -preise – sehr in Grenzen. Ein bereinigte Installation mit SP3 benötigt ca 2,3 GB. Es geht auch noch viel kleiner (~ 500MB), aber da sind schon sehr weiteingreifende Eingriffe nötig. Ich denke, dass sich dieser Aufwand angesichts der heutigen Rechenleistung und Festplattenleistung sich nicht mehr auszahlt. 

Szenario 1: VM ist am Rechner, von dem es ausgeführt wird (Unity-Mode)

Möglichkeit 1: Deaktivieren von „Enable applications menu“

Seit der Version 7 der VMWare Workstation gibt es unter Unity-Mode die Einstellung „Enable applications menu“

Dadurch verschwindet im Unity Mode die Startleiste des virtuellen Systems, womit schon fast die nahtlose Integration des virtuellen Gastsystems in das Hauptsystem ermöglicht wird. Zwei Dinge gibt es in dem Zusammenhang jedoch noch, die mich mehr oder minder stören. Es ist jetzt nur mehr über die Befehlszeile möglich Programme in der virtuellen Umgebung zu starten. Das zweite was mich sehr stört ist, dass es in der Taskleiste immer ein Symbol für den VMWare Player gibt (VMWare Player deswegen, da er der einzige Möglichkeit darstellt, ohne Umschalten den Unity Mode zu starten, dazu aber später)

Möglichkeit 2: alternative Shell (GUI) [funktioniert nicht]

Eine weitere Überlegung – wie man von Unity-Mode – die Taskleiste wegbekommt, war die Verwendung einer alternativen Shell. Über folgenden Reg-Key kann man die Shell anpassen:

REG – SHELL

Windows Registry Editor Version 5.00  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] „Shell“=“Explorer.exe“

Dabei ist die Explorer.exe durch das zu startende Programm (inkl. vollen Startpfad) zu ersetzen. Das Problem dabei ist, dass VMWare sich so nicht in den Unity-Mode versetzen lässt, da die VMWare Tools offensichtlich auf die Explorer.exe angewiesen sind. Sollte jemand eine Lösung dafür haben, wäre ich sehr dankbar, da es in meinen Augen die einfachste Möglichkeit wäre. (seit VMWare 7 und VMWare Player 3 stimmt diese Aussage nicht mehr)

Möglichkeit 3: die Taskleiste und das Startmenü ausblenden [funktioniert nicht]

Eine weitere Möglichkeit wäre es die Taskleiste und das Startmenü auszublenden, bevor man im Unity-Mode geht. (zB mittels Autostart). Das Problem dabei ist, dass VMWare die ausgeblendet Taskleiste respektive das deaktivierte Startmenü ignoriert. (Wer trotzdem mehr zum Thema Startmenü bzw. Taskleiste ausblenden wissen möchte, sollte hier weiterlesen.)

VMWare Maschine im Unity Mode starten

Interessanterweise stellt VMWare Workstation keinen Befehlszeilenparameter zur Verfügung, um VMWare im Unity-Mode zu starten. Diesbezüglich ist der VMWare Player weiter. Dort gibt es den Parameter: vmplayer -U path/to/vm.vmx

Das funktioniert grundsätzlich hervorragend mit der Einschränkung, dass man weiterhin ein Fenster hat, dass anzeigt, dass der VMWare Player im Unity Mode ist. 

Das wollen wir als nächstes unterdrücken. Wie das genau funktioniert, möchte ich nicht näher erörtern, sondern ein fertiges Programm präsentieren. 

Mit diesem Programm werden ShortCuts am Desktop oder im Startmenü erzeugt, die die Programme wirklich nahtlos in das System integrieren. Sie bekommen den VMWare Player nicht einmal zu sehen.

Szenario 2: VM ist auf einem anderen Rechner, von dem es ausgeführt werden soll 

Nach der Installation der virtuellen Maschine auf dem anderen Rechner, muss zuerst ein Netzwerk eingerichtet werden.

Der erste wichtige Schritt ist die passende Netzwerkkonfiguration. Zur Auswahl stehen:

• Bridged
• NAT
• Host-Only

Dazu jetzt jeweils eine kurze Erklärung (Quelle: aus Dennis Zimmer – VMware und Microsoft Virtual Server) weitere Informationen siehe Links

Host-Only

Dieses Netzwerk stellt Ihnen nur Netzwerkverbindungen innerhalb der virtuellen Umgebung zur Verfügung, d. h., alle virtuellen Maschinen, die einen solchen Adapter ihr Eigen nennen und das Wirt-System selbst können untereinander kommunizieren. Diese Netzwerkart wird häufig auch für Heartbeat-Netze bei geclusterten virtuellen Maschinen verwendet. Problematisch ist logischerweise die mangelnde Flexibilität, was das Verschieben einer virtuellen Maschine auf ein anderes Wirt-System angeht, da sich diese dann in einem »neuen« Host-Only-Netzwerk befindet. Bei geclusterten virtuellen Maschinen bedeutet diese Einschränkung, dass beide VMs auf dem gleichen Wirt-System laufen müssen, um sich gegenseitig über das Host-Only-Netzwerk finden zu können.

Bridged

Kommen wir nun zu dem am häufigsten genutzten virtuellen Netzwerk, dem bridged Network. Hier werden alle Pakete des Gast-Systems direkt auf die physikalische Netzwerkkarte des Wirt-Systems durchgereicht. Die virtuelle Maschine wird daher aus dem physikalischen LAN wie jedes andere Gerät mit einer eigenen MAC-Adresse und einer eigenen IP-Adresse wahrgenommen. Der interne VMware DHCP-Server kann diese Art von Netzwerk nicht mehr bedienen, daher müssen Sie entweder eine feste IP-Adresse vergeben, oder es muss dies ein DHCP-Server Ihres realen Netzwerkes übernehmen. Bis auf die Virtualisierung ist somit ein bridged Network nicht von einem realen Netzwerkadapter zu unterscheiden. Daher ist die virtuelle Maschine durch das reale Netzwerk auch uneingeschränkt erreichbar.

NAT

Das NAT-Gerät setzt die interne Adresse der virtuellen Maschine in die physikalische Adresse des Adapters im Wirt-Systems um. Adresse meint hier MAC-Adresse und IP-Adresse. Da NAT nur mit TCP/IP möglich ist, kann kein anderes Netzwerkprotokoll verwendet werden. Durch die Umsetzung der Quelladresse ist die virtuelle Maschine aus der realen Welt nur über eine Verbindung zum NAT-Gerät zu erreichen, d. h., nur Antwortpakete können den Weg zur virtuellen Maschine finden. Diese Form des virtuellen Netzwerkes nutzt man eigentlich nur, wenn die virtuelle Maschine zwar hauptsächlich innerhalb der virtuellen Umgebung bleiben, aber beispielsweise zum Surfen den Internetzugang im realen Netzwerk nutzen soll. Vorteil hierbei ist, dass nur das Wirt-System eine IP-Adresse im realen Netzwerk erhält und alle virtuellen Maschinen innerhalb des NAT-Netzwerkes dann darüber verwaltet werden.

Grundsätzliche Einstellungen für Remote Desktop Zugriffe

Um den Remote-Zugriff auf einen Computer (aber eben auch auf virtuelle Maschinen) zu ermöglichen, müssen ein paar Vorbereitungen getroffen werden.

• Benutzername und Passwort

Ein Punkt, auf den ich leider immer wieder selbst vergesse, Remote geht ohne Passwort grundsätzlich nichts. Windows lässt es grundsätzlich nicht zu, auf einen Benutzer ohne Passwort remote zuzugreifen. Es gibt daher 2 Möglichkeiten: einerseits gibt man den Benutzer, über den man sich remote anmeldet eine Passwort, oder man deaktiviert die Einstellung, dass der Remote Zugriff nur ohne Passwort erlaubt ist. 

• Benutzer mit Passwort anlegen – am besten mittels : control userpasswords2

• oder leere Kennwörter in Terminal Sessions erlauben (mittels Gruppenrichtlinien) [nicht empfehlenswert]

• Remote Desktop Zugriff zulassen (Start – Systemsteuerung – System – Remote Desktop)

• Installation der Remote Desktop-Webverbindung (nicht unbedingt erforderlich) Systemsteuerung – Software – Windows-Komponenten hinzufügen oder entfernen

Sofern das Netzwerk richtig konfiguriert ist und man einander (Gast – Host und Host – Gast) pingen kann, kann man sich remote einloggen. (gegebenenfalls Firewall und Router konfigurieren) Im Ergebnis sollte nun ein Ping vom Gast auf den Host und umgekehrt möglich sein. Die IP-Adressen findet man wenn man in der cmd – ipconfig /all eingibt (oder auf tausend andere Varianten). Im optimalsten Fall konfiguriert man das ganze so, dass der Rechner auf dem remote zugegriffen werden soll, eine fixe IP bekommt. 

Möglichkeit 1: Seamless RDP und RDesktop

Wenn es Ziel ist mittels RemoteDektop Programme nahtlos in den Arbeitsplatz einzubinden, führen die meisten Suchergebnisse zu folgender Lösung. Die Kombination aus dem Programm SeamlessRDP und dem Remote Desktop Client rdesktop. Das Problem dabei ist, dass diese Lösung für folgende Konstellation geschaffen wurde: Host: Linux | Gast: Windows. Aber sollte das nicht auch bei Host: Windows | Gast: Windows funktionieren. Die Antwort ist „teilweise“. In manchen Konstellationen funktioniert es problemlos, problematisch sind jedoch Konfigurationen, bei denen der Host mehr als einen Monitor hat. In einer solchen Konstellation habe ich es noch nie zum Laufen gebracht, was aber nicht bedeutet, dass es nicht vielleicht doch geht. Aber angesichts der anderen Lösungsmöglichkeiten, gibt es mittlerweile auch andere Lösungen. 

• SeamlessRDB
• Download http://www.cendio.com/seamlessrdp/seamlessrdp.zip
• Installation in einen Ordner in der VM, wie beispielsweise c:\seamlessrdp
• noch ein paar Verschönerungen:
  • Will man die Desktop-Symbole verschwinden lassen, bietet sich folgender RegKey an:

Desktop aus

Windows Registry Editor Version 5.00  [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer] „NoDesktop“=dword:00000001

• Damit die Remote Session auch wirklich optisch was hergibt, ändert man noch AllowFontAntiAlias und ColorDepth

mehr Farben & schönere Schriften

Windows Registry Editor Version 5.00  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations] „AllowFontAntiAlias“=dword:00000001   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp] „ColorDepth“=dword:00000004″AllowFontAntiAlias“=dword:00000001

Der Client:

Das eigentliche Problem dabei ist, dass die in Window integrierte Remote Desktop Software, die den Zugriff auf den Client ermöglicht mit dem SeamlessRDP nichts anfangen kann. Man bekommt also trotzdem den leeren Desktop der Virtuellen Maschine zu sehen.

Das kann nur das für Linux programmierte rdesktop. Das bedeutet, man benötigt eine Portierung von rdeskop auf Windows. Unter Verwendung der cygwin libaries kann man sich selber eines kompilieren, oder die Version im Anhang downloaden. Aber wie bereits erwähnt, habe ich es bei Multi-Monitor Setups noch nie zum Laufen gebracht. 

Programme werden dann mit … gestartet:

rdesktop -A -s „c:\<pfad zu seamlessrdp>\seamlessrdpshell.exe <programmname>“ IPAdresse -u Username -p Passwort

Schön in einen ShortCut verpackt und am Desktop oder im Startmenü integriert, sieht man keinen Unterschied zu Programmen, die direkt am Rechner installiert sind.

Möglichkeit 2: VirtualDesktop und RDP

Eine andere Möglichkeit ist die Verwendung von Virtuellen Desktops (beispielsweise Würfel oder dergleichen) und das Auslagern des RDP auf einen bestimmten Desktop. Das ist zwar nicht ganz eine vollständige Integration, aber ich habe es mehrere Jahre genau so gehandhabt und recht gute Erfahrungen gemacht. Das hat insofern einen Vorteil, wenn man für unterschiedliche Aufgabengebiete bei der Arbeit schnell zwischen den Terminal-Server hin und herschalten muss, braucht man nur den Würfel drehen und man ist am entsprechenden Terminalserver.

Aber so ganz ist das ja noch immer nicht, was wir eigentlich wollten. Nahtlos ist was anderes. Die Taskleiste und das Startmenü sind in dieser Konstellation noch zu sehen. Das war in meinem Fall damals auch so gewünscht, da man sonst die Programme kaum starten kann. Theoretisch ginge es auch, wenn man die Taskleiste und den Startbutton ausblendet und die Programme remote startet.

Dafür greifen wir wieder mal in die Trick-Kiste und verwenden PsExec von Mark Russinovich

Verwendung: Psexec [\\Computer[,Computer2[,…] | @Datei][-u Benutzer [-p Kennwort]][-n s][-l][-s|-e][-x][-i [Sitzung]][-c [-f|-v]][-w Verzeichnis][-d][-<Priorität>][-a n,n,… ] cmd [Argumente]

Angenommen der Computer hat die IP 192.168.178.21 (Computername: XP-REMOTE-TEST) und der Benutzername ist REMOTE-Zugriff und das Passwort ist Dummy und man möchte remote die Datei notepad.exe ausführen: so lautete die Befehlszeile:

psexec \\192.168.178.21 -u XP-REMOTE-TEST\REMOTE-Zugriff -p Dummy -i C:\Windows\System32\notepad.exe

Anmerkung: der Computername muss beim Benutzernamen nicht zwingend angegeben werden, es gibt aber Versionen von psexec, die dies erfordern.

psexec Troubleshooting

An dieser Stelle mal kurz ein psexec Troubleshooting. Was ist alles zu beachten, wenn psexec nicht funktioniert:

1. Ist die einfache Dateifreigabe deaktiviert (wenn nicht diese Anleitung befolgen)
2. Führen sie folgende Befehlszeilen aus:
   • net use \\target\Admin$ /user:Administrator 
   • dir \\target\Admin$ 
   • net use \\target\Admin$ /delete
3. wenn das nicht problemlos funktioniert, sollte man sich hier umsehen.

Wenn man in weiterer Folge das ganze in ein Batch-Datei packt, und die mit einem ShortCut und einem schönen passenden Icon versieht, integriert sich das gewünschte Programm nahtlos in das Betriebssystem.

Möglichkeit 3: TS Remote App

Windows 2008 Server bietet genau das was ich eigentlich haben wollte, sogenannte Remote Apps. Ich sehe jedoch zwei kleine Probleme darin. Einerseits ist es relativ teuer in der Anschaffung – es sei denn man bezieht es als Student oder Schüler über Dreamspark. Das größere Problem erachte, ich dass es nicht wirklich klein ist in der Installation und auch dien Anforderungen sind nicht zu unterschätzen. Mehrere Virtuelle Umgebungen mit Windows 2008 R2 benötigen im Verhältnis zu XP schon wesentlich mehr Rechenleistung.