1 / 64

Kaseya Fundamentals Workshop

Kaseya Fundamentals Workshop. DAY THREE. Developed by Kaseya University. Powered by IT Scholars. Kaseya Version 6.5 Last updated March, 2014. Day Two Overview. Day Two Lab Review Patch Management Configuration Monitoring Agent Procedures Introduction.

amelie
Télécharger la présentation

Kaseya Fundamentals Workshop

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Kaseya Fundamentals Workshop DAY THREE Developed by Kaseya University Powered by IT Scholars Kaseya Version 6.5 Last updatedMarch, 2014

  2. Day Two Overview • Day Two Lab Review • Patch Management Configuration • Monitoring • Agent Procedures Introduction

  3. Kaseya Fundamentals Workshop PATCH PROCESSING

  4. Patch Processing • When you schedule a patch the following occurs: • The agent on the managed machine is told to start the update process at the scheduled time. • The patch executable is downloaded to the managed machine from where the File Source is set for that machine ID. • The patch file is executed on the managed machine using the parameters specified in Command Line. You should never have to set these switches yourself, but just in case, this capability is there.

  5. Patch Processing • After all the patches have been installed the managed machine is rebooted. When reboots occur for a machine ID depends on the Reboot Action assigned to that machine ID. Applies to Machine Update, Patch Update and Automatic Update. Reboots in response to an Initial Update always occur immediately and without warning the user. • The managed machine is rescanned automatically. It takes several minutes after the rescan is complete for this data to show up on the VSA. Wait several minutes before checking the patch state after a reboot.

  6. Installing Multiple Patches • If you schedule multiple patches for installation on the same machine, all the patches are installed at the same time. • After all the patches have been installed the machine reboots once. • This technique saves time and reboots.

  7. WSUSSCN2.CAB • What is included in WSUSSCN2.CAB?

  8. Patch Failure • After the patch installation attempt completes—including the reboot if requested—the system re-scans the target machine. • If a patch still shows missing after the re-scan, failure is reported.

  9. Reasons for Patch Failure • Insufficient Disk Space • Bad Patch File • Corrupted Patch File • Missing Patch Location • No Reboot • Command Line Failed • MS Office Command Line Failed • Patch Download Blocked • User not logged in • Credential does not have administrator rights • Manual install only

  10. Kaseya Fundamentals Workshop MONITOR OVERVIEW

  11. What is Covered? • Overview • Terms & Concepts • Alerts • Event Logs • Monitor Sets • System Check • Review Monitor Data • Summary

  12. Why Monitor? • Proactive and preventive system maintenance is only possible with accurate and easily accessible information regarding the key aspects of the states of all the computers and peripherals within the network. • Understanding the environment is key to troubleshooting.

  13. Monitoring Concepts • How? • How to collect information? • How to categorize alerts according to the severity of the issue(s)? • How to present or notify alerts to VSA administrator? • Warning! • Too much info. is equivalent to no information. • Be very selective on what data to collect. • What is available? • Commodity operating systems support facilities to collect the needed data on an ongoing basis.

  14. What to Monitor? • Examples: • When any managed machine goes off-line. • When a machine user disables remote control. • When any software is added or removed. • When the hardware configuration changes. • When a computer is running low on disk space. • When a specific event log entry is generated. • When any protection policy violation occurs. • When an application attempts to access the network. • When an application attempts to access a file. • When a new device appears on the LAN. • When an external log records a specific log entry. • When machines resources are over utilized • ...

  15. How to Monitor? • Methods: • Alerts: Monitors events on agent machines. • Event Log Alerts: Monitors events in the event logs of agent machines. • Monitor Sets: Monitors the performance state on agent machines. • System Check: Monitors events on non-agent machines. • SNMP Sets: Monitors the performance state on non-agent devices. • Log Monitoring: Monitors events in log files.

  16. How to Respond? • Actions: • Create an alarm: Logs a record of the issue • Post a ticket: Keeps track of the issue • Execute an agent procedure: Resolves the issue • Send an email notification: Notifies the users

  17. Kaseya Fundamentals Workshop TERMS AND CONCEPTS

  18. What is an Alarm? • An alarm is a warning of an existing or approaching danger. • We refer such situation by indicating that an alarm condition exists. • For example, an alarm condition exists when a machine's performance succeeds or fails to meet a pre-defined criteria. • To check whether an alarm condition exist we need to monitor the environment.

  19. Alarms & Alerts • An alert is created when the performance of a machine or device matches a pre-defined criteria or "alert condition”. • An alarm is a warning that an alert has occurred. • In many graphical displays throughout the VSA, when users needs to be warned, the VSA displays by default a red traffic light icon: • If no warning is being issues, a green traffic light icon displays: • These icons can be customized.

  20. Logs Two logs distinguish between alerts and alarms. • Alarm Log: • Tracks any alarm that was created by an alert. • Monitor Action Log: • Tracks any alert that was created, whether or not an alarm or any other type of action was taken in response to the alert. • Example – VSA’s Monitor -> Alarm Summary

  21. Actions • Notification Actions: • A = Create Alarm • T = Create Ticket • S = Run Script / Agent Procedure • E = Email Recipients • These four types of actions are called the ATSE code. • None of the ATSE actions are required.

  22. Types of Alerts • VSA Pages that Create Different Types of Alerts: • Monitor > Alerts - These are specialized "fixed" alerts that are ready to apply to a machine. • Monitor > Assign Monitoring • Monitor > SNMP Traps Alert • Monitor > Assign SNMP • Monitor > System Checks • Monitor > Parser Summary • Monitor > Assign Parser Sets • Discovery > LAN Watch • Patch Management > Patch Alerts • Remote Control > Offsite Alerts Note: Add-on modules have alerts not listed here.

  23. Methods of Monitoring • Event-based • Alerts: monitors events on agent machines • Event Log Alerts: monitors events in the event logs • System Check: monitors events on non-agent machines • Log Monitoring: monitors events in log files • State-based • Monitor Sets: monitors the performance state on agent machines • SNMP Sets: monitors the performance state on non-agent devices

  24. Event-Based Alerts • Represent events that (occur or not occur) one or more times within a specified time period. • If an alarm is created for this type of event, then the alarm remains "open" in the alarm log even if the alert condition recovers. • Typically you use the Alarm Summary page to review alarms created by event-based alerts. • When the issue is resolved you "close' the alarm.

  25. State-Based Alerts • Represent changes in the state on whether it is within the expected range or outside of it. • The intent is to measure the level of performance rather than outright failure. • If you create an alarm for state-based alerts, alarm entries will be created just like event-based alarms. • But because state-based alerts typically go in and out of an alert condition dynamically, you may want to avoid creating an alarm each time.

  26. Note (On-Premise Only) • If you do decide to create traditional alarms for monitor sets and off-line alerts specifically, these two types of alerts can be closed automatically when they recover. • See the Enable auto close of alarms and tickets checkbox on the System > Configure page.

  27. Auto Close of Alarms

  28. Suspending Alarms • The triggering of alarms can be suspended. • The Suspend Alarms page suppresses alarms for specified time periods, including recurring time periods. • This allows upgrade and maintenance activity to take place without generating alarms. • When alarms are suspended for a machine ID, the agent still collects data, but does not generate corresponding alarms.

  29. Group Alarms • Alarms are automatically assigned to a group alarm category. • If an alarm is created, the group alarm it belongs to is triggered as well. • Group alarms helps with aggregating the alarms displayed in a monitoring dashboard (introduced later). • You can create new groups using the Group Alarm Column Names tab in Monitor > Monitor Lists.

  30. Kaseya Fundamentals Workshop Alerts

  31. Why Alerts? • Setting alerts is one good approach to staying informed when a certain event of interest is triggered. • You can set the alert to generate an alarm, which will in turn be added to the Alarm Logs in Kaseya VSA, or you can set it up so that it sends an email to you if your quick attention is needed.

  32. Why Alerts? • Generating an alarm can be used mainly for logging and documenting an alarm condition, while alerting via email can be used if the issue is more important. • Alerts can also create tickets, which will be discussed later; this feature is useful in cases that addressing an alarm condition would need creation of a service request that can be tracked.

  33. Agent Alerts • Agent Status • Alerts when Agent is offline • Application Changes • Alerts when an application is installed or removed • Get Files • Alerts when an agent procedure executes a Get File command and receive a different copy than previous Get File command. • Hardware Changes • Alerts when a hardware configuration changes • Low Disk • Alerts when free disk space falls below a specified percentage • LAN Watch • Alerts when an AGENT-LAN Watch function detects new machines

  34. Agent Alerts • Agent Procedure Failure • Alerts when an agent procedure failed to executes • Protection Violation • Alerts when an access violations is detected • New Agent Installed • Alerts when a new agent reports in for the first time • Patch Alert • Alerts when a threshold is triggered for patch management events • System • Alerts when selected system event occurred on the Kaseya Server

  35. Kaseya Fundamentals Workshop EVENT LOG ALERTS

  36. Windows Event Log • Alert on specific Windows Event Log entry. • Event Sets define the syntax to match to create the alert. • Alerts are defined by the Event Sets and also the number of occurrence of the events. • Pay close attention to the Windows Event type and Categories when configuring Windows Event Log Alerts. • Event Logs settings defines which events are to be captured.

  37. Capturing Event Logs • Under Agent > Event Log Settings • Select the Event Log Types and the Event Categories to capture.

  38. Windows Event Log • Source - The application that produced the event log • Event ID • Details - The description of the event • Event Log Sets define the Agent Alert to create an alarm for specific events.

  39. Windows Event Log • To avoid event log alerts from creating an alert, create an IGNORE EVENT SET with specific Source, Event ID, or Event Description.

  40. Kaseya Fundamentals Workshop MONITOR SETS

  41. How to monitor state? • Using Monitor Sets or SNMP Sets, i.e., sets of counter objects, counters, counter instances, services and processes used to monitor the performance of machines. • Basically we collect sample values of some counters associated with some performance object instances at a predefined interval. • For example, to monitor the percentage of processor time, we collect sample values of the “% Processor Time” counter.

  42. Performance Object • A logical collection of counters that is associated with a resource or service that can be monitored. • For example, processors, memory, and physical disks each have their own sets of predefined counters.

  43. Performance Object Instance • A term used to distinguish between multiple performance objects of the same type on a computer. • For example, multiple processors or multiple physical disks. • The VSA lets you skip this field if there is only one instance of an object.

  44. Performance Counter • A data item that is associated with a performance object, or if more than one instance of the object exists, the data associated with each instance of the object. • Each selected counter presents a value corresponding to a particular aspect of the performance that is defined for the performance object and instance.

  45. Update Lists by Scan • You can populate the Kaseya Monitor List for Perfmon Counter, Objects, and Instances. • Update Lists by Scan will also gather Windows Services and Event Log types. • Review the Monitor Lists for new items that Update Lists by Scan collected.

  46. Kaseya Fundamentals Workshop SYSTEM CHECK

  47. System Check • Leverage IP communication protocols to alert on IP Services • Web Server, Ping, DNS, or specific IP Port • Leverage the Kaseya Agent to execute an application that run diagnostics that outputs to a text file. • Command Shell command i.e defrag c: > output.txt • System Check can analyze the file to look for specific text string.

  48. Kaseya Fundamentals Workshop MONITORING RECAP REVIEWING DATA

  49. Monitoring Recap • Alerts • Agent Status, Low Disk, Application changes, … • Event Logs • EWISFCV: The event category • Monitor Sets • Counter Thresholds & Service Checks • Live Counter & Monitor Logs • System Check • Leveraging a Kaseya agent to monitor a device that does not have an agent to monitor IP services.

  50. Reviewing the Data • Monitor Log • Alarm remediation • Alarm Summary • Monitor dashboards • Dashboard • Classic Console, Alarm Dashboard, …

More Related