Samstag, 28. Oktober 2017

Hyper-V in in Arbeitsgruppen remote verwalten

Ich habe mal wieder etwas mit Virtualisierungsumgebungen gespielt. Hyper-V 2016 gibt es ja als freie Version ohne GUI. Damit man mit diesem Server arbeiten kann braucht man schon irgendwie den Hyper-V Manager auf einer Remotestation (Windows 10).
Nur leider so einfach geht das nicht. Die Microsoft Dokumentation beschreibt zwar viel, aber nicht alles. Ich habe hier eine Beschreibung gefunden die funktioniert, allerdings waren mir ein paar Dinge nicht ganz klar. Deswegen habe ich das Ganze nochmal aufgearbeitet.

Integrierte Firewall

Beide Maschinen sollten mit privaten Netzwerken verbunden sein. Im Netzwerk und Freigabecenter kann man das überprüfen. Ansonsten greifen die voreingestellten Firewall Regeln nicht.

Namensauflösung

Der Remote Computer muss vom Steuernden Computer per Hostnamen erreichbar sein! IP Adressen und DNS Namen sind zwar prinzipiell verwendbar, aber auch nur der Hostname muss aufgelöst werden. Notfalls muss die Maschine einfach in der Datei c:\windows\system32\drivers\etc\hosts eingetragen werden.

Einrichtung für Windows 10 Pro -> Hyper-V Server 2016

Man öffnet am Besten auf beiden Stationen eine Powershell als Administrator.

Auf dem Hyper-V Server 2016 muss Remote Management und der Credential Security Support Provider aktiviert werden.
Enable-PSRemoting
Enable-WSManCredSSP -Role server

Auf Windows 10 (bzw. steuernder Computer) muss der Hyper-V Manager und die Tools installiert werden und Remote Management  aktiviert werden. Ersteres muss man leider per Hand tun:
  • Im Punkt Windows-Features aktivieren müssen die Hyper-V Verwaltungstools ausgewählt werden. 
Enable-PSRemoting

Um in einer Workgroup eine andere Maschine zu Verwalten muss das Konto der Maschine und ein Admin Konto der zu steuernden Maschine eingetragen werden.
Dazu ein kurzes Script
$server = "<Hostname der zu steuernden Maschine>"
$user = "<lokaler user auf der zu steuerenden Maschine>"
Set-Item WSMan:\localhost\Client\TrustedHosts -Value $server -force
Enable-WSManCredSSP -Role client -DelegateComputer $server -force
cmdkey /add:$server /user:$user /pass
Nach interaktiver Eingabe des Passwortes ist die Konfiguration abgeschlossen.
Nun kann einfach nur der Computername im Hyper-V Manager eingetragen werden und die Verbindung wird hergestellt. Sollte ein Fehler auftreten in Richtung Host wird nicht gefunden oder WinRM Client kann nicht zugreifen, dann bitte die IP Adresse und den Hostnamen in die hosts Datei eingetragen. Warum das so ist weiß ich leider nicht.

Zusätzliche Informationen

Hyper-V Feature installieren

Bei der freien Version Hyper-V Server 2016 sind natürlich alle notwendigen Features installiert. Auf allen anderen Windows und Server Versionen kann man die Installation entweder über Programme und Features oder mit Powershell erfolgen.
Mit Get-<> kann man die möglichen Features ermitteln (3 Varianten):
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V*
Get-WindowsOptionalFeature -Online | ? featurename -match 'Microsoft-Hyper-V*'
Get-WindowsOptionalFeature -FeatureName "Microsoft-Hyper-V*" -online | Format-Table 
Mit Enable-<> oder Disable-<> kann man die Features installieren oder entfernen.
Enable-WindowsOptionalFeature -Online -FeatureName <>
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Tools-All
Leider funktioniert das nicht so wie es in der Doku steht. Ist noch kein Feature von Hyper-V installiert lässt sich keines der Einzelnen Sub-Features mit Powershell installieren. Der übergeordnete Schlüssel wird in der Registry nicht gefunden. Sobald ein Feature installiert ist, können weitere Features auch per PS installiert werden.

Zwischen den Versionen

Die Remote Administration von Hyper-V funktioniert nur einwandfrei untereinander bei gleichen Windows Versionen (Windows 10 und Server 2016). Von Windows 10 einen Hyper-V auf Server 2012 R2 funktioniert nicht. Ob man mit den separaten RSAT Versionen noch etwas erreichen kann habe ich nicht probiert.

Tools, Alternativen und Tipps

