“These customers didn’t have to wait for a new feature to ship. They used the tools NinjaOne already provides — scripting, API, custom fields, Dynamic Policies — and built exactly what their environment required. That’s the power of a platform that’s designed to be extended: when you need something specific, you have the building blocks to make it happen now, not next quarter.”
For most organizations, patching isn’t a simple process. They have change advisory boards, phased rollouts, CMDB-driven maintenance windows, annual freeze periods, and compliance calendars that make Patch Tuesdays woefully inadequate. When their tools can’t keep up, IT teams end up connecting spreadsheets to manual processes and hoping nothing falls through the cracks.
NinjaOne has been working with enterprise customers who refused to accept that compromise. Instead of waiting for a feature request, they used the NinjaOne scripting engine, API, custom fields, and Dynamic Policies to build exactly the patching workflows they needed. Here are two of those stories.
Building a better patching script with NinjaOne
A large enterprise had been running a legacy configuration management platform for years. It worked, but the infrastructure cost was enormous with dedicated servers, distribution points, database backends, and VPN dependencies for remote devices.
The company wanted to move to NinjaOne, but thought their patching process may have posed an insurmountable obstacle to adoption. They had built a phased rollout model where patches flowed through the organization in stages. They’d start with a small test group, expand to early adopters, then roll out to corporate offices, and finally patch field locations weeks later. Each phase had a specific delay tied to when Microsoft releases patches, and some phases could only install during overnight maintenance windows to avoid disrupting operations.
That kind of “release day plus N days” logic doesn’t exist natively in most endpoint management tools. It didn’t exist in the last three platforms they evaluated before NinjaOne, either.
Simplified patching without the overhead
Using the NinjaOne scripting engine, the customer created a gating script that runs automatically before every patch cycle. It does the date math, determines the current month’s release anchor, adds the appropriate delay for that device’s phase, and decides whether today is the right day. If it is, patching proceeds. If it isn’t, the script tells NinjaOne to skip the cycle cleanly and try again next time.
The script made it simple for the team managing patching day-to-day. Administrators don’t have to touch any code. They simply pick their deployment phase from a dropdown menu in NinjaOne and the script handles the rest. If the organization decides to adjust the delay for a particular group, they only need to change one dropdown value. That’s it.
Today, this company has fully decommissioned their legacy patching infrastructure. No more dedicated servers. No more VPN requirements for remote laptops. Their entire fleet patches directly from the vendor over the internet, and they still have the same phased rollout discipline they’ve always relied on — just without the overhead
Connecting a CMDB to NinjaOne so patching runs itself
A large enterprise manages a fleet of servers across multiple operating systems. Every server in their environment has a maintenance window defined in their CMDB. This maintenance window is a record that specifies the environment type, the day of the week, and the time window when patching is allowed. Across the organization’s entire server fleet, that adds up to dozens of unique maintenance window combinations.
An additional complication is that their patching calendar isn’t based on recurring patterns. They patch on specific dates each month, planned out a year in advance. They also enforce an annual freeze period during their busiest season where no patches touch production. Individual servers carry their own flags including some can’t be rebooted during patching, some only get reboots without patches, and some require full manual intervention.
Before NinjaOne, the IT team managed all of this manually. Spreadsheets tracked which servers were patched at what time. Tribal knowledge filled the gaps. Some devices fell through the cracks. Patches were missed.
NinjaOne removed all this complexity by connecting their CMDB directly to the NinjaOne policy engine using three layers of automation:
- Automated sync: A script runs on a schedule, reads each server’s maintenance window from the CMDB, and writes the relevant details to custom fields on the matching NinjaOne device. When a server’s window changes in the CMDB, NinjaOne picks it up automatically. No one has to manually reassign policies.
- Calendar gate: Once a year, an administrator enters the start dates for each month’s patch cycles into the NinjaOne custom fields. A daily script checks the date against those fields and sets a single value that determines if the patch will proceed or not. When it’s a non-production patch week, only non-production servers are eligible. When it’s a production week, only production servers are eligible. When it’s a freeze or an off week, everything goes quiet. One value controls the whole environment.
- Dynamic policies with layered targeting: Each unique maintenance window gets its own Dynamic Policy. The policies use multiple targeting conditions including the device’s environment, its assigned day, its assigned time, and the current calendar state. These all have to align before a device matches. When the calendar gate is off, no devices match any policy. When it turns on, only the right servers light up.
With these automations, the organization is able to patch their entire server fleet on the correct date, at the correct time, in the correct order — automatically. The CMDB remains the primary authority for maintenance windows, and NinjaOne executes against it without manual intervention. What used to take spreadsheets and coordination calls now runs itself.
The bigger picture
Neither of these customers asked NinjaOne to build a new feature. They didn’t file a request and wait for a release. They looked at the tools NinjaOne already provides — scripting, API, custom fields, Dynamic Policies — and built the scripts they needed for their environment.
That’s the difference between a tool and a platform. A tool does what it was designed to do. A platform lets you build what you need it to do.
For enterprise IT teams dealing with complex patching calendars, CMDB integrations, phased rollouts, and operational constraints that don’t fit neatly into a dropdown menu, NinjaOne gives you the building blocks to make it work. Not someday. Today.
Learn more at NinjaOne.com/patch-management
