What is the difference between disabling SMBv1 with a policy setting and uninstalling the feature?

## The distinction in one line Disabling changes **how the machine is configured**. Removing changes **what the machine can do**. Everything else follows from that. ## What 'disabled' actually leaves behind Take SMBv1 on a Windows host. Turning it off through a policy setting or a configuration value does all of this and no more: - the optional feature that provides SMBv1 is **still installed** - the driver and the server-side responder are on disk; - the service-manager entry is **still present**, with a start type set to disabled rather than absent; - the dialect is **still implemented** by the code that is running the rest of the file-sharing stack; - the setting itself is a value that the administrator role is allowed to write. So the honest description of a disabled protocol is: *the capability exists and is currently declined*. That is a real and useful state - but it is a state, and states are reversible by whoever owns the write. ## What 'removed' means Uninstalling the optional feature takes the responder and its supporting code off the host. Now the same configuration write that would have re-enabled it has nothing to act on. Restoring the capability is no longer a value change; it is a software installation, which needs the package, usually needs a reboot, and is a different kind of act from flipping a setting. That is the whole security value of removal: it moves the capability out of the set of things a single write can restore. ## Why interviewers ask this The wrong answer they are listening for is *'the group policy disables it, so it is gone from the estate.'* It is a comfortable answer because the reporting looks identical - the protocol is not in use either way. But the two states behave completely differently under pressure: | | Disabled | Removed | |---|---|---| | Component on disk | present | absent | | Restore cost for an administrator | one value write | install software, usually reboot | | Survives someone with delegated administration | no | not without a deliberate install | | Survives a badly scoped policy change | no | yes | | Available for every protocol | yes | **no** | That last row matters. Removal is not always on the menu. NTLM is the standard counter-example: it is a security package that ships with the operating system and cannot be uninstalled. You can restrict it, refuse it, and force the negotiation to prefer something else, but the package stays installed. Where removal is unavailable, the revocable configuration *is* the control, and the people who can rewrite it become part of the control's boundary. ## Do not over-swing Candidates who have just learned this distinction often go too far and say disabling is worthless. It is not. A disabled dialect is unavailable to every unauthenticated party on the segment, to every user without administrative rights, and to any process that has not already won that privilege. That covers most of the ways a host is approached. The correct framing is narrower and more useful: **a configuration setting is not a control against a position that already holds the privilege the setting lives inside.** There is also a non-malicious version of the same failure, and it is more common than the malicious one. A vendor's field engineer with delegated administration on a print or scanning fleet finds a device that stopped working, turns the legacy dialect back on because that is what makes the device work, and moves on. Nothing about that act is an attack, and mechanically it is the same act. Removal survives it; a setting does not. ## What a good answer sounds like Name the three things: the component is still installed, the setting is a writable state, and the write is inside the administrator's envelope. Then say what removal changes - the restore is now an installation, not a value. Then add the honest caveat that some capabilities cannot be removed, only refused, and that for those the question becomes who holds the privilege that can undo the refusal.