17.07.2017

4993

bat Abhandlung für Silent Deploy (Desktop Central)

Liebe Admins,

ich hab hier ein einfaches Script einer Installationsroutine von ePlan (eine Planungssoftware). Diese schmeißt mir nach Konfiguration mit eigenem Customization Tool folgendes in eine .bat:

@echo off
FOR /F "tokens=2*" %%C IN ('%windir%\system32\REG QUERY "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v ProductName') DO SET BS=%%D
FOR /F "tokens=2*" %%A IN ('%windir%\system32\REG QUERY "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CurrentVersion') DO SET CV=%%B
if "%PROCESSOR_ARCHITECTURE%"=="x86" (goto X86) else (goto X64)
:X64
set "ESS_USERPROFILE=C:\Users\Public"
set "ESS_Path=%ProgramFiles%"
set "ESS_EECONEPath=%ProgramFiles%"
set "ESS_BITF= (X64)"
set "ESS_BITM= (X64)"
set "ESS_USERPROFILE=C:\Users\Public"
set "BSB=64 Bit"
goto BSF
:X86
set "BSB=32 Bit"
goto UXP
:BSF
if "%CV%"=="5.1" (goto UXP)
if "%CV%"=="5.2" (goto UXP)
if "%CV%"=="6.0" (goto UXP)
if "%CV%"=="6.1" (goto UW8)
if "%CV%"=="6.2" (goto UW8)
if "%CV%"=="6.3" (goto UW8)
:UXP
echo The operating system %BS% %BSB% is no longer supported by the EPLAN platform ! For more details, please see the News of the EPLAN version
REM Pause
Exit
:UW8
set "MSIE=%windir%\System32\msiexec.exe /i "

