von Eine schöne Unart vieler Programme, gerade irgendwelcher Branchenlösungen, ist die Nutzung von Netzlaufwerken. Selbst wenn das Programm auf demselben Computer ausgeführt wird, muss das Arbeitsverzeichnis als ein Netzlaufwerk eingebunden werden. Davon abgesehen, dass dies oftmals zu unnötigen Rechtevergaben führt, so dass Exe-Dateien von Netzlaufwerken grundsätzlich gestartet werden können, so war dieses Verhalten von Microsoft auch gar nicht vorgesehen. Dazu gab es vor einigen Jahren mal einen Knowledgebase-Artikel, den ich aber auch nach einiger Recherchearbeit leider nicht mehr finden konnte.
Besonders ärgerlich, wenn es eigentlich unnötig ist, dass die Anwendung vom Netzlaufwerk gestartet wird, dass man diese je nach Betriebssystem ohne Netzwerk dann gar nicht verwenden kann! Einige Möglichkeiten zur Abhilfe zeige ich in diesem Artikel.
Lösungsmöglichkeit 1: Mounten
Wenn man wirklich nur das Laufwerk benötigt und sonst gar kein Netzwerk, dann kann das „Mounten“ des Ordners eine Alternative zum klassichen Netzlaufwerk sein. Das funktioniert mittels des Befehls „subst“:
|
1 |
subst Y: "C:\neuer ordner" |
So sieht es z. B. für die Anwendung so aus, als ob alle benötigten Daten des Programms unter dem Laufwerkbuchstaben Y: liegen würden. Diese Lösung bietet sich vor allen Dingen dann an, wenn man den Netzwerkadapter aus Sicherheitsgründen komplett deaktivieren möchte, z. B. wenn es sich nur um eine rein lokal betriebene Arbeitsstation handelt.
Weitere Informationen: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/subst
Lösungsmöglichkeit 2: Registry-Eintrag
Wenn man die Maschine regelmäßig im Netzwerk betreibt, aber die Anwendung auch funktionieren soll wenn sie vom Netz getrennt wird bzw. wenn das Netzwerk wegbricht, bietet sich ein Hack über die Registry an. Unter Windows 10 benötigt man dies allerdings grundsätzlich nicht, da dort auch bei nicht eingestecktem Lan-Kabel die Verbindung an die eigene IP-Adresse des Computers möglich ist. Bei XP hingegen ist das Netzwerk komplett tot, sobald man das Kabel aussteckt. Dort benötigt man den erwähnten Hack:
|
1 2 |
netsh interface ipv4 set global dhcpmediasense=disabled netsh interface ipv6 set global dhcpmediasense=disabled |
Mit folgenden Befehlen kann man das Ergebnis überprüfen:
|
1 2 |
netsh interface ipv4 show global netsh interface ipv6 show global |
Weitere Informationen: https://support.microsoft.com/de-de/help/239924/how-to-disable-the-media-sensing-feature-for-tcp-ip-in-windows
Achtung: Eventuell bewirkt dieser Registry-Eintrag noch weitere Dinge. Ich konnte nichts feststellen oder finden was beeinträchtigt worden ist. Allerdings sind die betroffenen Maschinen in meinem Fall auch manuell mit einer IP konfiguriert worden und bekommen diese nicht von einem DHCP-Server.
Lösungsmöglichkeit 3: Loopback-Adapter
Wenn man gar keine Netzwerkverbindung nach außen an der betroffenen Maschine benötigt, aber die Anwendung neben dem benötigten Laufwerk auch noch irgendwelche Dienste/Ports betreibt, die über das Netzwerk erreicht werden müssen, bietet es sich an einen sogenannten Loopback-Adapter zu installieren. Unter Windows XP benötigt man entweder diesen Adapter oder den Registry-Hack sobald das Netzwerkkabel ausgesteckt ist. Unter Windows 10 benötigt man ihn erst, wenn man den Netzwerkadapter komplett deaktiviert, denn ansonsten bekommt man zumindest nach dem nächsten Neustart auch dort eine solche Fehlermeldung:
Das Anpingen über den Rechnernamen funktioniert aber unter Windows 10 komischerweise trotzdem und zeigt auf die Standard-Loopback-Adresse 127.0.0.1.
