Deployment ended: Incorrect function on Java update

[JoshD]

I have repeated failure on scheduled deployments on my java updates since I started using Lansweeper at my company. It usually takes almost 2 weeks for the deployments to succeed on all clients. My question is why do I get the dreaded "Deployment ended: Incorrect function" on one day on a client and the very next day it succeeds without me changing anything?

From the installer logs:

Log Date-----------------Package----Message
01/22/2019 01:18:37----Javaupdate-Result: Deployment ended: The operation completed successfully. Stop(Success).
01/22/2019 00:37:27----Reboot-----Result: Deployment ended: The operation completed successfully. Stop(Success).
01/21/2019 01:10:08----Javaupdate-Result: Deployment ended: Incorrect function. Stop(Failure).
01/21/2019 00:39:03----Reboot-----Result: Deployment ended: The operation completed successfully. Stop(Success).

As you can see I reboot the machine 30 minutes before the install so the machine is cleanly booted without any apps open to interfere. I deploy on about 300 assets and the majority of them fail for 2 weeks with only 30 or so each day succeeding. That many failures for multiple days in a row rules out windows update or the machine taking too long to boot. The deployment I run is simple with 1 step. The command is below with the switches I use specified by the Java website for offline install:

"\\vmhost\DefaultPackageShare$\Installers\jre-8u201-windows-i586.exe" INSTALL_SILENT=Enable WEB_ANALYTICS=Disable REBOOT=Disable REMOVEOUTOFDATEJRES=1

Credentials used are the Domain Administrator. On a side note the deployment almost always succeeds if I manually deploy on individual machines, but I cant be doing that while users are on the machines so it must be done overnight on a scheduled deployment.

[JacobH]

Kind of related, but when I used LS deployment, and the step 'technically' finished - returned a success code, but spawned other processes like the above poster said, I'd have issues as well.

What I ended up doing is, once I figured out the steps of what it was doing, I put a dos command to wait or sleep for like 30 seconds, then GOTO the specific check that was spawned to see if it was complete... if not, wait another 30 seconds and go back to the step.... if its good, go to the next real step.

[CyberCitizen]

I have experienced the same issue previously with a few packages, yet running the same thing works fine. But I don't reboot my machines beforehand as we have a lot of staff that work remotely via VPN (construction company). I sometimes wish for a nice office with desktops that I could just WOL at night and push everything out.

Are you seeing this with a lot of packages or just your Java package?

Below is what I am using for our Java deployments. I am calling an uninstall first, then when installing the new version I am also issuing REMOVEOUTOFDATEJRES=1

