Release notes and what's new in each version of MDE Toolkit.
The headline is supply chain: release artifacts are now digitally signed, so you can verify what you downloaded before you deploy it to a fleet. Alongside that, a Smart App Control reporting bug is fixed that had been wrong in the dangerous direction, EDR onboarding moves onto the Overview page, and the application icon changes.
Every release artifact is signed with Azure Artifact Signing and RFC‑3161 timestamped. Until now the toolkit shipped as an unsigned MSI — an installer that requests elevation and reads your Defender configuration, with no way for you to confirm it was the file that left the build.
Timestamping matters more than usual here. Azure Artifact Signing issues short‑lived certificates by design; the RFC‑3161 countersignature is what keeps the signature valid after that certificate expires, rather than the download turning untrusted a few days later.
Verify before you deploy:
Get-AuthenticodeSignature .\MDE-Toolkit-3.4.0.msi |
Format-List Status, SignerCertificate, TimeStamperCertificateStatus should read Valid. A signed package also means SmartScreen has something to build reputation against, and that you can write WDAC or AppLocker publisher rules for the toolkit instead of hash rules that break on every update.
Two independent defects, both fixed. The second is the one worth reading.
MSFT_MpComputerStatus.SmartAppControlState is a string (On / Off / Eval), despite the name. The code ran it through int.TryParse, which always failed, so the assignment never executed and Smart App Control was silently left unset on the WMI path. The background collector read the same property correctly as a string, so a single machine could report one thing in the fleet table and something else in the interactive UI.VerifiedAndReputablePolicyState uses 1 for enforcement and 2 for evaluation; the toolkit had those the wrong way round. A device in evaluation mode — observing, not blocking — was reported as On, and the Security Score then counted it as fully protected. That is a false sense of safety rather than a cosmetic glitch, and it applied to every code path that fell back to the registry.Both the WMI and registry paths now produce the same normalised values, so the compliance check and the Security Score can no longer disagree about the same device. Thanks to Eric Lawrence for identifying the registry mapping error.
The Intune / Entra Management card gains three rows: EDR Onboarding, Sense Service and MDE Org ID. Previously this required opening a support bundle.
They are deliberately grouped separately from the enrollment rows above them, because MDM management and EDR onboarding are independent. A device can be fully Intune‑enrolled, compliant, and syncing happily while sending Microsoft Defender for Endpoint no telemetry whatsoever. Reading “Enrolled” and concluding “monitored” is exactly the mistake this is meant to prevent.
OnboardingState stays at 1 even when the Sense service is stopped or disabled, so that row on its own would read Onboarded on a machine reporting nothing. A warning badge calls out the onboarded‑but‑not‑running case explicitly.Running (Disabled) will not survive the next reboot; Stopped (Automatic) is not reporting right now. Either value on its own hides a real failure.Works against remote targets on the same terms as the rest of the Overview page.
The previous icon was Microsoft Defender’s own product icon. MDE Toolkit is an independent open‑source project and is not a Microsoft product, so shipping Microsoft’s product iconography was not appropriate regardless of how recognisable it was.
The replacement is a telemetry trace. The choice is deliberate: a shield claims protection, and the toolkit does not protect anything — it measures, reports, and tells you what to fix. The icon is supplied at every size from 16 to 256 pixels, each rendered natively rather than scaled down, so it stays legible in the taskbar.
Microsoft.Identity.Client, Azure.Identity).MDE-Toolkit-3.4.0.msiHKLM\SOFTWARE\MDE-Toolkit\Version = 3.4.0msiexec /i MDE-Toolkit-3.4.0.msi /qnGet-AuthenticodeSignature on the downloaded MSI and confirm Status is Valid and a timestamp is present. This is worth doing on the first signed release specifically, because it is the release that establishes what a genuine artifact looks like.
A sign-in correctness release. The MDE Toolkit Upload scheduled task could open a Microsoft Edge window and ask an unattended machine to authenticate. The failure was counterintuitive enough to be worth writing down: the machines that prompted were the ones joined to the tenant that owns the Function App, and the machines that stayed silent were the ones joined somewhere else entirely.
The uploader authenticated with DefaultAzureCredential. That credential knows nothing about Entra device join and cannot use the machine’s primary refresh token — it simply walks a fixed chain of providers and returns the first token it gets. The chain ends at an interactive browser.
az login, Connect-AzAccount, or signed in to Visual Studio, the chain found a cached developer token early and returned it silently. No prompt — but also no guarantee the token was for the right tenant, or the right identity.So device join was not just unhelpful here, it was invisible to the credential. The quieter machine was the misconfigured one.
Scheduled uploads acquire tokens through the Windows broker (WAM), which is the only provider that can redeem the machine’s Entra PRT. On a joined or registered device this is silent and uses the correct identity. The interactive browser is now excluded outright from every code path the background collector uses, and automatic authentication is disabled on the broker itself, so a machine that cannot sign in silently fails and logs a reason instead of rendering a window nobody will ever see.
The previous PreferredAuthMethod = WAM setting never actually used WAM — it constructed a plain interactive browser credential with no broker attached, so it could not do silent SSO either. It now does what its name says.
The fallback path is still available for machines that genuinely rely on a signed-in Azure CLI or Azure PowerShell session, but it is now pinned to the configured TenantId, so a stale sign-in to an unrelated tenant can no longer quietly become the upload identity.
AuthClientIdBroker sign-in needs a client application to request the token as. In most deployments the toolkit can work this out on its own, so no configuration change is required to upgrade. It tries, in order:
AuthClientId, if you set it. An explicitly named registration is used on its own — falling back to a different one would hide a typo and mint tokens under an identity you did not choose.FunctionAppAudience. Where a single registration both exposes the API and acts as the public client — the usual Function App setup — this is already authorized for its own scope and simply works.Set AuthClientId (REG_SZ, under HKLM\SOFTWARE\Policies\MDE-Toolkit) when your client and API are separate registrations, or to pin the choice and skip the probe. Whichever registration ends up being used needs public client flows enabled, redirect URI ms-appx-web://microsoft.aad.brokerplugin/<client-id>, and access to the scope named in FunctionAppAudience. When the probe succeeds on a fallback candidate, the log names the client ID that worked so you can pin it.
Recommended for production: set it explicitly. Optional is not the same as advisable — if the probe lands on the built-in Azure CLI client, your Function App is being accessed through Microsoft's app registration. That works, but it means anyone with the Azure CLI installed can request tokens for your API, and Conditional Access cannot be scoped to an application you control. Note that a registration used for blob upload also needs a delegated user_impersonation permission on Azure Storage; the Azure CLI client has that by default, a fresh registration of your own does not.
--auth-loginA device that is not Entra joined to the tenant that owns the Function App has no primary refresh token for it, so the broker cannot sign in silently there no matter how AuthClientId is set. Until now such machines worked only because a leftover az login session was quietly supplying every token — an unchosen dependency on a developer tool that would break the moment it expired.
Run once, as the user the upload task runs as:
"C:\Program Files\MDE-Toolkit\MDE Monitoring App.exe" --auth-loginThis prompts once, acquires consent for every configured upload target, and saves an authentication record to %LOCALAPPDATA%\MDE-Toolkit\auth-record.json. Scheduled uploads then refresh that account silently. It is the only mode in the toolkit that will ever display a sign-in window. Devices joined to the correct tenant do not need it.
MDE-Toolkit-3.3.4.msiHKLM\SOFTWARE\MDE-Toolkit\Version = 3.3.4msiexec /i MDE-Toolkit-3.3.4.msi /qnAuthClientId is recommended for production.Azure.Identity.Broker, which ships the native msalruntime binaries alongside the application. They are included in the MSI automatically.MDE Toolkit Collect task is unchanged. It runs as SYSTEM, which has no interactive Windows account and therefore no PRT, so it continues to use managed identity or Azure CLI and never involved the broker.service.log in the cache folder (default C:\ProgramData\MDE-Toolkit\cache\service.log). A silent-auth failure now names the account Windows is signed in as, the tenant a token was requested for, and the client IDs tried, rather than dumping the raw credential chain. If the signed-in account belongs to a different tenant than the Function App, that is the cause — run --auth-login once on that machine.
A telemetry honesty release. Building the fleet dashboards surfaced four fields that the enterprise collector had been reporting without ever measuring. Each was uploaded at its default value on every device, so a report reading them saw false or 0 and had no way to tell that apart from a real result — which is worse than not collecting them at all.
ExploitProtectionDepEnabled, ExploitProtectionAslrEnabled and ExploitProtectionCfgEnabled were declared on the snapshot model, never assigned anywhere, and uploaded as false. A fleet dashboard therefore reported “0% enabled” for all three across every device. They are now read from the packed MitigationOptions value under Session Manager\Kernel, decoding the per-mitigation nibble (1 = forced on, 2 = forced off, 0 = OS default). An unset nibble is reported as enabled on 64-bit Windows, because that is the platform default; if the value cannot be read at all, ExploitProtectionStatus becomes Unknown rather than leaving false to masquerade as a measurement.LocalAdminCount was never assigned and so was always 0 — impossible, since every Windows install has at least the built-in Administrator. It is now counted with NetLocalGroupGetMembers resolved through the well-known SID S-1-5-32-544, so it does not depend on the display language of the OS. Win32_GroupUser was deliberately not used: it can take tens of seconds on a domain-joined machine, and this collector runs unattended on a schedule. LocalAdminStatus now reflects the actual count rather than only whether LAPS is present.AppControlEnforcementMode was not even declared as a property, so the column was permanently empty. It now reports Enforced, Audit, Deployed or NotConfigured. Deployed is the state worth knowing about: .cip policies are present on disk but Code Integrity is not running them, so they are protecting nothing while looking, in any summary that only asks “is App Control configured”, entirely healthy.Quick and full scan times are derived from Defender’s scan age in days, and the code only recorded a timestamp when that age was greater than zero. A scan that ran today has an age of exactly zero, so the machines that had just scanned — the ones in the best shape — uploaded no scan time at all and were indistinguishable from machines that had never scanned. The test is now >= 0.
MDE-Toolkit-3.3.3.msiHKLM\SOFTWARE\MDE-Toolkit\Version = 3.3.3msiexec /i MDE-Toolkit-3.3.3.msi /qnServiceVersion to see how far the rollout has reached, and consider deleting pre-3.3.3 rows if the false zeros would skew a fleet percentage.
A policy-surface cleanup. An audit of every value under HKLM\SOFTWARE\Policies\MDE-Toolkit found nine settings that were read into the configuration object and then never used, so setting them did nothing at all. Two were worth building; seven were removed.
DisableRemoteTarget now pins the toolkit to the local machine. Enforcement sits in the TargetMachine setter rather than on the text box, because that setter is the single choke point every remote-capable service reads from — roughly thirty services branch on it. A non-local value is rejected and coerced back to localhost, so no remote path is reachable even if a future caller sets the target in code. The Target box is also disabled, with a tooltip naming the policy.DisableExportButtons now blocks every export path: report PDF/HTML, triage report, scan results, ASR event CSV, Advanced Hunting CSV and XML, supplemental and merged App Control policies, WDAC XML, firewall migration JSON, and investigation details CSV. Blocked attempts show a dialog naming the policy, so the button does not simply appear broken.Both were documented on this site and in the in-app KB while doing nothing — the same failure mode as ForceReadOnlyMode in 3.3.1. An administrator who set DisableRemoteTarget=1 reasonably believed remote access was off.
CollectFirewallRules, CollectWfpFilters, CollectDeviceControl, CollectNetworkInfo, CollectSecurityScore, DisableAiFeatures and DisableAdvancedNetworking are no longer read, no longer seeded by the installer, and are ignored if present. The five Collect* flags promised scope control over data the background collector never gathered. The two Disable* flags duplicated VisibilityAiAnalysisPage and VisibilityNetworkingPage, which are enforced — use those instead.
The six remaining Collect* flags — DefenderStatus, DefenderPolicies, FirewallStatus, AppControl, IntuneEnrollment and DeviceGuard — are genuinely honoured by the collector and are unchanged.
MDE-Toolkit-3.3.2.msiHKLM\SOFTWARE\MDE-Toolkit\Version = 3.3.2msiexec /i MDE-Toolkit-3.3.2.msi /qnreg delete "HKLM\SOFTWARE\Policies\MDE-Toolkit" /v CollectFirewallRules /f (and likewise for the other six).DisableExportButtons=1 or DisableRemoteTarget=1 expecting them to work, they will now take effect for the first time. If you set them speculatively and still want export or remote targeting, set them back to 0 before rolling out 3.3.2.
Visibility*Page value.
Attack Surface Reduction release. The ASR page becomes a two-page workspace — an overview that finally tells you what mode every rule is in and where that configuration came from, and a new Events page for investigating blocks and tuning them. Admins can create audited, expiring exclusions directly from an event.
The overview used to read rule state from a single registry key, which meant it could not see rules configured locally. Two consequences, both fixed:
Policy Manager\ASRRules (Intune/MDM), the classic Windows Defender Exploit Guard\ASR\Rules GPO key, and Get-MpPreference. On a typical managed device this recovers rules that were previously invisible.1 specifically means Block; labelling it "Enabled" was ambiguous sitting next to Audit and Warn in the same column. Action 5 ("not configured") is now decoded too.Source column — Intune / GPO, Group Policy, Local, or blank. Locally-set rules are highlighted, because they are real configuration that will not survive a rebuild and is not enforced fleet-wide.GUID column on the main grid, plus the GUID, a plain-English explanation of the source, and any per-rule exclusions in the expandable row details.Mode = Not configured.1125 and 1126 joined the existing 1121/1122/1129. Event 1126 means the user was warned and ran the content anyway — the rule fired and was defeated — which the overview card never surfaced.Add-MpPreference command and the command that will reverse it before anything is written.AttackSurfaceReductionRules_RuleSpecificExclusions) rather than the blunt all-rules form, with warnings for overly broad paths and wildcards.\MDE Toolkit\ASR Exclusion Sweep scheduled task — so they still expire when the app is closed.%ProgramData%\MDE-Toolkit\asr-exclusions.json recording who, when, why, the exact commands, and expiry. Defender records none of this itself. The directory is ACL'd to SYSTEM and Administrators.Remove-MpPreference is not proof — under Tamper Protection Defender can ignore the change silently. The result is re-checked against Get-MpPreference and reported honestly if it did not stick.Remove-MpPreference matches the ASR rule ID case-sensitively — given the wrong case it exits 0, logs nothing, and removes nothing. The expiry sweep normalised the GUID to lowercase, so every temporary exclusion silently outlived its expiry. Defender keeps whatever case was originally written, so the toolkit now reads the stored ID back and echoes its exact casing. A failed revert is also retried on the next sweep instead of being stranded permanently.Get-MpPreference returns rule-specific exclusions |-separated while the registry uses >; only the latter was handled, so a rule with ten excluded paths counted as one.UCEERR_RENDERTHREADFAILURE) terminated the process mid-investigation. These are now absorbed and logged to %LOCALAPPDATA%\MDE-Toolkit\diagnostics.log, falling back to software rendering only after repeated failures. Other exceptions are logged but deliberately not suppressed.NullReferenceException in ListCollectionView.PrepareLocalArray) when loading ASR data.New optional policy values under HKLM\SOFTWARE\Policies\MDE-Toolkit restrict what admins may create. A device with none of them set behaves exactly as before.
AsrAllowPermanentExclusions (DWORD, default 1) — 0 forces every exclusion to expire.AsrAllowTemporaryExclusions (DWORD, default 1) — set both flags to 0 to disable exclusion creation entirely.AsrExclusionMaxHours (DWORD, default 0 = uncapped) — hard cap, applied last so it cannot be widened by the list below.AsrExclusionDurationsHours (SZ, default 4,24,168,720) — custom duration menu; unparseable entries are ignored and reported rather than silently dropped.ForceReadOnlyMode was previously documented but never enforced. It now blocks every exclusion write, creation and removal alike.Enforcement happens in the apply path, not just the dropdown, so the policy is not merely cosmetic. Temporary-only with a four-hour cap is two values: AsrAllowPermanentExclusions=0 and AsrExclusionMaxHours=4.
MDE-Toolkit-3.3.1.msiHKLM\SOFTWARE\MDE-Toolkit\Version = 3.3.1msiexec /i MDE-Toolkit-3.3.1.msi /qnVisibilityAsrEventsPage (0 hidden / 1 admin / 2 users / 3 both). Defaults to 1, matching VisibilityAsrDashboardPage. Setting it to 3 gives standard users read-only event triage — the exclusion actions stay hidden regardless, as they are gated on elevation independently.HKLM\SOFTWARE\Policies\MDE-Toolkit at its built-in default, so knobs are visible in regedit and can be edited rather than created. Existing values are never overwritten, and because each seeded value equals the code default, a fresh install behaves identically to a device with no policy key. Values with no meaningful default, and the per-page Visibility*Page values, are deliberately left unseeded.\MDE Toolkit\ASR Exclusion Sweep task is registered at runtime on first use of a temporary exclusion, so uninstall removes it explicitly along with its script. Still-active temporary exclusions are reverted first — a temporary exclusion outliving the tool that promised to expire it would be a silent security hole. Permanent exclusions are left alone and the ledger is preserved as an audit record.Visibility*Page policy values are unaffected.
Enterprise telemetry + in-app guide release. Fixes the fields that were empty or wrong in the Azure Table row, adds richer columns for Power BI, and turns the Knowledge Base into a full offline guide for both MDE and the toolkit itself. No breaking changes — drop-in over 3.2.0.
The following columns used to arrive empty, Unknown, or wrong in the storage table. All now populate with real values on every uploaded snapshot:
AntivirusEngineVersion, SignatureVersion, PlatformVersion, ServiceVersion. CIM is preferred; registry (Windows Defender\Signature Updates\AVSignatureVersion) + filesystem (ProgramData\Microsoft\Windows Defender\Platform\*, MpEngine.dll FileVersion) act as fallbacks when CIM returns blank under SYSTEM.LastQuickScanUtc, LastFullScanUtc. Derived from the CIM age (days) fields, with the Windows Defender\Scan registry as backup.LastBootTimeUtc (from Environment.TickCount64) and IpAddress (first non-loopback IPv4 from NetworkInterface).MdeOrgId from HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status\OrgId.PowerShellExecutionPolicy (machine policy → per-shell → default) and a smarter PowerShellStatus that considers execution policy, CLM, and script-block logging.SmartScreenExplorerMode now carries the raw Explorer value (RequireAdmin / Warn / Off).TpmVersion now falls back to Win32_Tpm (CIM) when the registry key is missing.AppControlStatus used to say NotConfigured on machines with 28 audit-mode .cip policies deployed. Now:
C:\Windows\System32\CodeIntegrity\CIPolicies\Active\*.cip and reports the real count in AppControlPolicyCount.Enforced / Audit / Configured (N policies, not enforced) / NotConfigured.DeviceControlStatus, ControlledFolderAccessStatus, and ExploitProtectionStatus — they now report Disabled / NotConfigured instead of falling through to Unknown.The DeviceTag, OrgUnit, and Environment values from HKLM\SOFTWARE\Policies\MDE-Toolkit were already inside every uploaded JSON but the Function App wasn't writing them as table columns. The ingestion function now promotes all three to top-level, sliceable columns — Power BI slicers on DeviceTag / OrgUnit / Environment start returning values on newly upserted rows.
FunctionApp/HealthReportIngestion/run.ps1 now maps every new field above to a typed Table Storage column.DeviceTag, OrgUnit, Environment, PlatformVersion, AntivirusEngineVersion, SignatureVersion, MdeOrgId, LastQuickScanUtc, LastFullScanUtc, LastBootTimeUtc, IpAddress, AppControlPolicyCount, AppControlEnforcementMode, PowerShellExecutionPolicy, SmartScreenExplorerMode.ReportJson slim logic — existing deployments upgrade cleanly.The Knowledge Base page (left-nav → book icon) has been refreshed to serve as the primary in-app guide for both learning MDE and learning the toolkit. Everything is available offline — no external calls required.
<Option> in the WDAC schema with description, recommendation level (Recommended / Conditional / NotRecommended / Required), a worked example, and the exact Set-RuleOption / -Delete PowerShell to apply or remove it.Doubles as the tool's own How to use MDE Toolkit guide. Each Components article calls out which pages in the toolkit surface that pillar and what a "healthy" result looks like — for example, the ASR component explains which cards on the Defender Policies and Advanced Hunting pages to check. New operators can open the KB, read a component article, and immediately know which page to open in the app.
AuthorityHostOverride, CollectWfpFilters, CollectNetworkInfo, DisableAdvancedNetworking, and an entire new Logging section (LogLevel, LogFilePath, MaxLogSizeMb). Added a New Table Columns reference table.run.ps1 sample matches the tested production script; the Data Destination Reference now lists all ~100 columns grouped by category.js/copy-code.js; no per-page markup changes required.MDE-Toolkit-3.2.1.msiHKLM\SOFTWARE\MDE-Toolkit\Version = 3.2.1msiexec /i MDE-Toolkit-3.2.1.msi /qnrun.ps1 to pick up the new columns. Azure Table Storage is schemaless per row — existing rows keep their original columns; newly upserted rows carry the new fields.App Control Deep-Dive: six new workflow features and a completely rebuilt ticket-attachment export pipeline. This is the biggest App Control release since 3.1.0.
.cip is actually signed.*.json snapshot next to the report(s) — useful when Tier III wants to re-analyze the collection.%LocalAppData%\MDE-Monitoring-App\export-prefs.json).Single self-contained .html file — no frameworks, no external assets, no CDN references. Same "attach it to a ticket, no assets folder" story as the PDF.
scroll-margin-top so anchors don't land under the sticky nav).<details> — WDAC policies collapse by default so a 20-policy machine still opens on one screen.prefers-color-scheme.The Triage Report's HTML output now uses the same visual language as the Export Report — dark-mode, sticky TOC, verdict banner, collapsible sections, sortable tables, in-page search. The Save-File dialog now defaults to HTML with Markdown as the second option. Markdown output is unchanged for pasting into ticket bodies (still renders natively in ServiceNow, Azure DevOps, GitHub, Confluence).
The silent-mode App.xaml.cs handlers are now rewired through the same ExportReportAsync pipeline the GUI uses. Everything the dialog offers is exposed as a flag:
--export-html <file> — HTML mirror of --export-pdf.--format <pdf|html|both> — explicit format selection.--include-json — also emit the raw *.json snapshot.--redact <list> — comma list: none / all / machine / upn / ip / serial.--include-sections <list> — comma list of section names, or all / default / none.Backwards compatible: --export-pdf alone still produces exactly one PDF at the given path. Batch mode (--machines-file / --export-dir) now honours every new flag; per-host filenames get the appropriate extensions when --format both is used.
scroll-margin-top.PolicyObject.Rules for OptionType.EnabledAuditMode.MinHeight / MinWidth plus a bounded picker..cip policies.MDE-Toolkit-3.2.0.msiHKLM\SOFTWARE\MDE-Toolkit\Version = 3.2.0msiexec /i MDE-Toolkit-3.2.0.msi /qn--collect / --upload tasks are unchanged. New export flags are additive.MainViewModel.ExportPdfAsync remains available for existing automation. New code should prefer ExportReportAsync.Focus release: the policies the Advanced Hunting page exports now actually compile and enforce. A pile of rule-quality, accuracy, and usability fixes built on top of 3.1.1.
ConvertFrom-CIPolicy for you and drops the binary .cip file next to the .xml. No more switching to PowerShell.SigningScenarios wiring that tells WDAC which rules apply to user-mode binaries vs kernel drivers, so the policy compiled but did nothing. Now every Allow / Deny / Signer is correctly wired into the right scenario (UMCI for .exe / .dll, KMCI for .sys).ConvertFrom-CIPolicy with "There is an error in XML document" or "the signer ID is incorrect". The recommender walks the next fallback level instead.<Allow> elements without any matching constraint.MDE-Toolkit-3.1.2.msiHKLM\SOFTWARE\MDE-Toolkit\Version = 3.1.2msiexec /i MDE-Toolkit-3.1.2.msi /qnConfigCI module (built into Windows 11) or RSAT-WDAC (Windows Server). If neither is installed the toggle stays available but the export reports a clear "module not available" message and leaves the .xml for manual compilation.New App Control for Business → Advanced Hunting sub-page that pulls live WDAC events from Microsoft Defender for Endpoint, compares them against your local or custom App Control policies, and recommends the right allow rules to author — with the same -Level / -Fallback precedence semantics as PowerShell New-CIPolicy.
DeviceTvmInfoGathering, audit / enforced blocks, signing-info, script blocks) from the Microsoft Defender for Endpoint Advanced Hunting API. All four sovereign clouds are supported out of the box: Commercial, US Gov GCC, US Gov GCC High, and US Gov DoD — the right endpoint and authority host are picked automatically.Consolas so they line up.ActionType filter via regex so your custom WHERE clauses survive. Save / load .kql files to share queries with the team..cip in C:\Windows\System32\CodeIntegrity\CIPolicies\Active plus SiPolicy.p7b in one click, or browse to a folder of .cip / .p7b / .xml policies (recursive optional). Each event is evaluated as Allowed, Denied (explicit), or Would Still Block across every selected policy. Explicit Deny wins over Allow anywhere in the set, matching how WDAC merges policies at runtime.-Level / -Fallback)Hash, FileName, FilePath, SignedVersion, Publisher, FilePublisher, LeafCertificate, PcaCertificate, RootCertificate, WHQL, WHQLPublisher, WHQLFilePublisher, and PFN.-Level and the rest become -Fallback in order. A live Consolas-styled preview shows the resulting PowerShell-equivalent command. Order is persisted to %LOCALAPPDATA%\MDE-Toolkit\advanced-hunting-prefs.json.New-CIPolicy. Defaults to Microsoft’s recommended FilePublisher → Publisher → SignedVersion → FileName → Hash → FilePath on first launch.<Allow> per algorithm (SHA256, SHA1, and their Authenticode variants). App Control evaluates the strongest hash first and ignores any algorithm the running kernel can’t compute, so emitting every variant maximises match rate — exactly what PowerShell New-CIPolicy -Level Hash produces.<!-- WARNING --> comment instead of an empty Hash="".%LOCALAPPDATA% is no longer flagged — Hash pins exact bytes regardless of where the file lives. The RISK badge now only appears for FilePath rules in user-writable folders, FileAttribute / FileName rules for unsigned files in user-writable folders, or anything kernel-mode (.sys)..xml exporter now emits one short section header per rule type (Publisher / FileAttribute / FilePath / Hash) instead of repeating each fragment’s own multi-line comment dozens of times. Files exported with lots of Hash recommendations are dramatically smaller while still being valid input for ConvertFrom-CIPolicy.AdvancedHuntingService built on Microsoft.Identity.Client 4.76.0 (interactive auth, FOCI client ID, per-cloud authority + resource URIs, legacy WDATP endpoint fallback).AppControlPolicyComparerService uses Microsoft.Security.CodeIntegrity 3.1.1 to parse .cip / .p7b / .xml policies; sanitises unknown <Option> values so newer Wizard-generated policies load cleanly.MDE-Toolkit-3.1.1.msiHKLM\SOFTWARE\MDE-Toolkit\Version = 3.1.1msiexec /i MDE-Toolkit-3.1.1.msi /qn%LOCALAPPDATA%\MDE-Toolkit\advanced-hunting-prefs.json stores the chosen cloud, tenant, KQL window, custom policy folder, and the rule-precedence order.Focused on scrolling quality of life across every page and grid in the app.
gpupdate /force button now uses a "document with text" icon for better visual clarity.MDE-Toolkit-3.1.0.msiHKLM\SOFTWARE\MDE-Toolkit\Version = 3.1.0msiexec /i MDE-Toolkit-3.1.0.msi /qnFull release notes and downloads for older versions live on the GitHub releases page.