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.
Part 1) The simple answer is no. You might want to vote up this ER: Agent configuration to work like scan and repair settings.
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: Agent update notification
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: Agent Revision on device in inventory
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.
steller reply; thank you
RE part 1, S&R settings...yes I was aware of those and thought the Landesk implementation of them made sense, but then I couldn't figure out why that functionality wasn't already part of the agent. A static agent simply doesn't make sense in any context that have encountered.
RE part 2, Patch Manager, yeah I pretty much observed that using patch manager to update SP1 clients to SP2 didn't work. And when I recently deployed SP3 I saw maybe 15% of my clients update. Its pretty silly that the authors can't use their own updating product to update their own software!
I already found and voted on the 2nd ER; just voted on the 1st one you pointed out. Sadly the first is beyond 2 years old and the latter is just shy of 2 years old. I've pretty much lost hope that ERs actually affect product development, still I voted.
I didn't see the 3rd ER but it makes sense and I just voted it up.
RE using a query to target the Agent Configuration Name; I did end up building those last night after I discovered the problem. I'll be sure to use them in the future but I still have to repair the damage that I did because I still have a some clients that are reporting a different agent config then what they are supposed to have. Because the two configs use different components I'm not really sure what the fall out is...these mismatched clients report an agent config for which they don't have the right bits. What a mess.
thanks again and have a good day.
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?