2 Replies Latest reply on Apr 21, 2015 9:54 AM by csoto

    Deploying Custom Scripts via a Policy?

    csoto Specialist

      We have a handful of "housekeeping" type Custom Scripts that perform various tasks (conforming Mac "ComputerName", disabling BlueTooth/WiFi ports on desktops, etc.). These only need to run once per device, but many of these devices are not connected 100% of the time (laptops are away, systems are shut off, etc.), and some are only accessible via the CSA. I would love to be able to deploy these as Policies rather than as Scheduled Tasks. Is there any way to work around this limitation?


      If anybody else would like this, how do I go about making a Request For Enhancement?




        • 1. Re: Deploying Custom Scripts via a Policy?
          Peter Massa Expert

          Hi Charles,


          What you are looking for is DSC or Desired State Configuration.  DSC is about describing what a setting should be, the ability to remediate that setting if it is out of compliance, and the ability to report on that.


          You are able to accomplish this using LANDESK's patch and compliance module by following these steps:

          1. Go to Tools -> Security and Compliance -> Patch and Compliance

          2. Click the All Types button in the top left and change it to "Custom definitions" to narrow the number of patches you will be seeing

          3. Click the Green +

          4. Give it an ID and Title - I typically name mine DSC-OS-Type-Commonality-XXXX


          5. Create your first rule by clicking "Add"

          6. Give it a Name (typically describing what it is doing or checking)

          7. Pick what OS this rule should apply to

          8. Use Affected Platforms, Affected Products, and Query Filter to "include" devices that should be scanned.

          9. Use Files, Registry Settings, Custom Scripts to "detect" devices that should be remediated or are not configured appropriately.

          - In your case for scripts that should only be run once on a device - simply check for a File or Registry setting's existence.  If the script hasn't been ran yet - the registry key or file will not exist yet.

          - For scripts that need to run repeatedly - simply leave those empty so that they always detect as vulnerable - or - put your configuration script in the "Custom Script" location of Detection Logic.  If you put your configuration script there - simply stop creating the rule now otherwise continue with the next steps.

          - I typically use a custom script here to actually validate the settings that I am checking for exist - rather than just checking for a files existence - but this will take more work on your part and is completely up to you.

          10. Set Patch Information to be: This issue can be repaired without downloading a patch

          11. Use "Detecting the Patch" to see if your Configuration scripts have already been run if you are using a file/registry key to detect one time runs.  Otherwise skip this step.

          12. Under Patch Install Commands click "Add" then select "Run script"

          13. Put your configuration script here - be sure to follow the script rules for reporting success and failures.

          14. Add another action to create a file or registry key if this script should only be run one time to mark the device as having the DSC.


          Now your Definition is created as well as your DSC rule.  The next step to make this function as a policy would be to go under the definitions Scan tab:

          1. Choose which scopes should be scanning for these configurations or scripts.  You may set it to Global - so that all devices, including new devices get the settings. (note you restricted it to the OS of your choice above under detection settings so servers will not get these settings unless you choose server OSs)

          2. Go to the Autofix tab

          3. Enable Autofix for the same scopes that you are scanning


          This means that any time a device checks in and runs a vulscan - they will get these configurations automatically applied to them if they have custom definitions and autofix enabled in their agent settings.  There is no need to create a schedule task push/policy.


          You can also see which devices have gotten the configurations and which have not via the normal patch reporting.


          Note - these will also work via your CSA.


          Lastly for DSC to be most effective it is best practice to configure the Frequent Security Scanner to scan for Custom Definitions at a higher frequency (e.g. 1-4 hours) than the full vulnerability scans (1-7 days).  For more information on this see: The art of the patch


          Hope this helps,


          • 2. Re: Deploying Custom Scripts via a Policy?
            csoto Specialist

            Peter, this is brilliant. I especially like the idea in Step 9 of performing the actions as part of the Detection Rules. This effectively gives us a "mini Local Scheduler" capability, so that we can be sure scripts are run any time the vulscan process is kicked off. Many of these "housekeeping" things are tasks where it doesn't matter whether the job is run repeatedly. "Fire and forget" is helpful here.


            I'll test this out and maybe share some of those we implement.