Table of Contents
I patch daily, and I love it!
The term patching is now an unfortunate name as it conjures a historical image of unstable systems and bleeding edge technology we must avoid – while needing to protect ourselves behind layers of testing, trials and upgrade cycles.
A common term of “Patch Tuesday” defines the regular rhythm of perceived stability and instability for both desktops and servers with many choosing to avoid the problem altogether. A structured project cycle of Standard Operating Environment (SOE) creation results where each new version is updated, patched, tested and deployed. This process usually ends with a large and lengthy project that barely finishes before the next round needed and often well after.
Things have changed a lot over the years with patching no longer being a fix for inferior products and rushed release dates but more a way to improve and enhance productivity for users.
Manufacturers update your watch, phone, tablet, car, tv all automatically to provide new features and functions and rarely for issues, why would your computer be any different?
Windows and office products, updating a productive environment
The patching dilemma extends to productivity suite of office products and other Microsoft tools. What version to deploy, when and how to upgrade and what new functions will be the tipping point to initiate the project to do so.
User adoption and integration of poses all the same issues and commonly results in the bundling of operating system update along with that of productivity tools.
Times have changed: The world is your test environment, and you don’t know it.
How many workstations are deemed a sufficient test sample before considering a full deployment, 5%, 10%, or 20%? How big is your environment – 100 machines, or 1,000, or 10,000 plus? Even if we conduct a large test deployment, using 20% of workstations out of a total of 10,000, this is only a fraction of the total number of machines worldwide already using these updates.
Microsoft deploys Windows 10 updates in rings of adoption, each involving more users worldwide, and the feedback from each improving the process along the way until it reaches broad deployment. This process is designed to make implementation much more effective as a continual service approach than the traditional cyclic project. Windows 10 no longer gets “upgraded” per se. Instead, additional features, fixes, improvements and functions are added with each iteration. Iterations are spread over the environment based on this ring based approach not for stability but more to ensure the adoption champions receive the most advanced or new features in advance of the masses.
Servers treated better than desktops
Computers running Windows 10 may be sitting on desks, in the line of sight of all consumers, but the workhorses drive them are servers in the background which are running server operating systems of a variety of types. Servers also host a multitude of applications and services that users rely on as much as their own productivity tools and device.
Surprisingly server patching is generally seen as essential with less reliance on project-based cyclic upgrades and more on continuous patching.
Server patching has more risk to a business than desktop patching as a single server could affect many users if negatively impacted from an update. To reduce this risk, the same ‘circles’ methodology is to be applied to the Server 2016 operating system. The Windows Server 2016 lifecycle is no different from the Windows 10 process, with initial, pilot and broad deployment application over the same time periods.
Exponential Complexity
The complexity of patching servers is due to the combination of two things. Firstly, the consequences of failing to correctly patch servers can affect hundreds or even thousands of users. Secondly, patching a server also brings a requirement to update the applications that hosted on the server. These complexities often lead to servers being patched less often than desktops, out of a fear that the patches will introduce more instability than they resolve.
The ‘rings-based’ deployment approach, from least critical to most critical, is often used to manually segment and control the deployment of patches to servers. This also extends to the applications running on the servers such as Microsoft SQL, Exchange, SharePoint and Dynamics.
With the Server 2016 update process mirroring Windows 10, negative implications and risk are significantly reduced and more structured process driven patching regimens can be implemented to ensure ongoing and easy deployment.
The productivity of Process over Project
Many servers and desktops are now on a structured base receiving ongoing updates, across with millions of test users. The only restriction to action is often the management of the updates themselves.
How can we create rings, check on deployment, and ensure the servers and workstations are working correctly after an update? This is where modern tools can provide the framework that then only needs administration in the event of deviation. Desired state configuration (DSC) and operational runbooks to check functions work correctly as well as applying patches to the right servers, in the correct server order, to allow staff to monitor the process rather than implement each task individually.
The reason for patching has changed, but the perception of it has not. And our understanding of patching must change. Patching can be made simple. Patching has a core place in the modern workplace. And every organisation should modernise their patching approach and method.
If you would like to modernise your approach to patching and improve the reliability and stability of your environment – contact us. Talk to us and find out how Experteq can help augment your internal capability to enable both IT and business.
Experteq has devised an automated patch management service that removes the arduous task of monthly patching and reduces risk during the never-ending cycle of change. Our Automated Patch Management solution has smart alerting and notification capabilities to ensure that all dependencies and implementation flows are completed successfully, including checking systems are fully operational before and after.
Manual patching can often result in servers/systems being left in a partially operational state. Experteq’s automated patch management service includes workflows to test the functionality of websites, components, applications and even performance, after each patch cycle. This comprehensive level of testing results in confidence that systems are operational and stable after patches have been deployed and reduce the need for long hours by staff and the traditional morning-after headaches for all staff.
Experteq can tailor a solution to fit your organisation and give you and your staff back that valuable time, while reducing risk, outages and error associated with manual patching every month.
