Kaseya Community

Kaseya Policy Management

  •                 I’m in the process of setting up Policy Management on our Kaseya System. I understand the main concepts and configurations of it, but I would like to ask a couple of real-world questions regarding a couple of drill-down areas.

     

    Patch Management – File Source: Do most people create individual Policies (i.e. Local Patch File Source) that points to the local share for patches? Or, do they leave it blank and apply the File Source at the machine level under Patch Management?

    Monitor Sets – Server Drives: Do most people create individual Policies (i.e. Low Disk Space, Critical Disk Space) for C-drive, D-drive, E-drive, F-drive, etc.? Do you apply all the policies and let the View weed out the ones that don’t apply? 

    Monitor Sets – How do you handle Exchange and/or SQL Servers?

    Thanks!

  • I can comment on at least the first to items..

    Patch file source - I pretty much always use LANCache.  Then I end up with separate policies later that handle assigning the correct Lancache based on the machine group/network.

    Monitor sets.  Create the monitor sets for all potential drives that you *might* have, and use the "Enable Matching" checkbox.  That will basically have it ignore any that don't apply to the specific machines.  So you can then apply that same policy to everything (assuming you want the same thresholds across all servers)

  • Thanks Jonathan!

  • @Jonathan - I don't see "Enable Matching". Is that in the Policies or in Monitor Sets (native)?

  • Bill, "enable matching" is part of the monitor set.

  • Thanks @GreyDuck!! I see it now.

  • We've automated almost all of our operation - the only manual configuration steps while onboarding a customer are server patch schedules and occasionally some exceptions to our standard configuration.

    Patching - we default to "download form Internet". When a customer has a local cache, we create a policy with the overriding setting and apply it. This way, everyone gets updates, even if inefficient. The new Software Update will eliminate this when it replaces patching.

    Disk Space Monitoring - we wrote our own "smart monitor" for this, and every disk volume has a custom space threshold as a result. This Smart Monitor identifies every local volume (including mounted volumes, not just drive letters), then based on the disk size, calculates the appropriate threshold. Less than one disk volume per 1000 agents require a manual override. The smart monitor also handles transient suppression, so the threshold has to be exceeded by 80% or minimally exceeded for 3 days before an alert is generated. It also invokes the disk cleanup before alerting to try and self remediate. Handling individual drive detection and using fixed % thresholds resulted in hundreds of false alerts that we no longer deal with. This even has a trending capability that sends a warning when the capacity is expected to cross the threshold within 30 days based on increases in utilization. We have several "Smart Monitors" with similar capabilities.

    As for monitoring services, we developed an audit that runs every day. Among other data collection tasks, it identifies Roles, Features, and Application Services that exist and maps them to monitors that are applied by policy. This makes it impossible to "overlook" a critical app and not apply the correct monitor, By the same method, if a Role or Feature is removed, the monitors are removed within hours without any manual intervention.

    You can see more about this in the Application Exchange or the mspbuilder.com web site.

    Glenn

  • Before applying a Policy to a Group, should I manually remove all the settings to the agents in that Group? Is there a command, or option in Kaseya to remove all the settings? Or should I create a "clean" (nothing assigned) template and use Copy Settings?