This site uses cookies to serve our services. By using our site, you acknowledge that you have read and understood our Cookie Policy and Privacy Policy.
Menu
If you’re like everyone else, you’re scrambling to migrate your applications from your Windows Server 2012 hosts in response to Microsoft and their plans to sunset support for Windows Server 2012 in October 2023. And even if you are ahead of the game, Windows 10 support is likely to end in October 2025.
Either way, migrations to Windows Server 2019/2022 or Windows 11 are on the horizon, making this article a must-read.
Within this article I will use Red Hat Ansible and Microsoft Deployment Toolkit to automate a nightly re-building of your golden images so that each morning those images are ready to deploy your new servers or workstations, already patched with the latest updates from Microsoft.
If you’re a technical person, click the GitHub link below to be taken to the step-by-step instructions. For everyone else, scroll down and read the article.
That said, I never recommend skipping the article or just sending your IT staff a hyperlink to the GitHub repo. Let them read this article so they know the why and the how.
The best way to be alerted about our new news articles is to follow us on Twitter or LinkedIn. If you’d rather be notified by email, fill out the form below.
Scan the barcode below to open this article up on your mobile device and continue reading this on the go.
In media production, a gold image is the final cut of an album or film after all edits and mixing have been completed. It’s in its final, perfect form – it’s gold.
This meaning carried over into systems administration. In this context, a golden image is an intentionally configured snapshot of a system (server, virtual desktop environment, or even a disk drive) which can be used to deploy new virtual or physical machines. Because this golden image (or sometimes gold image) is used in network virtualisation to create new systems, it is also called a master image or clone image. Another popular term is a baseline image, which can be an illustrative term to frame why golden images are so useful: they create a consistent, reliable baseline for system configuration, making it easier to maintain those systems across their life cycle.
Privacy, Security, protection against configuration drift, reduced human error and uniformity are some reasons that come to mind when thinking of the reasons why you should have a golden image. The main reason, however, has always remained the same – every business is different. There are always settings or software you need loaded onto or removed from your server or workstation before it can be deployed onto your network. To tackle this as efficiently as possible, you create a golden image to serve as a baseline system configuration to ensure that all your workstations and servers start from the same baseline.
The best example is a staff workstation. Every Dell, Lenovo or HP laptop or desktop you purchase over the years will undoubtedly come pre-loaded with bloatware. Bloatware is software preinstalled by the manufacturer that your staff do not want or need for their day-to-day activities that should be removed from the workstation. That bloatware can hinder your staff’s productivity by possibly interfering with other software you require on the workstation. And if left on the workstation, that bloatware is additional software your IT team needs to monitor and patch with security updates.
You tackle this problem with a golden image, saving you time and money by creating a template Windows installation with only the software you want and need on the workstation. Everything else is removed. You create this golden image on any workstation (i.e. Dell, Lenovo, HP, etc.) and then deploy it on any workstation from any manufacturer, whether it be Lenovo, Dell, HP or even, in some cases, a virtual desktop.
Creating golden images (or templating) has been a common practice at many organisations for a decade or more. The problem is that many organisations need to develop better habits in managing these images. Let’s go through some examples.
Most organisations using golden images are only doing so for Windows 10/11 workstations. Even then, that golden image was almost always created months (or years) ago. An old image means after the golden image is deployed on a new machine, IT technicians must next install the Windows Updates released by Microsoft between when that image was created and the present day. This is to ensure that those outdated images are protected from the latest cybersecurity threats and zero-day vulnerabilities actively being exploited. And here’s a secret business leaders don’t ever hear – because those Windows Updates take time to install and workstations are generally needed as soon as possible, there is a good chance workstations are not being fully patched before being released into circulation.
The same can be said for Windows Servers. What’s worse for servers, you’re probably using a number of different technologies depending on whether you’re deploying a virtual machine or a physical server.
For virtual machines, images are almost always very old and never revisited VMware templates. Deploying a Windows machine from a VMware template is practically instantaneous, which is something Operation teams have become so used to, so much so that provisioning a new VM has become an eleventh-hour task done a few minutes before the virtual machine is needed. What’s the result? A “new” virtual server missing months (or years) of critical Microsoft patches, which sits on your network until your next patch cycle.
For physical servers, you’re probably just installing Windows using a USB stick and then manually installing all of the Windows Updates, making that machine susceptible to configuration drift.
Both of these are time-consuming. And both put dozens of machines on your network that either have “configuration drift” or vulnerabilities associated with unpatched systems.
Even if you have IT policies and platforms automatically installing Windows Updates after your endpoint is deployed, those installations take time. The time that takes is often the excuse for why those systems are not patched when they were provisioned.
The goal today is simple. We need to acknowledge that despite your well-written and strict IT policies and procedures, servers and workstations will always be needed and requested at the last minute. Meaning someone within your organisation will always need a server or workstation and cannot wait a minute longer than absolutely necessary.
And so, with that in mind, we’re going tackle this with an “it is what it is” mentality and come up with a solution to mitigate risks associated with releasing unpatched servers and workstations into your network. I will use Microsoft Deployment Toolkit (MDT) to install and capture golden images for your Windows workstations and servers. Then Ansible will be used to update the MDT deployment share so that the golden images you deploy from MDT are the images that were patched in the overnight automated process. All of this is a hands-free process that Ansible manages.
The automation is simple. Each night Red Hat Ansible will start a VMware virtual machine, which will launch Microsoft Deployment Toolkit to install Windows (or Windows Server) on that virtual machine. MDT will install the latest Windows Updates and whatever additional software you want to be preinstalled. After it is completed, MDT will Sysprep and Capture a reusable image of the machine. Red Hat Ansible will monitor MDT. Then once Ansible detects that the image capture process is complete, it will update the golden image in the Microsoft Deployment Toolkit Deployment Share, ensuring that MDT always has a Windows 10/11 and Windows Server Image with the latest patches from Microsoft preinstalled.
As mentioned at the beginning of the article, the problem isn’t with installing Windows Updates. The problem I am trying to solve is that your staff will eventually have legitimate reasons why there was no time to perform these tasks on the new server or workstation they provisioned yesterday. The solution is to do this work the night before using a hands-free automated process, so those excuses need to happen.
Another benefit of this approach is that you now have a uniform way to manage your golden images across all platforms, whether you’re deploying a workstation, virtual machine or physical server.
No. You shouldn’t read this article thinking that Red Hat Ansible is a product comparable to Acronis True Image or Norton Ghost because it isn’t.
Red Hat Ansible is an incredibly powerful automation platform that is an excellent product in your toolkit. It can help your organisation do many things related to SecOps, deploying code, network management, infrastructure automation, and much more. Ansible has integrations with VMware, Microsoft, Cisco, HP, Dell, Lenovo, FireEye and many other products you have deployed within your network. In this article we’re just using Ansible’s integrations with VMware and Microsoft Deployment Toolkit to add a feature missing from both products so that you have a uniform imaging solution useable by all environments, physical or virtual.
Please use the GitHub link at the top of the article for more information on how to get started. You can get a 30-day trial of Red Hat Ansible Automation Hub from Red Hat. BMT is an authorised reseller that I hope you will consider contacting, given our expertise and openest to share ideas and solutions.
If you would like more examples of how you can use Ansible to work smarter (not harder), please consider following me on LinkedIn to stay tuned for more Ansible-related articles.
The next article I will be releasing soon is: Patch on Tuesday (not Friday). In that article, we will discuss zero-downtime patching, where I use Red Hat Ansible to patch during business hours rather than patching during maintenance windows on weekends and public holidays. Smart and frequent patching means less downtime, makes you less susceptible to vulnerabilities and provides a better work-life balance for your IT staff.
In the weeks following I’ll discuss using Red Hat Ansible to automate the shutting down of your AWS and Azure Development and Test environments, saving corporations a tremendous amount of money on machines where you’re billed by the hour.
Subscribe for latest articles and resources
Sign up to receive updates, promotions, and sneak peaks of upcoming products. Plus 20% off your next order.