<?xml version="1.0" encoding="utf-8"?>
<Package>
  <Name>APP.Java</Name>
  <Description></Description>
  <ShutdownOption>0</ShutdownOption>
  <ShutdownTime>0</ShutdownTime>
  <MaxDuration>900</MaxDuration>
  <Rescan>True</Rescan>
  <RunMode>2</RunMode>
  <Steps>
    <Step>
      <Nr>1</Nr>
      <Name>Uninstall Previous Versions Of Java</Name>
      <Type>2</Type>
      <ReturnCodes>0,1641,3010</ReturnCodes>
      <Success>2</Success>
      <Failure>2</Failure>
      <Path></Path>
      <Parameters></Parameters>
      <MSIParameters></MSIParameters>
      <MSIName></MSIName>
      <MSIVersion></MSIVersion>
      <Command>wmic product where "name like 'Java%%'" call uninstall /nointeractive</Command>
      <EditMode>False</EditMode>
      <Conditions />
    </Step>
    <Step>
      <Nr>2</Nr>
      <Name>Check Architecture</Name>
      <Type>5</Type>
      <ReturnCodes></ReturnCodes>
      <Success>3</Success>
      <Failure>4</Failure>
      <Path></Path>
      <Parameters></Parameters>
      <MSIParameters></MSIParameters>
      <MSIName></MSIName>
      <MSIVersion></MSIVersion>
      <Command></Command>
      <EditMode>False</EditMode>
      <Conditions>
        <Condition>
          <Type>3</Type>
          <SpecOne></SpecOne>
          <SpecTwo></SpecTwo>
          <Operator>5</Operator>
          <Value></Value>
        </Condition>
      </Conditions>
    </Step>
    <Step>
      <Nr>3</Nr>
      <Name>Install 32bit</Name>
      <Type>1</Type>
      <ReturnCodes>0,1641,3010</ReturnCodes>
      <Success>5</Success>
      <Failure>-3</Failure>
      <Path>{PackageShare}\Java\jre-8u191-windows-i586.exe</Path>
      <Parameters>/s REMOVEOUTOFDATEJRES=1</Parameters>
      <MSIParameters>/i /qn /norestart</MSIParameters>
      <MSIName></MSIName>
      <MSIVersion></MSIVersion>
      <Command>"{PackageShare}\Java\jre-8u191-windows-i586.exe" /s REMOVEOUTOFDATEJRES=1</Command>
      <EditMode>False</EditMode>
      <Conditions />
    </Step>
    <Step>
      <Nr>4</Nr>
      <Name>Install 64bit</Name>
      <Type>1</Type>
      <ReturnCodes>0,1641,3010</ReturnCodes>
      <Success>5</Success>
      <Failure>-3</Failure>
      <Path>{PackageShare}\Java\jre-8u191-windows-x64.exe</Path>
      <Parameters>/s REMOVEOUTOFDATEJRES=1</Parameters>
      <MSIParameters>/i /qn /norestart</MSIParameters>
      <MSIName></MSIName>
      <MSIVersion></MSIVersion>
      <Command>"{PackageShare}\Java\jre-8u191-windows-x64.exe" /s REMOVEOUTOFDATEJRES=1</Command>
      <EditMode>False</EditMode>
      <Conditions />
    </Step>
    <Step>
      <Nr>5</Nr>
      <Name>Disable Update Schedule</Name>
      <Type>2</Type>
      <ReturnCodes>0,1641,3010</ReturnCodes>
      <Success>-1</Success>
      <Failure>-3</Failure>
      <Path></Path>
      <Parameters></Parameters>
      <MSIParameters></MSIParameters>
      <MSIName></MSIName>
      <MSIVersion></MSIVersion>
      <Command>reg delete "HKLM\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy\jucheck" /v "UpdateSchedule" /f</Command>
      <EditMode>False</EditMode>
      <Conditions />
    </Step>
    <Step>
      <Nr>6</Nr>
      <Name>Disable Update Check Time</Name>
      <Type>2</Type>
      <ReturnCodes>0,1641,3010</ReturnCodes>
      <Success>-1</Success>
      <Failure>-3</Failure>
      <Path></Path>
      <Parameters></Parameters>
      <MSIParameters></MSIParameters>
      <MSIName></MSIName>
      <MSIVersion></MSIVersion>
      <Command>reg delete "HKLM\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy\jucheck" /v "UpdateMin" /f</Command>
      <EditMode>False</EditMode>
      <Conditions />
    </Step>
    <Step>
      <Nr>7</Nr>
      <Name>Disable Update Check</Name>
      <Type>2</Type>
      <ReturnCodes>0,1641,3010</ReturnCodes>
      <Success>-1</Success>
      <Failure>-3</Failure>
      <Path></Path>
      <Parameters></Parameters>
      <MSIParameters></MSIParameters>
      <MSIName></MSIName>
      <MSIVersion></MSIVersion>
      <Command>reg add "HKLM\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy" /v EnableJavaUpdate /t REG_DWORD /d 00000000 /f</Command>
      <EditMode>False</EditMode>
      <Conditions />
    </Step>
    <Step>
      <Nr>8</Nr>
      <Name>Disable AutoUpdate Check</Name>
      <Type>2</Type>
      <ReturnCodes>0,1641,3010</ReturnCodes>
      <Success>-2</Success>
      <Failure>-3</Failure>
      <Path></Path>
      <Parameters></Parameters>
      <MSIParameters></MSIParameters>
      <MSIName></MSIName>
      <MSIVersion></MSIVersion>
      <Command>reg add "HKLM\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy" /v EnableAutoUpdateCheck /t REG_DWORD /d 00000000 /f</Command>
      <EditMode>False</EditMode>
      <Conditions />
    </Step>
  </Steps>
  <SoftwareVersion>7.0.110.2</SoftwareVersion>
