Kaseya Patch Management

Article by Mark Boyd
www.simpleit.tumblr.com
Kaseya, Patch Management

All of t he inf ormat ion pres ented in t his art ic le is t he opinion of t he aut hor, not t he opinion of t he any of t he v endors ment ioned. The aut hors ex perienc e is in t he M anaged Serv ic es Prov ider s ec t or , more s pec if ic ally , t he Educ at ion v ert ic al. This art ic le is a s pec if ic t ec hnic al art ic le ex plaining Kas ey as approac h t o pat c h management . The inf ormat ion is c ons idered c orrec t at t he t ime of writ ing, s hould anyt hing appear inc orrect pleas e reply bac k wit h s uggest ions f or 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 Kaseyas 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 dont 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. Lets 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.
Wednesday, 17 August 2011
Page 1
Article by Mark Boyd 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 Lets work through Kaseyas 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 2
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 dont 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 dont 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 wont provide a screen shot here because it isnt something you need to setup, just use it to review patch installations from time to time.
Page 3
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 dont 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 4
Article by Mark Boyd Step ten, Kaseya > Patch Management > Manage Updates > Rollback
Self-explanatory, I havent 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 havent 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. 2. 3. 4. Server General contains all our customer machines member count is 65 Server General (with the red at the end) is our internal production network Server patch testing is our patch testing servers, 7 servers of different roles exist here Server service packs unused, we dont 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 5
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 wont 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 Security Update Critical, Important, Moderate, Low (High Priority) Security Update Non-rated (High Priority) Critical Update (High Priority) Update Rollup (High Priority Service Pack (Optional Software) Update (Optional Software) Feature Pack (Optional Software) Tools (Optional Software) Approval policy Always review, always approve Always review, exercise caution Always review, always approve Always review, always deny Always review, always deny Always review, always deny Always review, always deny 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 6
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 dont 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 dont use it at my company, I wont provide a screenshot Step sixteen, Kaseya > Patch Management > Patch Policy > KB Override Again, another section we dont use. The default approval status will be over ridden on your existing patch policies if you do this. Because we dont use it at my company, I wont 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 7
Article by Mark Boyd Step nineteen, Kaseya > Patch Management > Configure > Reboot action
We always stagger our reboots 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 8
Article by Mark Boyd 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. 2. 3. 4. Always have Delete package after install (From working directory) checked Always have Pulled from file server using UNC path *\\servername\WUFS$] defined Always set your File share located on: *machinename] set the same as step 2 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 9
Article by Mark Boyd Step nineteen, Kaseya > Patch Management > Configure > Office Source
Used for configuring and installing office. We have never used it so I wont 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 wont 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.
Page 10

Kaseya Patch Management

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Kaseya Patch Management

Uploaded by

Copyright:

Available Formats

Article by Mark Boyd