Maintenance windows have been around for a long time. They were designed primarily to control when Windows updates were installed on machines. This was to minimize and control when reboots occurred and affected end users.
The history of maintenance windows and their relevance today
Maintenance windows first started in the mid- to late 1990s as a way to schedule maintenance tasks. The concept was more of a guide, not something fully supported by a platform. Maintenance windows were first introduced by IT admins in the form of Group Policy Objects and Scheduled Tasks in the Windows 2000/XP eras. This was long before we started pushing applications during these windows.
It wasn’t until 2007 (SCCM 2007) that IT admins were able to control not only the maintenance windows for Windows updates, but for deployments as well. And since applications and packages in SCCM are considered deployments, IT admins could control when end users got them.
Now, I am not here to say that maintenance windows are a bad thing when it comes to Windows and driver updates (and I would even second guess the driver updates piece). But I question whether they are needed for third-party updates. And you should be questioning it too. We should evaluate whether the ways of the past are still pertinent today, with all the threat actors out there actively trying to exploit applications’ vulnerabilities.
Options to control automatic updates
Not everyone wants to have full control over all their applications, namely auto-updates. There are some applications out there that have built-in abilities to update themselves when a new version comes out. Google Chrome, Microsoft Edge, Mozilla Firefox, Notepad++, and Microsoft Office: These are just a few well-known examples.
A lot of organizations like this process and leverage it to maintain security on those applications. Other organizations want more control over when those updates go out. They want to be able to approve them version by version. And that’s okay. That’s why there are tools out there to help. Here at Recast, we have two different products that can assist with this, but I am going to focus on how we can do it within our application delivery solution, Application Workspace.
Now, I get it. There are some situations where you may want a defined window in time to install an update to the device. However, that doesn’t mean that every application needs a tight timeline, and not all organizations need this level of control.
The goal is to make sure we don’t introduce vulnerabilities. But if one is identified, it needs to be resolved as soon as possible.
In recent news, the Notepad++ attack involved infrastructure-level compromise that allowed malicious actors to intercept and redirect update traffic destined for notepad-plus-plus.org. Although this was a targeted attack, it underscores the danger of allowing untested automatic updates. Preventing threat actors from gaining access to applications and infrastructure requires a diligent approach to application management.
How Application Workspace handles background patching today
In Application Workspace, we currently don’t have a mechanism for maintenance windows. Our goal is to patch on demand, when an application requires an update to keep those vulnerabilities out of environments. This doesn’t take away the DTAP process. It just speeds up delivery when needed.
Within Application Workspace, we can achieve patch compliance and control in several ways. It all starts when our Connectors synchronize. For those new to Connectors, this is how we connect to available resources. Synchronization is the process of comparing the packages you have brought in from the connector to see if there have been any updates to those packages since the last synchronization. In essence, it’s bringing in and applying those newer “binaries” to your packages and then delivering updates to your end users.
As an Application Workspace admin, you set up a scheduled task to synchronize that connector when you deem it appropriate for your environment. This could be hourly, daily, weekly, or even monthly. We have some cool PowerShell tricks to give you even more granular control over the scheduled tasks.
When you bring in those newer binaries determines how they go out to your environment. If you bring them right into your Production stage, then all users who are entitled to that package will start seeing the updated binaries being applied to their machines.
How and when those binaries are applied is what we want to focus on at this point.
Exploring patching scenarios in Application Workspace
By default, when someone uses a Smart Icon to launch an application that’s slated to be updated, Application Workspace will complete the update before the user can open the app. This means that once the new binaries are released, the user has no choice but to update their application.
What about those applications that users don’t launch, like services or agents that are always running? How can we address those? That’s where triggers come into play. Triggers allow you to “trigger” an action at certain points. Trigger examples include refresh, login, logoff, startup, shutdown, etc. Using a trigger allows those types of applications to upgrade in the background without the user having to launch something to update the application.
We can use triggers on entitled applications that a user would launch as well. They are not limited to services or agents, which ensures that applications are being updated whether or not users are launching them.
Then we have scenarios where the user never closes an application and relaunches it through the Smart Icon. I know that I leave Edge open all the time, and I rarely log out of my machine or reboot. So, in those instances, how can we take it to the next level and make sure applications are being updated efficiently?
This is where I build an “update” package, a separate package in Application Workspace that performs all the updates. Each action in the package is just an “install package” step where it calls the correct entitled package. I entitle it to everyone and add a trigger that will run on refresh. In each action, I add a few filters that help control that process. One filter makes it so that step will only run if they have installed that original package. Another filter ensures the process is not running, so it doesn’t generate errors. If I want to be fancier, I can even add steps that check if the application is running and then prompt the user to inform them that their application needs to update and then close it for them.
Next steps with Application Workspace
These are just ideas to get you thinking. You can devise the solution that best fits your organization’s needs. The great thing about Application Workspace is that it gives you the flexibility to think outside the box and not be stuck in that old way of thinking that requires maintenance windows for third-party apps. It’s a powerful tool to improve the digital employee experience.
If you’re already using Application Workspace and want to talk through ideas, let us know, and we would be glad to get that conversation started. Or, if you’d like to learn more about the product, you can request a demo.
Happy patching!
