5 Replies Latest reply on May 17, 2017 5:44 AM by phoffmann

    Weekly Core reboot

    Apprentice

      I'm running a recently installed LDMS 2016.3 core on Win2012 R2.  I'm just starting migration, so there are less than 100 nodes on it right now.  About once a week, all of my agents will fail a vulscan with a message about unable to contact host.  I can sometimes fix it by logging into the core and running IISRESET, or for a bit of a longer fix I can reboot the server.  I work in an environment that is secured to NIST standards, so IIS has been "locked down".  Is there a set of recommended settings I can compare my IIS and .NET to?  Are there other suggestions on where to look for what's causing the problem?

       

      My older LDMS 9.6 core does the same thing from time to time.

        • 1. Re: Weekly Core reboot
          crinto Rookie

          Hello Jstrain,

           

          what did you do like migration?

          (In use migration, side-by side,...)

           

          Did you deploy a new agent?

          • 2. Re: Weekly Core reboot
            Apprentice

            I did a side-by-side upgrade.  I made a backup of my 9.6 database and upgraded it during the 2016 Core installation.  I then reviewed the agent configurations and created new agents. I then used a custom vulnerability to install the new agent on top of the old. 

            • 3. Re: Weekly Core reboot
              phoffmann SupportEmployee

              Comparing .NET is "a mite tricky" by and large. It tends to "get broken" on its own (usually sneakily so) and the Microsoft binaries that are to "magically fix it" usually don't in my experience.

               

              However, .NET being broken TENDS to be a pretty nuclear affair (and one of the first things to suffer from it is the Scheduler service) ... so it shouldn't be a "well it works SOME time" stuff.

               

              IIS stuff wanting to be double-checked is easy though.

               

              Set up a clean Core in a VM (don't even need to activate it) and just compare what you want to, side by side (or via the various WEB.CONFIG / other files).

              • 4. Re: Weekly Core reboot
                Apprentice

                I have some additional information.  IIS seems to crash when the some of the agents run a vulscan.  I think I've narrowed it down to agents that don't show complete information in the column set, for example they're missing the "Full Name" and/or "Model".  I'm trying to reinstall the agent to see if that takes care of the problem.

                • 5. Re: Weekly Core reboot
                  phoffmann SupportEmployee

                  Interesting.

                   

                  I've never (in my nearly 15 years) have seen "bad" vulscans take down IIS. Might be a red herring, but worth looking into for sure.

                   

                  The Inventory Record (or quality thereof) shouldn't affect vulscan result files much. As long as there *IS* an inventory record of some sort for a device, that should be enough. The client does all of the "Hey, I'm a Windows 8.1 64-bit guy - gimme my content please" request to the Core & grabs its content that way (the Inventory data isn't touched -- makes sense, since devices can be reprovisioned for other OS'es).

                   

                  After that, the client "just" runs a vulnerability scan and then throws the results at the Core (using the DeviceID - that SID like number) as an identifier. I'm pretty sure if I'd hack myself a bare metal inventory record together, I could throw vulnerability scans at that.

                   

                  A few things to help you along though:

                   

                  • Did you know you can store (and then - reprocess) both inventory & vulnerability scans? Here's how (in a "cliff's notes" version.

                   

                   

                  • Here's where you enable the storing of vulnerability scans on the Core (saves into -- (...)\ManagementSuite\vulscanresults\Succeeded\ -- if everything goes well):
                  • Getting to the relevant menu:
                  • And here's the settings you want (no re-start of anything required):

                   

                  To re-process such a vulnerability results file, you just need a device with a LANDesk / Ivanti agent installed (specifically - you'll be needing vulscan.exe) - and a command prompt. The command line then looks basically like so (super easy):

                  <LDCLIENT-DIR>vulscan.exe /i=<path\filename of vulscan results file> /showui

                  I prefer forcing the "/showui" here (personal preference purely) in case any errors show up (either with vulscan itself, or the comms to the www-service / IIS).

                   

                  that's also an "/i=..." as in "India" (or "input file") - not an lower case "L" .

                   

                  So a real-world example would be for instance:

                  - My intended results file is "ScanResults_{E23F689F-04B1-924E-B614-EF28C1A5B3EB}_3.vr" and is stored in "C:\zz\"

                  C:\Program Files (x86)\LANDesk\LDClient>vulscan /i="C:\zz\ScanResults_{E23F689F-04B1-924E-B614-EF28C1A5B3EB}_3.vr" /showui

                   

                  <Mini tip -- running "vulscan /?" will show you a lot of the useful parameters to use . There's also this article -- About Vulscan switches for Windows clients  -- that helps a bit along >

                   

                  That'll save you having to run longer running vulnerability scans on your devices, if all you care about is just throwing the relevant data files at your IIS / Core .

                   

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

                   

                  Personally, I *suspect* it's more likely that your IIS runs out of resources (usually memory) and jumps off a cliff that way. You may want to look at your server resourcing (I know it's only 100 nodes atm, but IIS can be a greed beast at tomes) - especially around memory. If it's a VM, give it some more ... see how it behaves.

                   

                  Checking the IIS logs for errors / types of errors may help confirm this too (you'd be mainly looking for HTTP status 503's and 500's as a 2ndary ) ...

                   

                  don't know how to read an IIS log? Check the last few pages of the Provisioning momentum documentation here -- [Tech Brief On-Demand Webinar 2016] Provisioning with LANDESK Management Suite  -- I included a crash course guide in that regard .