Solving the problem rather than answering the question: Why does somebody want to write an unkillable process?

Via their customer liaison, a customer wanted to know how to create a process that runs with the context of the user, but which the user cannot terminate without elevating to administrator.

The customer is engaging in the futile arms race between programs and users (which is more properly a walls and ladders scenario). And we saw that Windows has decided to keep users in control of their own programs and data and let them kill any process that belongs to them. (For one thing, allowing a process running in a user’s context to protect itself from termination would mean that malware could make itself unkillable without requiring elevation.)

We asked the customer liaison why their program is so important that they don’t want the user to terminate it.

The customer liaison explained, “The program is launched when the user logs in, and the customer doesn’t want the user to be able to terminate the process from Task Manager.”

Observe that the customer (through the liaison) is not answering the question. They keep saying what they want to do (looking for an answer) without describing the problem they are trying to solve (developing a solution). We had to ask them a second time, adding that even if they managed to protect the program from being terminated via Task Manager, that doesn’t mean the user can’t get the program to crash, which is equivalent to terminating it. Now, the typical user won’t use these techniques, but the typical user also won’t go to the Processes tab of Task Manager and click End Task and then accept the scary warning dialog. We’re talking about a determined user at this point.

Finally, the customer coughed up the actual scenario. They have a service that monitors some central database. Based on the information in the central database, the service may decide that the user needs to log off. (Say, because the user’s profile server is going offline, or because the service needs to reconfigure the system. The exact reason isn’t important.) The application that launches at login listens for a notification from the service that a forced-logoff is about to occur and displays a balloon notification to the user warning them to save all their work because they are going to be logged off in N minutes.

At this point, I realized that they didn’t have a problem in the first place: The “horrible dire consequences” of the user terminating the application is simply that they don’t get balloon notifications? Who cares? For one thing, balloon notifications do not have guaranteed timely delivery. For example, Explorer won’t show a balloon if the user is in a fullscreen application or if the user is simply not at the computer. Furthermore, the user already has a way of not getting balloon notifications: By ignoring them when they appear on the screen!

If the user kills the “Please save your work and log off because the system is shutting down in N minutes for maintenance” notification application, and then they get booted off the computer without warning, well, they get what they deserve. It’s like somebody who intentionally pries the safety cover off the emergency power cutoff switch. If they bump into the switch and accidentally kill power to their computer, well, they went out of their way to disable the safety cover—they deserve what they get.

The customer appears not to have been listening very closely, because they summarized the situation as follows: “Right. There are currently two ways to meet the requirements. First, launch the UI process with service privileges, so that the user does not have permission to kill it. Or launch the UI process with user privileges, but marked as unkillable. It looks like your recommendation is to log off immediately if the user terminates the UI process. This will likely be satisfactory, but how can a process force the user to log off if it is terminated?”

I felt like I was stuck in one of those sitcom tropes where the comically obtuse character refuses to process any new information:

“I brought you the boxes from the storeroom.”

Thanks. Please put them against the wall.

“Should I put them on the shelf?”

No. Please put them against the wall.

“And then move them to the shelf?”

No. Just put them against the wall.

“Oh, sorry. I’ll take them back to the storeroom.”

No. Leave them here. Just put them against the wall.

“You want them here?”

Yes. Against the wall, please.

“Okay, I’ll put them on the shelf.”

The customer took my explanation of why the process doesn’t need to be unkillable and reinterpreted it as offering one of three options:

  • Launch a UI process with service privileges, which is a well-known security vulnerability.
  • Creating a process that cannot be killed by its owner, which we already noted was not possible. (Even if you deny Terminate permission, the user can simply edit the ACL to restore Terminate permission, because users always have WRITE_DAC permission on objects they own.)
  • Creating a process that logs the user off if it is terminated, which is possible with the help of the service, but is not something I ever mentioned at all.

I had to issue a clarification to the customer liaison: “My recommendation was not to log the user off immediately if the user kills the UI process. My recommendation is not to worry. Let the users kill the process if they want. They are only harming themselves. By killing the UI process, the users went in and disabled their smoke detector. If they die in a fire, that’s their problem.”

Unfortunately, this did not settle the issue with the customer, and we had another round of the scene with the comically obtuse character.

“Good news. We found a way to hide the process from the Applications tab, but it still shows up in the Processes tab. We would like to know if there is a way to hide the UI process from the Processes tab as well.”


