forum.opsi.org

Hallo Leute,

ich hätte da mal wieder ein Problemchen:

Ich setze gerade die Deinstallation unseres alten ERP-Clients in OPSI um um anschliessend die Installation des neuen Client per OPSI umzusetzen.
In beiden Fällen sind das aber Batchdateien die auf dem ERP-Server in einer Freigabe zu finden sind. Der ERP-Server selber ist in der Domäne und kann von jedem Client aus aufgerufen werden. Ist silent und manuell funktioniert es auch wunderbar!

So, ich habe also die Deinstallation erstellt und manuell per Winst auf einem OPSI-Client funktioniert das Paket auch wunderbar und das ERP-Programm wird deinstalliert (auch die ODBC-Treiber im zweiten Schritt ebenfalls).

Wenn ich das Paket aber auf dem OPSI-Server installiere und per configed 'herunterdrücke', funktioniert es nicht mehr!
Laut LOG findet er den Pfad und die Datei zum BATCH-Script auf der ERP-Server nicht.
So, da habe ich mir kurz Gedanken gemacht und denke das dasOPSI nicht als Domänen-Admin ausgeführt wird und als nicht Domänen-Benutzer die Freigabe nicht nutzen kann. Daran wird es sicherlich liegen.
So, die Frage jetzt ist aber: was dann? Ok, ich kann die Batchdatei auseinandernehmen und im OPSI-Script abbilden, sobald er aber in der Batchdatei weitere Scripte, Dateien o.ä. nutzen möchte die ebenfalls in Shares in der Dom#äne liegen, habei ch knapp verloren.

So, die Frage ist nun: wie macht ihr das? Was ist der beste Weg sowas zu lösen? Kann ich in OPSI ein Netzlaufwerk verbinden mit eigenen Logindaten? Die werde ich nicht in Batchdateien hinterlegen, in OPSI wäre es aber akzeptabel. Oder kann jemand gar einen anderen Lösungweg vorschlagen?

Also, ich habe das Problem mit der fehlenden Berechtigung auf Server-Shares in der Domäne so gelöst daß ich in einer Winbatch-Sektion ganz normal ein
ausgeführt habe und diesen Pfad dann genutzt statt des UNC-Pfades.
Am Ende aller Vorgänge wird das Maping mit
wieder aufgehoben.


Jetzt habe ich aber ein Problem mit dem Deinstallieren der Progress-ODBC-Treiber. Diese Deinstallations-Setup befindet sich lokal in
Wenn ich das Script an den Client übertrage und dort manuell per Winst ausführe -> alles gut!
Wenn ich das Script vom OPSI herunterdrücke -> gibt es einen ExitCode -2147213312 und wird unfertiger Dinger beendet!

Hier der Abschnitt meiner Logdatei:
Der einzige Unterschied den ich sehe wenn ich die LOG des OPSIs und die des winst (lokal) vergleiche ist
So, jetzt verstehe ich nicht ganz was das soll?
Ich verstehe wenn UNC-Pfade, wenn Berechtigungen im Netzwerk und der Gleichen falsch sind oder fehlen.
Aber hier verstehe ich jetzt nichtsu nd habe nicht einmal einen Ansatzpunkt!

Da wir zwischen den Feiertagen das Projekt abwickeln werden, und es bei mir zeitlich etwas pressiert, hat mein Vorgesetzter schon angedroht es per BATCH-Datei als LOGON-Skript auszuführen... Viel Spaß werde ich dann haben bei allen PCs mich anzumelden, abzuwarten bis alles erledigt ist und wieder abmelden statt des lokeren bedienen per configed aus der EDV heraus...

Hallo,

kann es vielleicht sein das beim Ausführen als System, die uninstall.iss nicht gefunden wird

>>So, jetzt verstehe ich nicht ganz was das soll?
Wenn Du winst manuell startest, läuft es in Deinem Benutzerkontext.
Wenn winst 'per OPSI' für die automatisierte Installation gestartet wird, läuft es im Benutzerkontext 'system'.

Hänge mal an Deinen Aufruf ein -f2%Temp%\My.log dran. Damit sollte InstallShield ein Log erzeugen. Das vielleicht Aufschluß gibt.
Weitere Möglichkeit könnte sein, daß der Installer lesend/schreibend ins user profile möchte. Da der user system keins hat - zumindest kein vollwertiges - gibt es dann Spaß.

@uncle_scrooge

Hänge mal an Deinen Aufruf ein -f2%Temp%\My.log dran

Das hat zwar nicht direkt geholfen (vielleicht weil %Temp% -> das temporäre Untervezreichnis von Windows ist und sich normalerweise in AppData\Local vom User befindet -> SYSTEM-User geht dann wohl nicht).

ABER:
Sobald ich statt

-f2%Temp%\MyOpsi.log

-f2c:\MyOpsi.log

setze funktioniert es! Ich kann die Progress-ODBC-Trebier deinstallieren!
Ich weiß zwar jetzt immer noch nicht ob es das Problem des fehlenden Userprofiles von 'SYSTEM' war (wahrscheinlich) oder was anderes, aber es funktioniert!
Vielen Dank dafür!

Das hat dann in diesem Fall nichts mit dem profile zu tun.
Die alten InstallShield-Installer (und wenn Du mit einer iss arbeiten mußt, ist Deiner fast so alt wie ich) schreiben eigentlich immer ein Log. Aber versuchen es meistens da, wo sie nicht dürfen.
Durch das Umbiegen auf einen beschreibbaren Pfad hat er keinen mehr auf die Nase bekommen.