Kaseya VSA: Software Management – Creating Scan Analysis Profile

This week Dan provides a brief summary of how to create a Software management Scan & Analysis profile in the VSA.

Step by Step:

1. In celebration of the official release of software management 2.0 I’d like to show you all how to create some basic profiles.
2. In this video, we will be exploring creating a basic scan and analysis profile let’s get into it.
3. A scan analysis profile is used to determine how an endpoint gets its list of available patches.
4.  In the profile we can set approval rules, third-party software patching if you have the appropriate licensing from Kaseya, pre-and post-scan procedures, and scan schedules.
5. As far as best practice goes, we typically recommend having a blanket scan profile for most of your endpoints.
6. Set the scan daily you can create multiple profiles if you want to target different approval rules and different groups however and remember that the scan schedule doesn’t impact the deployment schedule which we will.
7. Let’s make a scan and analysis profile now.
8. To create as new scan and analysis profile navigate to the software management profile, then to profiles, then to scan and analysis, then click new at the top left.
9. First, we want to assign a profile name make sure the name is descriptive to the type of profile that you want to create.
10. For example, our profile is going to target domain controllers, so we’ll want to name this profile domain controller patch scan.
11. Next, we can assign a patch engine to determine how the scan and analysis profile will pull the data for available patches the two applicable settings that aren’t deprecated are Kaseya 2.0 and OS native.
12. We typically recommend Kaseya 2.0 as it still uses the OS native patching engine but allows us to control the scan results more easily as well as deployment.
13. This does require we create a deployment profile as well which we will do in our next video.
14. If you select OS native, you don’t need a deployment profile, but patches will be deployed by the OS directly and you won’t be able to control things like when the machine patches or when it reboots.
15. Next, we want to determine which approval policies we want to set in the OS patches impact rules section.
16. We typically recommend leaving these default, but in our case, we really only want to apply the most critical patches to our domain controller to prevent frequent interruption in our production environment.
17.  Here I will set recommended to review, I can come back later after the scan and review any patches that aren’t critical for application.
18. Here you can set third-party patching profiles which patches third-party software if you have any available and if you have the necessary licensing in Kaseya.
19. You can also schedule a procedure here in this section to run before or after the scan.
20. For example, you can set a pop-up to appear on the endpoint when you start the scan to warn the end-user of possible performance impacts. (Since this is targeting a server I don’t really need to do that.)
21. Now the scan section here is incredibly important I want my scans to occur daily on this machine, so I set the time frame to daily to run once every day at noon.
22. The distribution window here is the time frame in which all endpoints assigned to this profile will scan.
23. If you have a large amount, of endpoints assigned to the scan and analysis profile you may want to increase the time frame so that all of your agents aren’t scanning simultaneously.
24. It’ll kind of stagger them out over the entire course of that distribution window that you’ve set.
25. Since we have a small set of domain controllers one hour should be some should be pretty fine.
26. Now finally we want to tell the policy whether or not it should run as soon as an offline agent that’s missed its window comes back online.
27. We can set this property using the skip if offline checkbox if this is checked the scan will not occur when the machine comes online after missing its schedule.
28. Now we’re scheduling this scan daily for our domain controllers, so I think it’s fine that we don’t immediately run a scan if it happens to be offline during its schedule. So, we’ll go ahead and check this box.
29. This other box here power up if offline simply sends a wake on LAN request to the machine if it’s offline at the scheduled scan time.
30. All right we saved this and that’s about all we need to do to create this profile.
31. Applying this profile should ideally be done within a policy in the policy management module which we’ll cover at a later date in more detail, but you can explicitly assign endpoints here in the software management module as well.
32. Well, that’s the basics of creating a software management profile.