Installation des Adobe Reader per Skript zeigt unerklärliches Verhalten
Hallo,
ich habe eine Kuriosität entdeckt aus der ich absolut nicht schlau werde. Ich hab das ganze mal als Microsoft allgemein eingeordnet, da ich nicht 100% sicher bin woran es liegt. Zum Hintergrund: Es muss bei uns sichergestellt sein, dass Adobe in einer gewissen Version vorliegt und dort das Adobe Plugin für Microsoft Azure Information Protection installiert ist. Leider haben wir derzeit noch keine Softwareverwaltung und das Azure Information Protection Projekt wurde höher priorisiert als die Softwareverteilung. ich bin daher gezwungen auf eine Verteilung per GPO auszuweichen. Dazu gibt es folgendes Skript:
Das Skript an sich funktioniert sowohl auf Windows 10 als auch auf Windows 8. Mir macht jedoch Zeil 10 zu schaffen. c:\temp\adobe\setup.exe /sall ist eigentlich ein sehr einfacher Befehl der nicht viel falsch machen kann. Die Lösung dafür stammt aus dem Adobe Forum: https://community.adobe.com/t5/acrobat-reader/adobe-reader-dc-15-023-sil ...
Was habe ich also gemacht: ich habe das aktuelle Setup heruntergeladen und mit 7Zip entpackt. Die Dateien liegen auf dem Server, werden lokal kopiert und anschließend ausgeführt. Erst das Setup, dann das MIP/AIP-Plugin. Das Setup vom Adobe enthält die Version 21.001.20135 und das Plugin 21.001.20145. Daher die entsprechenden Abfrage im Skript. Starte ich das Skript per Hand (als Administrator), wird die Software direkt richtig installiert. Manchmal muss ich das Skript insgesamt 3 Mal ausführen. Dies äußert sich dann so.
1. Die Dateien werden lokal abgelegt und das Adobe Setup startet. Das Plugin kann dann nicht installiert werden, weil der Adobe-Client den Installer noch beansprucht. Wäre theoretisch lösbar durch ein Sleep zwischen den IF-Abfragen. Da es jedoch nur temporär und einmalig ist um jetzt das Setup zu verteilen bis der Server für die Softwareverteilung fertig ist, kann ich damit leben.
2. Wenn das Plugin nicht direkt installiert wird, wird im zweiten Durchgang das Plugin installiert.
3. Wenn das Plugin und Adobe auf der entsprechenden Version installiert sind, werden die Dateien gelöscht. Dies passiert im ersten Durchgang nicht, da die Bedingung nur beim Skriptstart geprüft wird. Wäre leicht lösbar indem ich nach dem Setup die beiden Check-Variablen neu einlese/prüfe, also Zeile 1 und 2 erneut ausführe.
Da ich mit der ggf. drei-fach-Ausführung sehr gut leben kann, habe ich das Skript nun an Windows 8 und 10 Rechner ausgerollt. Testweise erstmal nur an einen, dann an zwei weitere, jetzt nochmal an 3 weitere. Konfiguriert ist das ganze als geplante Aufgabe die die System-Berechtigungen bei der Ausführung nutzt. Das Skript soll bei der User-Anmeldung und täglich um 12:00 Uhr ausgeführt werden, jeweils alle 5 Minuten für die Dauer von 30 Minuten wiederholen). Frohen Mutes habe ich also den nächsten Tag (das war Freitag) abgewartet und meine Abfrage (ebenfalls über PS) ergab. Keine Installation durchgeführt. Bei der Ursachenforschung habe ich folgenden Eintrag gefunden:
und
Keine weiteren Meldungen in irgendeinem Protokoll. Das ganze hat mich Freitag verwirrt. Wieso wird beim Aufruf des 21.001.20145-Setups versucht eine Produktversion 15.007.20033 zu installieren. Da passt was nicht zusammen. Da Freitag (und Feierabend) war, habe ich mich damit nicht weiter beschäftigt. Man kann ja auch mal Dinge auf die nächste Woche schieben. Gestern war ich nicht da, also wollte ich der Sache heute auf den Grund gehen. Zu meiner Überraschung stellte ich fest, dass die 19er-Version bei den Testrechnern durch die 21er ersetzt wurde. Sprich: Das gleiche Update was am Freitag noch die 15er installieren wollte hat gestern in meiner Abwesenheit die 21er installiert. Zufall? Updatekomplikationen?
Gehen wir der Sache auf den Grund. Ich habe also einen neuen Rechner installiert, per Hand von DVD. Keine weitere Software drauf. Rein in die Domäne, zur Testgruppe hinzugefügt und Situation geprüft. geplanter Task ist vorhanden. Am Rechner angemeldet, Setup-Dateien wurden lokal abgelegt. Abgewartet, aber kein Adobe tauchte auf. Logs geprüft: Erneut der Versuch die 15er Version zu installieren fehlgeschlagen. weiter gewartet und alle 5 Minuten das Protokoll geprüft. Die ersten vier Anläufe gingen wieder schief, da die 15er Version nicht installiert werden konnte. der 5te Durchlauf des Skriptes war dann auf einmal erfolgreich und die 21er wurde installiert, genau wie das Plugin. Danach wurde wie erwartet der Setup-Ordner gelöscht.
Fazit: Die gleiche Setup-Datei versucht bei identischen Berechtigungen mal die 15er und mal die 21er Version zu installieren. Die 21er funktioniert auf Anhieb. Die Fehlerquelle Kollege kann ich ausschließen, da ich heute alleine bin. Auch die Ausführung als System funktioniert. Es spielt daher auch keine Rolle ob es als normaler Anwender oder als Administrator ausgeführt wird. Das Verhalten tritt auch beim Domänen-Admin am Client auf, kann aber nicht gezielt reproduziert werden. Manchmal wird beim ersten Setup direkt die 21er installiert. Manchmal dauert es 2 Tage. Auch das händisch starten der geplanten Aufgabe führt manchmal zu dem entsprechenden Fehler. Wenn ich das Skript händisch ausführe klappt es immer. Ich habe daher die Vermutung, dass die Ursache in der Aufgabenplanung zu finden ist, allerdings fehlen mir weitere Ideen und Anhaltspunkte. Hat jemand schonmal ein ähnliches Verhalten beobachtet?
Gruß
Doskias
ich habe eine Kuriosität entdeckt aus der ich absolut nicht schlau werde. Ich hab das ganze mal als Microsoft allgemein eingeordnet, da ich nicht 100% sicher bin woran es liegt. Zum Hintergrund: Es muss bei uns sichergestellt sein, dass Adobe in einer gewissen Version vorliegt und dort das Adobe Plugin für Microsoft Azure Information Protection installiert ist. Leider haben wir derzeit noch keine Softwareverwaltung und das Azure Information Protection Projekt wurde höher priorisiert als die Softwareverteilung. ich bin daher gezwungen auf eine Verteilung per GPO auszuweichen. Dazu gibt es folgendes Skript:
# Installationsstatus abfragen
$check_adobe=Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Sort Displayname | Select-Object DisplayName, DisplayVersion, InstallDate |? displayname -like "*Adobe Acrobat Reader DC*"
$check_MIP=Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Sort Displayname | Select-Object DisplayName, DisplayVersion, InstallDate |? displayname -like "*Microsoft Azure Information Protection Plugin For Adobe Acrobat Reader*"
# Adobe prüfen
if ($check_adobe.DisplayVersion -ne "21.001.20145")
{
if (!(Test-Path c:\temp\adobe)){New-Item C:\Temp\Adobe -ItemType Directory}
Copy-Item \\Server\Software\Adobe_Aip\* C:\temp\Adobe\
c:\temp\adobe\setup.exe /sall
}
#MIP-Plugin prüfen
if ($check_MIP.DisplayVersion -ne "21.001.20135")
{
if (!(Test-Path c:\temp\adobe)){New-Item C:\Temp\Adobe -ItemType Directory}
Copy-Item \\Server\Software\Adobe_Aip\* C:\temp\Adobe\
C:\Temp\Adobe\AIPPlugin_Reader_DC_Cont_Feb21.msi /quiet
}
if (Test-Path c:\temp\adobe)
{
if ($check_adobe.DisplayVersion -eq "21.001.20145")
{
if ($check_MIP.DisplayVersion -eq "21.001.20135")
{Remove-Item c:\temp\adobe\ -Recurse -Force
}
}
}
Das Skript an sich funktioniert sowohl auf Windows 10 als auch auf Windows 8. Mir macht jedoch Zeil 10 zu schaffen. c:\temp\adobe\setup.exe /sall ist eigentlich ein sehr einfacher Befehl der nicht viel falsch machen kann. Die Lösung dafür stammt aus dem Adobe Forum: https://community.adobe.com/t5/acrobat-reader/adobe-reader-dc-15-023-sil ...
Was habe ich also gemacht: ich habe das aktuelle Setup heruntergeladen und mit 7Zip entpackt. Die Dateien liegen auf dem Server, werden lokal kopiert und anschließend ausgeführt. Erst das Setup, dann das MIP/AIP-Plugin. Das Setup vom Adobe enthält die Version 21.001.20135 und das Plugin 21.001.20145. Daher die entsprechenden Abfrage im Skript. Starte ich das Skript per Hand (als Administrator), wird die Software direkt richtig installiert. Manchmal muss ich das Skript insgesamt 3 Mal ausführen. Dies äußert sich dann so.
1. Die Dateien werden lokal abgelegt und das Adobe Setup startet. Das Plugin kann dann nicht installiert werden, weil der Adobe-Client den Installer noch beansprucht. Wäre theoretisch lösbar durch ein Sleep zwischen den IF-Abfragen. Da es jedoch nur temporär und einmalig ist um jetzt das Setup zu verteilen bis der Server für die Softwareverteilung fertig ist, kann ich damit leben.
2. Wenn das Plugin nicht direkt installiert wird, wird im zweiten Durchgang das Plugin installiert.
3. Wenn das Plugin und Adobe auf der entsprechenden Version installiert sind, werden die Dateien gelöscht. Dies passiert im ersten Durchgang nicht, da die Bedingung nur beim Skriptstart geprüft wird. Wäre leicht lösbar indem ich nach dem Setup die beiden Check-Variablen neu einlese/prüfe, also Zeile 1 und 2 erneut ausführe.
Da ich mit der ggf. drei-fach-Ausführung sehr gut leben kann, habe ich das Skript nun an Windows 8 und 10 Rechner ausgerollt. Testweise erstmal nur an einen, dann an zwei weitere, jetzt nochmal an 3 weitere. Konfiguriert ist das ganze als geplante Aufgabe die die System-Berechtigungen bei der Ausführung nutzt. Das Skript soll bei der User-Anmeldung und täglich um 12:00 Uhr ausgeführt werden, jeweils alle 5 Minuten für die Dauer von 30 Minuten wiederholen). Frohen Mutes habe ich also den nächsten Tag (das war Freitag) abgewartet und meine Abfrage (ebenfalls über PS) ergab. Keine Installation durchgeführt. Bei der Ursachenforschung habe ich folgenden Eintrag gefunden:
Das Produkt wurde durch Windows Installer installiert. Produktname: Adobe Acrobat Reader DC - Deutsch. Produktversion: 15.007.20033. Produktsprache: 1031. Hersteller: Adobe Systems Incorporated. Erfolg- bzw. Fehlerstatus der Installation: 1635.
und
Produkt: Adobe Acrobat Reader DC - Deutsch -- Installation fehlgeschlagen.
Keine weiteren Meldungen in irgendeinem Protokoll. Das ganze hat mich Freitag verwirrt. Wieso wird beim Aufruf des 21.001.20145-Setups versucht eine Produktversion 15.007.20033 zu installieren. Da passt was nicht zusammen. Da Freitag (und Feierabend) war, habe ich mich damit nicht weiter beschäftigt. Man kann ja auch mal Dinge auf die nächste Woche schieben. Gestern war ich nicht da, also wollte ich der Sache heute auf den Grund gehen. Zu meiner Überraschung stellte ich fest, dass die 19er-Version bei den Testrechnern durch die 21er ersetzt wurde. Sprich: Das gleiche Update was am Freitag noch die 15er installieren wollte hat gestern in meiner Abwesenheit die 21er installiert. Zufall? Updatekomplikationen?
Gehen wir der Sache auf den Grund. Ich habe also einen neuen Rechner installiert, per Hand von DVD. Keine weitere Software drauf. Rein in die Domäne, zur Testgruppe hinzugefügt und Situation geprüft. geplanter Task ist vorhanden. Am Rechner angemeldet, Setup-Dateien wurden lokal abgelegt. Abgewartet, aber kein Adobe tauchte auf. Logs geprüft: Erneut der Versuch die 15er Version zu installieren fehlgeschlagen. weiter gewartet und alle 5 Minuten das Protokoll geprüft. Die ersten vier Anläufe gingen wieder schief, da die 15er Version nicht installiert werden konnte. der 5te Durchlauf des Skriptes war dann auf einmal erfolgreich und die 21er wurde installiert, genau wie das Plugin. Danach wurde wie erwartet der Setup-Ordner gelöscht.
Fazit: Die gleiche Setup-Datei versucht bei identischen Berechtigungen mal die 15er und mal die 21er Version zu installieren. Die 21er funktioniert auf Anhieb. Die Fehlerquelle Kollege kann ich ausschließen, da ich heute alleine bin. Auch die Ausführung als System funktioniert. Es spielt daher auch keine Rolle ob es als normaler Anwender oder als Administrator ausgeführt wird. Das Verhalten tritt auch beim Domänen-Admin am Client auf, kann aber nicht gezielt reproduziert werden. Manchmal wird beim ersten Setup direkt die 21er installiert. Manchmal dauert es 2 Tage. Auch das händisch starten der geplanten Aufgabe führt manchmal zu dem entsprechenden Fehler. Wenn ich das Skript händisch ausführe klappt es immer. Ich habe daher die Vermutung, dass die Ursache in der Aufgabenplanung zu finden ist, allerdings fehlen mir weitere Ideen und Anhaltspunkte. Hat jemand schonmal ein ähnliches Verhalten beobachtet?
Gruß
Doskias
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665689
Url: https://administrator.de/forum/installation-des-adobe-reader-per-skript-zeigt-unerklaerliches-verhalten-665689.html
Ausgedruckt am: 22.12.2024 um 07:12 Uhr
6 Kommentare
Neuester Kommentar
Moin,
warum installiert ihr den "Quatsch" per Script + GPO und nicht nativ per GPO:
https://www.adobe.com/devnet-docs/acrobatetk/tools/DesktopDeployment/gpo ...
Dazu noch via Customa###Wizard das msi anpassen und als mst abspeichern.
für ein Slipstream der msp-Files in die Basis msi:
https://community.spiceworks.com/how_to/37467-how-to-create-a-slipstream ...
Hinweis:
Für die (automatische) Verteilung im Unternehmen ist ein Agreement mit Adobe erforderlich.
Gruß
em-pie
warum installiert ihr den "Quatsch" per Script + GPO und nicht nativ per GPO:
https://www.adobe.com/devnet-docs/acrobatetk/tools/DesktopDeployment/gpo ...
Dazu noch via Customa###Wizard das msi anpassen und als mst abspeichern.
für ein Slipstream der msp-Files in die Basis msi:
https://community.spiceworks.com/how_to/37467-how-to-create-a-slipstream ...
Hinweis:
Für die (automatische) Verteilung im Unternehmen ist ein Agreement mit Adobe erforderlich.
Gruß
em-pie