11
Per GPO zugriff auf lokales Verzeichnis sperren
Hallo!
Wir haben ein Programm, (dass leider nicht optimal programmiert ist, aber wir brauchen es...) welches fast jeder Rechner im Netzwerk installiert hat (ca. 300)
Nun ist ein Update fällig und das wurde schon 2x unterbrochen weil jemand das Programm geöffnet hat! Serverseitig können wir da nichts sperren, das gibt das Programm nicht her. Es greift auf eine Oracle9-DB auf unseren Unix-Server zu.
Meine Frage: Gibts es eine Möglichkeit den Nutzern per GPO das Recht auf z.B. C:\test zu nehmen (dort liegt das Programm; ein Teil lokal ein Teil serverseitig...)?
Wenn jemand eine andere gut und praktikable Lösung hat, immer her damit!
Danke schon mal!
Gruß
andi
Wir haben ein Programm, (dass leider nicht optimal programmiert ist, aber wir brauchen es...) welches fast jeder Rechner im Netzwerk installiert hat (ca. 300)
Nun ist ein Update fällig und das wurde schon 2x unterbrochen weil jemand das Programm geöffnet hat! Serverseitig können wir da nichts sperren, das gibt das Programm nicht her. Es greift auf eine Oracle9-DB auf unseren Unix-Server zu.
Meine Frage: Gibts es eine Möglichkeit den Nutzern per GPO das Recht auf z.B. C:\test zu nehmen (dort liegt das Programm; ein Teil lokal ein Teil serverseitig...)?
Wenn jemand eine andere gut und praktikable Lösung hat, immer her damit!
Danke schon mal!
Gruß
andi
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 82798
Url: https://administrator.de/contentid/82798
Ausgedruckt am: 25.11.2024 um 09:11 Uhr
11 Kommentare
Neuester Kommentar
Moin kann ja verstehen, das du zappelig bist, aber hol mal tief Luft zwischen den Zeilen...
Der Leser und Tippgeber wird dir das danken
Mach folgendes:
In der GPO sagst du, Explorer erst nach erfolgreichem Login starten.
Computer config / Admin Templates / System / Logon / run logon scripts synchronously
Das Updatescript legst du dann ins loginscript, das der User ausführt.
Der Leser und Tippgeber wird dir das danken
Mach folgendes:
In der GPO sagst du, Explorer erst nach erfolgreichem Login starten.
Computer config / Admin Templates / System / Logon / run logon scripts synchronously
Das Updatescript legst du dann ins loginscript, das der User ausführt.
Der Weg von Timo sollte funktionieren.
Falls du dennoch die Verzeichnisrechte mit GPO bearbeiten möchtest, schau mal unter
Computerkonfiguration / Windows-Einstellungen / Sicherheitseinstellungen / Dateisystem / Datei hinzufügen.
Falls du dennoch die Verzeichnisrechte mit GPO bearbeiten möchtest, schau mal unter
Computerkonfiguration / Windows-Einstellungen / Sicherheitseinstellungen / Dateisystem / Datei hinzufügen.
Hi,
Du kannst auch einfach mit taskkill das Programm schliessen und dann den Dateiaustausch durchführen.
So mach ich es bei unserer Softwareverteilung auch
Gruß Niko
Du kannst auch einfach mit taskkill das Programm schliessen und dann den Dateiaustausch durchführen.
So mach ich es bei unserer Softwareverteilung auch
Gruß Niko
viele Wege führen nach ReadOnlyMemory...
Du kannst den Weg gehen, der dir beschrieben wurde.
Du kannst das Update beim Rechnerstart in der GPO eintragen.
Du kannst vor dem aktualisieren den Link aus dem Startmenü löschen und erst bei vollendeter Aktualisierung wieder einfügen.
Du kannst die oracle Pfade deaktivieren und reaktivieren.
Nur mal der Vollständigkeit halber - owohl es ganz sicher noch einige Trampelpfade nach ROM gibt.
Du kannst den Weg gehen, der dir beschrieben wurde.
Du kannst das Update beim Rechnerstart in der GPO eintragen.
Du kannst vor dem aktualisieren den Link aus dem Startmenü löschen und erst bei vollendeter Aktualisierung wieder einfügen.
Du kannst die oracle Pfade deaktivieren und reaktivieren.
Nur mal der Vollständigkeit halber - owohl es ganz sicher noch einige Trampelpfade nach ROM gibt.
Hey Niko, ich hab zwar grade alle möglichen Trampelpfade beschrieben, aber einen Task, der "eventuell" gestartet ist oder auch nicht zu beenden - gehört ganz sicher zu den Kriechwegen
Taskkill, wer führt den aus? der User im Leben nicht - außer der hat Adminrechte...
Was passiert in deinem Fall, wenn der User "penetrant" ist und die Anwendung einfach nochmal startet?
Ebent.
Taskkill, wer führt den aus? der User im Leben nicht - außer der hat Adminrechte...
Was passiert in deinem Fall, wenn der User "penetrant" ist und die Anwendung einfach nochmal startet?
Ebent.
Immer schön einfach halt
Die Frage ist halt, ob man das Script nicht einfach schon in der Computerkonfiguration laufen lässt und so das Kopieren schon vor der Anmeldung durchlaufen wurde!?
Dann ist auch noch kein Programm vom User geöffnet.
Ansonsten ist ein taskkill mit einem sofortigen löschen der Dazei sicher schneller, als ein penetranter Benutzer.
Gruß Niko
Die Frage ist halt, ob man das Script nicht einfach schon in der Computerkonfiguration laufen lässt und so das Kopieren schon vor der Anmeldung durchlaufen wurde!?
Dann ist auch noch kein Programm vom User geöffnet.
Ansonsten ist ein taskkill mit einem sofortigen löschen der Dazei sicher schneller, als ein penetranter Benutzer.
Gruß Niko
Was passiert in deinem Fall, wenn der User "penetrant" ist und die Anwendung einfach nochmal startet?
Einfach per Logonscript ein Script starten, das schnell zyklisch prüft, ob ein entsprechender Prozess oder Task läuft. IF $programläuft THEN KILL $programm Ein passendes Beispielscript findet sich unter Application Watchdog selbst gemacht mit WSH. Ich lasse damit bzw. mit einer Abwandlung bei uns zum Beispiel alle 2 Minuten prüfen, ob eine nicht erlaubte Anwendung läuft. Und wenn ja schieße ich (bzw. das Script) sie ab. Das ist nämlich ein Nachteil von portable Applications - jeder kann alles mögliche mitbringen und starten.Manuel
Ui ui ui, so viele Antworten... 
Es ist so, dass zuerst ein Update am Server gemacht wird. Öffnet dann ein Benutzer das Programm: *peng* nochmal von vorn. Und die Updates sind leider kein Spaß...
Das Update dann am Client wird über eine eigene Updateroutine automatisch installiert (vom Programm-Hersteller)
Mit Taskkill wird es also nichts... Das müsste ich praktisch in Echtzeit prüfen.
Ich werd mal ein bisschen eure Vorschläge testen und dann geb ich bescheid...!
Es ist so, dass zuerst ein Update am Server gemacht wird. Öffnet dann ein Benutzer das Programm: *peng* nochmal von vorn. Und die Updates sind leider kein Spaß...
Das Update dann am Client wird über eine eigene Updateroutine automatisch installiert (vom Programm-Hersteller)
Mit Taskkill wird es also nichts... Das müsste ich praktisch in Echtzeit prüfen.
Ich werd mal ein bisschen eure Vorschläge testen und dann geb ich bescheid...!
Du könntest ja auch einfach das Verzeichnis oder die ausführbare Datei umbenennen. Dann läßt sich auch nichts mehr starten. Wenn du dazu ein kleines Script mit PSExec schreibst hast du die Umbenennung auf allen Rechnern mit einem Doppelklick und etwas Wartezeit erledigt. Danach solltest du in aller Ruhe deine Updates machen können. Im Anschluss daran auf dem gleichen Weg alles wieder in den Ausgangszustand versetzen. Fertig.
Manuel
Manuel
Hi,
mit den Infos - die wir jetzt haben - ist wohl keiner der bisher beschriebenen Wege sinnvoll...
Überlege mal, ob dir dieser Weg gefallen kann....
Den Link, mit dem die User die Anwendung starten, versteckst du und stelllst ihnen stattdessen folgende Batch zur Verfügung:
Jetzt mußt du nur dafür sorgen dass diese "update.ini" immer dann in der Freigabe vorhanden ist, wenn das Update gerade läuft und diese Batch anstelle des Links ins Startmenü kopieren.
@ Manuel: naja das Verzeichnis umbenennen, wird komplifiziert, denn die Updateroutine muß in der zwischenzeit laufen und an die Möglichkeit, dass sich jemand schon / noch angemeldet hat, bevor das Update gestartet ist - müßte man[n] auch noch denken.....
Ps: Mittlerweile sind wir Meilenweit von der Überschrift entfernt - kommen aber der Lösung immer näher
mit den Infos - die wir jetzt haben - ist wohl keiner der bisher beschriebenen Wege sinnvoll...
Überlege mal, ob dir dieser Weg gefallen kann....
Den Link, mit dem die User die Anwendung starten, versteckst du und stelllst ihnen stattdessen folgende Batch zur Verfügung:
:check4update
@cls
@color fc
@if exist \\softwareserver\update.ini >nul echo "Bitte einen Augenblick Geduld - die Anwendung wird gerade aktualisiert"
@if exist \\softwareserver\update.ini >nul goto check4update
@if not exist \\softwareserver\update.ini >nul "c:\meineanwendung\start.lnk
exitJetzt mußt du nur dafür sorgen dass diese "update.ini" immer dann in der Freigabe vorhanden ist, wenn das Update gerade läuft und diese Batch anstelle des Links ins Startmenü kopieren.
@ Manuel: naja das Verzeichnis umbenennen, wird komplifiziert, denn die Updateroutine muß in der zwischenzeit laufen und an die Möglichkeit, dass sich jemand schon / noch angemeldet hat, bevor das Update gestartet ist - müßte man[n] auch noch denken.....
Ps: Mittlerweile sind wir Meilenweit von der Überschrift entfernt - kommen aber der Lösung immer näher
Ich hatte das so verstanden, dass der Client lokal liegt (der OP schrieb ja als Beispiel c:\test). Was sollte also dagegen sprechen für die Dauer des Updates das Verzeichnis in c:\test_update umzubenennen. Meinetwegen könnte man es gleichzeitig auch noch verstecken, damit nicht ein findiger User auf die Idee kommt die EXE von dort zu starten. Jegliche Verknüpfungen zum Client laufen dann ins Leere und produzieren eine Fehlermeldung. Wenn es schöner sein soll könnte auch einfach die EXE umbenannt werden in programm_update.exe und temporär durch eine anderes File ersetzt werden. Dieses bringt dann einen entsprechenden Hinweis auf den Bildschirm.
Ob schon ein User angemeldet ist, ist für das umbenennen des Verzeichnisse bzw. der Datei ja unerheblich. Es muss lediglich sichergestellt sein, dass weder das Verzeichnis noch die Dateien darin gerade im Zugriff sind. Das wiederum sollte man über remotes beenden der Anwendung per Script in den Griff bekommen können - alles eine Frage der Reihenfolge. Per Script mit PSExec
Manuel
Ob schon ein User angemeldet ist, ist für das umbenennen des Verzeichnisse bzw. der Datei ja unerheblich. Es muss lediglich sichergestellt sein, dass weder das Verzeichnis noch die Dateien darin gerade im Zugriff sind. Das wiederum sollte man über remotes beenden der Anwendung per Script in den Griff bekommen können - alles eine Frage der Reihenfolge. Per Script mit PSExec
- laufendes Programm per Script beenden
- Programm-Datei umbenennen und durch Fake ersetzen
- Update am Server ausführen
- Fake löschen und Programm-Datei zurück umbenennen
- Programm starten um Client-Update anzustoßen
Manuel
