Immer noch Beschränkungen mit SMB (konkret: Installation/Ausführen von Programmen)?

[besterino]

Vor einiger Zeit (~Release Windows Server 2016) gab es das Phänomen, dass bestimmte Anwendungen sich nicht von einem Client über's auf SMB-Shares installieren/ausführen ließen, und zwar auch dann nicht, wenn die SMB-Share auf dem Client mit Laufwerksbuchstaben gemapped/gemounted war.

Konkret hatte ich das z.B. bei einigen Steam-Spielen. Entweder im Installer konnte man das Laufwerk schon nicht auswählen oder das ging noch (bzw. man hat es irgendwie brute-force rumgewurstelt/erzwungen) und dann startete das Spiel nicht. Woran das genau lag, habe ich seinerzeit nicht herausgefunden (aber auch nicht näher untersucht). Witzigerweise gab es diese Phänomene halt nicht bei allen Spielen. Mit iSCSI-Shares gibt es diese "Limitierung" naturgemäß nicht, darauf lässt sich alles installieren und ausführen. Nun hat aber SMB inzwischen einige Vorteile ggü. iSCSI bzw. macht einiges einfacher, weshalb ich überlege, noch einmal einen Anlauf zu starten. Wenn, ja nur wenn sich SMB-Shares aus Applikations-Sicht "wie ein lokaler Speicherplatz" nutzen lassen.

Bevor ich jetzt selbst also wieder tiefer in den Kaninchenbau krabbele, nur um am Ende herauszufinden, dass es diese "Beschränkungen" bei der Installation bzw. dem Ausführen von Anwendungen, die auf einem SMB-Share als Speicherort abgelegt werden sollen, immer noch gibt": weiss hier evtl. jemand mehr dazu? Insb. warum genau war das so und vor allem, hat sich das mittlerweile erledigt?

Exkurs 1: Habe zum Beispiel gesehen, dass sich inzwischen SMB-Shares auf Client-Seite "global" einbinden lassen (siehe hier unter 2.2) - wobei ich halt nicht weiss, ob das was bringt und mir auch noch unklar ist, ob das auch mit einem Windows Client-OS funktioniert. Das könnte eventuell helfen, um Rechte-/Account-Probleme beim Zugriff zu vermeiden (z.B. Share gemounted als "Administrator", Anwendung aufgerufen als "User" bzw. umgekehrt).

Exkurs 2: Wenn es diese Beschränkungen noch gibt, habe ich mir als möglichen Workaround ausgedacht, auf dem SMB-Share eine VHD(x) abzulegen und DIESE dann mit Laufwerkbuchstaben auf dem Client zu mounten. Das könnte aus OS-Sicht "strukturell näher dran sein" an einem physischen Laufwerk als vielleicht eine SMB-Share. Da wäre dann natürlich auch interessant, wie sich das performancemäßig verhält.

 

[passat3233]

Das liegt nicht an Windows oder SMB, sondern an den Anwendungen.
Der Installer ist so konfiguriert, das eine Installation auf Netzwerklaufwerken nicht zugelassen wird, egal, ob SMB oder z.B. NFS.
Dabei spielt es keine Rolle, ob das Netzwerklaufwerk einen Laufwerksbuchstaben zugewiesen bekommt oder nicht.
iSCSI ist aus Sicht von Windows kein Netzwerklaufwerk, sondern ein lokales Laufwerk.
Und deshalb geht da die Installation.

 

[besterino]

So einfach ist’s leider nicht. Es kann nicht nur am Installer liegen, sondern muss auch teilweise von den Programmen selbst bzw. dem Windows-Maschinenraum abhängen: selbst wenn man das einmal installierte Programm „as is“ z.B. auf ein SMB-Share verschiebt und dann auch Laufwerksbuchstaben entsprechend anpasst, funzte das trotzdem nicht. Und manchmal funzte das Programm auch nicht, obwohl der Installer ein SMB-Share als Ziel akzeptiert hatte. Das spricht meines Erachtens dafür, dass Windows SMB-Shares eben anders verwaltet und Applicationen Zugriff gewährt werden als „Blocklevel-Devices“.

Na, ich werd’s einfach mal wieder probieren.

 

[passat3233]

Naja, es kommt ganz drauf an, wie eine Anwendung programmiert ist.
Es gibt durchaus Anwendungen, die zuerst versuchen, aus einem Laufwerksbuchstaben einen UNC-Pfad zu ermitteln und dann arbeitet das Programm durchgängig mit dem UNC-Pfad und nicht dem Laufwerksbuchstaben.
Lokale UNC-Pfade sind auch grundsätzlich deutlich kürzer als UNC-Pfade von Netzwerkfreigaben und lassen sich eindeutig identifizieren.

 

[gea]

Es gibt in der Tat einige Programme die nicht auf Netzwerkshares laufen, entweder weil der Entwickler das nicht beachtet hat oder mit Absicht weil es "Pro/Server" Versionen gibt die das unterstützen.

Workaround ist wie bereis gesagt ein iSCSI Target. Das ist aus Windows Sicht eine lokale Festplatte.

 

[Trambahner]

Man kann ein SMB Share in Windows durchaus in einen Ordner mounten. eventuell hilft das.
mklink /d C:\Folder\ShareName \\Server\ShareName\Directory

Und dann kann man evtl. nochmals einen Layer drüberlegen z.B. mit SUBST/PSUBST ein Orderlevel höher ? Bissl schachteln und tricksen quasi . Erhöht natürlich die Komplexität und damit auch Fehleranfälligkeit.

 

[besterino]

Och… „lahm“ ist relativ würde ich sagen…

Von Client auf Server per SMB-Share via SMB-Direct (ohne großes Tuning):



Ist allerdings „etwas“ gefudelt: Ziel-„Storage“ war ne RAM-Disk. Wollte mal Storage als Bottleneck ausschließen…

 

[besterino]

Kenne ich - bei mir ist z.B. irgendwann der RAM-Cache auf dem Server voll und dann bricht die Performance z.T. ordentlich ein.