Highwind 3.5.0

Highwind 3.5.0

Previously released as MDE Toolkit. Same project, same maintainer, same licence.
The old name described a Microsoft product rather than this tool, and the tool is not a Microsoft product - it is an independent project that reads Microsoft's telemetry and tells you what it says.

Upgrading from 3.4.0

Your existing configuration is migrated on upgrade. The installer copies every value from HKLM\SOFTWARE\Policies\MDE-Toolkit to HKLM\SOFTWARE\Policies\Highwind before it seeds any defaults, and it never overwrites a value that is already set. GPO and Intune settings survive an in-place upgrade with no action required.
• The application also falls back at read time. Any setting missing from the Highwind key is read from the old key instead. That covers the portable ZIP, which never runs an installer and so never gets the migration.
• Per-user files are carried across on first launch. Cached sign-in records, export and Advanced Hunting preferences and the AI user secret are copied from the old per-user folders into the new ones. This is done by the application rather than the installer because those files are DPAPI-protected under each user, and the installer runs as SYSTEM. Earlier builds were not consistent about the folder name - several were in use at once - so every one of them is checked.
• Machine data moves too. The ASR exclusion ledger, the collector cache and stored reports are copied from %ProgramData%\MDE-Toolkit into %ProgramData%\Highwind. Without this the Exclusions tab would come up empty on an upgraded machine while the permanent exclusions it created were still live in Defender - the tool would no longer know it owned them, and the record of who excluded what would be stranded in a folder nothing reads.
• The expiry sweep changes hands cleanly. The upgrade retires the old \MDE Toolkit\ASR Exclusion Sweep task before handing the ledger over, because two SYSTEM sweeps reverting the same rule and path from two copies of the ledger is exactly the overlapping-exclusion corruption fixed in 3.3.2. Any temporary exclusion still running is then re-adopted at startup, so nothing outlives its expiry during the handover.
• Nothing is deleted. The old policy key is left exactly where it is. If you need to roll back to 3.4.0, its configuration is still there and still authoritative for that build.
The reason this is handled so carefully is that the failure mode is invisible. A renamed policy key that nothing reads does not produce an error - the application starts, the UI looks healthy, and the fleet quietly runs with no upload endpoint, no tenant and default guardrails. That is worse than a crash, because nobody investigates it.

Highwind AI

Ask a question about a machine in plain English and get an answer, instead of reading six pages of settings and working out for yourself which of them matter. "Is this machine protected?", "why is Defender not updating?", "what changed last week?" - Highwind reads the machine, works out which parts of it are relevant to what you asked, and explains what it found and what to do about it.
Two things make the answers worth trusting. Every fact comes from the machine itself and is shown with its source, so you can check it rather than take it on faith. And where Highwind cannot read something, it says so - it will not fill a gap with a confident guess, because a wrong answer that looks right is worse than no answer at all.

It remembers what your settings used to be

The biggest addition in this release, and the one with no equivalent elsewhere. Highwind now takes a quiet snapshot of the machine's security configuration every few hours and keeps a rolling 30 days of history. That turns a question nobody could previously answer into an ordinary one:
"What has changed on this machine in the last 30 days?"
• You get told what moved, when, and whether it left you worse off. "Controlled folder access was switched off on 9 September" - with a plain statement that this left the machine less protected than it was.
• It covers settings that Windows never records. Defender logs some of its own configuration changes, but the firewall profiles, App Control, Device Guard, BitLocker, Remote Desktop and the PowerShell policy emit nothing at all. Comparing snapshots catches all of them, and it does not depend on an event log that may have already wrapped.
• It does not matter who was signed in. Snapshots are taken by the system itself, so a change made overnight, or by someone else, or by a policy push, is captured the same way.
• Ask about any period. The last 24 hours, the last five days, the past two weeks - the question is answered over the period you actually asked about. If Highwind has less history than that, it tells you, rather than letting a short record look like a quiet one.

And it explains the setting, not just the change

Being told a value moved is only half an answer. Each reported change now comes with the part you would otherwise go and look up: what the setting actually does, where it is configured in Intune and in Group Policy, the registry location, what the numbers mean, and the handful of things that realistically cause it to move - most likely first.
Highwind then checks the machine live and tells you whether anything is enforcing that value right now. That is the difference between "go and check Intune or Group Policy" and "nothing is enforcing this here, so look at who has local administrator rights."
Where the change cannot be traced to a specific policy - which is usually, once the logs have rolled - it says so plainly and points at the places evidence may still survive, rather than inventing a culprit.

Research, with its sources shown

For the questions that are about Defender rather than about your machine - what a setting means, why a feature behaves the way it does - Highwind draws on a built-in knowledge base, and, if you allow it, looks things up at Microsoft Learn and other public sources. Answers carry links, so you can read the original. Your organization can turn outside lookups off entirely by policy.

Works on a machine with no internet, and on machines that are not yours

• No AI service required. Highwind AI answers using a local engine, so it works on an isolated machine with nothing configured and nothing outbound. Nothing about your machine is sent anywhere. Connect your own AI endpoint if you want richer wording - the facts come from the machine either way.
• Remote machines get real answers. Point Highwind at another machine and the answers are about that machine - including its settings history. If it cannot be reached, it tells you which machine and why, instead of quietly describing the one you are sitting at.

### Reports you can hand to someone else
Highwind AI can write the whole thing up as a report, and you choose what it should concentrate on: a security review, or a troubleshooting investigation. The same machine, the same evidence, but the emphasis, ordering and recommendations shift to suit the reader - a summary for management is not the same document as a working list for whoever has to fix it.

