10 minutes

You have a virtual workplace environment. Multiple servers or desktops, a number of images, hundreds of users. And every time something needs to be changed, the same ritual begins: log into one machine, make the change, hope you don’t forget it on the other machines, and weeks later discover that the production environment differs from what you expected.

This comes into play in any environment where virtual desktops or applications are provided. Whether you’re working with Citrix, Microsoft Azure Virtual Desktop, Parallels or Remote Desktop Services. The technology differs, the pain is the same.

And that pain is greater than it seems.

How image management works in practice and why it causes problems

In most organizations, image management is something that has grown, not been designed. An image was created, once upon a time. That image has been modified over the years. Software added, software removed, updates made, settings changed. The result is an image that carries the full history of everything that has ever been done on it.

It sounds harmless, but it is a creeping problem. Removed software leaves residue behind. Applications that have been updated but never cleanly reinstalled behave slightly differently than they should. Settings that were once modified but never restored cause unexpected behavior.

We call this image contamination. It’s not visible, but you notice it. In incidents you can’t explain. In behavior that deviates from what you expect. In an environment that is increasingly difficult to troubleshoot.

Gartner estimates that more than 60% of IT failures in enterprise environments can be traced to configuration errors or unplanned changes. A contaminated image is a structural source of exactly those types of errors.

How does this vary by platform?

Not every platform handles images in the same way. That determines how big the impact of poor image management is.

Citrix, AVD and Parallels: a shared image for the entire pool

With Citrix Virtual Apps and Desktops, Azure Virtual Desktop and Parallels RAS, you can work with a shared image for a group of virtual machines. You modify the image, and the whole pool gets that modification. That’s a big advantage, but it makes the quality of that one image determine what all your users experience every day.

If that image is contaminated, or if changes are not tracked consistently, the whole pool works suboptimally. And if you make changes directly to the running image without rebuilding it, the contamination accumulates with each change.

RDS: updating each server separately

With Remote Desktop Services, there is no shared image model. Each RDS server is an independent machine. A change you want to make must be made on each server separately. With five servers, this is manageable. At twenty servers, it’s time-consuming, error-prone manual work.

In practice, this leads to servers diverging from each other over time. One server has an application in version 3.2, the other still in 3.0. Patches are rolled out on some machines, not others. Users get a different experience depending on which server they land on. This is called configuration drift, and it is particularly difficult to control in RDS environments without automated tooling.

The problem with updating instead of rebuilding

Suppose you’ve been working with the same base image for three years. In those three years, dozens of updates have been made. Applications have been updated. Some have been removed. Drivers have been installed and replaced. Settings have been adjusted.

That image is no longer what it once was. It’s a sum of all the changes that have ever been made on it. And every change that has not been made cleanly leaves a trace.

Consider:

• Software that was uninstalled but left registry entries or residual files
• Applications updated via an installer that did not completely clean up the previous version
• Services disabled but not removed
• Drivers that have been replaced while the previous version is still in the driver store
• Configuration files once modified and never restored to a known good state

The result is an image that becomes increasingly heavy, increasingly noisy and increasingly difficult to fathom. And then when something goes wrong, you don’t know where to start.

The solution is not better tracking. The solution is rebuilding.

Additional benefit: easier switching of hypervisor or platform

An underrated benefit of working with IaC is the freedom it gives you when you want to migrate. Anyone who has ever moved an environment from VMware to Citrix Hypervisor, or from on-premises to the cloud, knows how difficult it is when your image is built with platform-specific tools.

Consider VMware Tools that are deeply intertwined with the image, or configurations specific to the underlying hypervisor. In a migration, you have to remove those tools, install the new tools, and hope nothing remains that causes problems. In an image that has been maintained manually for years, that’s a risky operation.

With IaC, you rebuild the image for the new environment. You modify the configuration script, you specify which tools and drivers are needed for the new platform, and you start the build. The result is a clean image, built specifically for the new environment, with no remnants of the old platform.

This makes migrations significantly easier and less risky. Whether you go from:

• VMware to XenServer or Citrix Hypervisor
• On-premises to Azure, AWS or another cloud provider
• One version of Windows Server to the next
• Citrix to AVD, or vice versa

In all these cases, a clean, reproducible image is your best starting point. And IaC makes sure you always have that.

What is Infrastructure as Code and what does it solve?

