Infrastructure / Workstation / Admin By Request
Remove local administrator privileges without logging anyone out.
The question isn't whether to remove them. It's what happens the next day.In most of the parks we visit, some of the users are local administrators of their own machines—sometimes everyone is. Everyone knows this is a problem, and the project doesn’t get off the ground because the real issue isn’t technical: it’s who will respond to requests, how long it will take, and what we do at 7 p.m. on a Friday.
Abolishing these rights: three reasons why it hasn't happened yet
They have nothing to do with choosing software. These are the issues that need to be addressed first, and that’s why this project is dragging on in many companies, even though everyone agrees on the principle.
No one knows who installs what
Permissions were granted over the years for specific, valid reasons, and no one has the list anymore. Revoking permissions without knowing the context is like blocking someone who, unbeknownst to you, needed to install a driver every week.
Measure before removing anything.
The fear of an overwhelmed IT department
If every installation becomes a ticket, the team spends its days approving requests. It is this legitimate fear that is holding the project back, and it’s addressed through policy, not through the product: most requests don’t require human intervention.
What is predictable becomes automatic; the rest is a matter of choice.
No one wants to be the one to say no
Taking away a right from a manager, an engineer, or someone who works the night shift is a political issue before it is a technical one. A written rule that applies equally to everyone is better than a case-by-case decision that no one wants to make.
The rule also protects the person who enforces it.
What Happens the Next Day
This is the part that product descriptions don’t cover, because it’s not a product issue. Four situations arise as early as the first week, and each one requires a different approach. Anticipating them is what keeps the project on track.
An ordinary installation, in broad daylight
A known software program, a known user, and an up-to-date machine. The request is processed without human intervention: it is automatically approved, the file is scanned before execution, and the action is logged.
These make up the vast majority of requests, and they're what determine whether or not your team is overwhelmed.
Software that nobody knows about
At this point, someone has to make a decision. The request includes all the necessary information to make that decision—who, what, from which machine, and the results of the file analysis— rather than just a message that says, “I’d like to install.”
What needs to be worked out with you: who makes the decisions, and how long they’ll take to respond.
7 p.m. on a Friday, and no one is answering
This is what causes projects to fail, because it leads to permanent circumvention. The solution is not to leave the door open: it’s a time-limited session that the user initiates themselves, with a written justification and a complete log of what was done during that time.
No one is left behind, and nothing is overlooked.
Those who install them every day
Developers, test engineers, and workshop staff. Taking away their rights—just as we’ve done with others—will turn them into the project’s staunchest opponents. They’re given their own set of rules—broader in scope, but laid out in the same way.
A different rule isn't an exception: it's written down, dated, and can be reviewed.
This tool does not manage your positions. It manages who is authorized to do what in those positions.
Deploying software, configuring settings, encrypting disks, and keeping machines up to date: these are the tasks of IT asset management. The two are often included in the same scope of work, but they are distinct topics, and one does not replace the other.
Questions We Are Asked
In that order, pretty much every time. The mechanisms described are documented by the publisher, and we double-check them before each proposal.
| The question | The Answer |
|---|---|
| Should I set up a server? | No. A client on each workstation, an online portal. Nothing to host on your end, nothing to publish externally, and therefore nothing extra to maintain or back up. |
| What can you see in an installation? | Who, what, when, from which machine, with what justification, and what the file analysis showed before execution. The log is the project’s true output —it’s what we review after an incident, and it cannot be reconstructed after the fact. |
| Will my users have to wait? | For the vast majority of requests, no—they’re handled without human intervention. What determines the user experience is your rule, not the product—and we work with you to define it before deploying anything. |
| What about Macs? What about servers? | The same mechanism and the same log on WindowsmacOS , and the servers—all accessed from the same portal. This eliminates the need for three different procedures and three different places to look. |
| Does this replace our antivirus software? | No, and it shouldn't be presented that way. The analysis focuses on the file that is about to be executed with elevated privileges at that moment. Your usual protection remains in place and continues to function. |
| Is there anything he doesn't do? | It doesn’t make decisions for you. It simply enforces the rules you set: if those rules are too broad, it neatly enforces permissions you shouldn’t have granted in the first place. It doesn’t deploy your software, it doesn’t take over asset management, and it will never tell you whether an unknown piece of software is worth installing on your system—that decision is entirely yours. |
The last line refers to our own product, not to those of others. That’s the only kind of statement we’re willing to make: we don’t make any claims about solutions we don’t manufacture and whose product lines change every quarter.
How Does a Mandate Work?
Four steps. The first one takes longer than the other three, and that's normal: it's the one that determines whether the rest goes smoothly.
We assess what is actually taking shape
The customer is placed in "observation mode": no one loses any rights, and for a few weeks we record what is actually installed, by whom, and how often. This data replaces all assumptions.
It almost always shows that the vast majority of installations come from a small list of well-known software programs.
We'll work with you to write the rule
What gets approved automatically, what requires a decision, who makes the decision, how long it takes, and what we do outside of business hours. This is a discussion about organization, not configuration.
It fits on one page, has been approved by management, and is the same for everyone.
Rights are being revoked in waves
First, a pilot service—chosen in consultation with you—and we only move forward after evaluating its results. Each subsequent wave builds on what the previous one has learned—almost always adjustments to the process, not to the product.
Those affected are notified in advance, along with a three-line guide on what to do.
We review the log, and we tighten things up
A month later, the newspaper reported what had actually been requested. Now is the time to narrow down what was too broad and expand what was holding things back—based on facts, not impressions.
This review takes place once a year: a park is constantly changing, and a rule established once eventually becomes outdated.
What You Need to Know Before Committing
Three questions we ask ourselves on the first date. Everyone figures it out for themselves; none of them is a reason to back out.
A tool is no substitute for a decision
If the written rule allows almost anything, you’ll end up with a very comprehensive record of rights you shouldn’t have granted. The rule applies; it doesn’t decide.
That’s why Step 02 exists and why it’s carried out in collaboration with your management team—not just your IT department. Once one page is approved, the rest will follow.
Some older software requires permanent access rights
Business software that writes to a system folder every time it is launched will not work for a standard user. This is rare, but it does happen, and it is detected in Step 01.
Here's what's done: those machines are isolated according to a specific set of rules, the rest of the fleet moves forward, and the software replacement is planned separately—without holding up the entire project.
The first few weeks require your full attention
Unusual requests all come in at the beginning. If no one responds quickly during this period, users conclude that the new system is inconvenient for them, and that impression cannot be undone.
We're part of the first wave, and the deadline commitment is set in writing before we begin. It's included in the budget from the start—not added later.
Related Topics
Who has the right to install is one question; who has the right to enter is another, and that is addressed elsewhere.
Position Management with Intune
Deploy software, configure settings, encrypt disks, and keep machines up to date. These two tasks often come together in the same project.
Read the page IdentityMicrosoft Entra ID
Your directory's administrative accounts—the ones that can create accounts and grant permissions—are a separate matter from a machine administrator.
Read the page DepartmentInfrastructure and Cloud
What the team responsible for setting up workstations, servers, email, and directories does: what they handle, and what they don't do.
View the departmentLet's start by measuring, without removing anything
After a few weeks of monitoring your property—without anyone losing any rights—you’ll get a list of what’s actually being installed on your property. It’s this inventory that tells you whether the project is straightforward or not —and it’s worth discussing, even if you later decide not to take any action.
Renens, Sion, Châtel-Saint-Denis. +41 21 806 37 15 — [email protected]