1. When using Agentless scanning and patching, patches are pushed from the Console. However when reviewing the Agent policy, I noticed there isn't an option to push patches from the console - only Vendor Over Internet and Distribution Server. Is this by design?
2. And if I select Vendor over Internet, does this literally query Microsoft, Adobe, Java etc and download the patches straight from the source, bypassing the Console and Distro points?
3. When "use vendor as backup source" is selected, will this recognize an Agent with the Cloud feature in the policy enabled and use the vendor in the case it is not connected to our MPLS?
I hope that helps!
Thanks, Adam. Before I posted I was thinking about creating a Distribution Server on the Console itself for the Agents since the Agentless deployments pushed from them anyway - but I am assuming this will have some drawbacks.
We are going to build additional Distribution Points specifically for Agents now.
Is there any difference in copy speed to machines when using the Vendor as opposed to a Distribution Server? Can you touch on the Pros/Cons?
The only difference in copy speed is going to be the limitation of the network for each type of traffic. If the agent is on your internal network I'd assume the bandwidth is higher vs downloading from a website online.
However the biggest pro to using distribution servers is that all the agents configured to use the distribution server will go to that, rather than each going out to the internet to download the patch. Getting the patches out to your distribution server is just a one time thing (Download > Synchronize) so overall there is less bandwidth used collectively.
As for cons to using a distribution server - you need to make sure it's configured and working properly and that you download and synchronize updates to the distribution server so they are available for the agents to download. This is also where the advantage of using vendor as backup comes into play. If you forget to download/sync the patches to your Distribution servers and agents can't get the patches from them - they just download from the internet instead so the patch(es) can still be applied.
Does that help? Let me know if you have other questions I can help with.
Awesome explanation. And yes that does help. Thank you. I am currently patching a machine is not on our MPLS very cool!
I am noticing in the Shavlik Console under Machine View that this machine shows that the Agent state is "Waiting for Check-in". It already has checked in and in the process of being patched. When will this Agent State flag actually show that is has checked in?
Is that one a cloud agent? If so it may just take a while for that to update.
Otherwise, try hitting the little refresh button at the top of machine view. It might just be that the view didn't refresh automatically.
OK it now shows as Checked In. Took a few minutes but it is showing accurately now. Thanks Adam.
Adam - I am going to keep pestering you if you don't mind
When I try to request a check in from the Shavlik console on the test machine with the cloud Agent, it fails with "Agent Didn't Respond". Now if I check in from the test machine, it works and the console shows the updated status within a few minutes. All needed firewall ports have been opened.. I even disabled Firewall (McAfee HIPS) to no avail.
Is this normal behavior for a Cloud agent, where it's basically "Set and Forget" until the Agent checks in by itself to the Console?
Also, is there any impact to network resources or the Console if I set the Check In interval to 15 or 30 minutes?
OK I just found the article on the Cloud Agent that explains my question. No further explanation needed for this Cloud agent.
However, the same scenario exists with a separate test machine using a standard Agent. Check-in fails immediately. All necessary Firewall ports are open. Netstat shows that 4155 is listening. I also made sure this policy does not have the "Cloud" check box selected.
Any ideas why this is happening?
Glad you found the document about the cloud agents. With the issue of requesting checkin even with a standard agent, it sounds like you did already check the most common issue, being the port used for communication. Are any agents working if you request checkin from the console? If so, what's different about the ones that don't work? Are they in a different subnet or domain possibly? This issue might be worth opening a case and submitting some logs.
If you want to collect the logs for this issue I'd recommend the following steps:
1. Please open the Protect GUI and then go to Tools > Options > Logging and change logging to “All” for both user interface and services.
a. If you are unable to set logging via the GUI see this doc: http://community.shavlik.com/docs/DOC-22938
2. Close the Protect GUI.
3. Stop the following services
a.Shavlik Protect Console Service
b. ST Remote Scheduler Service
4. Delete all the logs from
a. Windows 7, 8, 2008, 2012 & Vista: C:\ProgramData\LANDesk\Shavlik Protect\Logs
b. Earlier OS’s: C:\Documents and Settings\All Users\Application Data\LANDesk\Shavlik Protect\Logs
5. Start the console service and open the Protect GUI.
6. Attempt to reproduce the issue. (Try requesting the check-in of one agent where you have seen it fail previously)
a. Collect the logs from the Logs folder mentioned earlier in step 4 (please zip if possible)
7. Zip and send all the logs.
You could take a look in the logs as well before sending them in. If you notice any errors it might stick out as to what's causing the issue.
Adam - Last night I figured out why this is happening. It turns out that Shavlik cannot resolve the host name because the machine lost it's domain trust, which causes issues with DNS lookup.
After rejoining the machine to the domain, I was able to successfully check in from the console. Initially I had ruled this out because deploying the Agent from the console worked with no problem so I assumed check in would work too. Not the case. Anyway, here are the logs that pointed me in the right direction.
2015-04-06T23:27:17.6473320Z 0017 E AgentCommands.cs:379|There was no endpoint listening at that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
2015-04-06T23:27:17.6473320Z 0017 E AgentCommands.cs:382|The remote name could not be resolved: 'pm-..com'
2015-04-06T23:27:50.7506735Z 0048 V AgentCommandResultView.cs:750|Agent command poll interval is now 15 seconds
2015-04-06T23:27:52.7318811Z 0017 E AgentCommands.cs:379|There was no endpoint listening at that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
2015-04-06T23:27:52.7318811Z 0017 E AgentCommands.cs:382|The remote name could not be resolved: 'pm-..com'
2015-04-06T23:29:50.6721060Z 0031 V CredentialUsageController.cs:163|Found valid default credential.
2015-04-06T23:30:37.3412688Z 0054 V AgentCommandResultView.cs:750|Agent command poll interval is now 15 seconds
2015-04-06T23:30:41.5839112Z 0033 E AgentCommands.cs:379|There was no endpoint listening at that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
2015-04-06T23:30:41.5839112Z 0033 E AgentCommands.cs:382|The remote name could not be resolved:
2015-04-06T23:31:56.5320966Z 0001 I MainForm.cs:835|Closing...
2015-04-06T23:31:57.4991637Z 0001 I Launcher.cs:277|Exiting...
Awesome, good to see you got that figured out already even. Thanks for the follow up information on what you did as well, that could be helpful for others who see a similar issue in the future.