27
Zentral gesteuerte Clientinstallation mit lokalen Adminrechten
Guten Tag Admin-Gemeinde,
wir setzen hier im Betrieb die Software BRZ in Version 7.8.0.57 mit eigenem lokalen Server ein.
Diese bringt für Updates/Hotfixe, die regelmäßig auf dem Server installiert werden müssen, eine Clientsoftware mit, die natürlich auch aktualisiert werden muss.
Leider ist BRZ wohl nicht in der Lage, eine funktionierende .msi Setup-Datei zu liefern, die im silent-mode läuft und damit via GPO in
[Benutzerkonfiguration-Richtlinien-Softwareeinstellungen-Softwareinstallation ] verteilt werden könnte.
Es gibt leider nur ein Verzeichnis mit den Clientinstallationsdateien nebst einer setup.exe.
Diese ist mit dem Parameter --auto=TRUE aufrufbar. Damit soll eine silentinstallation laufen.
Das Ganze funktioniert auch. Jedoch nur mit lokalen administrativen Rechten (!).
Ich habe folgendes probiert :
GPO : [Benutzerkonfiguration-Einstellungen-Systemsteuerungseinstellungen-geplante Aufgaben]
Aufgabe erstellt
Beim Ausführen folgendes Benutzerkonto verwenden : %LogonDomain%\%LogonUser%
Nur ausführen, wenn Benutzer angemeldet ist
mit höchsten Privilegien ausführen
Konfigurieren für Windows7, Windows Server 2008R2 (ist das höchste, was angeboten ist)
Trigger : Bei Anmeldung / Jeder Benutzer
Aktionen : Programm starten / ..Pfad..\setup.exe --auto=TRUE -L0x0407 (letzter Parameter ist die Sprache)
Gemeinsam : Nur einmal anwenden
Alle anderen Aufgabeneinstellungen sind Standard.
Das funktioniert mangels lokaler Adminrechte nicht.
Also mache ich Folgendes (in der gleichen GPO):
[Benutzerkonfiguration-Einstellungen-Systemsteuerungseinstellungen-lokale Benutzer und Gruppen]
Rechtsklick - neu - lokale Gruppe, Gruppenname : Administratoren(integriert)
Mitglieder : Hinzufügen - %LogonDomain%\%LogonUser%
Gemeinsam : Element entfernen, wenn es nicht mehr angewendet wird.
Damit wird ja der angemeldete User jeweils Mitglied der lokalen Admins.
Und damit funktioniert auch die o.g. Aufgabe perfekt.
Wenn die GPO dann entfernt/entknüpft wird, ist der User aus der Admingruppe entfernt (wegen "Element entfernen, wenn..")
Soweit so gut.
Das ist mir jedoch ziemlich unsicher, da bei ca. 80 Usern der Vorgang eine ganze Weile dauert, bis ich die GPO entfernen und damit die lokalen Adminrechte rausschmeißen kann.
Habt Ihr für diesen Fall eine elegantere bzw. sicherere Lösung ?
Was ich probiert habe und was nicht funktioniert :
ohne GPO mit lokaler Admin-Gruppe:
als Aufgabenuser NT-Autorität\System benutzt
als AufgabenUser einen User, der in der Domainadmingruppe ist benutzt
Aufgabe unabhängig von Benutzeranmeldung zeitgesteuert starten lassen
Grobe Infos zur Umgebung :
DCs mit Server 2019, AD höchstmöglicher Stand
BRZ-Server : virtuelle Maschine mit Server 2019
Clients : Windows 10 und Windows 11 Pro
Ich hoffe auf Euer geballtes Gruppenwissen
Grüße
Mike
wir setzen hier im Betrieb die Software BRZ in Version 7.8.0.57 mit eigenem lokalen Server ein.
Diese bringt für Updates/Hotfixe, die regelmäßig auf dem Server installiert werden müssen, eine Clientsoftware mit, die natürlich auch aktualisiert werden muss.
Leider ist BRZ wohl nicht in der Lage, eine funktionierende .msi Setup-Datei zu liefern, die im silent-mode läuft und damit via GPO in
[Benutzerkonfiguration-Richtlinien-Softwareeinstellungen-Softwareinstallation ] verteilt werden könnte.
Es gibt leider nur ein Verzeichnis mit den Clientinstallationsdateien nebst einer setup.exe.
Diese ist mit dem Parameter --auto=TRUE aufrufbar. Damit soll eine silentinstallation laufen.
Das Ganze funktioniert auch. Jedoch nur mit lokalen administrativen Rechten (!).
Ich habe folgendes probiert :
GPO : [Benutzerkonfiguration-Einstellungen-Systemsteuerungseinstellungen-geplante Aufgaben]
Aufgabe erstellt
Beim Ausführen folgendes Benutzerkonto verwenden : %LogonDomain%\%LogonUser%
Nur ausführen, wenn Benutzer angemeldet ist
mit höchsten Privilegien ausführen
Konfigurieren für Windows7, Windows Server 2008R2 (ist das höchste, was angeboten ist)
Trigger : Bei Anmeldung / Jeder Benutzer
Aktionen : Programm starten / ..Pfad..\setup.exe --auto=TRUE -L0x0407 (letzter Parameter ist die Sprache)
Gemeinsam : Nur einmal anwenden
Alle anderen Aufgabeneinstellungen sind Standard.
Das funktioniert mangels lokaler Adminrechte nicht.
Also mache ich Folgendes (in der gleichen GPO):
[Benutzerkonfiguration-Einstellungen-Systemsteuerungseinstellungen-lokale Benutzer und Gruppen]
Rechtsklick - neu - lokale Gruppe, Gruppenname : Administratoren(integriert)
Mitglieder : Hinzufügen - %LogonDomain%\%LogonUser%
Gemeinsam : Element entfernen, wenn es nicht mehr angewendet wird.
Damit wird ja der angemeldete User jeweils Mitglied der lokalen Admins.
Und damit funktioniert auch die o.g. Aufgabe perfekt.
Wenn die GPO dann entfernt/entknüpft wird, ist der User aus der Admingruppe entfernt (wegen "Element entfernen, wenn..")
Soweit so gut.
Das ist mir jedoch ziemlich unsicher, da bei ca. 80 Usern der Vorgang eine ganze Weile dauert, bis ich die GPO entfernen und damit die lokalen Adminrechte rausschmeißen kann.
Habt Ihr für diesen Fall eine elegantere bzw. sicherere Lösung ?
Was ich probiert habe und was nicht funktioniert :
ohne GPO mit lokaler Admin-Gruppe:
als Aufgabenuser NT-Autorität\System benutzt
als AufgabenUser einen User, der in der Domainadmingruppe ist benutzt
Aufgabe unabhängig von Benutzeranmeldung zeitgesteuert starten lassen
Grobe Infos zur Umgebung :
DCs mit Server 2019, AD höchstmöglicher Stand
BRZ-Server : virtuelle Maschine mit Server 2019
Clients : Windows 10 und Windows 11 Pro
Ich hoffe auf Euer geballtes Gruppenwissen
Grüße
Mike
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: 3936881362
Url: https://administrator.de/contentid/3936881362
Ausgedruckt am: 21.11.2024 um 11:11 Uhr
27 Kommentare
Neuester Kommentar
Moin,
warum so kompliziert?
Fertig.
Gruß
em-pie
warum so kompliziert?
- erstelle ein Script,
- welches prüft, ob der Client schon installiert ist.
- Ist er nicht installiert, wird die
setup.exe --auto=TRUE -L0x0407ausgeführt - erstelle eine GPO, welche unter
Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Skripts -> Startenebendieses Skript ausführt
Fertig.
Gruß
em-pie
Geht so nicht, da, wie beschrieben Adminrechte erforderlich sind.
Das Script würde ja mit den Userrechten laufen.
Oder RUNAS.. Aber das ganz sicher nicht, da hier ja das Adminkennwort im Klartext im Script stehen würde.
Gruß
Mike
Das Script würde ja mit den Userrechten laufen.
Oder RUNAS.. Aber das ganz sicher nicht, da hier ja das Adminkennwort im Klartext im Script stehen würde.
Gruß
Mike
Das Script würde ja mit den Userrechten laufen.
das ist doch Quatsch. Ich schrieb ComputerkonfigurationFolglich läuft das Script mit Systemrechten. Mehr Rechte gehen fast gar nicht.
Hatte ich auch geschrieben. Mit SYSTEM habe ich es probiert.
Warum das nicht geht weiß ich nicht. Das sind wohl unergründliche Wege von BRZ.
Ich hatte nicht erwähnt, dass ich das Ganze natürlich statt nur mit Userkonfiguration auch mit Computerkonfiguration probiert habe.
Warum das nicht geht weiß ich nicht. Das sind wohl unergründliche Wege von BRZ.
Ich hatte nicht erwähnt, dass ich das Ganze natürlich statt nur mit Userkonfiguration auch mit Computerkonfiguration probiert habe.
Ich hatte nicht erwähnt, dass ich das Ganze natürlich statt nur mit Userkonfiguration auch mit Computerkonfiguration probiert habe.
Du hast ja nicht mal geschrieben, dass du es als Startskript schon probiert hast (Startskript != Softwareverteilung von MSI-Paketen)
Also nur um Missverständnissen aus dem Weg zu gehen, rede ich von dieser Einstellung:
Dann betreibe Troubleshooting:
Wird die Batch aufgerufen (ein
echo Test>>c:\test.txt hilft am Anfang der Batch?Kann das Systemkonto auf die Quelle der setup.exe zugreifen (liegt die setup.exe auf einem Share, muss das Computerkonto natürlich lesenden zugriff haben)?
Aufbau der Batch (Beispielhaft)
echo test>>c:\test.txt
@echo off
echo Das ist die install_BRZ.bat, welche auf \\myServer\rollout\brz\install_BRZ.bat liegt
echo.
echo installiere BRZ>>c:\test.cmd
\\myServer\rollout\brz\setup.exe --auto=TRUE -L0x0407"
echo.
echo ende>>c:\test.txt
OK, ich werde das nochmal probieren.
Mir ist allerdings schleierhaft, wieso der selbe Aufruf, der als Aufgabe lokal auf den PCs verteilt wird und mit "SYSTEM" nicht funktioniert, dann als Script mit denselben Rechten laufen soll.
Aber - ich werde es probieren und melde mich.
Mir ist allerdings schleierhaft, wieso der selbe Aufruf, der als Aufgabe lokal auf den PCs verteilt wird und mit "SYSTEM" nicht funktioniert, dann als Script mit denselben Rechten laufen soll.
Aber - ich werde es probieren und melde mich.
Nope, funktioniert nicht.
Fehlermeldungen beim Eintragen von Registryeinträgen - wie vorher auch.
Auf dem Verzeichnis, wo die Setup.Exe liegt sind Schreib- und Leserechte für alle Domänencomputer gesetzt.
Witzigerweise dachte ich, durch das echo test>>c:\test.txt wird eine entsprechende test.txt auf dem betreffenden Testcomputer erzeugt.
Jedoch Fehlanzeige...
Fehlermeldungen beim Eintragen von Registryeinträgen - wie vorher auch.
Auf dem Verzeichnis, wo die Setup.Exe liegt sind Schreib- und Leserechte für alle Domänencomputer gesetzt.
Witzigerweise dachte ich, durch das echo test>>c:\test.txt wird eine entsprechende test.txt auf dem betreffenden Testcomputer erzeugt.
Jedoch Fehlanzeige...
Moin,
bevor du nun aufwendig die GPOs verunstaltest äh umbaust, könntest du einfach auf psexec.exe hernehmen und eine Eingabeaufforderung als NT AUTHORITY\SYSTEM starten und den Installationsbefehl ausführen. Kopiere dazu die Installationsdatei temporär auf den Testclient, um mögliche Berechtigungensprobleme auszuschließen. Dann siehst du auch, ob es (nicht) funktioniert und hast zu dem evtl. Ausgaben/GUIs.
Links:
https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
https://specopssoft.com/blog/how-to-become-the-local-system-account-with ...
Gruß,
Dani
bevor du nun aufwendig die GPOs verunstaltest äh umbaust, könntest du einfach auf psexec.exe hernehmen und eine Eingabeaufforderung als NT AUTHORITY\SYSTEM starten und den Installationsbefehl ausführen. Kopiere dazu die Installationsdatei temporär auf den Testclient, um mögliche Berechtigungensprobleme auszuschließen. Dann siehst du auch, ob es (nicht) funktioniert und hast zu dem evtl. Ausgaben/GUIs.
Links:
https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
https://specopssoft.com/blog/how-to-become-the-local-system-account-with ...
Gruß,
Dani
Bevor ich das probiere : Berechtigungsprobleme gibt es ja.
Und auch wenn ich das alles temporär auf einen Testclient kopiere - im echten Verteilbetrieb kann ich das wohl eher vergessen..
Und auch wenn ich das alles temporär auf einen Testclient kopiere - im echten Verteilbetrieb kann ich das wohl eher vergessen..
Also, mit dem Befehl \\server\brz32\client\disk1\setup.exe --auto=TRUE -L0x0407 aus PSEXEC mit SYSTEM Rechten (NT-AUTORITÄT\SYSTEM) kommt : Zugriff verweigert.
Ich habe schon auf das Setupverzeichnis Schreibrechte für Domänencomputer gesetzt.
Wahrscheinlich renne ich dann doch zu allen PCS
Keine Ahnung, was das Problem bei BRZ ist. Mit anderen funktioniert es doch auch
Ich habe schon auf das Setupverzeichnis Schreibrechte für Domänencomputer gesetzt.
Wahrscheinlich renne ich dann doch zu allen PCS
Keine Ahnung, was das Problem bei BRZ ist. Mit anderen funktioniert es doch auch
Servus,
gibt es keinen Support des Anbieters bzw was sagt der?
Gruß
gibt es keinen Support des Anbieters bzw was sagt der?
Gruß
Hast du mal versucht, die Setup.exe (für den test) lokal auf einem Testclient abzulegen und dann das ganze zu starten (mit PSEXEC...)?
Moin,
Gruß,
Dani
Also, mit dem Befehl \\server\brz32\client\disk1\setup.exe --auto=TRUE -L0x0407 aus PSEXEC mit SYSTEM Rechten (NT-AUTORITÄT\SYSTEM) kommt : Zugriff verweigert.
der Fehler ist logisch. Denn NT-AUTORITÄT\SYSTEM hat grundsätzlich keinen Zugriff auf Network Shares. Work as designed. Daher habe ich geschrieben, dass du die DAtei auf dem Rechner legen sollst. Ich habe schon auf das Setupverzeichnis Schreibrechte für Domänencomputer gesetzt.
Wie gesagt NT-AUTORITÄT\SYSTEM ist nicht gleich Domänen-Computerkonto.Gruß,
Dani
Anbieter sagt ganz einfach : Nö, wir haben nur den besagten Aufruf der setup.exe.
Ganz toll BRZ!
Auf dem Testclient könnte ich das sicher probieren - allerdings, selbst wenn das funktioniert, wie mache ich das dann im Echtbetrieb ? Zu jedem Client kopieren ist quasi derselbe Aufwand, wie direkt hinzulaufen und als Admin direkt zu installieren.
Wenn ich nicht wüsste, dass es besser geht (z.B. mit Mailstore, die Clients waren in 2 Minuten im ganzen Netz installiert)....
Ganz toll BRZ!
Auf dem Testclient könnte ich das sicher probieren - allerdings, selbst wenn das funktioniert, wie mache ich das dann im Echtbetrieb ? Zu jedem Client kopieren ist quasi derselbe Aufwand, wie direkt hinzulaufen und als Admin direkt zu installieren.
Wenn ich nicht wüsste, dass es besser geht (z.B. mit Mailstore, die Clients waren in 2 Minuten im ganzen Netz installiert)....
Ist WOL vorhanden? Dann fahre die Rechner hoch, kopiere automatisiert die Software auf die Clients und prügle die Installation mit Powershell durch
Moin,
Gruß,
Dani
Auf dem Testclient könnte ich das sicher probieren - allerdings, selbst wenn das funktioniert, wie mache ich das dann im Echtbetrieb ?
eins nach dem anderen... wir können es doch selbst nicht ausprobieren. Daher sind wir auf deinne Input/Output angewiesen. Daher bleibt uns nur Tasten und fundierte Ausgangslage zu haben.Gruß,
Dani
Moin,
die .exe kannst du auch mit MSI Wrapper und den Parametern zu einer .msi machen, aber wie schon beschrieben wird das evtl. auch keine Besserung bringen.
Ich hab da vor einiger Zeit mit rum gespielt, die Free Version kann eigentlich alles.
MSI Wrapper
Grüzze
Tobi
die .exe kannst du auch mit MSI Wrapper und den Parametern zu einer .msi machen, aber wie schon beschrieben wird das evtl. auch keine Besserung bringen.
Ich hab da vor einiger Zeit mit rum gespielt, die Free Version kann eigentlich alles.
MSI Wrapper
Grüzze
Tobi
Das habe ich schon ausgiebig probiert, bevor ich hier diese Frage gestellt habe
ich hab das Gefühl, du bist gar nicht an einer Lösung interessiert.
Du hast bisweilen immernoch nicht geschrieben, ob es funktioniert, wenn das ganze Setup-Verzeichnis lokal liegt und von dort per GPO (Start-Skript) gestartet wird.
Solte das nämlcih funktionieren, sollte folgendes funktionieren:
Via GPP kopierst du zunächst alles vom Share auf den Client
Danach fängt das Start-Skript an zu prüfen, ob der Verzeichnis existiert (und gefüllt ist) und wenn die Info =TRUE lautet, dann soll das Skript das Setup mit den obigen Parametern ausführen
BTW: Wir installieren die Citrix WorkspaceApp via Startskript. Die Quelle liegt dabei auf einem File-Server - klappt alles wunderbar. Irgendwo hast du also noch einen Bock drin. Ohne eine konkrete Fehlermeldung können wir dir aber nicht helfen.
Das ist hier aktuell so, als wenn du in die Werkstatt kommst, die Mechaniker um Hilfe bittest denen aber nur sagst, es klappert am Auto (welches noch zuhause steht). Wenn du denen nicht sagst wo in etwa oder bei welchem (Fahr-) Verhalten, werden die dir auch nicht helfen können.
Du hast bisweilen immernoch nicht geschrieben, ob es funktioniert, wenn das ganze Setup-Verzeichnis lokal liegt und von dort per GPO (Start-Skript) gestartet wird.
Solte das nämlcih funktionieren, sollte folgendes funktionieren:
Via GPP kopierst du zunächst alles vom Share auf den Client
Danach fängt das Start-Skript an zu prüfen, ob der Verzeichnis existiert (und gefüllt ist) und wenn die Info =TRUE lautet, dann soll das Skript das Setup mit den obigen Parametern ausführen
BTW: Wir installieren die Citrix WorkspaceApp via Startskript. Die Quelle liegt dabei auf einem File-Server - klappt alles wunderbar. Irgendwo hast du also noch einen Bock drin. Ohne eine konkrete Fehlermeldung können wir dir aber nicht helfen.
Das ist hier aktuell so, als wenn du in die Werkstatt kommst, die Mechaniker um Hilfe bittest denen aber nur sagst, es klappert am Auto (welches noch zuhause steht). Wenn du denen nicht sagst wo in etwa oder bei welchem (Fahr-) Verhalten, werden die dir auch nicht helfen können.
Und ich habe das Gefühl, Du hast nicht korrekt gelesen :
Also nochmal : Die Installation benötigt lokale Adminrechte.
Damit hat es ja funktioniert.
Aus welchem Grund auch immer reicht NT-Autorität\System nicht.
Der Test war (um es nochmal zu schreiben) so, dass ich einen angemeldeten Nutzer via GPO in die lokale Administratorgruppe geschoben habe und das Setup lief wunderbar.
Genau das will ich aber vermeiden - das normale User auf einmal lokale Admins sind.
Aus welchem Grund auch immer reicht NT-Autorität\System nicht.
und dein SETUP lag dabei lokal auf dem Rechner oder weiterhin auf einem Share?Darum geht es doch! Denn @Dani schrieb ja
Denn NT-AUTORITÄT\SYSTEM hat grundsätzlich keinen Zugriff auf Network Shares. Work as designed. Daher habe ich geschrieben, dass du die DAtei auf dem Rechner legen sollst.
und das hast du bisher nicht gemacht/ hier geschrieben.
und wenn es LOKAL (=Datei liegt lokal und wird per psexec/ Start-Skript ausgeführt) mit dem SYSTEM-User klappt, habe ich dir einen Workaround genannt....
Und ein "Mit dem SYSTEM-User klappt es nicht" lasse ich nicht gelten.
Wenn du sagst "die 325er Reifen funktionieren nicht mit meinem Porsche" und wir dich fragen, ob die die überhaupt schon mal auf die für deinen Prosche passenden Felgen montiert hast, du hier aber keine Rückmeldung gibst, können wir dir auch nicht helfen.
So, da es ja hier nicht sehr hilfreich war, habe ich nochmal selbst etwas probiert.
Man nehme die Software AutoIT (V3.3.16.0) und SciTE4AutoIt3.
Man erstelle folgendes Script : (Bild)
Die geschwärzten Stellen sind Domäne, Adminkennwort und Servername.
Dann noch Tools - Compile und eine Exe draus machen.
Die führt dann einfach das Setup.Exe mit Parametern als Administrator via RUNAs aus und fertig.
Da frage ich mich, wieso ich mich von EM-Pie volltexten lassen muss.
Da ist wohl der Name Programm
Man nehme die Software AutoIT (V3.3.16.0) und SciTE4AutoIt3.
Man erstelle folgendes Script : (Bild)
Die geschwärzten Stellen sind Domäne, Adminkennwort und Servername.
Dann noch Tools - Compile und eine Exe draus machen.
Die führt dann einfach das Setup.Exe mit Parametern als Administrator via RUNAs aus und fertig.
Da frage ich mich, wieso ich mich von EM-Pie volltexten lassen muss.
Da ist wohl der Name Programm
und das kannst du per GPO installieren lassen oder machst du dann dennoch "Turnschuh-Administration?"
Wo liegt denn dann die brzinstall.exe?
Achja: Super Idee, die Installation mit dem Domain-Admin laufen zu lassen.
Egal: nicht mein Netzwerk
Wo liegt denn dann die brzinstall.exe?
Achja: Super Idee, die Installation mit dem Domain-Admin laufen zu lassen.
Egal: nicht mein Netzwerk
@miscmike
Es wäre wünschesnwert, wenn man als Antworter erkennen würde, wem und auf welche (Ab)Sätze du antwortest. Alles andere ist jedes Mal Spekulation ala "er meint mich - er meint mich nicht". Woher sollen die Kolleginnen und Kollegen und Ich das wissen?!
Wenn dir zu viel, zu langsam zu viel Text ist, empfehle ich dir einen IT-Dienstleister zu suchen. Der macht nämlich genau das, was du ihm (schriftlich) definierst. Da bekommst du aber auch hinterher die (gewünschte) Doku, eine Belehrung bezüglich möglicher Sicherheitsbedenken und die Rechnung für den entstandenen Aufwand. Nun kannst du dir überlegen, welche Option dir wie viel Wert ist.
Gruß,
Dani (Mod)
Es wäre wünschesnwert, wenn man als Antworter erkennen würde, wem und auf welche (Ab)Sätze du antwortest. Alles andere ist jedes Mal Spekulation ala "er meint mich - er meint mich nicht". Woher sollen die Kolleginnen und Kollegen und Ich das wissen?!
Aus welchem Grund auch immer reicht NT-Autorität\System nicht.
Hab ich oben - aus meiner Sicht - deutlich geschrieben. Die Windows Welt ist in den letzten 10 Jahren komplexer und umfangreicher geworden. Ein 0 und 1 oder schwarz/weis gibt es heute fast nicht mehr. Alles hat inzwischen mehrere Gründe und je nachdem auch verschiedene Auswirkungen.Der Test war (um es nochmal zu schreiben) so, dass ich einen angemeldeten Nutzer via GPO in die lokale Administratorgruppe geschoben habe und das Setup lief wunderbar.
Richtig. Das ist uns allen Antworteten auch nach wie vor sicherlich bewusst. Aber wie ich geschrieben haben, muss man sich in solchen Fällen rantasten. Nicht das am Ende z.B. die Benutzerkontensteuerung (UAC) der Glotz am Bein ist. Daher meine bitte es über die Eingabeaufforderung mit NT-Auth\System einmal zu versuchen. Die geschwärzten Stellen sind Domäne, Adminkennwort und Servername.
Danke, dir sind die Gefahren einer solchen Maßnahme klar?! How to protect password in script. Ansonsten wäre evtl. PowerShell mit PSCredentials eine sichere Umsetzung möglich. Die führt dann einfach das Setup.Exe mit Parametern als Administrator via RUNAs aus und fertig.
Warum musst du das Skript zweimal als RunAs ausführen? Weil nach der Definition von RunAs ist das doppel gemoppelt und sollte eigentlich für eine weitere (kritische) Frage sorgen: Da stimmt doch was nicht?!Da frage ich mich, wieso ich mich von EM-Pie volltexten lassen muss. Da ist wohl der Name Programm
Da triffst du den Nagel auf den Kopf. Ich frage mich, warum wir uns das Anhören müssen? Wenn du eine Frage in einem Q&A stellst, dann musst du damit rechnen, dass du nicht nur die bequeme Antworten bekommst sondern auch umfangreiche Texte mit entsprechenden Hintergründen. Viele der Nutzer hier helfen bei Fragen und Problemen in Ihrer Pause oder sogar in der Freizeit - egal ob wochentags, Wochenende oder sogar Feiertag. Es ist immer ein Geben und Nehmen...Wenn dir zu viel, zu langsam zu viel Text ist, empfehle ich dir einen IT-Dienstleister zu suchen. Der macht nämlich genau das, was du ihm (schriftlich) definierst. Da bekommst du aber auch hinterher die (gewünschte) Doku, eine Belehrung bezüglich möglicher Sicherheitsbedenken und die Rechnung für den entstandenen Aufwand. Nun kannst du dir überlegen, welche Option dir wie viel Wert ist.
Gruß,
Dani (Mod)
1
der Fehler ist logisch. Denn NT-AUTORITÄT\SYSTEM hat grundsätzlich keinen Zugriff auf Network Shares. Work as designed.
Moin Dani. Die Aussage ist bei Domänenclients falsch. In Domänen greift das Computerkonto laufend auf das Netzwerk zu, zum Beispiel für die Verarbeitung der Computer-GPOs.Wie gesagt NT-AUTORITÄT\SYSTEM ist nicht gleich Domänen-Computerkonto.
Doch, ist das Gleiche.In ganz seltenen Ausnahmefällen gelingen Installationen als Systemkonto nicht, hat aber nichts mit dem Netzwerkzugriff zu tun. \\server\share\setup.exe /silentparameter
läuft nach meiner Erfahrung (und die ist in dem Bereich sehr groß) in 99% problemlos, egal, ob als Startskript oder als geplanter Task, der als Systemkonto läuft. Leserechte auf dem Setupordner für jeder/authentifizierte Benutzer oder Domänencomputer natürlich vorausgesetzt.
Kennwörter einbetten bitte vermeiden. Autoit und Co machen das nicht auf sichere Weise.
Zitat von @em-pie:
und das kannst du per GPO installieren lassen oder machst du dann dennoch "Turnschuh-Administration?"
Ja, kann ich.und das kannst du per GPO installieren lassen oder machst du dann dennoch "Turnschuh-Administration?"
Wo liegt denn dann die brzinstall.exe?
Da, wo die komplette Clientinstallation liegt.Achja: Super Idee, die Installation mit dem Domain-Admin laufen zu lassen.
Egal: nicht mein Netzwerk
War ein Beispiel - nimm "Administrator" einfach als Platzhalter.
Das man hier jedes einzelne Wort nochmal erklärten muss , mann mann
Zitat von @Dani:
@miscmike
Es wäre wünschesnwert, wenn man als Antworter erkennen würde, wem und auf welche (Ab)Sätze du antwortest. Alles andere ist jedes Mal Spekulation ala "er meint mich - er meint mich nicht". Woher sollen die Kolleginnen und Kollegen und Ich das wissen?!
@miscmike
Es wäre wünschesnwert, wenn man als Antworter erkennen würde, wem und auf welche (Ab)Sätze du antwortest. Alles andere ist jedes Mal Spekulation ala "er meint mich - er meint mich nicht". Woher sollen die Kolleginnen und Kollegen und Ich das wissen?!
Ich werde in Zukunft dran üben
Die geschwärzten Stellen sind Domäne, Adminkennwort und Servername.
Danke, dir sind die Gefahren einer solchen Maßnahme klar?! How to protect password in script. Ansonsten wäre evtl. PowerShell mit PSCredentials eine sichere Umsetzung möglich.Ich hätte mir die Mühe machen können, für alles Platzhalter ala %Administrator%, %Adminkennwort% und %Domäne% zu benutzen.
Allerdings dachte ich mir, wir sind hier in einem Administratorforum....
Die führt dann einfach das Setup.Exe mit Parametern als Administrator via RUNAs aus und fertig.
Warum musst du das Skript zweimal als RunAs ausführen? Weil nach der Definition von RunAs ist das doppel gemoppelt und sollte eigentlich für eine weitere (kritische) Frage sorgen: Da stimmt doch was nicht?!Nein, falsch verstanden. Der Aufruf der Setup.Exe mit den Parametern für Silentinstall wurde lediglich in eine brzinstall.exe "verpackt". Dort drin sind die Runas Parameter integriert, also nicht doppelt, da brzinstall.exe ganz normal als User aufgerufen werden kann.
Da frage ich mich, wieso ich mich von EM-Pie volltexten lassen muss. Da ist wohl der Name Programm
Da triffst du den Nagel auf den Kopf. Ich frage mich, warum wir uns das Anhören müssen? Wenn du eine Frage in einem Q&A stellst, dann musst du damit rechnen, dass du nicht nur die bequeme Antworten bekommst sondern auch umfangreiche Texte mit entsprechenden Hintergründen. Viele der Nutzer hier helfen bei Fragen und Problemen in Ihrer Pause oder sogar in der Freizeit - egal ob wochentags, Wochenende oder sogar Feiertag. Es ist immer ein Geben und Nehmen...EM-Pie schreibt "ich hab das Gefühl, du bist gar nicht an einer Lösung interessiert."
Das ist anmaßend und "von oben herab".
Wenn ich Langeweile habe, dann schreibe ich sicher nicht in einem Adminforum.
Und nein, ich bin nicht neu sondern seit 30 Jahren IT-Dienstleister und jetzt (da es sich so ergeben hat) in einer großen Firma angestellt.
Jedenfalls ist die beschriebene Lösung eine Sache, die funktioniert.
Woran ich überhaupt noch nicht gedacht habe ist, dass ich ja den Setup-Aufruf ganz einfach mit dem Kaspersky KSC machen kann.
Gerade probiert - 2 Minuten für die Aufgabe, auf "Manuell ausführen" geklickt, und es läuft.
Hmm - soviel zu den berühmten GPOs - Softwareinstallationen können eben doch leichter gehen.
Hatte diese Funktion letzte Woche nur nicht mehr auf dem Schirm..