Infrastructure as Code is an approach where you don’t maintain your image, but rebuild it. You describe in code or a configuration file what should be on the image: what software, what versions, what settings. And every time you want a new image, you build it from a clean base.

No accumulation of changes. No remnants of old software. No unexplained behavior. Each build is a clean start, with fully documented content.

The build process in practice

Briefly, an IaC-based image pipeline works like this:

• Start with a clean base image, Windows Server or Windows 11
• Configuration script installs all desired software in appropriate versions
• Windows updates are integrated
• The appropriate agent is installed, for Citrix, AVD, RDS or Parallels
• Application-specific settings are configured
• The image is validated and released for deployment

Every step is documented in the code. Every version of every application is documented. You can always go back to a previous build, and you can always see exactly what’s in the current image.

How New Yard handles this for you

At New Yard, we provide IaC-based image management as an ongoing service. That means we build a new image for you at set intervals, with all updates and changes incorporated, without you or your team having to do it manually. You pay a fixed monthly fee and know what you’re getting.

Fixed build times, tailored to your environment

By default, we build a new image after every Patch Tuesday, Microsoft’s monthly update cycle. But we can also build a new image several times a month. Applications like Microsoft Edge, Google Chrome and Adobe Reader get regular updates outside the monthly cycle. If you want those to always be current in your environment, we tune the build frequency accordingly.

Request unlimited changes

You can request unlimited changes per image. Add a new application, replace an existing one, change a setting. We process the change in the code and then rebuild the image. No manual work on the machines, no risk of incomplete deployment.

Detailed build report after each build

After each build, you receive a complete overview of all installed software, including version numbers. This makes it easy to compare the new build with the previous one. You can see exactly which applications have been updated, which have been newly added and whether you are completely up to date. This is not only useful for day-to-day management, but also valuable for compliance and audits.

The risks of continuing as you work now

Irreducible incidents

If your environment is inconsistent, troubleshooting takes a disproportionate amount of time. You don’t know if the problem is in the configuration of that particular machine, in an update halfway through somewhere, or in something else. Without a reproducible basis, you have no reference point to work from.

Security holes due to incomplete patching

Patches deployed manually do not always get to all machines. This results in inconsistent patch levels. Microsoft data shows that more than 80% of successful cyberattacks exploit known vulnerabilities for which patches were available. An automated build cycle after Patch Tuesday structurally caps that risk.

Dependence on individual knowledge

When the administrator who knows the environment leaves or is sick, you stand still. What exactly is on which machine is not recorded, or at least not current. At IaC, the code is the documentation. Always current, always insightful.

Scalability

Is your environment growing? Then the problems scale with it. What is manageable at five machines becomes a management burden at fifty. IaC is inherently scalable: you add a parameter and the build process takes care of the rest.

Common objections and honest answers

‘We already have a golden image, which works fine’

A golden image is a good starting point. But if you’ve been updating that image for years with loose modifications, the contamination accumulates. IaC rebuilds the image, clean, every time. That is fundamentally different from tracking.

‘This sounds complex, we don’t have the knowledge for that’

You don’t need to have that knowledge in-house either. We implement the pipeline and manage it for you. You tell us what needs to change, we make sure it gets into the image correctly and that the build is correct.

‘We are engaged in a platform migration’

Then this is the right time. With IaC, you build a clean image for the new platform, with no clutter from the old. Whether you’re moving from VMware to XenServer, or from on-premises to the cloud, you leave with a solid foundation.

‘This now takes more time than we have’

Implementation requires a one-time investment. But look at how much time now goes monthly into manual patching, deployment of updates and incident resolution due to inconsistent environments. You’ll recoup that time.

Practical checklist: where are you now?

• Are all changes to your images documented and reproducible?
• Can you currently build a completely new image without manual steps?
• Are all the machines in your pool at the same patch level?
• Do you have a current list of all installed software including versions?
• Can you compare the current build with the previous one to see what has changed?
• Is there a set cycle for updating your image after Patch Tuesday?
• In a platform migration, can you build a clean image without any remnants of the old environment?

The more times you answer “no,” the more likely it is that your image environment will quietly pollute and lose quality.

Ready to streamline your image management?

If you recognize what is described in this article, a no-obligation consultation is the logical next step. Together, we’ll look at your current environment, identify the risks and show you what an automated image pipeline looks like for your situation.

Schedule a free consultation through newyard.com. No obligations, but concrete insights.