Installation von Office 2019 funktioniert per Winst, nicht jedoch vom OPSI-Server aus?

[IvicaE]

Hallo Leute,

ich habe die Aufgabe ein Office 2019-Paket für OPSI zu erstellen.
Ich kämpfe nun seit ein paar Tagen damit herum obwohl die Installation ja sehr einfach zu sein scheint.
Per ODT funktioniert die Installation ja super einfach und reibungslos. Ich habe 3 XML-Dateien erstellt (MS bietet Online ein tolles Tool dafür) für die Installation von 32-Bit- und 64-Bit-Versionen und die Deinstallation von Office 2019.
Installiere ich es komplett manuell per Konsole (CMD) funktioniert das Installieren und Deinstallieren super.
Nutze ich die Winst mit einem Setup- und Uninstall-Script, welche ich für Office 2019 angelegt habe, indem ich auf dem Client dies dann 'manuell' starte funktioniert es auch super (1 Warnung die ich jedoch nicht finden kann -> hat alles funktioniert und somit ignoriere ich so was dann).
Pake ich daraus aber ein OPSI-Paket, installiere es auf den OPSI-Server und führe es dann dort auf dem gleichen Client aus bei welchem es vormals per manueller Winst-Installation geklappt hat, funktioniert es nicht mehr und OPSI meldet im LOG ein Fehler mit unbekanntem Exit-Code!


Wie kann das sein? Ich dachte Winst per Hand und vom OPSI-Server sind ein und die selbe Geschichte? Was kann ich nun machen? Habt ihr ein Office 2019 Installation hinbekommen? Hattet ihr auch ähnliche Probleme? Für eure Hilfe wäre ich sehr dankbar da ich so langsam an dieser Geschichte verzweifle...

Schon einmal im voraus vielen Dank für eure Mühe!

[Jan.Schmidt]

o2k instalier(t)e ich immer über einen copyjob des installers auf den client und dann danach ein setup von dem Client aus.
Die installerdateistruktur bleibt auf dem client u.a wegen reparaturinstallationen, die man manchmal machen muß.

Imho geht das nicht anders.

[magicalUnicorn]

Moin,

wie sieht denn die Struktur deiner Sources aus? Bei unseren alten 2016/2019 ProPlus Office hatten wir da n richtigen offline Installer. Für Office 365 gibts ja nur die Setup-Exe. Da kannst du zwar die Sources für auch runterladen und neben der Setup.Exe im Ordner "office" ablegen, da funktioniert dann aber die Installation von der OPSI-Freigabe nicht mehr.

Der ExitCode ist in dem Fall "17004". Das Fang ich im Skript einfach ab und kopiere in dem Fall die Dateien lokal auf den Rechner und führe von dort aus. So wie Jan das auch schon geschrieben hat.

[IvicaE]

Hi,

