Kaseya Patch Management

10
Article by Mark Boyd www.simpleit.tumblr.com Wednesday, 17 August 2011 Page 1 Kaseya, Patch Management All of the information presented in this article is the opinion of the author, not the opinion of the any of the vendors mentioned. The authors experience is in the Managed Services Provider sector, more specifically, the Education vertical . This article is a specific technical article explaining Kaseya’s approach to patch management. The information is considered correct at the time of writing, should anything appear incorrect please reply back with suggestions for amendment. Kaseya and patch management If you arrived at this article, you were probably looking for an approach to handle patch management in Kaseya, if you are unfamiliar with Kaseya, this article is probably useless to you. Kaseya is a remote systems management tool (keeping it simple for now) used by managed service providers for remote monitoring and support. One of its specific functions is Microsoft Windows patch management for desktops and servers. This article is a step by step, screen shot by screen shot approach to patch management in Kaseya. There are a few ways Kaseya handles patch management, approval by policy, approval by patch, holistic machine updating. Kaseya patch management should be used to replace WSUS, if you have a Microsoft domain controller applying patch management group policy / wsus rules, delete them before bothering with Kaseya’s patch management functionality. Before you dig into this article head to https://lms.kaseya.com/kedu/login/index.php to look at the official Kaseya patch management material, along with all other Kaseya training guides, if you don’t have a log in and you are a Kaseya user, get a log in from your Kaseya representative. Kaseya staffs, if you are reading this and I have overstepped the mark on anything above or below, you know how to contact me. I will happily amend or remove any / all of the content. Let’s get started, this article outlines just one way to handle patch management in Kaseya, at the time of writing, I strongly believe it is one of the better ways to approach patch management.

Transcript of Kaseya Patch Management

Page 1: Kaseya Patch Management

Article by Mark Boyd www.simpleit.tumblr.com

Wednesday, 17 August 2011 Page 1

Kaseya, Patch Management

All of the informat ion presented in this art ic le is the opinion of the author, not the opinion of the any of the

vendors ment ioned. The authors experience is in the Managed Services Provider sector, more specif ical ly , the

Educat ion vert ical . This art ic le is a specif ic technical art ic le explaining Kaseya’s approach to patch

management. The informat ion is considered correct at the t ime of wri t ing, should anything appear incorrect

please reply back with suggest ions for amendme nt.

Kaseya and patch management

If you arrived at this article, you were probably looking for an approach to handle patch

management in Kaseya, if you are unfamiliar with Kaseya, this article is probably useless to you.

Kaseya is a remote systems management tool (keeping it simple for now) used by managed service

providers for remote monitoring and support. One of its specific functions is Microsoft Windows

patch management for desktops and servers. This article is a step by step, screen shot by screen shot

approach to patch management in Kaseya.

There are a few ways Kaseya handles patch management, approval by policy, approval by patch,

holistic machine updating. Kaseya patch management should be used to replace WSUS, if you have a

Microsoft domain controller applying patch management group policy / wsus rules, delete them

before bothering with Kaseya’s patch management functionality.

Before you dig into this article head to https://lms.kaseya.com/kedu/login/index.php to look at the

official Kaseya patch management material, along with all other Kaseya training guides, if you don’t

have a log in and you are a Kaseya user, get a log in from your Kaseya representative.

Kaseya staffs, if you are reading this and I have overstepped the mark on anything above or below,

you know how to contact me. I will happily amend or remove any / all of the content.

Let’s get started, this article outlines just one way to handle patch management in Kaseya, at the

time of writing, I strongly believe it is one of the better ways to approach patch management.

Page 2: Kaseya Patch Management

Article by Mark Boyd www.simpleit.tumblr.com

Wednesday, 17 August 2011 Page 2

Step one, know your Kaseya VSA

It is important you know your machine groups and machines that are in your VSA, at the MSP I work

for, we group our customers by customer name, and we have a testing machine group for

equipment to test patches on.

Step two, Kaseya > Patch Management > Manage Machines > Scan Machine

Let’s work through Kaseya’s patch management module, the first screen I bring your attention to is

Patch Management > Manage Machines > Scan Machine.

Pick a machine group, I have highlighted out the machine names, but you can clearly see a bunch of

machines from one customer, and a schedule for scanning available patches on that machine. This

feature of scanning for new patches regardless of your patch policy and or patch group

memberships (more on that later)

All we have here is a schedule for when you are to scan the machines for new and available patches,

you simply click the schedule button, and away you go.

Step three, Kaseya > Patch Management > Manage Machines > Patch Status

This is self-explanatory but I will provide a screen shot anyway, all you are looking at is the

outstanding amount of patches remaining on a group of machines. This area is a good way to tell if

you there is a misconfiguration of a machine in a machine group.

Note the bottom machine in that screen shot is incorrectly configured, this is ok, this is the area to

know if machines are incorrectly configured.

