Funkcionalnosć toś togo sedła se pśez wótwardowańske źěła wobgranicujo, kótarež maju wašo dožywjenje pólěpšyś. Jolic nastawk waš problem njerozwězujo a cośo pšašanje stajiś, wobrośćo se na našo zgromoźeństwo pomocy, kótarež na to caka, wam na @FirefoxSupport na Twitter a /r/firefox na Reddit pomagaś.

Pomoc pśepytaś

Glědajśo se wobšudy pomocy. Njenapominajomy was nigda, telefonowy numer zawołaś, SMS pósłaś abo wósobinske informacije pśeraźiś. Pšosym dajśo suspektnu aktiwitu z pomocu nastajenja „Znjewužywanje k wěsći daś“ k wěsći.

Dalšne informacije

Firefox 60.9.0 ESR remaining after newer version silent install

  • 1 wótegrono
  • 1 ma toś ten problem
  • 27 naglědow
  • Slědne wótegrono wót m30guy

more options

Attempting to patch a corporate template (reason why the version is so old) and when using any later ESR installer with the -ms parameters the old version remains.

The installer returns a 0 exit code when done through our scripting. However it never actually installs.

Being ESR there are no logs.

When you manually install everything goes fine. The scripting handles elevating permissions, we use the same functionality across the enterprise so we know this should not be the issue.

However, and this is the odd part, if we "inject" a new installer in our scripting it will install if done without any other actions. However, for production support we have many other third party app updates.

I was leaning towards app conflicts (maybe handle locks on required libs etc) but after much testing, there are no conflicts.

I am at a loss. Any thoughts?

Attempting to patch a corporate template (reason why the version is so old) and when using any later ESR installer with the -ms parameters the old version remains. The installer returns a 0 exit code when done through our scripting. However it never actually installs. Being ESR there are no logs. When you manually install everything goes fine. The scripting handles elevating permissions, we use the same functionality across the enterprise so we know this should not be the issue. However, and this is the odd part, if we "inject" a new installer in our scripting it will install if done without any other actions. However, for production support we have many other third party app updates. I was leaning towards app conflicts (maybe handle locks on required libs etc) but after much testing, there are no conflicts. I am at a loss. Any thoughts?

Wšykne wótegrona (1)

more options

Forgot to mention this is on Windows Server 2012 R2 x64 (yes I know using servers as client platforms is wonky)