none
Dateizugriffe je Benutzer in RDP umleiten (sonst File access denied) RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    auf einem Windows Server arbeiten mehrere Personen gleichzeitig über den Remote Desktop. Jetzt benötigen wir dringend eine ältere Software, die leider hardcoded in einem Verzeichnis C:\FOO\ etwas schreiben möchte. Das klappt bei mehr als einem gleichzeitigen Benutzer leider nicht mehr, da es dann nur noch "File access is denied" Meldungen regnet.

    Jetzt habe ich schon überlegt wie man das lösen könnte. Wenn man z.B. für einzelne Benutzer eigene Links für Verzeichnisse setzen könnte wäre das praktisch. Gibt es dafür eventuell irgendwelche Lösungen? 

    Danke

    Donnerstag, 4. Mai 2017 14:51
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Ist halt die Frage, ob die Altsoftware damit zurechtkommt:

    Jeder User hat normalerweise irgendwelche Netzwerklaufwerke.
    Wenn nicht, kann man per "subst" ein Laufwerk erstellen.
    Dieses Laufwerk erstellt man dann beim Login userspezifisch.
    Beispiel: subst N: %appdata%
    In %appdata% legst du das Verzeichnis FOO noch an.
    Nun erstellst du noch einen Link mit
    mklink /D C:\FOO N:\FOO
    Da N jedesmal ein anderer Pfad ist, wäre C:\FOO ebenso userspezifisch.
    Bei mir hat es zumindest funktioniert, wenn ich "N:" eine anderen Pfad zuweise.

    Donnerstag, 4. Mai 2017 16:35
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Moin,

    wenn ihr App-V (ThinApp, ...) Know-How greifbar habt, wäre das vermutlich die Lösung. Ansonsten habt ihr mit C:\ vermutlich verloren.

    Oder ihr findet einen Weg, Windows auf einem anderen Buchstaben zu installieren und C: als Netzlaufwerk zu mappen.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    Donnerstag, 4. Mai 2017 15:16
    |
  • Question
    Anmelden
    1
    Anmelden

    Ist halt die Frage, ob die Altsoftware damit zurechtkommt:

    Jeder User hat normalerweise irgendwelche Netzwerklaufwerke.
    Wenn nicht, kann man per "subst" ein Laufwerk erstellen.
    Dieses Laufwerk erstellt man dann beim Login userspezifisch.
    Beispiel: subst N: %appdata%
    In %appdata% legst du das Verzeichnis FOO noch an.
    Nun erstellst du noch einen Link mit
    mklink /D C:\FOO N:\FOO
    Da N jedesmal ein anderer Pfad ist, wäre C:\FOO ebenso userspezifisch.
    Bei mir hat es zumindest funktioniert, wenn ich "N:" eine anderen Pfad zuweise.

    Donnerstag, 4. Mai 2017 16:35
    |
  • Question
    Anmelden
    0
    Anmelden

    > mklink /D C:\FOO N:\FOO

    Das geht IMHO sogar mit %userprofile% oder %appdata%, also ohne Netzlaufwerk :)

    Montag, 8. Mai 2017 15:44
    |
  • Question
    Anmelden
    1
    Anmelden

    > mklink /D C:\FOO N:\FOO

    Das geht IMHO sogar mit %userprofile% oder %appdata%, also ohne Netzlaufwerk :)

    EDIT: Nein, das mit dem Symlink geht NICHT. Gerade ausprobiert, das Objekt ist global, und der zweite User kann kein zweites mit dem gleichen Namen erstellen.

    Ich hatte also doch Recht ;-)

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    Montag, 8. Mai 2017 16:22
    |
  • Question
    Anmelden
    0
    Anmelden

    Der mklink ist permanent und braucht nicht ständig neu erstellt werden!
    Er verweist ja auf ein Laufwerk, dass eben je User individuell auf einen anderen Pfad verweist (echtes Netzlaufwerk oder eben subst).
    Eben dadurch erhält das Link-Verzeichnis immer ein anderes Ziel.
    Du benötigst also nur den Link auf C und bei der Anmeldung immer ein Laufwerk mit dem individuellen Pfad.
    Klar verbrätst du damit einen Laufwerksbuchstaben. Aber ggf. haben die meisten sowieso ein individuelles Laufwerk auf zentral abgelegte aber private Dokumente.

    Montag, 8. Mai 2017 18:52
    |
  • Question
    Anmelden
    0
    Anmelden
    Das stand ja auch so in meinem Beispiel;-).
    Montag, 8. Mai 2017 18:55
    |
  • Question
    Anmelden
    1
    Anmelden

    Ja, das stimmt, mit einem Zwischenschritt über einen Drive funktioniert das sogar.

    Aber boah, würde es mir widerstreben, so etwas auf täglicher Basis zu supporten. Solche Drecks-Applikationen sind ja in der Regel auch noch wichtig... Und Wehe, SUBST ist in der aktuellen Sitzung (noch) nicht gelaufen, und die Applikation startet schon - gleich gibt es ein Ticket...

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    Montag, 8. Mai 2017 19:15
    |
  • Question
    Anmelden
    0
    Anmelden

    Warum meinst du, dass Microsoft den Pfad "ProgramData" erfunden hat?
    Weil es immer noch viele "DrecksApps" gibt, die wichtige Daten in ihrem Programmverzeichnis verwalten und nun von Windows nach ProgramData umgeleitet werden.

    Schau dir mal das Verzeichnis an, dann weißt du wievele Programme das so sind.
    Normalerweise ist dafür %APPDATA% oder %LOCALAPPDATA% zu verwenden.

    Dienstag, 9. Mai 2017 06:45
    |
  • Question
    Anmelden
    1
    Anmelden

    > mklink /D C:\FOO N:\FOO

    Das geht IMHO sogar mit %userprofile% oder %appdata%, also ohne Netzlaufwerk :)

    EDIT: Nein, das mit dem Symlink geht NICHT. Gerade ausprobiert, das Objekt ist global, und der zweite User kann kein zweites mit dem gleichen Namen erstellen.

    Du hast "bedingt" recht - ich krieg die Umgebungsvariable zwar mit Escaping (^%) in den Linkpfad rein, aber NTFS kann es nicht auflösen, da die Symlinks im Dateisystem aufgelöst werden müssen, nicht im Explorer. Und das Dateisystem weiß natürlich nix von %appdata%.

    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    Dienstag, 9. Mai 2017 08:23
    |
  • Question
    Anmelden
    0
    Anmelden

    Es ging ja nicht darum, dass der Link selber eine dynamsiche Adresse enthält.
    %-Variablen werden normalerweise zur Ausführungszeit direkt aufgelöst.
    Der Linkpfad selber wird dann später "as is" verwendet, vergleichbar auch mit dem Setzen in einfache Hochkommata. Dies ist durch ggf. vorhandene Leerzeichen auch erforderlich.
    Das Ganze funktioniert eben nur dadurch, dass das Ziel des Links dynamisiert wird und das geht (leider) nur durch Laufwerkszuordnungen.

    Somit muss man zum Anmeldezeitpunkt oder bei Bedarf (Script) das Ziel erstellen, so dass der statische Link dann greift.

    Dienstag, 9. Mai 2017 10:03
    |