If you go to C:\Windows\Propatches on one of the target machines where the value stayed at 'scheduled', can you check in the dplyevts.log to see what address the tracker was sending results to?
As an example it should show a line like this:
2013-07-09T18:06:52.8975908Z 0b90 I DplyEvts.cpp:94 PingBack updates - tracker(https://18.104.22.168:3121/ST/Console/Deployment/Tracker/TrackerService) id(2) status(4).
Make sure the address listed there is actually pointing to your Protect console system.
Does the Protect console system have multiple Nics? You might have to verify what's currenty set in the Protect console under Tools > Options > Deployment > Deployment Tracker address.
Also, verify that communication over TCP port 3121 is not being blocked from the client system to the console system.
Those are just some ideas, but if this doesn't help I'd suggest opening a case directly with support and provide logs for both the console side and target side based on this document: http://community.shavlik.com/docs/DOC-22921
I did that last night. the Ip address is the correct address. i can telnet from the host machine that was failing to update the schedule to the shavlik console on 3121.
Does the Protect console system have multiple Nics? You might have to verify what's currenty set in the Protect console under Tools > Options > Deployment > Deployment Tracker address. This is setup to be the FQDN of the shavlik console.
The weird thing is that all of my SQL servers patched flawlessly. They are on the same VLAN as the application servers. So its very wierd.
should i try to give the tracker an IP address instead of the FQDN?
Thats what it was.. It was trying to reach the heartbeat nic. Thanks!