Windows Client (v2) deployment guide

The new ScoutDNS Windows Client is a major architectural change from the original Scout360 device agent. It delivers system-level DNS visibility and enforcement without changing adapter DNS settings, NRPT entries, or customer-managed DNS routing configuration. Adapter DNS, Name Resolution Policy Table (NRPT) entries, GPO-pushed DNS policy, and ZTNA-supplied namespace routing all stay exactly as the customer’s network configured them. The agent intercepts outbound DNS at the kernel layer, applies policy, and returns answers transparently. On top of that, it can block common encrypted-DNS bypass paths (known public DoH endpoints and standard DoT/DoQ traffic patterns), reducing the ability for browsers and applications to route DNS around policy.

This guide covers what’s new, what stays the same, prerequisites, install, and post-install verification. For installations that need to run alongside a ZTNA agent or VPN client (such as SonicWall CSE, Enclave, and similar), see the companion article: VPN and ZTNA compatibility (Windows Client).

[!IMPORTANT] The Windows Client (v2) is in public beta. It is available to all customers and MSPs who want to try it. The v1 Scout360 agent remains the recommended default until V2 reaches general availability. We are actively taking feedback during the beta.

[!NOTE] If you’re still running the original device agent, the Roaming clients (device agents) guide is the right reference. The two clients can coexist in a tenant during rollout, but a single device should run only one.

What’s new in v2

Area	v1 (Scout360)	v2 (Windows Client)
Interception model	Sets device adapter DNS to a loopback address managed by the agent	Windows Filtering Platform (WFP) kernel driver transparently redirects outbound DNS to a local listener. No adapter DNS changes. No NRPT changes.
Existing DNS routing	Adapter changes occasionally interfered with GPO, DirectAccess, or ZTNA-supplied DNS routing	Customer’s existing DNS routing is preserved: DHCP-assigned servers, GPO NRPT, DirectAccess, and ZTNA namespace rules all continue to work
Encrypted DNS bypass control	Could not stop browser DoH or app-level DoT/DoQ	Blocks known public DoH provider IPs (TCP/443) and standard DoT (TCP/853) and DoQ (UDP/853) ports
VPN / ZTNA compatibility	Could compete with VPN or ZTNA tools that managed adapter DNS	Operates below the adapter and NRPT layers; sits alongside modern VPN and ZTNA stacks without competing for ownership
Service language	Mixed	Rust-based system service for memory safety and long-running stability
Visibility scope	Apps using the system resolver	Plaintext UDP/53 is redirected through ScoutDNS; TCP/53 fallback is blocked fail-closed; known public encrypted DNS endpoints and standard DoT/DoQ ports are blocked

What stays the same

The operational surface is intentionally familiar:

• Control Plane management. Profiles, policies, install keys, sites, networks, personas, and reporting all behave the way they did with the v1 agent.
• Profile-based local forwarding. Same Local Forwarders tab, same Auto vs. specific-IP behavior. See the v1 guide’s local forwarding section.
• Silent install. No prompts, no tray icons.
• Remote Disable / Forget / Uninstall. One-click remote actions from Client Details.
• Fail-open by default. If ScoutDNS can’t be reached, DNS continues to work through the device’s normal resolution path.
• Auto-update. A separate updater service manages versions with rollback.
• Reporting. Per-device and per-user logs become available after install.

How it works (in brief)

The v2 client uses a Microsoft-attested Windows Filtering Platform (WFP) kernel driver paired with a Rust system service. For normal Windows resolver traffic, the flow is:

1. The application uses the Windows DNS Client as normal.
2. Windows applies its existing DNS configuration, including adapter DNS, NRPT, DirectAccess, VPN, or ZTNA-supplied rules. ScoutDNS does not modify those settings.
3. For plaintext UDP/53, the ScoutDNS WFP driver redirects the outbound DNS packet to the local ScoutDNS service.
4. The service classifies the query, applies policy, and either resolves it through ScoutDNS encrypted DNS or, when a matching Local Forwarder is configured, sends it to the intended local, domain-controller, VPN, or ZTNA-provided resolver.
5. TCP/53 fallback is blocked fail-closed so truncated DNS retries cannot bypass policy.

Two practical consequences for deployments:

• Existing DNS routing is preserved when configured. When the corresponding Local Forwarder is configured, corporate namespaces continue to resolve through the intended local, domain-controller, VPN, or ZTNA-provided resolver path.
• No registry or adapter mutation. Running Get-DnsClientNrptRule or Get-NetIPConfiguration before and after install will show the same output.

Prerequisites

• OS: Windows 10 (x64) or Windows 11 (x64). ARM64 is not yet supported.
• Admin rights on the target device for the MSI install.
• Outbound TCP/443 to the ScoutDNS resolver network (the agent communicates over DoH).
• Profile created in the Control Plane with policies and local forwarding configured.
• For AD-joined devices: the internal AD suffix (for example, corp.example.com) added to the profile’s Local Forwarders, pointing at the corporate DNS servers. This keeps domain controller lookups working correctly.

Step 1: Configure a profile