</Package>

[JoshD]

CyberCitizen wrote:
I have experienced the same issue previously with a few packages, yet running the same thing works fine. But I don't reboot my machines beforehand as we have a lot of staff that work remotely via VPN (construction company). I sometimes wish for a nice office with desktops that I could just WOL at night and push everything out.

Are you seeing this with a lot of packages or just your Java package?

Below is what I am using for our Java deployments. I am calling an uninstall first, then when installing the new version I am also issuing REMOVEOUTOFDATEJRES=1

I cant really do an uninstall first for the risk of a successful uninstall then a failed install leaving me with 100 or more workstations without java the next morning. All our main software runs on java so that would be a disaster. I honestly think the java installer is the problem. I dont have any problem with my other scheduled deployments. I'll just have to request they leave their pc's on at night and do manual deployments after hours.

[CyberCitizen]

JoshD wrote:
I cant really do an uninstall first for the risk of a successful uninstall then a failed install leaving me with 100 or more workstations without java the next morning. All our main software runs on java so that would be a disaster. I honestly think the java installer is the problem. I dont have any problem with my other scheduled deployments. I'll just have to request they leave their pc's on at night and do manual deployments after hours.

Create a test / dev package that you can test on a few problematic machines first to see if it works / gets around your errors.

The other option is to copy the installer locally first to rule out and server / comms issues from occuring before you complete the uninstall etc.

In our case we use Bluebeam (Construction) and it is about 1gb installer. So when we want to update a user from 2016 we have to uninstall the old version and install the new version. Problem is most of our users are on a VPN and they are on and off regularlly while working on site. What I have done is copy the uninstall command to a bat file, copy everything to the temp folder, execute the uninstall first after confirming everything is copied locally, otherwise it would uninstall it then install from our server and depending on their VPN connection and speed (4G) it could drop out or would take over an hour at times to install from a network resource.

[Esben_D]

In Lansweeper, the scanning service will create a scheduled task, it creates a registry key with the steps of the deployment and copies the remote deployment executable. After that the deployment executable executes the deployment on the local machine.

Why deployments would work one time but not the other, I have no idea. Our support team can give you debug options to enable so that more information can be logged.

[KrisNelson]

I don't really use Lansweeper's deployment, but in SCCM, often times I'll see a failure result because the installer is spawning sub processes to deal with everything. This causes the initially called install to finish which causes the sequence to check for results. Since it's not really done running the installer it fails the check. But when it runs the second time it's already installed since the original install does actually finish. Therefor check 2 is a success.

For Java in particular, it's finished installing and spawns the uninstaller for the previous version. Depending on the success criteria, it may fail if it expects to no longer see the previous version.

-Kris

[JoshD]

KrisNelson wrote:
I don't really use Lansweeper's deployment, but in SCCM, often times I'll see a failure result because the installer is spawning sub processes to deal with everything. This causes the initially called install to finish which causes the sequence to check for results. Since it's not really done running the installer it fails the check. But when it runs the second time it's already installed since the original install does actually finish. Therefor check 2 is a success.

For Java in particular, it's finished installing and spawns the uninstaller for the previous version. Depending on the success criteria, it may fail if it expects to no longer see the previous version.

-Kris

That actually happens but only on a successful deployment. I end up with both the new version of java and the old version installed at the same time which means the deployment is terminating before the REMOVEOUTOFDATEJRES=1 switch can spawn the uninstall process. This actually isnt a problem because I reboot the machine after install and then the new java version is the "main" version and I can remotely run an uninstall deployment that doesnt affect the user since the old version is no longer in use. I can testify from experience upgrading to a new version of java and uninstalling the old version while the user is using the machine can make their java apps crash.