Elias Thorne spends his mornings in a workshop that smells faintly of cedar shavings and expensive wool. He is a bespoke tailor, the kind who still uses a heavy iron powered by actual steam and keeps a collection of chalk stubs that are smaller than a thumbnail.

Last Tuesday, Elias decided to optimize his supply chain. He realized that for the structural seams of a dinner jacket, he needed a high-tensile polyester thread, but for the visible top-stitching, only pure silk would do. On his ledger, this looked like a stroke of genius. He would save 14% on raw material costs by not wasting silk where nobody would see it.

But three days later, Elias was nearly in tears. Every time he transitioned from a seam to a lapel, he had to stop, unthread his 1950s-era Singer, purge the bobbin, and recalibrate the tension. What looked like a 14% savings on the balance sheet was actually a 40% drain on his billable hours. He had optimized the material but forgotten to account for the friction of the transition.

In the world of IT infrastructure, Esteban is our Elias.

The Logic of the Kiosk and the Laptop

Esteban is the kind of systems administrator who actually reads the documentation before he starts clicking “Next.” He had been tasked with refreshing the Remote Desktop Services (RDS) environment for a mid-sized logistics firm. It was a classic mixed-use case.

For those 10 kiosks where shifts of three people rotated throughout the day, Device CALs (Client Access Licenses) were the only logical choice. Why buy thirty licenses for thirty people when you only have ten machines?

For the rest of the staff-the eight roaming sales executives who lived on their laptops and iPads-User CALs were the obvious play. Esteban did the math, presented a tidy spreadsheet to his CFO, and felt the same satisfaction I felt this morning when I managed to peel a Navel orange in one single, unbroken spiral of zest. It was clean. It was efficient. It was a disaster waiting to happen.

The Reality of the “Mode Lock”

Nobody warns you that while Microsoft allows you to install a mix of User and Device CALs on the same Remote Desktop License Server, the management of that mix is not a “set it and forget it” affair. It is an administrative tax that most people only discover when they are three inches deep in a licensing audit or a server migration.

The fundamental problem is that the RDS Licensing service treats User CALs and Device CALs with a completely different set of physics. When you configure an RD Session Host, you have to tell it which “mode” to operate in. It’s a binary choice. You are either in “Per User” mode or “Per Device” mode.

Esteban’s first realization of his mistake came when he tried to point his warehouse kiosks at the session host. Because he had set the host to “Per User” to accommodate the sales team, the kiosks were stubbornly refusing to check out the Device CALs he had sitting in the pool.

The Hidden Overhead of Segregation

This is the “Mode Lock.” To truly use both types of CALs in a single environment, you often end up having to segregate your hosts into different collections. One group of servers is set to Per Device for the warehouse, and another group is set to Per User for the office.

Suddenly, Esteban’s “efficient” 18-license environment required double the virtual machine overhead just to keep the licensing logic from tripping over its own feet.

“Efficiency is a trap if the cost of monitoring it exceeds the savings of the resource.”

– Sarah R.J., Veteran Supply Chain Analyst

She’s right. When you buy a mix of CALs, you are essentially betting that your time is worth less than the price difference between a User CAL and a Device CAL. In many cases, especially in smaller deployments, that is a losing bet.

The Opaque Nature of Tracking

The tracking reality is even more opaque. If you look at the RD Licensing Manager, Device CALs are tracked with surgical precision. You can see which machine has which license and when it expires. User CALs, however, are a different beast.

In many versions of Windows Server, the Licensing Manager doesn’t even track the issuance of User CALs in a way that allows for real-time enforcement. It’s more of a “gentleman’s agreement” reflected in a report.

When you mix them, your license server becomes a hall of mirrors. You have one set of licenses that are strictly enforced and another set that are loosely reported. If an auditor walks in, you can’t just hand over a single PDF. You have to explain the architecture of your split collections, show why certain users are hitting certain hosts, and pray that your documentation matches the reality of a Tuesday afternoon three months ago.

The Price of Cleverness

The silence around this friction is loud. If you go to a major reseller, they will happily sell you five of these and ten of those. They won’t ask if you have the infrastructure to support two different licensing modes. They won’t mention that you might need to manage multiple RDS deployment properties.

I’ve seen this play out dozens of times. A small business owner tries to save $200 by mixing five Device CALs for their front-desk machines with five User CALs for their remote bookkeepers. They spend the next three years fighting with “No license server available” errors because they tried to point a “Per Device” machine at a “Per User” session host.

When I finally sat down with Esteban, we looked at his dashboard. He’d bought his licenses from the

RDS CAL Store,

which was the only thing that went right-he had his keys in 15 minutes and the support team actually answered his email-but the architecture he’d built on top of those licenses was a house of cards. He was trying to be too clever.

The Hard Call: Choosing Simplicity

We ended up making a hard call. We converted the entire environment to User CALs. Yes, it meant “over-buying” licenses for the warehouse staff. On paper, it looked like we were being wasteful. We were buying licenses for thirty human beings instead of ten machines.

But the moment we flipped the switch to a unified “Per User” mode across all hosts, the “License not found” tickets vanished. The server overhead dropped because we could collapse his separate collections into one. Esteban stopped spending his Friday afternoons checking the License Manager and started actually improving the user experience.

Microsoft’s licensing documents are written by lawyers and product managers who operate in a world of perfect logic. They assume that if a feature exists (like mixing CAL types on a server), it is a viable path for everyone. They don’t account for the guy who has to manage it while also fixing the printer and worrying about the firewall.

Re-threading the Needle

If you are currently looking at your environment and thinking about a 60/40 split between User and Device CALs, I want you to imagine Elias the tailor. I want you to imagine the frustration of re-threading the needle every time you move from the seam to the lapel.

For most people, the answer is a resounding no. The most expensive license you can buy is the one that requires a human being to manually supervise it every month.

There is a certain dignity in the “unbroken orange peel” approach to IT. It’s the realization that simplicity is a feature, not a lack of sophistication. By choosing one licensing mode and sticking to it-usually User CALs for the modern, mobile-first world-you are buying back your own peace of mind.

The Final Stitch

You are deciding that your time is more valuable than the marginal savings of a “clever” licensing mix. You are deciding to be a tailor who actually finishes the suit, rather than one who spends all day fighting with his sewing machine.

In the end, Esteban took the lesson to heart. He didn’t just fix the licenses; he changed how he approached the entire stack. He realized that every “clever” shortcut usually comes with a long-term maintenance fee that nobody mentions at the checkout counter.

He stopped looking for the “cheapest” way to be compliant and started looking for the “cleanest” way to stay operational. And that, more than any spreadsheet optimization, is what makes a great systems administrator. He learned that sometimes, the most professional thing you can do is refuse to be too smart for your own good.