Profile configuration is identical to v1. If you have not created one yet, follow Step 1 in the Roaming clients guide to set:

• Default policy
• Block page template
• Dynamic policy (different policy on-network vs. roaming)
• Local Forwarders for any internal-only DNS namespaces

[!IMPORTANT] If the device joins an Active Directory domain, the AD-integrated suffix must be in Local Forwarders before you install the agent. Devices without forwarders for their corp suffix will see “site can’t be reached” on internal hostnames.

Step 2: Generate an install key

From the profile, open the Install tab and click New Key. Configure:

Option	Value
Platform	Windows (V2 - beta)
Architecture	x64
Duration	How long the key is valid for new registrations
Installs	Maximum number of devices this key can register

Save the key, then click into it to open the Script Installer panel. The panel shows three values for that specific profile + key combination:

• URL: the MSI download location, https://download.scoutdns.com/assets/device_agent/installers/scoutdns-client-win-x64.msi
• Key: a unique value generated for this key, used as the INSTALLKEY MSI property at install time.
• Install Command: the full msiexec invocation with the unique key already substituted in. Copy this verbatim.

[!IMPORTANT] The install key is no longer embedded in the MSI. The MSI is a single shared download; the key is passed at install time as the INSTALLKEY MSI property. Each profile + key combination generates a unique value, so an install command from one profile cannot be reused for another.

[!NOTE] Already-installed agents are not affected by deleting or rotating a key. Keys are only consumed during the initial registration handshake.

Step 3: Deploy the MSI

The Windows Client MSI is silent by default. The install command from the Script Installer panel takes the form:

msiexec.exe /i scoutdns-client-win-x64.msi /qn INSTALLKEY=<unique-key-from-panel>

Copy the command verbatim from the panel. The unique INSTALLKEY is already substituted in.

Group Policy / Intune / MDM / RMM

Because the install requires a per-key INSTALLKEY property, deploy through a mechanism that lets you supply the full install command:

• Microsoft Intune: package as a Win32 app and paste the Install Command from the panel.
• GPO startup script or RMM: run a script that fetches the MSI from the URL and executes the install command.
• Other MDM: wherever a custom install command can be specified, use the value from the panel.

Plain “assign the MSI” software-distribution paths (for example, legacy GPO software installation without an MST transform) will not work, because they cannot pass the INSTALLKEY property at install time.

Manual install

Download the MSI from https://download.scoutdns.com/assets/device_agent/installers/scoutdns-client-win-x64.msi and run the install command from the panel on the target device:

msiexec.exe /i scoutdns-client-win-x64.msi /qn INSTALLKEY=<unique-key-from-panel>

Install as a local administrator so standard users cannot stop or remove the service.

[!WARNING] Installing with an expired or exhausted key will still place the agent on disk, but it will not register. The device will continue to use whatever DNS resolution path it had before until the key is reactivated or replaced. To confirm registration, check Manage Clients in the Control Plane after install.

What gets installed

• ScoutDNS Windows Client service (ScoutDNSService), runs as LocalSystem. Handles DNS proxying, policy decisions, and Control Plane communication.
• ScoutDNS Updater service, separate service that manages version updates and watchdogs the main service.
• ScoutDNS kernel callout driver, Microsoft-attested WFP driver that intercepts DNS traffic and enforces blocking of unauthorized encrypted DNS.

Active Directory and domain controllers

Because the agent does not modify adapter DNS or NRPT, the Windows-side DNS configuration (DHCP-supplied DNS, GPO NRPT, AD-managed namespaces) stays as configured. With a matching Local Forwarder, domain controller lookups and Group Policy fetches resolve through the corp path.

There is one configuration item to set:

1. Add the internal AD suffix (for example, corp.example.com) to the profile’s Local Forwarders.
2. Point it at the corporate DNS servers that host the AD-integrated zone (this is usually the domain controllers themselves).
3. Keep the forwarder list complete. Any internal-only namespace the customer expects to resolve must be in the list. Without a matching Local Forwarder, an internal name would be sent to the cloud resolver and return NXDOMAIN.

[!TIP] When matching Local Forwarders are configured, GPO NRPT entries, DirectAccess rules, and ZTNA-supplied namespaces resolve through their intended local path. Boot-time DC lookups happen before the agent is fully armed and use the OS’s normal path unaffected.

Blocking common encrypted-DNS bypass paths

The v2 client blocks common encrypted-DNS bypass paths at the kernel level, including known public DoH provider IPs and standard DoT/DoQ ports, so browsers and apps have fewer ways to route DNS around policy.

Protocol	Port	Behavior
DoH (DNS over HTTPS)	TCP/443 to known public DoH provider IPs	Blocked. Browsers fall back to the system resolver or fail depending on browser policy; where fallback occurs, requests route through ScoutDNS.
DoT (DNS over TLS)	TCP/853	Blocked once policy is loaded.
DoQ (DNS over QUIC)	UDP/853	Blocked once policy is loaded.

The block list of known public DoH provider IPs is maintained by ScoutDNS and updated periodically. The major commercial providers (Cloudflare, Google, Quad9, NextDNS, Mullvad, and others) are covered.