The customer is totally fixated on putting the boxes on the shelf, no matter how many times we say, “Putting the boxes on the shelf will not solve your problem.”

Eventually we settled on some sort of compromise: Have the service monitor the UI process, and if it terminates, log the user off immediately or alternatively relaunch the UI process.

Extra wrinkle: Actually, the original design of the system was that the UI process would show the balloon, then wait N minutes, and then call Exit­Windows­Ex to log the user off. That’s why they didn’t want the user to be able to kill the process: If they killed the process, then nobody was going to perform the logoff. The solution to this was to move the forced logoff into the service. Note that preventing the user from terminating the UI process wouldn’t solve their problem anyway, because the user could simply patch out the Exit­Windows­Ex call or suspend the process so it never got a chance to call Exit­Windows­Ex in the first place. As with Web programming, you need to design on the assumption that the client has been completely compromised.

Comments (49)
  1. DWalker59 says:

    That's SO weird, that the customer is being so obtuse and won't listen to reason.  They seem to be blinded by their own assumptions… Often, when we get something in our head, it's hard to be talked out of it.  Human nature, I suppose, but they are wasting their time and Microsoft's time, which could be put to better use!

  2. I admire your perseverance and quality of service. But maybe you went a bit too far with this customer. It's fair to ask for the reason the customer wanted an unkillable process, and it's fair to try to solve what may be a misconception or even a problem of communication. But when the customer, after being said twice how to do things right, insists in doing them the wrong part, I don't think Microsoft customer service is to blame. As you said, if they want to disable the smoke detector, all you can do is recommend them not to do that. The smoke detector is theirs, and they can do whatever they want with it, no matter how bad it would be.

  3. MazeGen says:

    Well, if the boss wants the process unkillable, make it unkillable by whatever means and don't try to change the viewpoint!

  4. Mordachai says:

    There are a lot of people in the world who take it upon themselves to decide that they know better than the end-user, and do all sorts of things to force boundaries around that end-user, curtailing the user's ability to control their world.

    We're all living in a world full of people trying to control one another's actions.

    Personally, I wish Microsoft would do less controlling, and give more control over my computer to me and other end-users.  It's my machine, and if I want to disable my smoke detectors, I should be allowed to do so.  However, this culture war between those who want to control you and those who want to set you free is fundamental to our species behavior mechanisms, and I don't see it ending any eon soon.

    Nor is it as simple as all that… children do need to be protected – so it is a bit of a tight-rope walk to strike a good balance between giving users freedom while not making it too easy for the novices to blow their own legs off by accident.

  5. Anon says:


    Microsoft takes the blame for every single one of these customers, though. That's why they released reliability data demonstrating that the number of crashes attributable to Microsoft software are statistically insignificant. Yet people continue to blame Microsoft for instability, rather than third-party driver and software vendors.

    When the end-user in this scenario can't kill this process and is automatically logged off, they're going to blame Microsoft for it. They're going to go to all of their friends and talk about how horrible Windows is. Then they're going to go buy an iFruit, where FruitCo's response to this customer would be "You can't do this, and we're going to blacklist your software if we catch you trying."

  6. Anon says:


    The problem is that if Raymond could actually say "Here is how you make an unkillable application," he's liable to end up with another customer liaison next week demanding to know why there are a bunch of unkillable applications running.

  7. dbacher says:

    What's really funny is there's an app built into Windows NT 3.51 and later named shutdown.exe, that can be used on remote machines with a simple command line switch.  It already displays a balloon notification "you will be logged of in 10 minutes" — or on some platforms it pops up a dialog box with a count down.

    It seems like that fits their use case perfectly, and so why write something at all?

    It's similar to here they have the policy set to block cmd.exe, but not to block .cmd files or other scripts — nor PowerShell.  I'm pretty sure there's nothing that I can do with cmd.exe that I cannot do with PowerShell.  (blocked for non-admin users, I can use my admin credentials but that takes typing my PIN again on my smart card which is a pain).

  8. Anon says:


    But shutdown.exe was NMH, so someone got the idea into their head that maybe Microsoft might one day eliminate it.

    An equally likely explanation is that the "admin" is actually a developer, not an administrator, and thus doesn't actually know/hasn't taken the time to learn anything about system administration.

  9. Joshua says:

    [alternatively relaunch the UI process]

    I occasionally have to kill  wmiprvse.exe because it won't let go of some .exe file. It relaunches automatically, but is no longer holding the .exe file long enough for me to delete & replace it. This only happens on customer machines, never dev or test machines, so I haven't been able to get to the bottom of the problem.

    Auto-relaunch comes in handy sometimes.

    The "Extra wrinkle" puts the request out of insane and back to semi-sane territory. Have the service auto-launch the desktop process, and set the service to auto-launch 1 minute after termination.

  10. Philip says:

    my guess is that this was being written by the network &  infrastructure group,  not a dev group.   I've seen that before, anyway.   The IT department wants something secure so they write out themselves in VB6 or whatever that one guy knows.   Then it gets pushed out via group policy,  without going through a normal QA process,  and causes all sorts of problems.  But your stuck with it because it's required for "security reasons".   This being the same group not letting you install any tools because it's "non standard software"

  11. J says:

    did the customer insist on balloon notification?  If not they could have used InitiateSystemShutdown and let Windows give the users a warning and a count-down.

  12. Jim says:

    @MazeGen, You got the point. This is the typical Corp behavior. Just do what your boss says, stop thinking….

  13. Matt Brown says:

    This is a great article.  I was just reviewing an IM monitoring app, and I recommended this exact architecture to reach the goal of an "always on" app.  The problem still exists for members of Administrators (since they own all objects, right?); you'd have to implement a [separate] watchdog service that is in constant communication with [a server (for instance)], and [have the server] keep an eye on the actions of those damn pesky, annoying human brains.

  14. You can make a process that runs under user's account, but cannot be killed by the user. The process' token owner (which is different from the process user context) needs to be the service account (LOCAL_SERVICE), and the ACL needs to only allow "read" privileges on the process for the logged on user.

  15. "There are a lot of people in the world who take it upon themselves to decide that they know better than the end-user, and do all sorts of things to force boundaries around that end-user, curtailing the user's ability to control their world."

    Typical users have no more understanding of the world inside the computer, than a 3 year old has about the world around them, and will as happily run around with scissors and shove them into electric sockets without any second thought.

  16. > will as happily run around with scissors and shove them into electric sockets without any second thought.

    And install anything that proclaims itself useful and needed (giving it all keys to the kingdom), and click on everything clickable, and run everything runnable. You can only hope Windows is designed to limit the damage. It's NOT, and the home (and many domain) users still have unlimited privileges.

  17. >That's SO weird, that the customer is being so obtuse and won't listen to reason.

    No, it's business as usual. Weird it would be only if the customer saw the light and righted their way.

  18. Myria says:

    How do you even become "a customer" who can ask such development questions to Windows developers?  I've run into some really exotic Windows issues at my employer.  Is there some sort of developer-level support contract?

  19. @alegr1:

    "You can make a process that runs under user's account, but cannot be killed by the user."

    Oh no, the process has just gone into an infinite loop and I can't kill it. What is Microsoft doing creating such a bad operating system that stops me from terminating processes which have hung.

    Also, while it is true a limited user would have issues with it, if the user is determined, they would still be able to kill it anyway. If they try hard enough, they probably could find an exploit or some other issue to cause the application to crash. As was said, it is an arms race, and if you take one step forward, so will other people.

    In general though, even if you manage to create this super process that is so awesome, you still couldn't get past the administrator. SE_TAKE_OWNERSHIP privilege and all that.

  20. 12BitSlab says:

    This is an age-old problem not necessarily related to Windows.  I have seen repeatedly where someone has a management problem, but somehow that someone thinks that the management problem at hand needs to turn it into a technology problem.  Fundamentally, if a business has rules that must be followed, then it is up to the managers and supervisors to make sure that the rules are indeed followed.  If there are a substantial number of managers who think the rule is wrong or that the infraction is simply not worth their time to enforce, then the business has a different problem; i.e., who are the senior managers who are too far out of touch that they make up stupid rules?  In this case, the right answer is, do not write a single line of code.

  21. Bob Hir says:

    "How do you even become "a customer" who can ask such development questions to Windows developers?  I've run into some really exotic Windows issues at my employer.  Is there some sort of developer-level support contract?"

    Be a big enterprise with alot of seats, have a paid support agreement and a TAM assigned to you, and you can open all kinds of requests and have them escalated with Microsoft in all kinds of ways.

    I once opened an issue with MS about something through our TAM, and it made it's way through Microsoft all the way to Michael Kaplan for a response (had something to do with language packs or language something or other). I was suprised when the response I got tracked back to him..

  22. Matt Brown says:

    @Myself from earlier:

    Also, allowing interaction in the user session would be granted by some separate UI process that can be run by the user, and use some inter-process communication.

  23. wombat says:

    I suppose Raymond could simply say "You can't make such a process unkillable". That would be a less helpful approach, but might save him from a few ulcers. The big problem is that Raymond wants to help the customer solve their REAL problem.

    It's always possible that the customer liaison person is "translating" the questions and answers. I have come across such a situation in the past. When the customer and the developer finally met it turned out that the "problem" wasn't what had been reported, and the solution was an existing API call. They didn't end up lynching the liaison person, but they did request a change :)

  24. Aaron Margosis says:

    One simple solution:  monitor for "need to log off" from the service.  When that happens, THEN start the process in the user's session that displays the warning (or just call WTSSendMessage).  Five minutes later (or whenever), then the service calls WTSLogoffSession function to end the user's session.

  25. >That's the main reason why FruitCo, selling higher quality hardware than the average PC maker, has a worldwide market quota of less than 5%

    …while enjoying more profits than the rest of the industry combined…

  26. >In the end, it's the end user who can say "no software of this firm will run on my computer" when the case arrives.

    Of course, every end user has enough qualification and expertise to know that "software of this firm" is full of hacks and security holes and/or installs a rootkit/spam server/keylogger, too.

  27. smf says:

    They are just being passive aggressive.

    I have empathy for them, while it is an amusing anecdote here they will likely have anecdotes of their own about their users.

    Employee: "I am not using that computer again because it doesn't work, it logged me out without telling me."

    Your customer: "It will have showed you a message before shutting down"

    Employee: "No it didn't"

    Your customer: "We know you've been killing the process"

    Employee: "So? I'm not using your broken computer anymore, but you have to keep paying me or I'll file a grievance with the union"

  28. Gechurch says:

    @Steve Wolf

    "Personally, I wish Microsoft would do less controlling, and give more control over my computer to me and other end-users."

    That's exactly what's going on here. The programmer in this case wanted to create an app that the end-user couldn't kill. But Windows does not allow this because that would be taking control out of the hands of the user. Microsoft are championing the rights of the end-user here.

  29. Cheong says:

    This sounds so familar… seems someone has asked the question in MSDN forum, and we told him we're not going to assist something that can be used for malware development.

    Maybe he took it as a hint that this can somehow be done.

  30. @Anon: yes, I know Microsoft gets the blame of everything, from overclocked CPUs/GPUs and cheap/faulty hardware to badly written drivers or software. But there is little Microsoft can do about it, if they want Windows to continue being an open platform.

    That's the main reason why FruitCo, selling higher quality hardware than the average PC maker, has a worldwide market quota of less than 5%, where the PC, even with all its "bad press", holds a 95% – *nineteen* times greater. People isn't as silly as those pundits would like us to believe.

    Of course, opening the platform so the end user can do whatever wants to do, also allows third party developers to do what the end user doesn't want. In the end, it's the end user who can say "no software of this firm will run on my computer" when the case arrives. That's exactly what Windows offers to users: actual choice.

  31. Anonymous Coward says:

    The customer wasn't ‘comically obtuse’, you were. They probably have some users with clout that insist on terminating processes and complain when they lose data. The customer told you exactly what they needed but you behaved throughout as if you didn't understand the question. Even though perfectly good solutions to the problem exist.

    What is this article even supposed to accomplish? Trying to convince yourself that you were right by presenting us a coloured version of the story?

  32. Medinoc says:

    Ah, the "interactive service" solution. I remember one which both worked as LocalSystem and had a "Browse…" button with a file dialog… Hello, cmd.exe!

  33. Non sequitor says:

    @Anonymous Coward. Interesting inference based on the information presented. Anyways, I think a comically obtuse way of solving their problem would be to present a solution whereby the monitoring service deployed hooks and snooped on taskmgr.exe and moved the task manager window out of the way anytime the mouse neared its client area (same idea for keyboard events).

  34. dave says:

    @Steve Wolf

    >It's my machine, and if I want to disable my smoke detectors, I should be allowed to do so.  

    And indeed you can do so.  On the other hand, demanding that someone else helps you to design a foolproof smoke-detector-tampering-tool seems a bit much.

  35. 640k says:

    "Windows has decided to keep users in control of their own programs and data and let them kill any process that belongs to them"

    This is a lie.

    taskmgr stops an administrator to kill some processes, even when a kill command/api allows it. Thus, taskmgr has support for preventing killing some processes, and does NOT put the user in control.

    [That hasn't been true for quite some time. -Raymond]
  36. Maurits says:

    So you're saying I can kill winlogon from Task Manager? Cool, let's see if this wo#$(@#*&NO CARRIER

  37. Danny says:

    Whoa whoa whoa..what happened here? I saw it with my own eyes, she hit it! (sorry, just saw Despicable Me and this got stuck in my head). Anyway, here is a real life scenario, which, funny enough, I encountered on one of my clients and it's close enough to what your customer wanted. So, definition:

    - customer is running an Internet Cafee kind of business. All the PC are his, none are of the actual user who just rents time on running programs on them. Any program. Including games, heavy audio/video editors, all flavors of servers (IIS, Apache, MSSQL, MySQL, PostgreSQL, you name it it's installed on those machines), all flavors of programming languages (should I do here what I did for servers?), all browsers (yes, IE too :D), all everything, you name it, it's there!!!

    - customer wants everything automated, his goal is no need of human supervision. His clients swipe a credit card at the booth door and pushes one button from an array of buttons, each determining how much time he wants (10 minutes, 30 minutes, 1 hour, 2 hours, 5 hours – let's take an example), door opens, client sit down, PC automatically logs in and in upper right corner a counter display how much time he has left. When counter reaches zero, screen goes to log off. At any given time, including after the counter is zero, the client can swipe the credit card and push the desired button adding time in this way to his counter.

    Let's assume the clients using this type of service would be in a secured area so no bad human behavior would arise (like cutting the mouse cord). Now, if someone with such an idea would come to you (you being the uber super informed programmer who understand Ray's hidden question at the end of his article even before reading half of it) and get asked:

    "- look dude, I need a program who runs in the admin privileges but I don't want to be killed and I want to do the log off after a period of time" – what your response would be? Reading this article it springed in my mind that the customer who got so obtuse was the programmer who got this task. He could not go past of Ray answer simply because he got asked to implement a program that would do exactly that – survive the kill! Except the dude never got a chance to understand what was the initial vision of his employer (the automated PC booth). So, how you would implement such a program?

  38. @640k:

    These days you get a message along the lines of:

    "Are you sure you really want to do something so stupid?"

    If you click yes then you can experience the awesomeness of weird things happening, from weird things happening to your account being forced logged off to some really great bug checks.

  39. @Danny:

    It normally done by means other than "unkillable program". You can log off the user session by a service request, for example. You can display a dialog box by WTS* API call. The policies can limit the user to be able to only launch a set of applications, and even if he manages to start Task Manager, he won't be able to do anything destructive.

  40. Danny says:

    @alegr1 – I am logged as admin, so i can kill your service. I can mess around with policies as well, change them, remember, I am logged as Admin. Why? Because some programs that my clients use are most profitable, they rent my PC booth specifically for that and those programs requires Admin privileges in order to properly run.

    [With admin privileges, they can just reformat the hard drive and install Linux. No software enforcement will stop that. You will have to go to another level, like having a hardware timer that physically kills power to the computer when time runs out. -Raymond]
  41. Igor Levicki says:


    Given enough privileges, users can download and run process explorer or process hacker.

    If they can't do that, they can put the certificate used to sign your software into utrusted certificate store and software won't be run on next reboot if UAC is enabled.

    Finally, if that is somehow blocked they can reboot computer from USB or DVD (or if those are disabled off the network/TFTP), run some live Linux distro, mount system partition and simply delete your program.

  42. @Danny:

    I don't think you understand what PC booth is. If your clients run some very profitable program, they/you can afford to exclusively use a dedicated computer. Or rent a virtual machine.

    @Igor Levicki:

    A PC booth/kiosk doesn't give users "enough" privileges. It might even not allow file download. It might as well just run a disposable virtual machine which is rolled back after each client session. It won't even allow DVD/USB flash boot without BIOS password. And you can't open the box to reset the password.

  43. I'm so frustrated that too many times the question boils down to: "We're going (or we insist) to do the things the wrong way. How to make it as if we're doing it the right way? And please don't tell us to do the things the right way"

  44. Danny says:

    @Ray – yes, they can "attempt" to do that. How do you let them believe they did it only to find out at reboot that windows is still there? If they want to burn their time trying to install Linux, trust me, the booth in question would aloow that as well. And you're right, there is a hardware involved that would simply reset the PC at the end of the rented time.

    @alegr1 – well, since the scenario was laid out from the beginning I believe that what I understand with "PC booth" and what you think I understand could be 2 different things. Anyway, the scenario is real and working.

    How I solve it? Deep Freeze. DF and the very simple electronic board with a CI and a 512 bytes EEPROM. Sometime, in order to succeed at software, hardware knowledge is required.

    However, this article was about a possible programmer who could not see the whole idea and got stuck with "unkillable" process. My real life project, that ended quite quick after I told him to go buy Deep Freeze licenses and gave him the electronic schematic, did that to me too – I started to wonder how to make an "unkillable" process. I promise Ray, it wasn't me the customer you're talking about in here :)

    [If you have a hardware device to cut power, then why do you care about writing an unkillable process? The hardware device is unkillable. Use that. If the user kills the warning balloon, then they deserve what they get. -Raymond]
  45. Joshua says:

    > If they can't do that, they can put the certificate used to sign your software into utrusted certificate store and software won't be run on next reboot if UAC is enabled.

    And there we have it, a good reason to not sign software. Figures the very thing that UAC encourages turns out to have a nasty wrinkle, that of giving MS or some upstream certificate provider a bloody kill switch for your software.

    @Danny: I have a Deep Freeze killer.

  46. Danny says:


    Good luck using it at my customer PC booths

  47. Guys, I don't understand. Do you want your booth to give the user access to World Wide Web, or to Wild Wild West?

    Why you're even talking about the user adding a rogue certificate? An user should not be able to do that.

  48. j b says:


    > the question boils down to: "We're going (or we insist) to do the things the wrong way.

    Sure. However, most professionals do a very poor or mediocre job of explaining to the layman the rationale behind the RIGHT way (or even what IS the right way) in a way that makes sense to the nonprofessional, and that relates to his situation. We say "Do so-and-so, and be happy when it works!"

    To keep people from doing it the WRONG way, we must explain to them WHY it is wrong. Generally, we fail miserably; we are even worse at explaining the wrongs than the rights. The user may understand that the right way is a viable alternative, maybe even a good one, but "if it works, don't fix it". As long as the user's approach ALSO seems like a viable alternative, why not stick to that?

    The answer to "But why can't I do it the way I planned to?" is NOT "Because it is the wrong way". If the user has to ask, again and again, "But WHY is it wrong?", you have failed to explain it well enough. You haven't grasped the user's way of thinking any more than he has grasped yours; the lack of understanding is certainly not only on the user's side. And don't forget: This is NOT a symmetrical situation, the user's alternative vs. yours. YOU are the one claiming that solution A is wrong, solution B is right; YOU must defend both claims. Not for yourself to be convinced, but for the user to be convinced.

    A few people are good at explaining both sides; Raymond stands out as one of those. (I suspect that in many of the cases he reports, he did not handle the customer himself – he would have done better… :-).) But far too often, when I come in after someone else have tried to help the user, it ends up in some "So THAT'S why it fails? Then I understand why it should be done the way Joe insisted on doing it." Amd it comes out right.

    Finally, I'd like to remark that in a couple cases, I have myself been one of those argumentative users, insisting on my own approach, asking repeatedly "But why not?", and ended up with a reply "Well, I guess your argument makes sense…", and the software has indeed been updated to fit my approach. Obviously, my arguments have been at a professional level; yet we should carefully avoid seeing our established approach as the single viable one, now and forever.

  49. >To keep people from doing it the WRONG way, we must explain to them WHY it is wrong.

    Or at least do not make the wrong way the Windows default. The single most damaging thing to Windows security reputation has been that it was making the new users Administrators by default. It's still a default. And there are enterprise deployments where all domain users are also local administrators, because of that.

Comments are closed.