Seit einer Weile enthält Windows das “Subsystem für Linux” (WSL). Damit kann man Linux-Code nativ unter Windows ausführen, ohne dafür erst eine VM starten zu müssen oder ähnliches. Di Installation ist super einfach:
Am besten und einfachsten geht es per PowerShell (womit auch sonst? )
Im Zuge der Weiterentwicklung von PowerShell Core und der Ausrichtung auf Linux-Systeme hat Microsoft eine neue Strategie für die Remote-Verwaltung von Systemen entwickelt. Diese beinhaltet u.a. die Verwendung von OpenSSH unter Windows. Das an sich ist nicht wirklich neu – zumindest etwas neuer ist aber die Tatsache, dass diese Technologie jetzt seit dem 1709 Build (“Fall Creators Update”) als Beta im System integriert ist. Allerdings müssen die Komponenten bei Bedarf noch aktiviert / installiert werden. Und das geht so:
Startmenü / Einstellungen (Zahnrad) / Apps / Optionale Features verwalten / Feature hinzufügen:
Dort finden sich dann die beiden OpenSSH Optionen:
Beide Optionen sollten eigentlich selbst-erklärend sein…
Alternativ kann die Installation auch über PowerShell erfolgen:
# Installieren von Server und Client Add-WindowsCapability -Online -Name OpenSSH* # Nur Server Add-WindowsCapability -Online -Name OpenSSH.Server* # Nur Client Add-WindowsCapability -Online -Name OpenSSH.Client*
Der SSH Client läuft jetzt völlig problemlos von der Kommandozeile – wenn man den vollen Pfad benutzt:
C:\Windows\System32\OpenSSH\ssh.exe
Spätestens nach dem nächsten Neustart ist dann der Pfad auch in PATH und damit von überall aus aufzurufen.
Die Konfiguration des OpenSSH-Servers ist ein kleines bisschen aufwändiger. Diesem Thema werde ich demnächst einen weiteren Blogartikel widmen. Stay tuned!
Seit Windows 8 gibt es die Möglichkeit, eine WLAN- oder WWAN-Verbindung als “getaktet” (metered) festzulegen. Das hat Auswirkungen auf die Nutzung dieser Verbindung. Ziel ist es dabei, eine Verbindung mit beschränktem Datenvolumen oder Kosten pro kB/MB, möglichst wenig mit Dingen zu belasten, die man später auch über unbeschränkte Datenverbindungen machen kann, z.B. das Herunterladen von Windows Updates oder die Bereitstellung neuer Software, die erst aus dem Netzwerk geladen werden muss.
Wenn man nun z.B. in einer kleinen Außenstelle, auf einer Baustelle oder sonst wo einen LTE- oder UMTS-Hotspot bereitstellt, damit einige Mitarbeiter darüber arbeiten können, dann haben diese Verbindungen in der Regel ein Datenlimit pro Monat, nach dessen Erreichen die Geschwindigkeit massiv gedrosselt wird, z.B. 3, 5 oder 10GB. Will man nun für diese Mitarbeiter erreichen, dass z.B. keine Windows-Updates über diese Verbindung geladen werden, dann kommen die getakteten Verbindungen zum Einsatz und es wäre wünschenswert, das entsprechende WLAN per Gruppenrichtlinie als “getaktet” zu bestimmen.
Das Problem dabei:
In den GPOs lassen sich zwar die Kosten für WLAN festlegen (es gibt dabei 3 Stufen, “unrestricted”, “fixed” und “variable”, wobei “fixed” bedeutet, dass die Kosten pro übertragenem Kilo- oder Megabyte entstehen und “variable” für ein monatliches Limit steht), dies gilt dann aber für ALLE WLAN-Verbindungen:
Als Alternative kann man nun aber das gute, alte “netsh” benutzen. Damit lassen sich Verbindungsdetails zeigen:
Der Befehl dazu lautet:
netsh wlan show profile WLANSSID
Will man nun für eine Verbindung die Kosten verändern, so geht dies folgendermaßen:
Der Befehl dazu lautet:
netsh wlan set profileparameter name=WLANSSID cost=variable (oder alternativ “fixed”)
Daraus braucht man nun nur noch ein passendes kleines Script basteln und dieses per GPO wirken lassen:
Kürzlich stand ich vor der Aufgabe, altes Fotomaterial aufzuarbeiten um dabei insbesondere Schäden an den Fotos und andere Bildfehler zu korrigieren. Für derartige Aufgaben nutze ich sehr gern Photoshop Elements. Für einen schmalen Taler bekommt man viele Funktionen (natürlich nicht so viel wie beim “richtigen” Photoshop, aber das kostet fast 10x soviel). Das von mir sonst benutzte Adobe Lightroom kann das leider nicht oder nur mit riesigem Aufwand.
Nachdem ich das erste Bild bearbeitet hatte, kam mir die Idee, auf meinem Surface Pro weiter zu machen, da dieses ja über einen Digitizer verfügt und mir somit das Arbeiten mit einem Stift ermöglicht hätte. Ein Grafiktablet ala Wacom o.ä. habe ich leider nicht, bin davon aber auch nicht so überzeugt. Bei den halbwegs bezahlbaren ist kein Display enthalten, so dass man auf dem Tablet nur arbeitet, das Ergebnis aber auf dem Monitor zu sehen ist. Beim Surface hingegen kann ich mit dem Stift direkt “im Bild” arbeiten.
Nun hatte ich aber kein Photoshop Elements auf dem Surface und mangels DVD-Laufwerk hätte ich erst die DVD auf USB.-Stick kopieren müssen. Also habe ich nach einer Möglichkeit gesucht, das Surface einfach nur als zweiten Bildschirm an meinem “Haupt-PC” (wo das Photoshop läuft) zu benutzen – und ich wurde fündig. Die Lösung nennt sich “Splashtop”. Wie das genau funktioniert, seht ihr in einem meiner YouTube-Videos:
Nur ein kurzer Hinweis: Seit einigen Tagen gibt es ein kostenloses eBook zum Verteilen von Windows 10 mit Hilfe des System Center Configuration Manager (SCCM). Das fast 100 Seiten umfassende Werk enthält viel Wissenswertes vor allem für SCCM-Einsteiger, die Windows 10 in Ihren Umgebungen ausrollen wollen.
Unter früheren Windows-Versionen konnte man bei VPN-Verbindungen noch den gesamten IPv4-Teil konfigurieren. Dort gab es eine Option “Standardgateway für das Remotenetzwerk verwenden”, die man abschalten konnte:
Standardmäßig war/ist diese Option eingeschaltet und sorgt dafür, dass SÄMTLICHER Datenverkehr über das Remote-Netz geleitet wird, auch das, was eigentlich “DIREKT” ins Internet gehen könnte. Der Vorteil dabei ist, dass der Traffic vom eigenen Endgerät bis zum Firmennetzwerk verschlüsselt ist, was insbesondere dann nützlich ist, wenn man in einem Internetcafe oder Hotel-WLAN sitzt und nicht klar ist, wer den Verkehr mithören kann.
Will man nun auf einem Windows 10 Client dieses Verhalten ändern – also erreichen, dass nur Traffic, der für das Remote-Netzwerk gedacht ist, über VPN geht, der Rest direkt ins Internet, müsste man diesen Haken entfernen, was bei Windows 10 nicht mehr geht, da sich die IPv4-Optionen der VPN-Verbindung nicht mehr öffnen lassen.
Was man aber tun kann, ist dieses Verhalten mit Hilfe der PowerShell herbeizuführen, und zwar mit diesem Aufruf:
Damit wird für alle VPN-Verbindungen das “Split-Tunneling” aktiviert, was eben diesem Haken entspricht.
Seit heute Morgen wird Windows 10 in dem Build 10240 an die Teilnehmer des Insider-Programms (Fast-Ring) ausgerollt. Dabei handelt es sich nun scheinbar um die finale RTM Version. Der Hinweis auf die Preview ist nach dem Update und Neustart vom Desktop verschwunden.
Was ich bisher gar nicht geprüft hatte, mich aber nun sehr interessiert hatte: Windows 10 heisst nun endlich auch “intern” Windows 10 und nicht etwa “Windows 6.4” oder so. Klasse!
Der nächste Build von Windows 10 wird im fast-Ring ausgerollt: 10166! Es geht jetzt also weiter Schlag auf Schlag in Richtung RTM. Vermutlich wird 10166 aber eine der letzten Vorab-Versionen sein.
Einzige Neuerungen, von der man etwas sehen kann: Die Microsoft Wi-Fi App. Damit kann man gegen Gebühr WLAN-Netze nutzen. Aktuell ist dies aber auf das Areal rund um den Microsoft-Sitz in Seattle beschränkt, soll aber zeitnah in ganz Amerika zur Verfügung stehen. Für Europa gibt es noch keine Ankündigungen in diese Richtung.
Der schnellste Weg zur Build 10166 ist (nach dem Update aus dem Vorgänger) der Download der ISO mit Build 10162 und anschließendem Upgrade:
Der Build 10162 ist aber noch nicht der finale Build, der am 29. Juli veröffentlich werden wird. Dennoch scheint es so, als ob noch im Laufe dieser Woche die finale RTM-Version entstehen soll.
Es gibt bereits erste Leaks eines Build 10163 – mal sehen, ob dieses noch in den kommenden Tagen über das Insider-Programm ausgerollt wird…
Es bleibt weiter spannend!
Ein Download der aktuellen ISO sowie einige weitere Informationen dazu finden sich hier:
