Skip navigation
259 Views 3 Replies Latest reply: Apr 27, 2012 3:18 AM by RichardA RSS
AspenSkier Specialist 479 posts since
Apr 29, 2010

Has received 3 of 9 achievements.
Currently Being Moderated

Apr 25, 2012 3:12 PM

what is "Schedule Update to Agent Settings", really?

RE:  LDMS 9.0SP3


So this is sort of a two-part question:


part 1)  lets say I use a single agent config across my deployment.  If I decide I want to add something like Power Management to the Agent Configuration I know how to do that.  My question is this:  do agents that are already in service check in and see that their agent configuration has changed and in this case they would download the appropriate Power Management settings?


-I'm pretty sure the answer to this question is NO, so I'd then like to ask "why not?"



part 2)  I see the option under AGENT CONFIGURATION - > SCHEDULE UPDATE TO AGENT SETTINGS.  What does this really do?  How is it really supposed to be used?


-I scheduled one of these in a two-agent config environment and simply assigned all of my clients to the task thinking that only the agents using the one config would update their settings: WRONG! It looked like all of my agents got overwritten, even the ones that were not using the agent config that I wanted updated.  I feel like that I have to be deliberate and manually update my agents when I decide I need to change something and this just seems wrong to me.  Shouldn't this just be an automatic process?






Anyone have any thoughts on this?


a few somewhat related posts on this topic:

no replies here


this one doesn't really have qualfied advice; why do you sometimes have to redeploy the agent vs just updating?


this one seems to have the most useful information, but it doesn't really explain what happened in the 2nd part of my scenario above.

  • RichardA Apprentice 152 posts since
    Apr 14, 2010

    Has received 4 of 9 achievements.

    Part 1) The simple answer is no. You might want to vote up this ER: Not authorized to view the specified document 1407.


    Of course, the less simple answer is that some things do update themselves (a good example being the scan and repair settings referenced in the above ER). To clarify: If you change the default S&R settings deployed with a particular agent configuration, existing agents with that configuration will not change their default S&R. However, if you change the specifics of that S&R behaviour, agents using that behaviour will update. Hope that makes sense.


    Part 2) The Schedule update to agent settings feature exists because the answer to the above is no. My understanding of the official line is: you only need to deploy a full agent if you change any of the checkboxes on Start panel of the agent configuration. Those checkboxes control what modules/components are installed and therefore changes involve installing/uninstalling parts of the agent, which requires a full deployment. Additionally, if you've applied a Service Pack or Component Patch that updates agent files (almost all of them do) you probably want to do a full deploy to push out those new files (you can use Patch Manager but I've never had much luck with that).


    Any other change to the configuration theoretically just requires some registry changes on the client. In these cases you can use an Update. You might want to vote up this ER: Not authorized to view the specified document 1602


    You can also, theoretically use an update task to change the overall configuration of an agent (sounds like this is what you discovered accidentally) but a) the old and new configs must have the same components enabled and, otherwise the full deploy rule applies b) I'm not sure if this is formally supported by LANDesk.


    You can automate the targeting of an update task (to avoid the mass-change you made) by creating a Query based on the Computer -> LANDesk Management -> Agent Configuration Name inventory value and targeting the task at that. This way only machines using that Agent config will get the update. On the subject of keeping track of what configuration version machines have, you might want to vote up this ER: Not authorized to view the specified document 2724


    One of the discussions you linked to mentions scheduling policy rather than push tasks for agent settings updates. I recall reading somewhere that all agent setting are deployed using the <agentname>.msi in ldlogon. In theory that means you could create a Software Distribution package to deploy the MSI and then uses a policy-based distribution method. That said, I'm not 100% convinced the MSI is completely reliable on that front. Changes to Remote Control settings, for example, require the RC service be restarted to take effect, and I don't know if the MSI does that.

  • RichardA Apprentice 152 posts since
    Apr 14, 2010

    Has received 4 of 9 achievements.

    Thanks, I try


    I hear you. As a slightly related aside, we're evaluating endpoint encryption solutions at the moment so I've recently been working with several products that implement some kind of mechanic for wide-spread application of various policy sets to your estate. I have to say, almost without fail, they all do it better than LANDesk. But I digress...


    I think the issue with LANDesk patching itself is that so much of the agent is used during patching that you just end up with half the files being in use. When you do a full agent deployment, it actually uninstalls and reinstalls the agent using a completely standalone executable, so it generally goes smoother. If you read the release notes on SP3, they actually explicitly tell you not to use patch manager if you want to benefit from all the improved client-side functionality in SP3. Makes you wonder why they bother releasing LDPM content for LANDesk patches when it's clearly a broken process.


    I don't think there's any "harm" in having the wrong config deployed to agents. If the new config does have settings for components that are not installed, they should just get ignored. If it does not have settings for components that are installed, one would assume/hope/guess that the previous settings will remain in place.


    If you have Inventory History enabled on the Agent configuration name value (unlikely, I know) you could run a SQL query to list the machines that previously had the old agent config. If you still have the original agent deployment tasks around, you could refer to those. Hmm, thinking about it, if, as you say, there were different components deployed by the original configurations, you could make a query that detect the presence/lack of said component and use that to target your fix. Either use detected software, or perhaps the file name reported under the LANDesk Management inventory branch?

More Like This

  • Retrieving data ...

Bookmarked By (0)


  • Correct Answers - 20 points
  • Helpful Answers - 10 points
LANDESK Community powered by Jive SBS®  |  Legal Notices  |  Privacy Policy  |  Icon 

TweeterOn Twitter  |  Icon FacebookOn Facebook © 2007 LANDESK Software