Page 3: Kaseya Patch Management

Article by Mark Boyd www.simpleit.tumblr.com

Wednesday, 17 August 2011 Page 3

Step four, Kaseya > Patch Management > Manage Machines > Initial update

I have never used this part of the module. Initial update will arbitrarily update your machines with

every single outstanding patch on each and every machine. This is dangerous especially on servers, I

don’t think I need to explain why, just know that you are to use it at your own discretion, I am not

going to go into it, and you can figure it out.

Step five, Kaseya > Patch Management > Manage Machines > Pre / Post procedure

Another part of the module I don’t use, not because it is dangerous, just because I have no real need

for it, patch management in Kaseya just works, I have never had to run an agent procedure on the

machine after an update has been applied, head over to www.community.kaseya.com and see if

anyone on the community has any more insight on this.

Step six, Kaseya > Patch Management > Manage Machines > Automatic update

To my understanding, this is where you schedule the day your patches are installed. For our

customers we schedule patches to be installed each week, Thursday to Sunday. It is important you

set a reboot action after your patches are installed otherwise patches will just be installed on

Thursday and never rebooted if they are needed. It is best not to arbitrarily reboot customer servers

for obvious reasons; this should be a discussion you have with your customers when they come on

board.

Step seven, Kaseya > Patch Management > Manage Machines > Machine history

Another area I very rarely use unless there is something wrong, I won’t provide a screen shot here

because it isn’t something you need to setup, just use it to review patch installations from time to

time.

Page 4: Kaseya Patch Management

Article by Mark Boyd www.simpleit.tumblr.com

Wednesday, 17 August 2011 Page 4

Step eight, Kaseya > Patch Management > Manage Updates > Machine Update

This is where you start looking at updating your machines, this whole area (manage updates) is

where you can manually control patching on a machine by machine basis. I don’t use it; it defeats

the purpose of using an automatic patch management suite. For the purpose of this article however

I will document it briefly.

Its best use is for seeing what patches are outstanding on a specific machine and scheduling their

install manually. Note below, there is one patch missing on the machine

Step nine, Kaseya > Patch Management > Manage Updates > Patch update

This is another largely “useless” part of the module, if you are fully automating your patching you

should see nothing here, we tick the box “hide machines set for automatic updates” so that we

know all the machines are part of an automatic patch policy, more on that later.

I will post a good and bad example of what this screen should look like.

The below image is bad only because you will be manually overriding you automatic patching setup

Page 5: Kaseya Patch Management

Article by Mark Boyd www.simpleit.tumblr.com

Wednesday, 17 August 2011 Page 5

Step ten, Kaseya > Patch Management > Manage Updates > Rollback

Self-explanatory, I haven’t had to use this in the 12 months I have been working with Kaseya. This is

in part due to good planning which I will go into later. No screenshot provided because it is easy

enough to visualise yourself.

Step eleven, Kaseya > Patch Management > Manage Updates > Cancel

Another self-explanatory one, I haven’t used this one in 12 months either. No screenshot will be

provided, it is easy enough to visualise yourself.

Step twelve, Kaseya > Patch Management > Patch Policy > Create / Delete

This is where the real configuration starts to take place. Here you will create or delete patch policies

and their membership groups. This K.I.S.S (Keep it simple, stupid) rule applies here; we support well

over 500 servers, and have only four groups for patch membership. See the screenshot below.

The logic behind this is quite simple (screenshot taken from our testing VSA)

1. Server General contains all our customer machines – member count is 65

2. Server General (with the red at the end) – is our internal production network

3. Server patch testing – is our patch testing servers, 7 servers of different roles exist here

4. Server service packs – unused, we don’t apply service packs automatically (more later)

The reason we do this is because

1. In the first week of a patches release, we apply the patches to the testing group

2. In the second week of a patches release, we apply the patch to our production network

3. In the third week of a patches release, we apply the patch to our customers

We cycle through patches like this so that we have 2 weeks of non-customer production systems

running the new patches at a minimum. If a patch is “dodgy” we will know before it touches a

customer network.

Step thirteen, Kaseya > Patch Management > Patch Policy > Membership

This area is simply where you assign machines to the membership groups you just created, a simple

concept, a simple screenshot below. (Sorry if it is small, the next screen is important)

Page 6: Kaseya Patch Management

Article by Mark Boyd www.simpleit.tumblr.com

Wednesday, 17 August 2011 Page 6

Step fourteen, Kaseya > Patch Management > Patch Policy > Approval by Policy

This is perhaps the most important part of the Kaseya patch management setup, get this wrong and

you won’t be in pain but you have defeated the purpose of having Kaseya handle your patching

Red:

The current policy you are editing, select pending approvals to see what patches you want to apply

Green:

Wait 2 weeks of waiting to see if you “Server patch testing” policy worked.

You then “Copy approval status to policy”: Server General

