Deployment Tracker stuck at Scheduled during Deployment but patches install

Version 11



    The purpose of this document is to go over what to do when the deployment tracker fails to update beyond Scheduled.




    • Deployment tracker will stay at scheduled despite the deployments being initialized on the target machines being deployed to.
    • Deployment tracker shows scheduled:



    • When looking at the STDeployerCore.log on the target machine(s), you will see results similar to below indicating the patches were installed successfully:


    2016-10-06T21:01:35.1775494Z 0b78 I DeploymentPackageReader.cpp:782 Deploy package 'C:\Windows\ProPatches\Installation\InstallationSandbox#2016-10-06-T-21-00-54\' successfully opened unsigned for package IO

    2016-10-06T21:02:38.2639494Z 0b78 I Authenticode.cpp:134 Verifying signature of C:\Windows\ProPatches\Patches\Windows6.1-KB2544893-x64.msu with CWinTrustVerifier

    2016-10-06T21:02:38.3263494Z 0b78 V UnScriptedInstallation.cpp:29 Executing (C:\Windows\ProPatches\Patches\Windows6.1-KB2544893-x64.msu /quiet /norestart), nShow: true.

    2016-10-06T21:02:47.7895494Z 0b78 V ChildProcess.cpp:140 Process handle 000004FC returned '0'.






    1. Ensure that port 3121 is not being blocked in your network. Perform a telnet command from the target machine(s) to your Protect console machine's IP or FQDN address.

    telnet {console IP/FQDN} 3121


         If Telnet is not installed, you will see the following:

         To Enable Telnet:


         If the port is blocked, you will see a similar error:


       If at this point you see the port fail to connect, you will need to make sure that 3121 is enabled in your network before attempting to deploy again.


         If the port is not blocked, you should see a blank command prompt:


    2. Once you have confirmed that port 3121 is able to connect, check to ensure that your Deployment Template being used has 'Send Tracker Status' enabled:


    3. Confirm that either TLS 1.0 is enabled between the console and the problem client machine or TLS 1.2 is properly configured

         Disabling TLS 1.0 may causes issues with Patch for Windows Servers.

         Enabling TLS 1.2 for Ivanti Patch for Windows Servers


    4. Verify that you 'Console Alias Editor' has all of the following located within it:

    • Console NetBIOS name
    • FQDN
    • IP address


    Tools > Console Alias Editor




    Once updated, test your deployment again. If the device is able to properly connect, the tracker status will updated as expected.


    If after updating the 'Console Alias Editor' the deployment status is still showing 'Scheduled', you will find in the dplyevts.log file on the target machine something similar to the following:


    PingBack.cpp:63 Sending data to 'https://PROTECT-92-5119:3121/ST/Console/Deployment/Tracker/V92' failed: 12002.



    If you find something similar to the above, you will need to uninstall the scheduler service from the machine(s).


    Protect 9.2:

    Manage > Scheduled Remote Tasks


    Find device(s) being deployed to, right click the machine and select 'Refresh Selected':



    Device will be shown as 'Online':


    Once online, right click the device again, go to Scheduler service > Uninstall:


    Patch for Windows Servers 9.3:


    View > Machines



    Find the device affected using the search window



    Highlight machine > Right-click > View scheduled tasks



    Click Uninstall to remove the scheduler service.


    NOTE: To validate scheduler is uninstalled, go to C:\Windows\ProPatches and if you don't see a folder named Scheduler, the service was uninstalled.


    Test another deployment to your target machine(s). During this deployment, the Scheduler service will reinstall and should update the deployment tracker to show the deployment operation executing.



    Additional Information



    Affected Products


    Shavlik Protect 9.2.x

    Ivanti Patch for Windows Servers 9.3.x