If a customer reports that Chrome or Firefox is still reaching blocked sites with Use Secure DNS enabled, please open a support ticket so the provider’s current IP set can be reviewed.

Captive portals

Hotel Wi-Fi, airport networks, and similar public networks use a captive portal that intercepts DNS before login. The v2 client detects captive portal conditions on each network change:

• On network join, the agent probes a known connectivity endpoint.
• If the probe fails in a way consistent with a captive portal, the agent enters a bounded Bypass mode and lets the local network resolver handle queries.
• The user logs in through their browser as normal.
• Once the probe succeeds, the agent exits Bypass and resumes encrypted DNS to ScoutDNS.

No customer action is required; the agent handles this automatically.

Fail-open behavior

The v2 client is health-aware fail-open by default. DNS availability is preserved during the following conditions, with normal enforcement active when the client is healthy:

• Service starting / pre-rule-push. The driver passes DNS unfiltered until policy is loaded.
• Service unreachable (crash, hung). The driver enters a passive state; DNS continues through the system’s normal resolution path.
• Cloud resolver unreachable. The service falls back to a configured direct upstream so the user keeps internet access.

TCP/53 fallback is an intentional exception to the general fail-open posture: it is blocked fail-closed because truncated-response TCP retry can otherwise bypass UDP-level DNS enforcement.

Customers who require fail-closed behavior (no DNS unless ScoutDNS is reachable) can opt in via the profile.

Auto-update and rollback

The Updater service handles version upgrades automatically:

1. Polls the Control Plane for newer builds.
2. Downloads the MSI and verifies its Authenticode signature.
3. Installs via MajorUpgrade so the previous install is replaced cleanly.
4. Watchdogs the new build, rolling back automatically if the upgrade fails to register or repeatedly crashes.

[!NOTE] Driver upgrades may require a reboot to fully take effect. Windows can sometimes load the new driver during the upgrade, but if the previously loaded kernel driver remains in memory, rebooting activates the new driver. Policy-only updates do not require a reboot. If support asks you to reboot to confirm a fix, this is why.

Verify the install

After deploying to a test device:

1. Open Manage Clients in the Control Plane and confirm the device appears with Status: Online.
2. Confirm the device’s network configuration is unchanged: Get-DnsClientServerAddress should still show the original adapter DNS, and Get-DnsClientNrptRule should show the same NRPT entries (if any) the device had before the install.
3. On the device, browse to a known-blocked test domain (or a sample category the profile blocks). The ScoutDNS block page should render.
4. Resolve an internal hostname (for example, a host on the corp AD suffix). It should resolve successfully via the configured Local Forwarder.
5. With Use Secure DNS enabled in Chrome or Edge, browse to the block test again. The block page should still render, confirming the encrypted-DNS block is active.
6. Optional TCP/53 bypass check (for support). Run a TCP-only DNS query to a public resolver, for example Resolve-DnsName -Name example.com -Type A -Server 8.8.8.8 -TcpOnly. On an enforced device this should fail or time out rather than return an answer from the public resolver.

If any step fails, collect a diagnostic capture before changing the agent state:

• See Windows Agent Diagnostic Tool for the capture procedure.
• Attach results.yaml and the agent log to your support ticket.

Coexistence with VPN, ZTNA, and other endpoint tools

The v2 client is designed to operate alongside modern VPN clients, ZTNA agents (such as SonicWall CSE, Enclave, and similar), and endpoint protection products. Because it does not modify adapter DNS, does not write NRPT, and does not compete for ownership of any loopback address those tools typically claim, conflict surface is minimal by design.

For specifics on supported configurations, namespace routing through a ZTNA tunnel, and how Local Forwarders interact with vendor-supplied DNS rules, see: VPN and ZTNA compatibility (Windows Client).

Testing DNS the right way

A quick note that catches many troubleshooting sessions:

[!NOTE] nslookup is not a complete test of Windows DNS Client behavior. It uses its own DNS socket and can bypass Dnscache, suffix search behavior, and NRPT/cache behavior. It is useful for targeted resolver checks, but use Resolve-DnsName, browser tests, and the diagnostic tool to verify normal endpoint behavior.

Tools that exercise the real resolution path:

• Resolve-DnsName -Name <name> (PowerShell)
• Get-DnsClientCache to see what the system cached and from where
• ping <hostname> for a basic name-resolution check
• A browser address bar (with Secure DNS disabled, so the browser uses the system resolver)

Related

• Roaming clients (device agents), the v1 agent reference (Scout360 / loopback-adapter model).
• VPN and ZTNA compatibility (Windows Client), companion article for mixed-endpoint environments.
• Windows Agent Diagnostic Tool, capture procedure for support tickets.
• Working with policies, assigning policies to profiles and devices.
• Active Directory policies, per-AD-group policy via Personas.
• Custom block pages, block-page templates assigned per profile.
• Browser HTTPS certificate errors, installing the ScoutDNS root cert.
• Prevent DNS bypass, firewall-side companion to the agent’s encrypted-DNS block.