All machines in “Server General” will then start getting patches that have been tested for 2 weeks

Blue:

Pending approval patches are what you want to pay attention to weekly, they are the patches just

released by Microsoft. If you set it up right, you will only need to deal with two dozen patches at the

most a fortnight here (unless Microsoft releases a deluge of patches)

Yellow:

This is perhaps the most important part of the screen shot, choose carefully which patches you

approve or deny, the company I work for is rightly conservative. We approve or deny based on patch

type. The patches we deny, are either dealt with elsewhere, or a risk to the stability of the machine

Patch type Approval policy Security Update – Critical, Important, Moderate, Low (High Priority) Always review, always approve Security Update – Non-rated (High Priority) Always review, exercise caution Critical Update (High Priority) Always review, always approve Update Rollup (High Priority Always review, always deny Service Pack (Optional Software) Always review, always deny Update (Optional Software) Always review, always deny Feature Pack (Optional Software) Always review, always deny Tools (Optional Software) Always review, always deny

Brown:

As a rule, we set everything to straight up denied or pending approval. We want to review all

patches coming into the VSA, so we never automatically approve anything. General speaking, when I

say we “always approve” it is because we have review the patches coming in.

Page 7: Kaseya Patch Management

Article by Mark Boyd www.simpleit.tumblr.com

Wednesday, 17 August 2011 Page 7

Step fifteen, Kaseya > Patch Management > Patch Policy > Approval by Patch

Given how streamlined step fourteen is, we never feel the need to touch this section. If you set up

“Approval by Policy” properly, you don’t need to touch this section. If you apply any settings here,

you will override the default patch policy, “erasing” any work you have done prior to this. Exercise

extreme caution when using this section.

I strongly believe this section is far too granular to administer, and defeats the purpose of a holistic

approach to patch management.

Because we don’t use it at my company, I won’t provide a screenshot

Step sixteen, Kaseya > Patch Management > Patch Policy > KB Override

Again, another section we don’t use. The default approval status will be over ridden on your existing

patch policies if you do this.

Because we don’t use it at my company, I won’t provide a screenshot

Step eighteen, Kaseya > Patch Management > Configure > Windows update

To allow Kaseya to take over patch management, set all machines in your machine group to disabled

Page 8: Kaseya Patch Management

Article by Mark Boyd www.simpleit.tumblr.com

Wednesday, 17 August 2011 Page 8

Step nineteen, Kaseya > Patch Management > Configure > Reboot action

We always stagger our reboot’s here, it makes sense to allow half an hour to an hour between

server reboots, if you reboot 2 domain controllers at one time for example, users that are still logged

onto exchange may not be able to send emails. Same goes for Exchange, if you have a clustered

Exchange setup, it would make sense to stagger the reboots.

Some customers prefer us to not reboot at all, just apply the updates and have the system email

them when the machines are ready for a reboot. This is doable and perfectly acceptable.

Page 9: Kaseya Patch Management

Article by Mark Boyd www.simpleit.tumblr.com

Wednesday, 17 August 2011 Page 9

Step nineteen, Kaseya > Patch Management > Configure > File Source

This is another bit that is of critical importance. You do not under any circumstance want your

machines downloading updates from the internet all at once. This is a waste of resources, and could

have a noticeable affect to your customers’ end users.

Let me explain what to do without a screenshot first

1. Always have “Delete package after install (From working directory)” checked

2. Always have “Pulled from file server using UNC path *\\servername\WUFS$] defined

3. Always set your “File share located on: *machinename] set the same as step 2

4. Always set your “In local directory” to C:\WindowsUpdateFileSource

Here is a screen shot

For the above to work, pick a server you will consider your customers central windows update

repository. On that server, create the folder C:\WindowsUpdateFileSource and share it is WUFS$

As you may have gathered from the above, the server you picked essentially becomes the WSUS

server for that site. All the customers’ servers will pick up their updates from this site.

Step nineteen, Kaseya > Patch Management > Configure > Patch Alert

We set up all servers to alarm if an install fails, invalid credentials are supplied or the auto update

policy changes on the customer site.

If the auto update policy changes at a customer site, there may be group policy settings changing it

back to the customers WSUS server, it is best to get this out of the way with early.

Page 10: Kaseya Patch Management

Article by Mark Boyd www.simpleit.tumblr.com

Wednesday, 17 August 2011 Page 10

Step nineteen, Kaseya > Patch Management > Configure > Office Source

Used for configuring and installing office. We have never used it so I won’t document it.

Step twenty, Kaseya > Agent > Configure Agents > Set Credential

Use a high privileged account to have the agents install the updates you require. Set up the

username, password, and domain. Pretty self-explanatory, I won’t go on

Conclusion

Lots of screenshots, lots of information, only a few of the steps you really need to understand here I

guess. The only way you will figure it out is trial an error. I hope this document has given you a good

heads up on how to configure patch management on your Kaseya server.