Terminalserver .ini Datei unter C:Windows

Guten Abend zusammen

Ich habe mir hier einen Server 2012R2 Terminalserver zum Testen aufgesetzt. Ich habe dann unsere alte Businesssoftware über GPO Installiert (ist eine MSI Datei)

Diese braucht unter C:\Windows\ eine ini Datei die Angibt, wo die Datenbank davon gespeichert ist (muss nach der Installation geschehen). Nun laufe ich aber in das Problem, dass ein User der sich über RDP Anmeldet nicht die ini aus C:\Windows hernimmt, sondern anscheinen von wo anderst. Dabei kann ich aber nicht feststellen von wo.

So eine kurz Recherche hat für mich ergeben, dass anscheinend bei RDP Servern pro User ein C:\Windows angelegt wird?? Aber bin da nicht ganz schlau drauß geworden.

Könntet ihr mir sagen, wie ich Windows dazu zwingen kann, dass ein RDP User auf Dateien unter C:\Windows zugreifen kann?

Vielen Dank!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 315738

Url: https://administrator.de/forum/terminalserver-ini-datei-unter-c-windows-315738.html

Ausgedruckt am: 22.12.2024 um 23:12 Uhr

8 Kommentare

Neuester Kommentar

Hi

das mit dem jeder User hat ein Windows höre ich jetzt auch zum ersten mal ... das ist Unsinn. Jeder User hat ein Benutzerprofil. Mehr nicht.

Die Frage ist, ob das Programm hart in C:\Windows nach seiner INI sucht oder ob es sich an einer Variable wie %PATH% orientiert.

Such doch einfach nach dem dateinamen der INI auf der Festplatte.

cmd.exe
cd\
dir /s deine.ini

Eine Möglichkeit wären auch Netzlaufwerke, die irgendwie in die %PATH% aufgenommen wurden

Hallo

doch gibt es.
In Verbindung mit der Benutzerkontensteuerung werden INI-Dateien im Windows-Verzeichnis verschoben.
c:\users\Benutzername\AppData\Local\VirtualStore\Windows

Dazu gibt es auch eine Umleitung für 32 Bit Programme unter 64 Bit OS.

Stefan

Hi,
wenn der Benutzer ein Homedirectory hat, dann wird bei Anmeldung am Terminalserver dort ein Windows-Verzeichnis erstellt. Dort landen dann auch die benutzerbezogenen INIs.
Selbst wenn man nur computerbezogene INIs hat, kann es sein, dass die Anwendung die Standard-APIs für das Behandeln von INIs, welches vom Windows selbst kommen, benutzt, und deshalb im Homedirectory sucht.
Abhilfe schafft also, diese INI in die benutzerbezogenen Windows-Verzeichnisse im Homedirectory zu kopieren.
Oder:
Wenn das Erstellen/Bearbeiten der INI nicht schon beim Setup erfolgt, sondern erst beim ersten Start der Anwendung:
CMD starten

change user /install

Anwendung als Administrator starten, alle Konfigurationseinstellungen, welche für alle Benutzer gelten sollen, vornehmen.
Anwendung schließen

change user /execute

Jetzt sollten auch die Änderungen an den INIs und im HKCU aufgezeichnet sein. Bei nächster Anmeldung der anderen Benutzer bekommen sie diese Änderungen in ihre Kopen der INIs bzw. in ihre HKCU-Schlüssel geschrieben.

E.

man lernt nie aus ...

Moin,
alternativ zu Kollege @emeriks kannst du Virtual Store über die Lokalen Sicherheitsrichtlinien deaktivieren. Haben wir hier schon öfters so gemacht, weil's einfacher ist.

Solange die INI nur gelesen wird, sehe ich da kein Problem.

Gruß,
Dani

Für Interessierte steht hier noch mehr zu emeriks Gedanken. Normalerweise sind aktuelle Anwendungen immer tsaware und brauchen deshalb kein change user mehr: https://helgeklein.com/free-tools/istsawareapp/ - mit dem verlinkten Tool kannst Du deine alte Anwendung testen.

Vielen Dank an alle für die Hilfe. Das mit dem Change User, habe ich gestern noch gefunden. Muss ich nacher mal Austesten.

Das mit dem Virtual Store habe ich bereits vor ein paar Jahren gefunden, das war auch hier wieder meine erste Vermutung, aber leider nicht der Fall... War damals ein ziemlicher Kampf, da man nicht genau wusste warum es sich so benimmt.

@DerWoWusste
Danke für das Tool! Muss wohl Change User verwenden, da sie nicht TsAware ist.

Werde berichten

Tante Edit: Funktioniert wunderbar mit Change User. Vielen Dank!