Windows Server, NAT und der FTP-Transparentproxy

Auf der Arbeit haben wir einen Server, den wir als Hyper-V-Host benutzen. Auf dem Server läuft NAT (als Teil von Routing/RRAS), damit die virtuellen Maschinen alle eine private IP-Adresse haben und über den Host (als Gateway) ins Internet kommen bzw. ihre Dienste kontrolliert anbieten können. So weit, so gut.

Jetzt hatten wir das Problem, dass wir von den Gästen keine Verbindung zu FTP-Servern herstellen konnten. Es gab auch keinen Workaround; es gab exakt diesen einen FTP-Server, der nur FTP anbot. Kein HTTP, kein alternativer Server.
Der übrige Traffic lief normal durch – eingehender Traffic, ausgehender Traffic, alles wurde durch den Host und die NAT geroutet und durch die Firewall gefiltert. Perfekt. Bis auf das Problem mit FTP.

Die Firewall konnte es nicht sein, immerhin gab es keine explizite Regel für Port 21, und ohnehin – die VM stellt die Anfrage (ausgehender Traffic), und normalerweise sollte die Firewall solche passiven FTP-Verbindungen auch dynamisch erlauben.
Ports über und unter 1024 liefen gleichermaßen normal; auch bekannte Ports wie 25 oder 110, die von manchen ranzigen ISPs weggeblockt werden, um Spam-Server zu verhindern, waren nicht betroffen.
Auch im NAT-Router war kein Filter irgendeiner Art eingestellt (abgesehen von den Portweiterleitungen, aber die spielen ja nur für eingehenden Traffic eine Rolle). Trotzdem kam die Verbindung nie über ein SYN hinaus, das am Hostrechner verendete.

Ping, Traceroute und sonstige Tools waren erfolgreich; andere Dienste auf den getesteten FTP-Servern waren auch nicht beeinträchtigt. Nur FTP weigerte sich zu arbeiten.

Ein paar Stunden (ja, Stunden. Und wir waren zu dritt damit beschäftigt) später haben wir das Problem finden können: der FTP Transparent Proxy.

Die Dokumentation in TechNet ist ziemlich spärlich und hilft für dieses konkrete Problem nicht weiter. Die meisten Suchergebnisse bei Google sind entweder russisch, behandeln Linux-Server oder beschäftigen sich damit, wie man durch eine NAT seinen eigenen FTP-Server ansprechen kann.

Die Lösung ist ein Einzeiler auf der Kommandozeile:

netsh routing ip nat delete ftp

Und plötzlich waren die Verbindungen von Hyper-V-Gästen zu FTP-Servern erfolgreich.

Windows Store komplett entfernen

Microsoft liefert seit Windows 8 den Windows Store als Teil des OS aus, und mit neueren Versionen von Windows 10 kann man den Store nicht mal mehr per Gruppenrichtlinie verbieten.
Was mich auch sehr erstaunt hat, ist dass Microsoft mit Windows Server 2016 (derzeit nur als Prerelease erhältlich) ebenfalls in der Desktop-Konfiguration den Windows Store mit ausliefert. Was zum Geier hat der Windows Store auf einem Server verloren? Wollen sie uns so zur Verwendung von Server Core und Nano Server drängen?
Für alle, die dennoch die grafische Shell auf ihrem Server brauchen, stellt sich jetzt die Frage: wie entfernt man den Windows Store, am besten permanent?

Es gibt zwei Möglichkeiten (die Befehle jeweils in der PowerShell1 mit erhöhten Rechten ausführen):

Möglichkeit 1: Windows Store von allen lokalen Accounts entfernen.
Get-AppxPackage -AllUsers "Microsoft.WindowsStore" | Remove-AppxPackage

Nach der Deinstallation steht die App nicht mehr auf Installed, sondern nur noch auf Staged (prüfen mit Get-AppxPackage -AllUsers "Microsoft.WindowsStore"):
Der Windows Store wurde für alle Benutzer deinstalliert.

Möglichkeit 2: Windows Store de-provisionieren (die Bereitstellung streichen).
Get-AppxProvisionedPackage -Online | ? {$_.DisplayName -eq "Microsoft.WindowsStore"} | Remove-AppxProvisionedPackage -Online

Nach der De-Provisionierung taucht die App weder unter den installierten noch provisionierten AppX-Paketen auf (letzteres prüfen mit Get-AppxProvisionedPackage -Online):
Der Windows Store wurde aus der Provisionierung entfernt.
(Die Ausgabe stammt von Windows Server 2016; auf Windows 8 bis 10 wird die Liste der provisionierten Pakete natürlich etwas länger sein.)

Viel Spaß bei der Deinstallation (und wie immer: alles auf eigene Gefahr).


1 Was mich ebenfalls erstaunt hat: in der Standardkonfiguration von Server 2016 (TP5) ist als Kommandozeilentool im Startmenü (Rechtsklick auf Start oder Win+X) immer noch cmd.exe eingetragen. Vielleicht ändert sich das ja noch bis zum RTM.