ich habe zum ersten mal das "Office Deployment Tool" (ODT) benutzt und musstem ich selber erstmal reinlesen / ausprobieren.
Es ist also eine setup.exe enthalten die auf der Kommandozeile ausgeführt / bedient wird.
Ein Parameter legt fest was zu tun ist (ich nutze einmal den Parameter 'configure' und davor den 'download'.
Ein dritter Parameter übergibt die Konfigurations-Datei in Form einer XML. Diese XML kann man manuell erstellen oder ganz gemütlich und recht einfach auf der Webseite von MS den Konfigurator für die Konfigurationsdatei nutzen und die fertige XML abschliessend herunterladen.

So, ich habe mir erstmal 2 XML-Dateien erstellt: einmal für die 32-Bit-Version von Office 2019 PP und einmal die 64-Bit-Version.
Unser ERP-System hat, obwohl modern, noch seine Schwierigkeiten mit der Office-Integration in 64-Bit und somit verteilen wir noch hauptsächlich die 32-Bit-Version.

Dann habe ich erstmal die Installationsdateien heruntergeladen per ODT (-> als 2. Parameter das '/download' gesetzt statt '/configure') so daß der ODT tatsächlich erstmal in relativ langer Zeit die Installationsdateien heruntergeladen hat und dort abgelegt hat wie es in der XML als Quell-Pfad für die Office-Installation hinterlegt wurde. Das habe ich für die 32-Bit-Version und danach für die 64-Bit-Version so gemacht.
Die Installationsdateien befinden sich auf einer Share auf unserem Dateiserver.

Wenn ich nun die Installation vornehme, funktioniert es wunderbar, auch wenn alles auf dem Share verweilt.

Code: Alles auswählen

"\\servername.firma.local\Freigabe$\Office 2019\ODT\setup.exe" /configure "\\servername.firma.local\Freigabe$\Office 2019\ODT\Install-32.xml"

Mache ich daraus ein Paket, kopiere alles lokal auf den Zielrechner und führe dort manuell, als Administrator, die winst.exe von OPSI und wähle das Setup-Script aus und führe es aus -> funktioniert das ebenso!

Erstelle ich ein Paket für den OPSI-Server aus genau diesen, unveränderten OPSI-Scripten, installiere es auf den OPSI-Server und 'drücke es herunter' (Wie gehabt -> in configed Ziel auswählen, Produkt auf Setup setzen, Speichern und 'on demand' ausführen), so wird es auf dem Zielserver ausgeführt und dann jedoch abgebrochen mit der Fehlermeldung das der Errorcode nicht gefunden werden kann o.ä.

So, ich dachte immer daß die manuelle Winst.exe-Ausführung 1:1 mit der OPSI-Server-Ausführung ist nur das die manuelle Ausführung mit Admin-Berechtigung funktioniert und der OPSI-Server mit Systemberechtigung ausführt.
An was kann das liegen?

Jedenfalls habe ich, bis auf die Installationsquelle, die Daten (die setup.exe und die XML-Dateien) mit ins OPSI gepackt und von dort, statt über den Fileserver-Share also lokal, ausführen lassen. Es war der gleiche Fehler obwohl es manuell per winst.exe wieder funktioniert hat.

Wo liegt hier das Problem? Nutzt ihr auch das ODT zum Installieren von Office? Funktioniert das bei euch? Wenn nein: was ist die Alternative? Wenn jka, musstet ihr noch was beachten/machen damit es funktioniert?

[magicalUnicorn]

Hey, wie ich schon sagte:

Office hat was dagegen, wenn die Sources auf einem Netzlaufwerk liegen. Hab dazu irgendwo auch Mal n Post von M$ selber gefunden. Wenn ich den wieder finde lass ich ihn dir als.link hier.

Du musst die Sources also immer lokal auf den Rechner kopieren, sonst schlägt der Installer mit dem ExitCode 17004 fehlt.

Ich probiere aber trotzdem immer erst die Installation ohne kopieren, damit Clients die das WAN-Modul bitte da nicht unnötig die Daten verdoppeln. Ich kann morgen gerne Mal mein Skript da lassen

[IvicaE]

@magicalUnicorn

Aber der gleiche Vorgang funktioniert doch per Kommandozeile und auch per Winst und OPSI-Script?
So wie du das sagst klingt es so als ob Office was dagegen hätte wenn die Sources auf einem Share liegen und das stimmt ja nicht da es ja funktioniert.
Nur eben nicht wenn der OPSI-Server dies macht.

Wie ich dir das hier so schreibe kommt mir der Gedanke dies per "RunAs" zu machen und zwar mit dem Administrator. Dann läuft das Script ja nicht mit Systemrechten sondern Adminrechten und somit wäre auch die letzte Abweichung zum manuellen Winst-Vorgang beseitigt. Müsste es nicht dann absolut gleich sein und funktionieren?

Bei deinem letzten Satz: du hast ein Script welches zuerst versucht das vom Share aus zu erledigen und wenn du den Exitcode 17004 abfängst, kopierst du die Installationdateien lokal und machst es nochmals? Hmm, die Idee ist auch nicht schlecht. Kannst ja mal posten dein Script falls du es findest. Andernfalls kann ich mich auch mal versuchen. Bei diesem Vorgang muss ich ja in der Exit-Routine nur den Code Abfragen und eine Subroutine starten die dann kopiert und die Installation nochmals startet mit der entsprechenden XML-Konfigurationsdatei die kein Pfad zur Quelle angibt und somit automatisch das 'ODT'-Unterverzeichnis verwendet (habe ich gerade aus dem Kopf heraus, kann auch anders genannt sein).

[Jan.Schmidt]

Wie ich dir das hier so schreibe kommt mir der Gedanke dies per "RunAs" zu machen und zwar mit dem Administrator. Dann läuft das Script ja nicht mit Systemrechten sondern Adminrechten und somit wäre auch die letzte Abweichung zum manuellen Winst-Vorgang beseitigt. Müsste es nicht dann absolut gleich sein und funktionieren?

DAS / den Gedanken läßt du mal bitte ganz schnell wieder dort versinken wo es hingehört.
Les dir mal den Fred [OT} DFN Institut gehäckt durch...
Denn hinter Adminrechten und passwörtern im klartext steckt auch ein "ein" Adminpasswort, dass global genutzt wird drin und das machst du bitte nicht.

dumme lernen durch eigene Fehler
schlaue durch Fehler die die anderen gemacht haben.

[magicalUnicorn]

@magicalUnicorn

Aber der gleiche Vorgang funktioniert doch per Kommandozeile und auch per Winst und OPSI-Script?
So wie du das sagst klingt es so als ob Office was dagegen hätte wenn die Sources auf einem Share liegen und das stimmt ja nicht da es ja funktioniert.
Nur eben nicht wenn der OPSI-Server dies macht.

Hast du denn wenn du das OPSI-Script via Winst ausführst die Sources auch auf dem Netzlaufwerk liegen? Wird aber vermutlich mit Berechtigungen o.Ä. zusammenhängen, da das ganze dann ja in deinem User-Kontext läuft. Auf jeden Fall hattest nicht nur du das Problem siehe: viewtopic.php?p=55446&hilit=17004#p55446
Oder gib in der Suche mal 17004 ein, da findest du ein paar Threads.

Der relevante Teil meines Skripts sieht wie folgt aus. Ist wahrlich nicht perfekt, aber es funktioniert

Code: Alles auswählen

Files_Copy_Install_Config
Winbatch_Silent_Install /64Bit

Set $exitCode$ = getLastExitCode

;Exitcode 0 = Erfolg. Exitcode 17004 = Ausführungsfehler wegen Samba-Share
;Wenn Exitcode 17004 erkannt wird, werden die Sources lokal kopiert und dann installiert
if not($exitCode$ = "0")
    if ($exitCode$ = "17004")

        LogWarning "ExitCode ist $exitCode$. Will try to copy sources to local Directory and install from there"

        ;Eigentlich nur ~4GB erforderlich, aber wegen kopieren werden 8GB abgefragt
        failOnInsufficientDriveSpace($InstDrive$, "8GB")
        Files_Copy_Sources
        ChangeDirectory $TempSourceLocation$
        Winbatch_Silent_Install /64Bit

        Set $exitCode$ = getLastExitCode
        if not($exitCode$ = "0")
            LogError "Installation of $productId$ failed. Exit code: " + $exitCode$
            isFatalError "$productId$ failed: " + $exitCode$
        endif
    else
        LogError "Installation of $productId$ failed. Exit code: " + $exitCode$
        isFatalError "$productId$ failed: " + $exitCode$
    endif
endif

[Winbatch_Silent_Install]
setup.exe /configure "$TempSourceLocation$\install_office365_$organisation$.xml"

[Files_Copy_Install_Config]
copy "%SCRIPTPATH%\copy\install_office365_$organisation$.xml" $TempSourceLocation$

[Files_Copy_Sources]
copy -s "%SCRIPTPATH%\sources\Office" $TempSourceLocation$
copy "%SCRIPTPATH%\sources\setup.exe" $TempSourceLocation$

[Files_Cleanup_Local_Sources]
del -s -f $TempSourceLocation$

[Jan.Schmidt]

Wird aber vermutlich mit Berechtigungen o.Ä. zusammenhängen, da das ganze dann ja in deinem User-Kontext läuft.

Bei Windoof kann man per GPO setzen welche UNC Pfade / Netwerkshares als Intranet und damit sicher gelten und da den OPSI eintragen.
Diese GPOs gelten für AD Maschinen - stellt man in den GPOs bei Computern ein oder für AD Benutzer stellt man unter User ein.
OPSI läuft aber unter mit einem Maschinenlokalen Benutzer namens System.

So einfach isses und der Workaround ist nun mal so wie er ist.

[Michael H.]

Hallo,
versuche das mal beim Paket erstellen die Parameter
opsi-makepackage --no-compression --no-pigz
Ohne diese Parameter sind manche Pakete (z.b. Office Offline Installer) zu groß und die Dateien im Paket werden corupted.
Das ist ein Problem von der Zip Software die OPSI benutzt

Gruß
Michael