The object on the mahogany table is a simple, brass-plated letter opener. It has a heavy handle and a dull edge, more suited for prying than slicing, and it has sat in the same spot through three changes of departmental leadership. It represents the lingering hope that something complex might eventually be opened and understood with a single, decisive motion.
In the world of enterprise infrastructure, we are constantly reaching for this letter opener while staring at a mountain of mail we refuse to read. We talk about the weight of the brass and the history of the polish, but we never actually slit the envelope.
The Masterpiece of Corporate Architecture
The meeting today is about the licensing strategy for the next . There are fourteen people in the room, three of whom are dialed in from time zones where the sun hasn’t even considered rising. The goal is to produce a framework-a robust, multi-layered governance model that accounts for hybrid cloud transitions, remote work fluctuations, and the inevitable shift toward “as-a-service” everything.
It is a quarterly engagement. It will involve four workshops, twelve stakeholder interviews, and a final presentation that will occupy sixty-four megabytes of storage. It is a masterpiece of corporate architecture. What is missing from the room is a sentence.
Specifically, the sentence that should have been written in : “We use Device CALs for the warehouse terminals because the machines are shared, and User CALs for the office staff because they move between desks.” That is the truth of the situation. It has been the truth for nearly .
Yet, because that sentence requires someone to stand up and own a definitive rule, the organization has spent commissioning frameworks instead. We prefer the safety of a framework because a framework is a process, and a process cannot be “wrong” in the way a sentence can.
I used to be the person who built the weather systems. I spent a significant portion of my early thirties believing that if a problem felt heavy, the solution needed to be equally dense. I once spent nearly five thousand dollars on a third-party audit to determine if we should consolidate our server clusters, when the answer was plainly visible to anyone who walked into the server room and saw the layers of dust on the secondary rack.
I was wrong to think that volume of data was a substitute for the courage of a conclusion. I wanted the comfort of a spreadsheet that stretched to column ZZ. I didn’t want the vulnerability of saying, “Turn it off.”
The RDS Grace Period Pressure
This happens most frequently in the quiet, dusty corners of Microsoft Remote Desktop Services. There is a specific kind of atmospheric pressure that builds when an IT administrator realizes the for a new Windows Server deployment is ending.
Day 45
Footnote
Day 90
Task
Day 121
Crisis
It is a low-grade fever of a problem. Suddenly, the “strategy” for how the company handles remote access becomes an urgent boardroom topic. They want a governance model for RDS. They want a long-term roadmap for virtualization. They do not want to admit they just need to buy fifty keys before the logins stop working.
A damp sock is a small misery that ruins a large day. I am currently wearing one, having stepped in a puddle of unknown origin near the breakroom cooler, and it has sharpened my intolerance for the “strategic” fluff happening in this meeting. The discomfort of the wet cotton against my heel makes the three-year roadmap feel particularly absurd.
When your terminal server is about to lock out your accounting department, you don’t need a licensing framework; you need a quantity and a type.
The institutional escalation of simple questions into complex programs is a defense mechanism. Programs have “owners,” which sounds important but actually serves to distribute the risk of being wrong across a committee. If a “Licensing Optimization Program” fails to deliver clarity, the program was simply “under-resourced” or “hampered by data silos.”
But if a single sentence written by a single administrator-“We need 50 User CALs for the Server 2022 migration”-is wrong, that administrator is the one standing in the rain. We build frameworks to keep our clothes dry, even if the roof is already gone.
The Binary Choice: User vs. Device
Consider the actual technical requirements of a Remote Desktop Services environment. You are faced with a binary choice: User or Device. It is a fork in the road that has existed since the dawn of the terminal server.
User CAL
A User CAL allows one person to access the server from any number of devices-laptop, home PC, tablet.
Device CAL
A Device CAL allows an unlimited number of people to access the server from one specific machine.
This is not a philosophical debate. It is a headcount exercise. Yet, I have watched companies spend weeks debating the “strategic alignment” of these two choices as if they were choosing a political ideology.
If you have a terminal server running Windows Server 2019, 2022, or the upcoming 2025, the “strategy” is almost certainly just a math problem. How many people are connecting? How many devices do they use?
If the number of people is smaller than the number of devices, buy User CALs. If the number of machines is smaller (like a call center or a hospital nursing station), buy Device CALs. Write that down. Put it in a single sentence on the top of the internal wiki.
That sentence is now your strategy. It is more valuable than any slide deck because it is actionable at on a Tuesday when the server starts throwing licensing errors.
There is a certain dignity in a clear sentence. It acknowledges the reality of the work. A sysadmin under pressure doesn’t have time to navigate a “decision-tree framework” designed by a consultant who has never seen a server rack.
They need to know that the licenses are official, perpetual, and backed by a guarantee that makes the purchase reversible if they made a mistake. They need the not because they are indecisive, but because the business is often indecisive, and the admin needs a safety net while the “strategists” are still debating the font for the executive summary.
I remember a specific failure of mine involving a fleet of mobile devices. I spent designing a “Mobile Device Management Strategy” that included 12 different tiers of user permissions. It was a beautiful document. It had color-coded diagrams. It had a glossary.
“The ‘strategy’ was a 50-page document. The ‘sentence’ should have been: ‘Buy the $20 rubber cases.'”
– Author Reflection
I was so focused on the governance of the data that I forgot about the gravity of the hardware. We do the same thing with RDS licensing. We worry about the “global compliance posture” while the grace period timer is ticking down in the corner of the screen.
We look for a framework that will justify our existence to our superiors, instead of looking for the license key that will allow our users to do their jobs. The reality is that official Microsoft licenses are a commodity, and the best way to handle a commodity is to acquire it with the least amount of ceremony possible.
The Theatre of Risk
The brass letter opener is still sitting there. The meeting is now entering its second hour, and someone is currently explaining the difference between “proactive compliance” and “reactive remediation.” My sock is still wet.
I am thinking about the delivery time of a digital license key and how it represents a different world-a world where we just do the thing we said we were going to do.
The solution to complexity is rarely more complexity. It is usually a reduction of the problem to its most basic, undeniable components. If you are running Windows Server, you need CALs. If you need CALs, you need a reliable source and a clear count. Everything else is just theatre.
We perform the theatre because it makes us feel like we are managing the “risk” of the technology, when the only real risk is the server stopping.
In the end, the most “strategic” thing an IT department can do is to stop behaving as if every purchase is a philosophical crisis. A perpetual license is a simple tool. It is a key that fits a lock. You don’t need a three-year roadmap to unlock a door; you just need to know where the key is kept.
When the organization finally tires of the meetings and the frameworks, they will find that the answer was always waiting in a single, unglamorous line of text. They will realize that the “governance model” was just a very expensive way of avoiding a very cheap decision.
The meeting breaks for lunch. The letter opener is left on the table, unused. As I walk out, squelching slightly with every step, I realize that the most important work isn’t happening in this room.
The important work is happening in the server rooms and the home offices where people are just trying to connect. They don’t need our strategy. They need us to write the sentence, buy the licenses, and move on to the next problem. They need us to fix the leak instead of describing the water.