@echo on
"\\Netzwerkpfad\ePlanv2.6\Electric P8 2.6.3.10395\License Client (Win32)\setup.exe" /q /L 1031
usw. (noch 3 Pakete, setup.exe und .msi

Ich kann die .bat über elevated cmd ausführen und die Abarbeitung erfolgt problemlos. Wenn ich dieses .bat jedoch über mein Deploy Tool aus dem Repository starte, bekomme ich eine Fehlermeldung siehe Anhang. Vergesse ich hier irgendwelche Argumente?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 343634

Url: https://administrator.de/contentid/343634

Ausgedruckt am: 25.11.2024 um 14:11 Uhr

22 Kommentare

Neuester Kommentar

Hi.

Es scheint, als könne das Konto, unter dem Dein Deploymenttool arbeitet, schlicht nicht auf \\Netzwerkpfad\ePlanv2.6\Electric P8 2.6.3.10395\License Client (Win32)\setup.exe zugreifen. Prüf das.

du hast natürlich recht. Es war beim deployen System User voreingestellt - bei Nutzung eines Domänenadmins lief es durch.
Vielen Dank wie immer @DerWoWusste

Ui - du nutzt nun einen Domänenadmin? Das ist doch eine schlechte Idee und sehr gefährlich. Gib lieber der Gruppe "authentifizierte Benutzer" oder meinetwegen der Gruppe "Domänencomputer" Leserechte auf das Setup. Das Systemkonto eines Domänenmitglieds kann immer auch im Netzwerk handeln.

Kannst du mir erklären warum das sehr gefährlich ist?
Es wurde für die Deployment Lösung ein AD Benutzer angelegt, welcher Mitglied der DomainAdmins ist. (ich bin nicht der Admin dieser Anwendung, ich bastel hier nur auf Krampf ein paar Pakete und lese mich ins Patchmanagement dieser Software ein)

Aber hab es eben nochmal über das Deploy Tool versucht mit den richtigen Credentials / klappt leider doch nicht.
Liegt aber am Paket in DesktopCentral / bin gerade mit Support in Kontakt.

Edit Support:
you will need to use the right set of script arguments to get elevated privileges to run the script through desktop central.
Ok, verstehe aber nicht warum es darunter "run as" gibt...

weißt du wie die Argumente aussehen könnten? im Anhang ein Screenshot

~~Wie arbeitet dein Tool, pusht es vim Server aus, oder arbeitet es mit Agents am Client (pull)?~~

Sorry, die Frage war ja nun überflüssig, wenn man das Skript sieht - es ist also ein Pull.
NImm das Systemkonto. Nachdem du die Berechtigungen wie zuvor benannt angepasst hast, wird das laufen.

Domänenadmins nimmt man immer nur zur Domänenadministration serverseitig und nicht clientseitig. Gefährlich deshalb, weil sonst die Kennwörter oder Kennworthashes dieser Superadmins in falsche Hände geraten können. Ds sollte man ruhig sehr ernst nehmen.

Zitat von @DerWoWusste:

Nachdem du die Berechtigungen wie zuvor benannt angepasst hast, wird das laufen.

Sorry das ich nochmal nachhake: also meinst du system user, jedoch verwirrt mich die Richtung des Supports ein wenig mit den Argumenten...

Mit Domänen Admin macht das Paket garnichts und bleibt hängen. Mit System User bekomme ich eben für jeden Teil des Scripts den obigen Fehler.

Was mir aufgefallen ist: So wirklich silent scheint es aber sowieso nicht zu sein. Wenn ich per cmd die bat aufrufe führt er die Installationen zwar selbstständig durch, die install shield Fenster erscheinen aber dennoch für den User sichtbar trotz aller Argumente /qn /l usw.

Aber egal, wichtig wäre mir in erster Linie nur das ich das nicht manuell für alle Workstations machen muss. Ich bin dir Dankbar für die Geduld und deine Hilfestellung.

Hallo,

Was mir aufgefallen ist: So wirklich silent scheint es aber sowieso nicht zu sein. Wenn ich per cmd die bat aufrufe führt er die Installationen zwar selbstständig durch, die install shield Fenster erscheinen aber dennoch für den User sichtbar trotz aller Argumente /qn /l usw.

Dann passen die Parameter halt nicht zur Installationsroutine Deiner Software.
Kann die Software ueberhaupt silent installiert werden? Hersteller gefragt?

BFF

Bin ich dran, wäre auch nicht so schlimm wenn ich das Script wenigstens Automatisch verteilen könnte.

Mit System User bekomme ich eben für jeden Teil des Scripts den obigen Fehler.

Ja, weil Du meinen Rat nicht befolgst und die Zugriffsrechte auf das Installationspaket nicht anpasst.

So wirklich silent scheint es aber sowieso nicht zu sein. Wenn ich per cmd die bat aufrufe führt er die Installationen zwar selbstständig durch, die install shield Fenster erscheinen aber dennoch für den User sichtbar trotz aller Argumente /qn /l usw.

Es gibt bei manchen Installern eine Unterscheidung silent/verysilent. Letzteres wäre "ohne alles", Ersteres ist noch mit sichtbaren Dialogen, die aber automatisch ablaufen. Vielleicht wird hier "verysilent" einfach nicht unterstützt - kein Grund zur Sorge.

Leider keine verysilent möglich, macht aber nichts.

Eben noch einmal nachgeguckt:
die .bat und Installfiles liegen im selben Netzwerkshare wie alle anderen Pakete - ich habe bereits 28 Pakete geschnürt die auch mit System User installiert werden und am selben Share liegen. (soeben noch einmal kontrolliert) - ich kapiers nicht.

Du machst nun mal folgendes: nimm Dir einen Rechner, wo das Paket noch nicht drauf ist und melde Dich als Administrator an. Starte eine cmd elevated und führe dort aus:
psexec -s -i cmd
(psexec ist Teil der MS pstools - zuvor runterladen)
Psexec öffnet Dir nun eine Shell mit Systemrechten und von da aus kannst Du testen, sprich, das Setup mit der vorgesehenen Kommandozeile einmal starten.

Sinn der Übung: herausfinden, ob dieses eine Setup als Systemkonto normal durchläuft. In ganz seltenen Fällen laufen Setups eben nicht als Systemkonto.

sysinternals sind spitze, nutzen unsere Admins schon seit Ewigkeiten. - vielen dank für den Tipp, selbe Fehlermeldung. - Somit muss dieses setup wohl über ein anderes Konto ausgeführt werden. - nun liegt es an der Deploy Software, denn mit Admin Credentials passiert beim deploy garnichts - logs sind bereits beim Support.

Du willst es irgendwie nicht verstehen...

Du hast dem msiexec als Argument das Paket gegeben und msiexec meldet: "ich kann es nicht erreichen". Gib dem Systemkonto die Zugriffsrechte auf das Paket.

wie mache ich das? bitte verzeih die Basisfragen, ich möchte es gerne verstehen. Du meinst das lokale Systemkonto? In welcher Gruppe ist es Mitglied? SYSTEM Gruppe hat vollen Zugriff auf den Share auf dem die bat liegt.

Oben schrieb ich:

Gib lieber der Gruppe "authentifizierte Benutzer" oder meinetwegen der Gruppe "Domänencomputer" Leserechte auf das Setup.

Dabei spreche ich von den NTFS- und Freigaberechten.

Ja, welche über ACL gereglt ist. Die haben ja alle das Recht. Auch "User" haben Leserecht auf dieses Share, er pullt die Datei auch in das Installationsverzeichnis des Agents am Client. Kann ich set "MSIE=%windir%\System32\msiexec.exe /i " credentials mitgeben?

Stop. Gib mir bitte zunächst mal die Ausgabe der am Server ausgeführten Kommandos

net share Freigabename

sowie

icacls laufwerk\ordnername\setup.exe

an.

Edit:
Schuld war der Proaktive Bedrohungsschutz SONAR von Symantec Endpoint Protection. Hat verhindert das msiexec in dem Kontext gestartet wird (Authentifizierung)
bin selbst gerade nur durch den Trouble Shooting Agent des Clients drauf gekommen....