Mit cmdkey kann man Anmeldeinformation für Netzwerkobjekte speichern und bearbeiten. Oder man geht in die Systemsteuerung und dort dann:
Systemsteuerung\Benutzerkonten\Anmeldeinformationsverwaltung
Als Dateimanager kann man recht einfach den FreeCommander portabel nachrüsten.

Wird auf der steuernden Maschine selbst ein Hyper-V Host ausgeführt, erzeugt Enable-PSRemoting eine Fehlermeldung. Am Ende funktioniert es trotzdem. Allerdings lässt sich auf einer solchen Station offenbar wegen dem Virtuellen Switch die Netzwerkverbindung (private public) nicht mehr ändern. Die Maske öffnet sich einfach nicht. (Windows 10 pro 1703/Netzwerk und Interneteinstellungen/Status/Verbindungseigenschaften ändern)

Will man nested Hyper-V betreiben, muss man das pro VM aktivieren (Doku):
Set-VMProcessor -VMName <Name der VM> -ExposeVirtualizationExtensions $true

Donnerstag, 5. Oktober 2017

Homematic Nachrichten sniffen

Der Wiki Artikel dazu ist ziemlich kurz.
Nachrichten Sniffen ist im Prinzip loggen mit speziellen Einstellungen. Dazu wird vor allem der HM IO in einen speziellen Log Modus versetzt. Die Nachrichten landen in der zentralen Logdatei von FHEM.

Durch setzen bzw. modifizieren folgender Attribute wird er Sniffer Modus beim Homematic IO aktiviert:
attr global verbose 1
attr global mseclog 1
attr <IO> logIDs <ID1>,<ID2>

Was genau passiert dadurch?
  • verbose 1 schaltet so ziemlich alles aus. Konzentration aufs Wesentliche!
  • mseclog 1 schaltet die "exakte" Zeit ein, es werden die Millisekunden geloggt.
  • logIDs schaltet das Logging für bestimmte HM Komponenten wieder ein. Dabei können mehrere Angaben mit Komma getrennt werden:
    • all - steht für alle Homematic Geräte
    • sys - steht für Systemnachrichten
    • <HMID> - HMID des Gerätes/Channels für ein oder mehrere selektive Geräte/Kanäle

Normales Logging - Sniffen wieder ausschalten


Ist man fertig mit Sniffen löscht man einfach die zusätzlichen Attribute und versetzt das globale Logging wieder in den gewünschten Zustand (Standard verbose 3)
deleteattr global mseclog
deleteattr <IO> logIDs
attr global verbose 3

Mehrere IOs setzen


Man kann den Namen des <IO> durch einen devSpec ersetzen. Z.B. alle IOs die der VCCU zugeordnet sind.
attr own_CCU=VCCU logIDs ID1,ID2

deleteattr own_CCU=VCCU logIDs

Praktisches Beispiel


Ich logge in einer zweiten FHEM Instanz, mein produktives System bleibt wie es ist. Ich sniffe zwei Fernbedienungen
attr global verbose 1
attr global mseclog 1
attr myHmUARTLGW logIDs 101E78,53F520

Wenn man parallel den Event Monitor öffnet kann man sehr gut verfolgen welche Nachrichten und Events zusammengehören. Im Event Monitor muss man dazu folgendes Regexp im Filter eintragen
101E78|53F520

Drücke ich jetzt auf beiden Fernbedienungen kurz eine Taste bekomme ich folgende Einträge im Log

2017.10.05 14:50:57.978 0: HMUARTLGW myHmUARTLGW recv: 01 05 00 00 31 msg: A2 A4 40 101E78 152B02 0264
2017.10.05 14:50:58.110 0: HMUARTLGW myHmUARTLGW recv: 01 05 00 00 3F msg: A2 80 02 152B02 101E78 0101C80048
2017.10.05 14:51:02.752 0: HMUARTLGW myHmUARTLGW recv: 01 05 01 00 37 msg: 3A A2 40 53F520 200DB8 0305

Dazu gehört diese Bild im Event Monitor


Erste einfache Auswertung

Die Nachrichten werden pro Gerät fortlaufend Hex nummeriert (Zahl vor msg:)

Der erste Tastendruck (msg 31) geht von Gerät (101E78) zu Gerät (152B02) und wird quittiert (msg 3F). Diese Taste ist gepeert. 

Der zweite Tastendruck geht (msg 37) vom Gerät (53F520) zur Zentrale (200DB8) und wird nicht quittiert. Diese Taste ist nicht gepeert.