10 Replies Latest reply on Oct 4, 2018 2:36 AM by phoffmann

    Agent Health Questions

    markdevr Apprentice

      I never really used agent health in the past and have started looking into again today. Some things confuse me about it. It seems there are three pieces to it and I'm not fully understanding how they all connect. You have a bootstrap task, an agent setting (which isn't even part of agent config), and patch manager definitions (which are much smaller in number compared to the amount of repair items in the agent settings).

       

      Do we really have to manually run a change settings against all agents to use agent health or does the default agent health setting come into play? I couldn't find evidence of this in the registry. Having to deploy an agent AND run a change settings task seems odd to me.

       

      How do the agent health patch definitions relate to the actual agent settings?

       

      What happens if you use one without the other?

       

      Some of the definitions reference specific file versions. I just updated to SU5, but have not updated most agents yet. Would these definitions start replacing files on those updated agents?

       

      What part is the bootstrap task working in conjunction with? It looks like it just kicks off a vulscan for type 3 which would lead me to believe it works with the definitions.

        • 1. Re: Agent Health Questions
          seattleman1969 SupportEmployee

          I will do my best to answer your questions here:

           

          Do we really have to manually run a change settings against all agents to use agent health or does the default agent health setting come into play? I couldn't find evidence of this in the registry. Having to deploy an agent AND run a change settings task seems odd to me.

           

          The only setting you must deploy via a Change Agent Settings Task is the Agent Health setting. This is because it is not an integral part of the Agent Configuration, it's "Optional".

           

          How do the agent health patch definitions relate to the actual agent settings?

           

          The Agent Health Definitions should be placed (They should be there by default on download) in the Agent Health Patch Group. The Agent Health Setting should be configured to execute the Agent Health patch Group.

           

          What happens if you use one without the other?

           

          If you do not have the Agent Health definitions in the Agent Health Patch group, or configured to scan and repair, then Agent health will not repair agents it detects that are broken.

           

          Some of the definitions reference specific file versions. I just updated to SU5, but have not updated most agents yet. Would these definitions start replacing files on those updated agents?

           

          Once the Agent Health settings are deployed, yes, if the file versions are not up to date according to the definitions, then the files will be updated. that does not mean the agent is fully updated however and an full agent deployment may still be necessary to take advantage of any new features included in the Service Update.

           

          What part is the bootstrap task working in conjunction with? It looks like it just kicks off a vulscan for type 3 which would lead me to believe it works with the definitions.

           

          Yes it works with the definitions.

          1 of 1 people found this helpful
          • 2. Re: Agent Health Questions
            markdevr Apprentice

            Thank you for these answers! Few more questions...

             

            How do they expect people to use agent health efficiently if you have to deploy the agent health settings separate for every agent outside of the agent deployment? Do you have to create a query for machines without an agent health settings and just have an ongoing policy to task to deploy to them? Just seems very strange to have to do this...

             

            Why would they give you the option to scan/repair agent health definitions within the agent health agent setting? What is the benefit to doing here or doing it with regular vulscans?

             

            I have some things aren't configured in our standard agent. Should the associated agent health definition (power management, custom data forms, adaptive settings, etc) not be scanned for these machines?

             

            How do people usually handle agent updates? I'd be weary of these definitions updating a few files on an agent leaving it in an odd state where some components don't match.

            • 3. Re: Agent Health Questions
              seattleman1969 SupportEmployee

              Best practice would be to only scan for the components you have installed on the devices, IE, you would need a different agent health settings for devices that are configured differently. Regular vulscans will only detect, not repair, agent health settings (I could be wrong about this, but I am fairly certain that is the case). Set the broadest possible settings that apply to the most devices (Agents) in your environment and use that as your baseline.

               

              What I usually recommend to my customers, if they have multiple agent configurations with differing major components (As it sounds you do) such as some with Power Management and others without, AND they only want to deploy one Agent Health setting, is to only Scan/Repair the Base Agent and Remote Control components. Base Agent would cover CBA/Resident Agent, Vulscan, and Inventory, Remote Control is self explanatory. With those critical functions healthy you can take care of anything else that needs to be addressed.

               

              One more note, if you select to enforce Agent Settings, make sure that everyone is aware of the fact that Agent Health, on each scan, will replace those settings. So, if you happen to deploy a different setting (Let's say RC for example) to a device and agent health runs and enforces a particular RC setting then the "New" setting you deployed will no longer be active on that device. Make sense? It's a good thing to use in SOME circumstances, but I have seen it cause confusion.

              1 of 1 people found this helpful
              • 4. Re: Agent Health Questions
                markdevr Apprentice

                Thank you for this. I kept agent configurations very simple here. So far we only have two configurations (workstations and servers). I'm not even planning to use agent health on servers. I created an agent health-type report that detects machines that are stale/missing in LDMS and runs a number of tests against them.

                 

                There are some components in the agent health setting that I've never seen specifically listed as a component in an agent configuration (AMT, Hardware monitor, HP device management, etc.). I'm not sure how to choose an install state action for those.

                • 5. Re: Agent Health Questions
                  seattleman1969 SupportEmployee

                  HP device Management would be used only if you have HP Devices.

                   

                  AMT supports Intel's Active Management Technology and would only be used if you have that enabled on your devices.

                   

                  Hardware Monitor is for monitoring HW changes and I believe, works in conjunction with the Endpoint security component. If you are just starting to implement Endpoint Manager, Endpoint Security should be something you wait on for a while, or get some deeper assistance with. It's a very powerful tool with very serious repercussions if not properly set up.

                  • 6. Re: Agent Health Questions
                    markdevr Apprentice

                    Yes, I chose not to deploy endpoint security even with a neutered agent setting because I didn't want to have to tackle any issues related to that until we actually want to start using it.

                     

                    One last question. What is the best way to have an agent health agent setting deployed automatically for all future agent installs? I mentioned maybe doing a policy task with a query looking for the agent setting to be missing from inventory... Seems hacky to have to do this, but I don't see another way...

                    • 7. Re: Agent Health Questions
                      phoffmann SupportEmployee

                      You can just create a "update settings" policy/task and target a query of "device exists" (i.e "everything" or - more filtered, if you want) in there, for instance.

                       

                      That way, they'd pick it up upon checking in with the Core (since everything is a policy these days) .

                       

                      <Request -- Mark one of Brandon's responses as "the correct answer" since he put all the effort into giving you the info here.   It'll also help future folks who come across this thread to instantly see "the most relevant" response.>

                      • 8. Re: Agent Health Questions
                        markdevr Apprentice

                        I've marked an answer as correct, but I would say that agent health needs a little more documentation. I've done a bit of experimentation with it and will post a little later with all of my findings for future reference.

                        • 9. Re: Agent Health Questions
                          markdevr Apprentice

                          In testing I came across some issues/questions...

                           

                          1.) Bootstrap (LANDESKAgentBootStrap.exe) does some of its own basic repairs (copies some core missing files and attempts to start some services like CBA8, Local Scheduler, Softmon, and Intel PDS), but kicks off vulscan with /scan=3 /autofix=true to do the definition-based repairs. If autofix isn't enabled for the definitions, they won't repair at this point. ALSO, if there is maintenance window in the distribution/patch agent setting that is applied to the actual agent they also won't repair at this point. This means that if bootstrap doesn't kick off during a maintenance window and/or the definitions aren't set to autofix, bootstrap will not do any repairs using the definition-based repairs.

                           

                          2.) If you configure your agent health setting to periodically scan for issues under the 'Enforcement' page AND check 'Automatically remediate any issues found after scanning' a local scheduler task for vulscan will be added to the agent with the switches /group=*DefinitionGroupID* /fixnow. I found that the maintenance window issue from above also applies here. The definition-based fixes did not actually repair unless the agent was within its maintenance window.

                           

                          3.) I removed a component that was not part of the definition-based fixes, but that I did have set to 'Install' under the 'Components' page. I used 'Agent Watcher' for this and manually removed the component by deleting all files specified in my agent configuration INI under the '[Watcher Files]' section. I also set Install=0 under HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\landesk\managementsuite\AgentInstallPolicy\Components\Watcher. I attempted to get agent health to reinstall this component by kicking off the bootstrap process (which also kicks off vulscan of course). In the vulscan.log you can see line where it just says 'Setting component 'Install' install state to 1', but it doesn't actually do anything to reinstall the component. All it did was set the Install value that I changed to 0 back to 1. How does the 'Components' page of the agent health setting actually work?

                           

                          There are pretty much two issues here... First, if an agent is never in its configured maintenance window when either the bootstrap OR the local scheduler vulscan process (if configured in 'Enforcement') kicks off the definitions will not do anything (also, for the bootstrap process to do pretty much anything the definitions have to be set to autofix regardless of what is configured in 'Enforcement'). Second, I'm not entirely sure that setting the install state for a component under the 'Components' page does anything.

                          • 10. Re: Agent Health Questions
                            phoffmann SupportEmployee

                            Re: point 1:

                            • Correct -- this is how logic works (in regards to the maintenance window). Unfortunately this is one of those "wash me but don't get me wet" type situations, where people can't really have it both ways. They either need to be considerate with their maintenance windows, or things may not work.

                              People have been tripping themselves over with logic for as long as such logic existed (I'm particularly fond of a memory where someone came up with several local scheduler tasks that'd never run, because it would have to be multiple days of the week ... at the same time ).

                              So yeah, this is an "educate" type point. People will fall afoul of it ... but it's not something that can't be fixed by some reading up / education.
                            • And Since agent health follows regular vulscan logic, the Autofix thing too makes sense (and is consistent). It's as an additional safeguard (some people want to "deploy agent health" but not "switch it live" for various reasons).

                              There's a LOT of reasons (weird change control views, politics, etc, etc) why we end up usually being very "hands off" and "only if you're REALLY sure..." in regards to agent updates (especially automated ones). This CAN (and has in the past) caused issues (for instance, "So I didn't know that 'new agent version X' put down 'different version of C++ runtime Y' which breaks my in-house app that I didn't test for") ... so there's a bunch of stuff there to go softly on it.

                              Automated / agent-health stuff is very much an "opt-in" thing (as much as I'd like to just "brute-force" upgrade everything all the time, the above compatibility stuff and baseline testing tends to be a definite stumbling block in many enterprises due to 'weird application X'), so that's why it feels like "the stars must align" in order to ACTUALLY use this.

                              Automation is VERY powerful. And you can REALLY powerfully burn your hands with it if you're not careful (I have a few horror stories). It's like any logic ... not necessary working "as intended", but "as defined". The two can be QUITE different at times .

                            ===============

                             

                            Re: Point 2 ...

                            Yes - again, this is how maintenance windows work - they're mean as an override "to REALLY, REALLY not mess up your workers".

                             

                            The point made *DOES* suggest that it might not be a bad idea to have a separate "actual override" type function (if desired) for such cases though (esp. in environments where there's a lot of different admins). I'd put the warning out of "be careful what you ask for" here though.

                             

                            But HAVING the feature may not be a bad idea, so you can request in the usual place here -- Enhancement Requests -- (be sure to include / explain WHY ... i.e. the business case. Just requesting "I want a thing" without context won't usually go very far. ).

                             

                            ============

                             

                            Part 3 I'd need to look at (and sadly don't have the time at present). But in principle the theory is ... "vulscan detects something is broken ... it auto-fixes it as per the definition and should pull down / re-add missing things, if it's configured to do so". So that part I can't help much out with at the moment (in terms of detail), but maybe someone else can throw some time at that / has a recent example with logs & such).