Head Nerds
Negocios de MSP
Administración de parches

6 Best Practices for N‑central Patch Setup Wizard

What’s this I hear you cry, “Not another blog about Patch Management, what’s there left to say?”; well a lot, actually. I recently just passed my eighth work anniversary with N‑able, and over those eight years I’ve spent more time talking to partners and prospects about Patch Management than any other topic. Whether you are an MSP or work in internal IT, when you effectively manage your patching process, you are helping to protect the organizations and end users you support from cyber threats, preventing unauthorized access, maintaining system stability, and ensuring the overall security and functionality of the IT infrastructure.

I’m sure you all remember my recent blog on why N‑central’s Patch Management is best in class. That blog focuses on what N‑central’s Patch Management does, but what good is that to you if you don’t set it up properly. Luckily, N‑central has an awesome Patch Setup Wizard to get you started, so in this blog we will explore some best practices you can take to maximize the effectiveness of the N‑central Patch Setup Wizard and streamline your patch management deployment.

Now you are never going to have a ‘one size fits all’ rule—you’ll likely want to separate your server patching rules from your workstation and laptops patching rules—so you can run through the patch setup wizard several times to create patching rules to cover all your requirements.

So, let’s take a look at the six steps of the Patch Setup Wizard and what you need to know along the way.

1. Profile Configuration

This has always been an area where N‑central users do more than they need too. A new profile does not have to be configured every time you run the wizard, nor does it need to be customer specific.  Best practice here is to just have a few generic profiles that cover all scenarios. Start off with one for servers and one for workstations and laptops, and add other profiles as needed if a scenario presents itself that is not covered by your generic profiles.

Related Product

N‑central

Manage large networks or scale IT operations with RMM made for growing service providers.

2. Detection Windows

Running multiple detection windows on a daily basis can result in large amounts of unnecessary data being sent to you N‑central server. Every time a detection window runs it will send the entire result to N‑central in order to compare what’s installed on the device to what patches are available for it. So even if nothing has changed, the agent will still be sending the entire results, which could impact the performance of your N‑central server; particularly in larger deployments. Best practice here is to schedule the detection window for a time the devices you are targeting will be online.

3. Pre-Download Maintenance Windows

The biggest mistake I see N‑central users make when configuring the pre-download maintenance window is that they schedule it after hours. This maintenance window, although not required for patch management to run, is designed to streamline the installation process by downloading the approved patches to the device ahead of the installation window. If the device is offline, this maintenance window will be skipped. The best practice here would be to run it once a day at least one hour after the detection window, and at least one hour before any installation windows you may configure.

4. Installation Window

This is the key part of the whole wizard as this is when you are going to decide what time you are going to install patches as well as what categories of patches you wish to install. When I started with N‑able first it wasn’t uncommon to hear N‑central users patching on a monthly or even quarterly basis, the threat landscape has changed dramatically over recent years, so it is imperative now that you apply patches on a more regular basis. My recommended approached here is to schedule patching installations to run at least once a week, and ideally twice to ensure both Microsoft and third party patches are installed as soon as possible. 

These installation windows also allow you to select what categories of patches you wish to install. If you feel the need to be more aggressive with certain categories like critical and security patches, you can setup the installation window to install those categories on a more regular basis to the others. This could be configured in a second installation window by editing the rule after it’s created. If you don’t want to have different installation windows for different categories then make sure you move all classifications to install to the right hand side. Remember only patches you have approved will be installed during this window. Any patches that fall into classifications you have moved to the right that are not approved, will NOT be deployed during this window.

5. Reboot Maintenance Window

Anytime I speak to partners about patching, more often than not we spend a lot of time discussing the reboot maintenance window. There are lots of differing options out there regarding what notice you should give the end user, whether they should be allowed postpone it, and when to trigger it. So I know it’s very hard to define a singular best practice here. What is important, though, is that when a patch requires a reboot it is triggered. Choose a time that works for your end users, I would recommend you choose the option to ‘Force users to reboot in the maintenance window’, you can extend the period of the maintenance windows to up to 1440 minutes, which is a day. In my opinion, that is a sufficient window to allow the end user to find a time for the reboot that suits them. 

It’s also vitally important that the reboot maintenance windows does not overlap with the installation window. If they do, then the reboot can trigger before all the patches from the installation window have been installed, and this process will not resume after the reboot until the next installation window.

6. Rule Configuration

The final step when running the patch setup wizard is to combine everything into a rule. If you intend to do third-party patching—which you absolutely should—then make sure you check the box to enable it. You also want to use good name convention when creating the rule name, I recommend you include the days and time that the installation is taking place and whether this rule is aimed at servers or workstations and laptops.

By following these best practices and utilizing N‑central’s Patch Setup Wizard effectively, you can enhance your patch management processes and ensure the security and stability of your IT infrastructure.

If you’re looking for best practices for N‑central patch management check out the linked blog by my fellow Head Nerd Jason Murphy.

If you have questions you can join me on the N-Central office hours. For more insight on how you can get the most out of N‑central, you can attend our N‑central Boot Camps, recordings of which are available in N‑able U, alternatively keep an eye on www.n-able.com/events to register for the live sessions.

Paul Kelly is the Head Nerd at N‑able. You can follow him on Twitter at @HeadNerdPaulLinkedIn and Reddit at u/Paul _Kelly. Alternatively you can email me direct.

© N‑able Solutions ULC y N‑able Technologies Ltd. Todos los derechos reservados.

Este documento solo se proporciona con fines informativos. No debe utilizarse para obtener orientación legal. N‑able no ofrece ninguna garantía, implícita o explícita, ni asume ninguna responsabilidad legal o jurídica por la exactitud, integridad o utilidad de cualquier información contenida en este documento.

N-ABLE, N-CENTRAL y otras marcas comerciales y logotipos de N‑able son propiedad exclusiva de N‑able Solutions ULC y N‑able Technologies Ltd., y pueden ser marcas sujetas al derecho anglosajón, estar registradas o pendientes de registro en la Oficina de Patentes y Marcas de Estados Unidos o en otros países. El resto de marcas comerciales mencionadas en este documento solo se utilizan con fines de identificación y son marcas comerciales (o marcas comerciales registradas) de sus respectivas empresas.