Purpose
The purpose of this document is to go over what to do when the deployment tracker fails to update beyond Scheduled.
Symptoms
- 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\deployPackage-2855.zip' 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'.
Cause
- Port 3121 being blocked.
- The Deployment Template used for the deployment doesn't have 'Send Tracker Status' enabled.
- The Console Alias Editor doesn't have the NetBIOS name, FQDN, and IP address of the Protect console added to it.
- The Shavlik Scheduler is in a corrupted state.
Resolution
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 Protect and 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
- Deciphering Shavlik Protect Deployment Tracker Status Messages
- Using Telnet to Test Ports
- Understanding installer return codes
Affected Products
Shavlik Protect 9.2.x
Ivanti Patch for Windows Servers 9.3.x