An SMBv1 session fails against every host you try - does that prove the feature is removed?

## What a refused negotiation actually asserts SMB, like most of the protocols this question comes up about, begins with a negotiation: the client offers the dialects it is willing to speak, the server picks one or refuses. If the server does not serve SMBv1, the offer is declined and the session never forms. The direction of that claim matters and candidates routinely get it backwards. A failed negotiation proves **an offer was declined**. It does not prove: - that the component is absent - a disabled feature declines exactly the same way; - that the host will decline the next offer - the negotiation is re-run per connection against configuration that is writable; - anything at all about hosts you did not reach, including everything behind a device that answered for something else, everything powered off, and everything you never had a route to. ## Disabled and removed are indistinguishable from the outside This is the crux. From the client's position, a host with SMBv1 installed-but-disabled and a host with SMBv1 uninstalled behave the same: no response to the dialect, no session. The difference between them is entirely a fact about what is present on the host, and there is no way to read that fact off a refused connection. So any claim that rests on connection attempts is a claim about **current configuration of the hosts you reached**, and it decays. A single write on one host, one policy scope change, one vendor engineer restoring a scanner, and the same attempts start succeeding again with nothing in the estate having been installed. ## What would settle it Two separate questions, and they are both about presence rather than behaviour: 1. **Is the optional feature installed on this host?** Answered per host from the host's own installed-feature state. This is the question that distinguishes disabled from removed, and it is the only one that does. 2. **Which consumer requires the exception?** Wherever the answer to (1) is 'installed', there is usually a reason, and the reason is a device or an application. Naming it converts a vague 'some hosts still have it' into a specific, ownable item - and it is the question that tells you whether removal is even achievable. A third, weaker check is worth mentioning because it comes up: watching which dialect two ends actually agree on tells you what is being used today. That is useful for finding the last consumer, but it still cannot prove absence. A capability that is not exercised is not a capability that is gone. ## The scope trap The other half of the failure is population. 'Every host I tried' is not 'the estate'. On a flat site segment full of multifunction scanners, badge controllers and cameras, the hosts most likely to be holding the protocol open are the ones least likely to appear in whatever list you drew your targets from: they are appliances, they are owned by facilities rather than by the platform team, and they are frequently missing from the inventory that a hardening programme is measured against. So a defensible answer states the population explicitly: 'of the 612 hosts in the domain, 611 have the feature uninstalled and one scanner fleet controller has it installed and enabled; here are the appliances I could not enumerate.' ## How to say this in an interview Start by refusing the inference: connection failures show declines, not absence. Then give the reason - disabled and removed are identical from the client side. Then say what settles it: per-host installed-feature state, plus the named consumer behind each exception. Then bound the claim by the population you actually reached. Candidates who do all four are demonstrating exactly the habit this area is testing - knowing the difference between what a result shows and what people want it to mean.