The typing hang
The original bug report, and the one that started everything else in this release. Every keystroke in the target field triggered a synchronous UNC probe of the typed value. Typing a machine name meant firing a network round trip at every prefix of it, on the UI thread, so the window locked up for as long as the network took to give up on names that were never going to resolve.
The probe is gone from the keystroke path entirely. Reachability is established when you actually target the machine, where waiting for the network is something you asked for.

Remote targeting actually works now
Investigating this exposed something considerably worse than a hang. Credentials were not reaching most of the remote data paths, and the code that needed them fell back to reading the local machine instead of failing.
• Credentials now reach remote registry, UNC, event log and WMI. Previously they were honored on some paths and silently dropped on others, which is why a remote target could half-work and look convincing.
• Timeouts everywhere. Every remote call is now bounded. An unreachable host returns an answer instead of holding the operation open indefinitely.

Silently-local data is gone
This is the headline correctness fix. When a remote collection could not complete, several subsystems fell through to the local machine and presented the result as though it came from the target. A remote assessment could therefore describe the analyst's own workstation while naming somebody else's device at the top of the report.
That is not a cosmetic bug. It produces a confident, specific, well-formatted answer about the wrong computer, and there is nothing in the output to suggest you should not believe it. Every one of the following now reports the target or reports nothing:
• Device Control
• Firewall enrichment
• Support bundle
• ASR rules and exclusions
• Live event tailing
• Endpoint Posture Score
• STIG compliance

Wrong-machine writes are blocked
The mirror image of the previous problem, and the more dangerous half. Several actions could write locally while a remote target was selected - so an operator intending to change a remote device would instead modify their own.
Device Control policy edits, ASR exclusion creation, Quick Actions and support bundle generation are all now refused rather than silently redirected when the write cannot be performed against the selected target.

** Uncertainty is visible**
The through-line of this release: where the tool does not know something, it now says so instead of producing a verdict it cannot support.
• Per-page data-source banners. Every page states which machine its data came from, so "local" and "remote" are never something you have to infer.
• "Not determined" replaces invented verdicts. A check that could not run reads as not determined rather than defaulting to pass or fail. A fabricated pass is a security finding you never see; a fabricated fail wastes a day.
• Per-section collection results. Partial collections report which sections succeeded and which did not, instead of presenting an incomplete picture as a complete one.

CLI / GUI parity and batch reporting
The command line and the interface had drifted apart and could produce different results from the same inputs. They now run the same code path. Batch reporting, previously CLI-only, is available in the GUI on that same shared path - so a report generated either way is the same report.

PsExec
PsExec-based remote provisioning was broken and is repaired. Fetching it is now an explicit, optional, signed download rather than an assumption, and it remains disabled entirely where DisablePsExecDownload is set - a tool Defender flags as HackTool:Win32/PsExec should never arrive on a machine without someone choosing it.

App Control - building a policy from Advanced Hunting
The largest body of work in this release. The goal is narrow and specific: make it realistic for an administrator to go from "App Control is deployed in audit mode" to "here is the policy I am prepared to enforce" - the step most rollouts stall on.
• Fleet Impact with a Group by level. Aggregates events server-side so one row is one thing you would write a rule for, rather than one raw event. Five levels - publisher, publisher + product, file identity, file + location, hash - matching the rule you intend to author. Per-user install paths are normalized to \Users*, so one application stops producing one row per profile.
• Switching view or Group by no longer re-runs the query. Results are regrouped from data already collected. Grouping only runs one way, though: you can always go coarser, but detail discarded server-side cannot be rebuilt - asking for hashes after collecting at publisher prompts a re-run rather than showing something wrong.
• A Decisions workbench. Record Allow / Block / Investigate per application, with owner, rationale and a reference. The ledger can be exported, imported and synced against a file on a share, so several administrators can work the same list. Merges are last-decision-wins and report conflicts rather than hiding them.
• Rule precedence on the main toolbar. It decides the recommended rule on every row, so it now sits beside the results instead of inside the Policies drawer. A badge marks an order that differs from Microsoft's recommended default. See Rule precedence.
• Graduated scrutiny instead of a risk flag. A Microsoft-signed kernel driver is not "risky" simply because it loads in the kernel. Rows are now rated on how much review they warrant, which stops the signal being drowned by things that never needed looking at.
• Duplicate path forms are collapsed. Code Integrity reports the same event twice, once with a \?\ prefix. That is not cosmetic - a FilePath rule containing \?\ is invalid - so the pair is merged and counted once.
• Export reflects what you are looking at. CSV export moved to the main page and now honors the active filters and includes the comparison columns when Compare has run. A companion -context.txt records the query window, filters and policies compared against, so the file can be handed on without explanation.

Very large tenants
Advanced Hunting has a 30-day retention, a complexity limit, a response-size cap and a rate limit. On a six-figure device estate all four bite, and the previous behavior was to quietly return less data rather than say so.
• The 30-day window is collected as shards. A shard that overflows is split repeatedly down to a 30-minute floor, and transient throttling is retried per shard rather than restarting the scan.
• Truncation is now reported, not absorbed. A per-shard row cap could succeed while dropping rows, and the adaptive split only reacted to outright errors. Saturation is now detected and surfaced - which matters, because the dropped rows are the low-reach long tail that is precisely what is still missing from your policy.
• Device counts are never summed across shards. Shard windows are disjoint in time, not in devices, so summing counted one machine running one application daily as thirty machines. Counts are now a union where exact, and a stated lower bound otherwise.

App Control documentation
Numbered walkthroughs in the in-app knowledge base, and a fuller guide at App Control. The guided tour now loads policies before running the query, so results come back already compared.

Renamed: Endpoint Posture Score
The old name sat too close to Microsoft Secure Score, an unrelated Microsoft product. This score is calculated locally by Highwind from local data and has never had any relationship to it. The score, weighting and remediation guidance are unchanged - only the label.