Zum Inhalt wechseln


Foto

Rechte in C:\Program Files (x86)


  • Bitte melde dich an um zu Antworten
11 Antworten in diesem Thema

#1 ChrisRa

ChrisRa

    Senior Member

  • 411 Beiträge

 

Geschrieben 19. Oktober 2015 - 11:39

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


Keep IT simple.  ;)


#2 Sunny61

Sunny61

    Expert Member

  • 22.101 Beiträge

 

Geschrieben 19. Oktober 2015 - 12:04

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?
Gruppenrichtlinien: http://www.gruppenrichtlinien.de/

#3 ChrisRa

ChrisRa

    Senior Member

  • 411 Beiträge

 

Geschrieben 19. Oktober 2015 - 12:12

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.


Keep IT simple.  ;)


#4 Daniel -MSFT-

Daniel -MSFT-

    Expert Member

  • 2.434 Beiträge

 

Geschrieben 19. Oktober 2015 - 18:22

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?

.: Daniel Melanchthon :.

 

Ich arbeite für die Microsoft Deutschland GmbH.

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität.

 

Hinweis zur Rechtsverbindlichkeit dieser Informationen

Diese Informationen sind Hinweise, die das Verständnis hinsichtlich der Microsoft Produktlizenzierung verbessern sollen. Microsoft weist ausdrücklich darauf hin, dass diese Informationen keinen rechtsverbindlichen Charakter haben, sondern als erklärende Informationen zu verstehen sind. Die einzig rechtsverbindlichen Lizenzinformationen sind in den entsprechenden Endnutzer-Lizenzverträgen (als Beilage zu Softwarepaketen oder in Form von Lizenzverträgen) zu finden.


#5 NilsK

NilsK

    Expert Member

  • 12.334 Beiträge

 

Geschrieben 19. Oktober 2015 - 18:53

Moin,

 

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

 

Gruß, Nils


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#6 ChrisRa

ChrisRa

    Senior Member

  • 411 Beiträge

 

Geschrieben 20. Oktober 2015 - 06: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.


Keep IT simple.  ;)


#7 Sunny61

Sunny61

    Expert Member

  • 22.101 Beiträge

 

Geschrieben 20. Oktober 2015 - 08:03

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 von Sunny61, 20. Oktober 2015 - 09:02.

Gruppenrichtlinien: http://www.gruppenrichtlinien.de/

#8 ChrisRa

ChrisRa

    Senior Member

  • 411 Beiträge

 

Geschrieben 20. Oktober 2015 - 11:15

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.


Keep IT simple.  ;)


#9 Sunny61

Sunny61

    Expert Member

  • 22.101 Beiträge

 

Geschrieben 20. Oktober 2015 - 11:49

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

Bearbeitet von Sunny61, 20. Oktober 2015 - 11:49.

Gruppenrichtlinien: http://www.gruppenrichtlinien.de/

#10 ChrisRa

ChrisRa

    Senior Member

  • 411 Beiträge

 

Geschrieben 20. Oktober 2015 - 13:15

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.


Keep IT simple.  ;)


#11 Sunny61

Sunny61

    Expert Member

  • 22.101 Beiträge

 

Geschrieben 20. Oktober 2015 - 13:51   Lösung

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 von Sunny61, 20. Oktober 2015 - 14:11.

Gruppenrichtlinien: http://www.gruppenrichtlinien.de/

#12 ChrisRa

ChrisRa

    Senior Member

  • 411 Beiträge

 

Geschrieben 20. Oktober 2015 - 14:09

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!


Keep IT simple.  ;)