19
RunAs MSI Error 1603
Hallo,
ich habe einige Domains (AD), in denen ich wie folgt kleinere Software wie z.B. Java per Silent MSI Installer verteile (die User sind keine Admins):
Erstelle ein Skript mit Autoit, in dem der Domain Admin + PW fest codiert sind und dort wird dann via RunAs als Domain Admin der MSI Installer mit div. Parametern (u.a. für Silent und Logging) aufgerufen. Die compilierte exe liegt auf dem Server und wird via Loginscript bei den Usern bei der Anmeldung ausgeführt, sodass die Software als Domain Admin installiert wird.
Das hat bisher immer problemlos geklappt. Nun habe ich ein AD, wo das nicht klappt. Dort erzeugt der MSI Installer immer den Fehlercode 1603 gepaart mit Einträgen wie z.B. "Error: Need Administrative privileges to proceed".
Hat jemand auf die Schnelle eine Idee woran das liegen könnte?
Also ich würde mal auf die AD Umgebung tippen. Der Virenscanner, der dort im Einsatz ist, ist a) auch mit identischer Konfig bei den anderen AD Umgebungen im Einsatz (wo es funktioniert) und er wurde testhalber auch schon deinstalliert.
Besten Dank.
ich habe einige Domains (AD), in denen ich wie folgt kleinere Software wie z.B. Java per Silent MSI Installer verteile (die User sind keine Admins):
Erstelle ein Skript mit Autoit, in dem der Domain Admin + PW fest codiert sind und dort wird dann via RunAs als Domain Admin der MSI Installer mit div. Parametern (u.a. für Silent und Logging) aufgerufen. Die compilierte exe liegt auf dem Server und wird via Loginscript bei den Usern bei der Anmeldung ausgeführt, sodass die Software als Domain Admin installiert wird.
Das hat bisher immer problemlos geklappt. Nun habe ich ein AD, wo das nicht klappt. Dort erzeugt der MSI Installer immer den Fehlercode 1603 gepaart mit Einträgen wie z.B. "Error: Need Administrative privileges to proceed".
Hat jemand auf die Schnelle eine Idee woran das liegen könnte?
Also ich würde mal auf die AD Umgebung tippen. Der Virenscanner, der dort im Einsatz ist, ist a) auch mit identischer Konfig bei den anderen AD Umgebungen im Einsatz (wo es funktioniert) und er wurde testhalber auch schon deinstalliert.
Besten Dank.
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: 510132
Url: https://administrator.de/contentid/510132
Ausgedruckt am: 04.11.2024 um 22:11 Uhr
19 Kommentare
Neuester Kommentar
Öhm, nur so als Randnotiz: Erscheint mir hochgefährlich das PW des DomainAdmins(!) irgendwo "fest codiert" zu speichern
Zitat von @NetzwerkDude:
Öhm, nur so als Randnotiz: Erscheint mir hochgefährlich das PW des DomainAdmins(!) irgendwo "fest codiert" zu speichern
Öhm, nur so als Randnotiz: Erscheint mir hochgefährlich das PW des DomainAdmins(!) irgendwo "fest codiert" zu speichern
Nicht nur dir ^^ .
"Error: Need Administrative privileges to proceed".
Und da besteht doch das Problem . Hat denn dein Domain Admin in der passenden Domäne auch die Berechtigung Pakete zu installieren ?
Hast dich dort mal angemeldet und versucht das Paket manuell zu installieren ?
Gruss
Ja wenn man sich mit dem Domain Admin auf einer Arbeitsstation anmeldet läuft der Installer durch.
Das liegt vermutlich daran, dass die UAC an ist.
Moin,
Das dachte ich mir auch...
Nachtrag dazu: https://www.autoitscript.com/wiki/Decompiling_FAQ
@hannsgmaulwurf:
Warum deployst du die Software nicht via GPO?
Das wäre eine deutlich bessere Lösung.
Gruß
em-pie
Zitat von @NetzwerkDude:
Öhm, nur so als Randnotiz: Erscheint mir hochgefährlich das PW des DomainAdmins(!) irgendwo "fest codiert" zu speichern
Öhm, nur so als Randnotiz: Erscheint mir hochgefährlich das PW des DomainAdmins(!) irgendwo "fest codiert" zu speichern
Das dachte ich mir auch...
Nachtrag dazu: https://www.autoitscript.com/wiki/Decompiling_FAQ
@hannsgmaulwurf:
Warum deployst du die Software nicht via GPO?
Das wäre eine deutlich bessere Lösung.
Gruß
em-pie
Das ist ein guter Hinweis, die hab ich bei den meisten anderen ADs tatsächlich per GPO beschnitten, danke, schaue ich mir gleich mal an.
Da es Autoit ist...
Hast du ein #RequireAdmin mit im Code?
Edit:
Achja, sofern das Script keine Netzwerkberechtigungen braucht überleg dir mal ob dus nicht als Computer Shutdown Script laufen lääst. Dann hat es lokale Systemberechtigungen, kann also auch alles installieren und duch brauchs kein DomainPW im Script.
Hast du ein #RequireAdmin mit im Code?
Edit:
Achja, sofern das Script keine Netzwerkberechtigungen braucht überleg dir mal ob dus nicht als Computer Shutdown Script laufen lääst. Dann hat es lokale Systemberechtigungen, kann also auch alles installieren und duch brauchs kein DomainPW im Script.
Zitat von @hannsgmaulwurf:
Das ist ein guter Hinweis, die hab ich bei den meisten anderen ADs tatsächlich per GPO beschnitten, danke, schaue ich mir gleich mal an.
Hat geholfen, aber nur teilweise, komisch. Bei manchen Clients (alle Win10 in gleicher OU) wurde installiert nachdem UAC via GPO deaktiviert wurden. Bei einigen tritt das Problem trotzdem noch auf.Das ist ein guter Hinweis, die hab ich bei den meisten anderen ADs tatsächlich per GPO beschnitten, danke, schaue ich mir gleich mal an.
Danke für die Tipps.
@require Admin im Skript hilft nicht, gleiches Problem.
Warum machst du das nicht per GPO?
An die MSI von der Javesetup kommst du doch!?
An die MSI von der Javesetup kommst du doch!?
Weil i.d.R. vor und nach der Installation noch einige Dinge zu prüfen sind und zu erledigen sind, z.B. Registry Werte prüfen/löschen/ändern, vorhandene Verzeichnisse und Konfig Dateien etc... Deshalb packe ich das gerne alles immer in ein Skript.
Geht nicht selten auch, wenn man die TRANSFORM-Files für die MSIs erzeugst und die dann mit bei der GPO angibst...
Schaue dir einfach mal ORCA an;)
Schaue dir einfach mal ORCA an;)
Ich hoffe, dass Du die Hinweise zur Sicherheit Ernst nimmst. Im Handumdrehen wird deine Domäne auf diese Weise übernommen.
Nimm ein Startskript oder einen geplanten Task (ausführendes Konto: "system"), da brauchst Du keine Credentials mitzugeben.
Nimm ein Startskript oder einen geplanten Task (ausführendes Konto: "system"), da brauchst Du keine Credentials mitzugeben.
Danke für den Tipp, ist notiert, hilft mir aktuell aber nicht, denn mit reinen MST Files komme ich nicht weiter, weil vor der Installation diverse Dinge geprüft und abgearbeitet werden müssen.
Zitat von @DerWoWusste:
Ich hoffe, dass Du die Hinweise zur Sicherheit Ernst nimmst. Im Handumdrehen wird deine Domäne auf diese Weise übernommen.
Ja.Ich hoffe, dass Du die Hinweise zur Sicherheit Ernst nimmst. Im Handumdrehen wird deine Domäne auf diese Weise übernommen.
Nimm ein Startskript oder einen geplanten Task (ausführendes Konto: "system"), da brauchst Du keine Credentials mitzugeben.
Die Exe läuft ja als Startskript (GPO -> Benutzerkonfig -> ... -> Anmeldeskript) - gibt man keine Credentials an, bricht die Installation mangels Berechtigungen ab.
Das ist kein Startskript, sondern ein Anmeldeskript. Nimm GPO -> Computerkonfig -> ... -> Startskript)
Das geht wieder nicht, weil ja, wie gesagt, in der Exe diverse benutzerspezifische Dinge geprüft und abgearbeitet werden (z.B. Ordner im Userprofil prüfen/anlegen/mit Dateien füllen).
Doch, geht schon, indem man das eben in allen Profilen gleichermaßen prüft.
Hm, dann müsste man ja erst mal schauen, welche Profile vorhanden sind, welche noch aktuell sind und dann für jedes potentiell aktive Profil die individuellen Einstellungen vornehmen. Erscheint mir unendlich aufwendig...
Oha... na "unendlich" sollte der Aufwand nicht wirklich sein - nimm halt jedes Profil, fertig.
for /f %a in ('dir c:\users /b') do copy... Datei.txt c:\users\%a\ziel\ /y
Der Trick besteht in einem zweitiligen Setup.
Einer Computerkomponente die mit dem Systemkonto arbeitet und einer Benutzerkomponente die im Benutzerkontext ausgeführt wird.
Ist zwar aufwendiger zu bauen, wird dafür aber auch ausgeführt für Benutzer die sich später am System anmelden.
Active Setup ist hier das Stichwort
https://helgeklein.com/blog/2010/04/active-setup-explained/
Einer Computerkomponente die mit dem Systemkonto arbeitet und einer Benutzerkomponente die im Benutzerkontext ausgeführt wird.
Ist zwar aufwendiger zu bauen, wird dafür aber auch ausgeführt für Benutzer die sich später am System anmelden.
Active Setup ist hier das Stichwort
https://helgeklein.com/blog/2010/04/active-setup-explained/
