Rechte in C:\Program Files (x86)

[ChrisRa 42]

Hallo liebe Gemeinde,

 

ich habe hier eine Software die lt. FAQ-o-Matic den sogenannten T.R.O.S.T-Preis verdient hätte.

Problem an der Geschichte ist, dass diese Software alle 1-2 Monate schreibrecht auf:

- C:\Program Files (x86)\

sowie

- C:\Program Files (x86)\Common Files\
benötigt, um Updates durchzuführen.

 

Um dieses Problem zu lösen habe ich mir gedacht, ich gebe den jeweiligen Benutzern möglichst granulare Rechte. Ich habe Ihnen diese Rechte nun mittels GPO eingeräumt.

Der Software scheint es allerdings egal zu sein.

Rein technisch vergleicht die Software die Prüfsumme zwischen den beiden Programmdateien (alt/neu). Wenn diese sich unterscheidet, wird die alte Datei von der neuen überschrieben (von einem Netzwerkshare).

 

Ich selber kann in den Pfaden ohne UAC hin- und her kopieren. Warum kann das Programm es nicht?

Gibt's hier was besonderes zu beachten? BS: Windows 10

 

Ich danke euch!

 

Grüße

[Sunny61 807]

Kann es denn sein, dass das Programm bzw. der Updatetask unter einem anderen Benutzer läuft? Wenn ja, dann mußt Du diesem Benutzer auch noch die passenden Rechte geben.

Möglicherweise hat die SW ja auch keine Rechte auf dem Netzwerkshare. Lass auch mal bei so einem Updatetask den Process Monitor mitlaufen, anschließend nach ACC DENIED filtern.

 

NTFS-Berechtigungen auf Dateisystemebene vergibst Du im Computerteil der GPPs, hast Du auch den richtigen Teil getroffen? Rechtsklick auf das Programmverzeichnis > Eigenschaften > Sicherheit. Kommen hier die aktuellen neuen Berechtigungen an? Wenn ja, führe in einer administrativen Commandline den Befehl aus:

 

gpupdate /target:computer [ENTER]

Funktioniert es jetzt?

[ChrisRa 42]

Hey Sunny61,

 

danke für deine schnelle und ausführliche Hilfe. Die Berechtigungen kommen an. Den Procmon habe ich auch schon nebenher laufen lassen.

Ich habe gerade im %TEMP% einen Log gefunden.

"... kann nicht entregistriert werden"

 

Ist ziemlich eindeutig würde ich sagen. Habe den Softwarehersteller nun nach den Schlüsselstrukturen gefragt, auf welchen der Anwender Berechtigungen haben muss.

 

Ich melde mich.

[Daniel -MSFT- 129]

Klingt so, als wenn eine DLL (oder OCX) entregistriert und eine neue registriert werden soll. Dafür braucht man erhöhte Rechte. Kannst Du die Anwendung nicht separat verteilen?

[NilsK 2.957]

Moin,

 

nur zur Ergänzung: Der Preis war von Mark (gruppenrichtlinien.de), nicht von mir. ;)

 

Gruß, Nils

[ChrisRa 42]

Klingt so, als wenn eine DLL (oder OCX) entregistriert und eine neue registriert werden soll.

 

Ja, es werden scheinbar OCX entregistriert und die neuen wieder registriert. Gibt's eine elegante Lösung, ohne dem User gleich Adminrechte zu geben?

 

 

 

nur zur Ergänzung: Der Preis war von Mark (gruppenrichtlinien.de), nicht von mir. ;)

 

Tatsache, dann habe ich das wohl verwechselt.

[Sunny61 807]

Ja, es werden scheinbar OCX entregistriert und die neuen wieder registriert. Gibt's eine elegante Lösung, ohne dem User gleich Adminrechte zu geben?

Du kannst dir den WSUS Package Publisher in Kombination mit dem WSUS anschauen. http://www.wsus.de/wpp Somit würdest Du eingebaute Technik benutzen um 3rd Party Software auf Clients installieren zu lassen.

 

EDIT: Beim WPP wäre vermutlich das Custom Update das Mittel der Wahl für dich. Die SW kann ja wahrscheinlich nur aktualisiert werden, wenn der Benutzer *NICHT* damit arbeitet, oder? Wenn ja, dann kannst Du mit Hilfe des Custom Update natürlich auch das Programm bzw. den Prozess beenden lassen, den Benutzer darüber *vorher* informieren und anschließend das Update installieren. Die Installation erfolgt im SYSTEM-Kontext, also mit den passenden Zugriffsberechtigungen.

bearbeitet 20. Oktober 2015 von Sunny61

[ChrisRa 42]

Das Problem ist, dass die Software einen "Programmstarter" mitgeliefert bekommt. Die Updates werden vor dem Programmstart durch den Starter verarbeitet.

Eine Dokumentation, welche Datei wie und wo bearbeitet wird, wird nicht ausgeliefert.

Ich habe mal vorgeschlagen, dass sie eventuell msi Pakete schnüren.

Damit wäre anderen Kunden wahrscheinlich auch geholfen.

 

Nach jedem Update Stunden an dem WPP rumzubasteln ist für mich leider keine Lösung. Zumal ich ja auch noch herausfinden muss, welche Dateien wie und wo geändert werden.

 

Das heißt dann wohl Turnschuh-Administration oder Adminrechte für jedermann. Dann aber lieber den Turnschuh und hoffnungsvoll auf msi-Pakete warten.

[Sunny61 807]

Hmm, was sagt eigentlich der Hersteller zu der ungewöhnlichen Art des Updates? Ist das SAP?

bearbeitet 20. Oktober 2015 von Sunny61

[ChrisRa 42]

Nee, ist nicht SAP. Eher ein kleines Softwarehaus, welches Branchenlösungen programmiert.

 

Der Hersteller liefert ein kleines Zusatzprogramm mit aus. Ich habe mich nicht großartig damit auseinandergesetzt. Das einzige was ich mitgekriegt habe ist, dass der Starter dann mit einem Konto ausgeführt wird, welches über lokale Adminrechte verfügt. Dazu wird das Adminkonto mitsamt Passwort in eine Textdatei geschrieben und das Passwort selbstverständlich verschlüsselt (jaja, blabla).

 

Und zu guter Letzt muss die UAC abgeschaltet werden.

 

Nein danke.

[Sunny61 807]

Uiui, welch eine Krücke. Tja, was kannst Du dagegen unternehmen? Vermutlich nichts. Weise den Verantwortlichen in eurer Firma schriftlich auf den Fehler hin, mehr kannst Du vermutlich nicht machen. Den Mehraufwand kannst Du noch versuchen zu beziffern, dann war es für dich auch schon.

bearbeitet 20. Oktober 2015 von Sunny61

[ChrisRa 42]

Die Anwendung wird glücklicherweise zu 95% auf dem Terminalserver verwendet. Die Restlichen 20 Clients mache ich dann lieber per Hand.

 

Danke für eure Ratschläge!