24
User benötigt Admin-Rechte für Programm-Update
Morgen!
Ich komm jetzt mit einer blöden Frage, aber ich steh irgendwie gedanklich auf dem Schlauch.
Wir haben hier ein Programm, das immer wieder aktualisiert werden muss. Von den Usern.
Aber das Dings braucht Adminrechte.
Wie löse ich das am einfachsten? Wer schubst mich mal an?
k.
Ich komm jetzt mit einer blöden Frage, aber ich steh irgendwie gedanklich auf dem Schlauch.
Wir haben hier ein Programm, das immer wieder aktualisiert werden muss. Von den Usern.
Aber das Dings braucht Adminrechte.
Wie löse ich das am einfachsten? Wer schubst mich mal an?
k.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671909
Url: https://administrator.de/forum/user-benoetigt-admin-rechte-fuer-programm-update-671909.html
Ausgedruckt am: 17.04.2025 um 09:04 Uhr
24 Kommentare
Neuester Kommentar
Moin,
ich pesönlich hab diese Variante hier <link> für Updates von UPS Worldship im Einsatz.
Ist sicherlich anpassbar auf andere Gegebenheiten.
Gruß
aXas
ich pesönlich hab diese Variante hier <link> für Updates von UPS Worldship im Einsatz.
Ist sicherlich anpassbar auf andere Gegebenheiten.
Gruß
aXas
Moin,
was für ein Programm?
https://chocolatey.org/ bietet viele Standard Apps. Startup-Script unter SYSTEM z.B. liefert dann alle rechte.
Ansonsten könnte man noch MSI Pakte bauen und es via GPO verteilen. Wir nutzen im Moment zu 99% choco für alles.
Oder wo ist das Problem? Kann die Software nicht mit mehreren Profile umgehen? Installation als SYSTEM oder Administrator läuft natürlich dann in dessen Kontext ab. Oder wie darf ich deine Frage verstehen?
mfg Crusher
was für ein Programm?
https://chocolatey.org/ bietet viele Standard Apps. Startup-Script unter SYSTEM z.B. liefert dann alle rechte.
Ansonsten könnte man noch MSI Pakte bauen und es via GPO verteilen. Wir nutzen im Moment zu 99% choco für alles.
Oder wo ist das Problem? Kann die Software nicht mit mehreren Profile umgehen? Installation als SYSTEM oder Administrator läuft natürlich dann in dessen Kontext ab. Oder wie darf ich deine Frage verstehen?
mfg Crusher
Moin
Was ich prüfen würde, wäre, ob sich das Programm in Usersapce oder einen Pfad der für User beschreibbar ist installieren lässt. Dann sollte es auch ohne Adminrechte gehen.
Alternativ würde ich prüfen, ob es reicht. den Usern Scheibrecht für das Installationsverzeichnis unterhalb von "Programme" zu geben.
Oder gleich den Hersteller treten. Damit er einen Dienst für die Updateprozedur bereitstellt.
lks
PS: wie heißt denn das ominöse Programm? Vielleicht kann man da bessere Tipps geben.
Was ich prüfen würde, wäre, ob sich das Programm in Usersapce oder einen Pfad der für User beschreibbar ist installieren lässt. Dann sollte es auch ohne Adminrechte gehen.
Alternativ würde ich prüfen, ob es reicht. den Usern Scheibrecht für das Installationsverzeichnis unterhalb von "Programme" zu geben.
Oder gleich den Hersteller treten. Damit er einen Dienst für die Updateprozedur bereitstellt.
lks
PS: wie heißt denn das ominöse Programm? Vielleicht kann man da bessere Tipps geben.
1
Die Software ist eher ein Stück Sch... Die gute Dame aus HR hat es sich aber eingebildet. Das war zum installieren auf dem Server schon eine Katastrophe. Ich war da eher nur als Beisteher dabei (weil ist ja HR und ich darf da die Daten nicht sehen).
Ist quasi vergleichbar wie Firefox. Der wollte doch eine Weile für das Update auch immer Adminrechte.
Hm....lokaler Admin auf den Clients vielleicht.
Ist quasi vergleichbar wie Firefox. Der wollte doch eine Weile für das Update auch immer Adminrechte.
Hm....lokaler Admin auf den Clients vielleicht.
Hm...Userspace hört sich gangbar aus. Müsste ich mal probieren.
Das Dings schimpft sich spdata.
Mit denen hatte ich von Beginn an Probleme. Installation ging komplett über die. Die forderten eigenen Application-Server und einen weiteren für den SQL. Natürlich bekamen die es nicht hin und da wurde dann doch der SQL auf den Application-Server installiert.
Irgendwann dann mal eine Nachfrage von mir (übles Ticketsystem) wie ich denn den (damals verwendeten) W2k16 auf W2k19 bzw. W2k22 mit ihrem Programm heben könnte, bzw. wie es sich bei Inplace-Upgrade verhält. Nach mehreren Wochen kam dann die Antwort, das wissen sie nicht, Anleitung oder so haben sie nicht aber sie bieten an, das Dings wieder komplett neu zu installieren und dann die Clients konfigurieren. Natürlichg gegen volle Bezahlung.
Ich hab dann abgelehnt und hab inplace auf W2k19. W2k22 gabs damals noch keine Kompatibilitätsfreigabe.
Sorry für den Rant, aber ich kann die nicht ab.
Das Dings schimpft sich spdata.
Mit denen hatte ich von Beginn an Probleme. Installation ging komplett über die. Die forderten eigenen Application-Server und einen weiteren für den SQL. Natürlich bekamen die es nicht hin und da wurde dann doch der SQL auf den Application-Server installiert.
Irgendwann dann mal eine Nachfrage von mir (übles Ticketsystem) wie ich denn den (damals verwendeten) W2k16 auf W2k19 bzw. W2k22 mit ihrem Programm heben könnte, bzw. wie es sich bei Inplace-Upgrade verhält. Nach mehreren Wochen kam dann die Antwort, das wissen sie nicht, Anleitung oder so haben sie nicht aber sie bieten an, das Dings wieder komplett neu zu installieren und dann die Clients konfigurieren. Natürlichg gegen volle Bezahlung.
Ich hab dann abgelehnt und hab inplace auf W2k19. W2k22 gabs damals noch keine Kompatibilitätsfreigabe.
Sorry für den Rant, aber ich kann die nicht ab.
Als letzter Ausweg ein Skript erstellen das, das Update durchführt und dieses als Aufgabe einrichten. Aufgaben können mit Adminrechten gestartet werden, so dann auch das Skript. Und man kann zusätzlich Aufgaben so einrichten, dass normale Benutzer diese Aufgaben starten dürfen.
Ja, ich muss mir das alles mal durchdenken.
Tatsächlich wär mir ein Update-Dienst am liebsten. Von mir aus auch auf den Client-Rechnern. Dann leg ich den einmalig an und gut is.
Ich befürchte aber, dass die das nicht hinkriegen (wollen).
Skript würde auch....aber ist halt alles K, wenn du irgendwo Admin für ein einfaches Update brauchst, das dann aber auch alle paar tage ansteht.
Tatsächlich wär mir ein Update-Dienst am liebsten. Von mir aus auch auf den Client-Rechnern. Dann leg ich den einmalig an und gut is.
Ich befürchte aber, dass die das nicht hinkriegen (wollen).
Skript würde auch....aber ist halt alles K, wenn du irgendwo Admin für ein einfaches Update brauchst, das dann aber auch alle paar tage ansteht.
Ich hänge mich hier mal ran, wir haben ebenfalls SP_Data im Einsatz und mich nervt es ebenfalls, dass die Benutzer Adminrechte für die Installation des Updates benötigen. Bisher bin ich aber zu faul gewesen, diesbezüglich bei denen ein Ticket zu schreiben.
Bei meinem alten Brötchengeber hatten wir auch SP_Data im Einsatz.
Ein Graus.....
Wir haben das nur noch über RDS angeboten und dort per Hand aktualisiert.
SP_Data hatte damals aber nicht so oft Updates herausgegeben, öfters war da Perfidia dran.
Ein Graus.....
Wir haben das nur noch über RDS angeboten und dort per Hand aktualisiert.
SP_Data hatte damals aber nicht so oft Updates herausgegeben, öfters war da Perfidia dran.
Ein "Update-Dienst" - das ist im Allgemeinen eine Lösung, die ein Endpunkt verwalten kann, z.B. MS Intune. Oder man kauft kommerzielle Produkte, die dann auch mehr können. Wenn man da eine "sch..." Software hat, die kein Update-Mechanismus hat und umständlich geupdated werden muss, kommt man um eine kommerzielle Lösung oder manuelles PowerShell-Skripting nicht herum.
Zitat von @Seborted:
Bisher bin ich aber zu faul gewesen, diesbezüglich bei denen ein Ticket zu schreiben.
Bisher bin ich aber zu faul gewesen, diesbezüglich bei denen ein Ticket zu schreiben.
Ich wollte gerade eins schreiben und hätte mir von denen eben einen Dienst gewünscht. Nuja. Es wurde mal wieder mein Benutzeraccount gelöscht (wahrscheinlich wegen Inaktivität). Ich hab jetzt nicht mal mehr einen Ansprechpartner von dem ich den Benutzeraccount wieder eingerichtet bekomme. Die Dame, die das letztes mal gemacht hat, als ich mien Account mal wieder verschwunden war, arbeitet dort nicht mehr.
Aber schön zu hören, dass es da auch Leidensgenossen gibt.
Hat da wer eine Empfehlung? Kann das Chocolatey? Ich hab mir das noch nicht angesehen.
Ich gehe nämlich stark davon aus, dass die Entwickler da nix vernünftiges bieten können.
Du kannst Chocolatey dafür nutzen aber es hat keine zentrale Verwaltung bzw. die muss man dann mühsam selbst aufbauen. In größeren Umgebungen kann das ohne zentralisierte Verwaltung ziemlich aufwendig sein. In Verbindung mit Intune ist es aber durchaus nutzbar. Wenn ihr da aber ne Handvoll Clients nur habt, dann geht das auch Standalone.
1
Wenn das Produkt keinen Dienst hat, der Updates mit hohen Rechten installiert und ebensowenig als normalernutzer installierbar ist in typischen Pfaden wie %appdata%, dann musst Du basteln.
Man kann, um ein paar Ansätz zu nennen, das Setup regelmäßig runterladen lassen von einem Task und dann von diesem installieren. Dazu
Vor Urzeiten jabe ich das einmal für Windows defender Offlineupdates beschrieben. Updating eines Virenscanners ohne Adminrechte - offline
Man kann, um ein paar Ansätz zu nennen, das Setup regelmäßig runterladen lassen von einem Task und dann von diesem installieren. Dazu
- muss das Setup automatisierbar runterladbar sein die Webadresse muss vorhersagbar sein oder fix
- muss es ebenso silent installierbar sein (z.B. so: setup.exe /silent)
- zudem sollte natürlich auch sichergestellt werden, dass in diese Automation nichts reingrätschen kann, sprich: der bewusst schwache Alltagsnutzer darf den task nicht beeinflussen können, indem er zum Beispiel in den Setup-Pfad etwas eigenes zur Installation ablegt.
Vor Urzeiten jabe ich das einmal für Windows defender Offlineupdates beschrieben. Updating eines Virenscanners ohne Adminrechte - offline
Was du tun könntest, ist zu schauen wo das Programm Adminrechte braucht zum Schreiben und dort explizit Rechte zu vergeben. Authenticated-Users würde sich anbieten. Das kann man für Files, Folders und Registry-Keys.
Mit Programmen wie ProcMon kannst du nachverfolgen was das Setup oder der Update-Prozess versucht.
Grüße!
Mit Programmen wie ProcMon kannst du nachverfolgen was das Setup oder der Update-Prozess versucht.
Grüße!
Ich bin jetzt soweit, entweder die kommen mit einem Dienst daher, oder ich dräng die Geschäftsleitung auf einen Wechsel.
Da ist mir manuell zu viel Spielerei dabei. Und für was eigentlich selbstverständliches will ich jetzt keine Drittsoftware bemühen. Wegen so einem windigen Programm so einen technischen Aufstand muss jetzt auch nicht sein.
Mal schauen, wie lange sie dieses Mal benötigen, mir eine Antwort im Ticketsystem zu geben.
Von mir jetzt meine hochoffizielle Meinung: wenn ihr igrendwo "SP_DATA" laufen seht, rennt. Rennt schnell, rennt weit.
Da ist mir manuell zu viel Spielerei dabei. Und für was eigentlich selbstverständliches will ich jetzt keine Drittsoftware bemühen. Wegen so einem windigen Programm so einen technischen Aufstand muss jetzt auch nicht sein.
Mal schauen, wie lange sie dieses Mal benötigen, mir eine Antwort im Ticketsystem zu geben.
Von mir jetzt meine hochoffizielle Meinung: wenn ihr igrendwo "SP_DATA" laufen seht, rennt. Rennt schnell, rennt weit.
2
Das hört sich zugegebenermaßen richtig gut an. Und für 3 bis 5 Euro pro Client wär das auch ein Schnapper.
Zumindest für alle die, die nicht so gut im Programmieren sind.
Sofern du eine Antwort bekommst, wäre ich über eine Rückinformation von dir dankbar. Aber vermutlich kommt da nichts bei rum, da die Clientupdates ja bei denen nicht bereitgestellt werden. Die Updates kommen ja durch die Anwendung direkt.
Aber die Anwendung wird ja in Askus nur "verpackt" daher sollte schon das Update funktionieren, wenn du natürlich eine proxy-Authentifizierung hast, dann könnte das problematisch werden
Bei uns benötigt das Programm keinen Zugriff ins Internet
Bei uns benötigt das Programm keinen Zugriff ins Internet
Ich hab mir das jetzt nochmal angesehen, wie das Update denn wirklich funktioniert.
User bekommen eine Mail, dass ein Update ansteht. Das müssen sie dann manuell runterladen, auf den Server schubsen und dann auf dem Server installieren (per RDP).
Dann muss die Software auf einem einzigen Client-PC mit Adminrechten gestartet werden. So wie ich das sehe holt sich der die Dateien vom Server und reiht die dann auch in irgendwelchen systemrelevanten Ordnern ein.
Alle weiteren Clients können dann normal mit Userrechten.
Im Grunde scheint die Software auf dem Server nur ein etwas aufgebohrter Client zu sein, wie er auch auf den Client-PCs der User zu finden ist.
ASAP könnte dann für dieses einmalige Starten des Clients funktioneren. Es ist ja im grunde nur ein RunAs mit dazugepackten Credentials.
Für den Server selber brauchts vom Hersteller einen Dienst. Die haben sich schlicht das Programmieren gespart und überlassen das den Kunden.
Für das Server-Update wirds dann wohl ein lokaler Admin für einen ausgewählten User (plus Stellvertretung) werden. Weil einen funktionierenden Update-Dienst trau ich denen nicht zu.
Und dann das Drängen an die Geschäftsleitung, dass da was vernünftiges kommen muss.
Dass man sich überhaupt traut, sowas halbgares zu verkaufen, bei dem die Kunden selber für eine Lösung suchen müssen. Klar, für kleine Klitschen (nicht mal abwertend gemeint) mit Workgroup und lauter Admin-User auf den PCs mag das funktionieren. Mit einer Domäne siehts dann böse aus.
User bekommen eine Mail, dass ein Update ansteht. Das müssen sie dann manuell runterladen, auf den Server schubsen und dann auf dem Server installieren (per RDP).
Dann muss die Software auf einem einzigen Client-PC mit Adminrechten gestartet werden. So wie ich das sehe holt sich der die Dateien vom Server und reiht die dann auch in irgendwelchen systemrelevanten Ordnern ein.
Alle weiteren Clients können dann normal mit Userrechten.
Im Grunde scheint die Software auf dem Server nur ein etwas aufgebohrter Client zu sein, wie er auch auf den Client-PCs der User zu finden ist.
ASAP könnte dann für dieses einmalige Starten des Clients funktioneren. Es ist ja im grunde nur ein RunAs mit dazugepackten Credentials.
Für den Server selber brauchts vom Hersteller einen Dienst. Die haben sich schlicht das Programmieren gespart und überlassen das den Kunden.
Für das Server-Update wirds dann wohl ein lokaler Admin für einen ausgewählten User (plus Stellvertretung) werden. Weil einen funktionierenden Update-Dienst trau ich denen nicht zu.
Und dann das Drängen an die Geschäftsleitung, dass da was vernünftiges kommen muss.
Dass man sich überhaupt traut, sowas halbgares zu verkaufen, bei dem die Kunden selber für eine Lösung suchen müssen. Klar, für kleine Klitschen (nicht mal abwertend gemeint) mit Workgroup und lauter Admin-User auf den PCs mag das funktionieren. Mit einer Domäne siehts dann böse aus.
Zur Info:
SPDATA meint, sie arbeiten gerade an der Überarbeitung des Updatevorgangs.
Dass uns /den Admins, die damit hantieren müssen) ein Dienst lieber wäre und die User (ähnlich wie beim Windows-Update) wählen können, ob ein Update eingespielt wird oder nicht (ich denke da an Jahresende). Im Idealfall soll für gar nix ein Admin vor Ort benötigt werden.
Hoffnung habe ich nicht wirklich.
SPDATA meint, sie arbeiten gerade an der Überarbeitung des Updatevorgangs.
Dass uns /den Admins, die damit hantieren müssen) ein Dienst lieber wäre und die User (ähnlich wie beim Windows-Update) wählen können, ob ein Update eingespielt wird oder nicht (ich denke da an Jahresende). Im Idealfall soll für gar nix ein Admin vor Ort benötigt werden.
Hoffnung habe ich nicht wirklich.
Ich habe deinen Post zum Anlass genommen und habe letzte Woche ebenfalls ein Ticket bei denen geöffnet über unsere Personalabteilung. Rückantwort war, dass nachdem Update auf dem Server unter "\SP_Data\ClientSetup\LohnClientUpdate.exe" die Installationsdatei für die Clients liegt. Diese rufen diese via UNC Pfad auf und installieren die Anwendung mit Adminrechten.
Beim nächsten Pflichtupdate werde ich die Installation über unsere Softwareverteilung an einem Testclient ausprobieren.
Beim nächsten Pflichtupdate werde ich die Installation über unsere Softwareverteilung an einem Testclient ausprobieren.
Zitat von @Seborted:
"\SP_Data\ClientSetup\LohnClientUpdate.exe" die Installationsdatei für die Clients liegt. Diese rufen diese via UNC Pfad auf und installieren die Anwendung mit Adminrechten.
"\SP_Data\ClientSetup\LohnClientUpdate.exe" die Installationsdatei für die Clients liegt. Diese rufen diese via UNC Pfad auf und installieren die Anwendung mit Adminrechten.
Naja, nix anderes passiert ja jetzt auch schon. Die Installation auf dem Server muss manuell upgedated werden und danach muss vom Client aus enmalig ein Client mit Admin-Rechten ausgeführt werden.
Laut Aussage Buchhaltung machen die wirklich nur einen Client mit Admin-Rechten (traurigerweise haben die vom Cheffe die Credentials von einem Domänenadmin bekommen, aber das ist eine andere Geschichte).
So wie ich das sehe, ist der User-Client auf den PCs was ganz einfaches und kopiert nur die Daten vom Server. Im Grunde ist auf dem Server auch nur ein "User-Client" installiert.
Und entweder man installiert dann pro Client-PC das Update oder man lässt einen bestehenden Client mit Adminrechten laufen und der sortiert da die Daten ein, wo sie hingehören. Die anderen Clients holen sich dann nur noch die Daten und kopieren die vom Server auf die Client-PCs.
Alles irgendwie ganz wüst und "dreckig" programmiert.
Aber mit diesem ASAP von askus.biz könnt man zumindest die User-Client-Geschichte abhandeln. (Für 20 Clients wollen die einmalig 100 Euro) Ist halt nur ein RunAs mit mitgegebenen Credentials, die aber nicht auslesbar sind.
Bleibt halt nur noch das Update auf dem Server. Das sollten die eben mit einem Dienst abhandeln.
Dann könnte man das alles ganz Turnschuhfrei die User selber machen lassen.
