Why PVS Was Never the Problem—It Was the Lack of Tools

pvs vs. mcs

Let me say this right off the bat: Citrix Provisioning was never the inferior technology. Nevertheless, the industry has flocked to MCS—not because PVS was inferior, but because there were no decent tools available for it. I saw this gap in projects over the years, and at some point I decided to close it. The result is called PVS Forge.

It started with a customer who had several master targets

The specific trigger was a customer for whom fresh vDisks had to be created regularly—at least once a month—from several master targets. Even back then, that was a thankless, repetitive manual task. At the time, I semi-automated the process using a script I wrote myself—but only to a limited extent. Synchronization with the other servers wasn’t yet automated, and much of the work still had to be done manually.

It didn't stop with that one customer. With others, I saw the same pattern, only more painful: They struggled with imaging. Images that froze. Boot problems. The whole string of issues that can go wrong with vDisk imaging. What looks like a simple process on paper turned into a source of errors and a time-sink in everyday use.

And then the same pattern on a much larger scale

About one and a half to two years ago, another case came to light that made the issue even clearer—this time on a large scale. A customer with several thousand workers and a double-digit number of PVS servers was experiencing massive performance issues. The cause lay not in PVS itself, but in the architecture: a central shared storage system had become a bottleneck.

The solution was to switch to local storage per PVS server—technically the right answer, as it resolved the performance bottlenecks. But it promptly created the next problem: If every vDisk has to be stored locally on each server, synchronizing across all these stores becomes the real challenge. And this is exactly where the pattern reemerges: PVS scales exceptionally well—several thousand workers across a two-digit number of servers are the best proof of that. What was missing was the tool to make managing this scale manageable. This case, too, was directly incorporated into PVS Forge.

The Real, Invisible Problem: the Lifecycle

The longer I worked on these projects, the clearer it became to me that imaging is only half the story. The other half is versioning—and that’s just as painful. What changes were made to which vDisk version, and when? What is the current status of each one? Neither PVS nor MCS answers these questions on its own.

And yes—this is explicitly not just a PVS issue. With MCS, too, the lifecycle of a Golden Image is just as difficult to track. The entire lifecycle of a vDisk or a golden image is simply not tracked anywhere. People rely on notes, memory, and the administrator’s gut feeling. For a technology that provides productive workstations, that’s surprisingly haphazard.

Why the Industry Turned to MCS—and Why That Was a Tooling Problem

I've always been a proponent of PVS. I've implemented the technology for many customers and helped them understand its strengths: a single image, streamed over the network to any number of targets, and hypervisor-independent.

And yet I’ve seen how work gradually shifted over to MCS. The reason was almost never „PVS can’t do that.“ The reason was: the imaging It was easier with MCS, the distribution was easier to do. In short—MCS had usable, integrated workflows, while PVS lacked them. It was a tool problem, not a technology problem.

That’s exactly where my train of thought comes in: If PVS is just missing the tools, then we simply have to build those tools. Tools that make imaging as easy as it is with MCS—or even easier. And if we succeed in doing that, then PVS, as a server system paired with a good tool, won’t be the second-best option, but rather the ideal solution.

PVS Forge: The Missing Tool Layer

PVS Forge is exactly this tool layer. It handles the imaging process and breaks it down into just a few steps: enter login credentials, locate the master target in Active Directory, select a store, and start. The tool handles the rest—vDisk creation, restarting the master target, logging out open sessions, synchronization across all PVS servers, and import. The process is identical every time and therefore produces the same result every time: no errors.

Synchronization, in particular, is more than just a side issue here. Anyone who relies on local storage per server for performance reasons—such as the customer experiencing performance issues—needs a reliable, traceable way to deploy each vDisk to every server. That’s exactly what PVS Forge does, rather than leaving it up to the administrator and a collection of scripts.

And it closes the second, invisible gap: the lifecycle. PVS Forge shows which version is located where and what has has changed between two states of a vDisk – right down to the installed software. That’s the traceability I’ve been missing for years. Add to that the built-in practical knowledge gained from all these projects: the many little details related to Sealing, DNS, and boot that experienced administrators usually stumble over.

And then came Proxmox

It is only at this point—and deliberately only here—that the topic of hypervisors, which is currently on many people’s minds, comes into play. This is because it reinforces my argument; it does not substantiate it.

MCS is heavily dependent on the hypervisor. You need its API, and if something goes wrong with MCS, that's Troubleshooting is often tedious. However, as soon as a company switches to a hypervisor that MCS doesn't support—Proxmox is the current example—MCS simply stops working. PVS, on the other hand, streams over the network and is hypervisor-agnostic. The technology, which many had already written off, is thus suddenly the a safe haven for migrants.

To me, that's proof of the original thesis: PVS was never the problem. All it took was the the right tools to make the most of his strengths in everyday life as well. And right now, of all times, as the hypervisor landscape is changing, that's paying off.

Conclusion

PVS Forge wasn’t conceived on the drawing board to fill a gap in the market, but rather grew out of specific customer projects and a firm belief: that excellent technology doesn’t fail because of its own shortcomings, but because of a lack of tools. I’m now providing those tools. Anyone who runs PVS—or who is rethinking their approach in light of the hypervisor question—will find an answer that truly makes day-to-day operations easier.


PVS Forge is my commercial tool for automating, versioning, and monitoring Citrix Provisioning. For full details, a free trial, and technical documentation, visit www.pvs-forge.com.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top