Resolving Slow Wi-Fi Device Switching on Windows AD Domain-Joined PCs

AiM Technical Knowledge Base Article

Applies to: RaceStudio 3, AiM Data Loggers, Displays, and SmartyCam4 devices operating in Access Point (AP) Wi-Fi mode.

Audience: Network Administrators, System Integrators, and IT Support Teams.

Executive Summary

When switching Wi-Fi connections between AiM devices on Windows PCs that are joined to an Active Directory (AD) domain and simultaneously hold another active network connection (typically the corporate wired Ethernet), users may observe a delay of 12 to 50 seconds before the new network connection becomes fully active. During this window, Windows temporarily assigns an APIPA address (169.254.x.x).

This article explains the underlying networking dynamics, announces an upcoming firmware update that addresses the root cause, and provides a simple, reversible IT workaround for existing devices deployed in the field.

Scope: Who Is Affected?

This scenario occurs under a specific combination of network conditions:

Affected: Windows PCs joined to an Active Directory domain (or configured with a primary DNS suffix) that have dynamic DNS registration enabled (the default Windows setting) AND hold a second active network connection — typically the corporate wired Ethernet — while switching between AiM Wi-Fi networks.
Not affected: Standard standalone laptops or PCs used at the track, PCs not joined to an AD domain, or PCs operating with Wi-Fi as their sole active network connection. In these standard scenarios, Wi-Fi switching completes within a few seconds.

Technical Root Cause

DHCP Option 6 Announcement: Current firmware versions of AiM Wi-Fi devices include DHCP Option 6 (Domain Name Server) in their DHCP responses, advertising their own IP address (e.g., 10.0.0.1 or 192.168.50.1) as the DNS server. However, AiM devices operate as standalone instruments and do not run an active DNS server.
Windows Dynamic DNS Deregistration: When a Windows domain-joined PC disconnects from one AiM device to connect to another, the Windows DHCP Client service attempts to deregister the PC’s Active Directory host record (e.g., COMPUTER-NAME.domain.com) from the DNS server of the previous connection (10.0.0.1).
Misrouted Queries and Timeouts: Because the Wi-Fi IP address has just been removed during the disconnection and the corporate Ethernet adapter provides an active default route, Windows routes these DNS lookup queries (SOA requests) out the Ethernet adapter toward the corporate network. Since no DNS server exists at 10.0.0.1 on that network, the queries go unanswered and expire only after their retry cycles (12 to 50 seconds in total). During this timeout window, Windows temporarily falls back to an APIPA address (169.254.x.x) before finally applying the new Wi-Fi DHCP lease.

Solution Strategy & Firmware Roadmap

Upcoming Firmware Update (Permanent Device-Level Fix)

Future firmware releases for all AiM device families (loggers, displays, and SmartyCam4) will completely omit DHCP Option 6 from their DHCP server responses.

Since AiM software (RaceStudio 3) and mobile applications communicate with AiM hardware via direct IP addressing (10.0.0.1), DNS server advertising is unnecessary. Omitting Option 6 means Windows no longer records a DNS server for the device connection, so the DNS deregistration step never starts and Wi-Fi switching completes within a few seconds.

Note

Note on the first connection after a firmware update. Windows caches the DHCP parameters of each Wi-Fi network it has joined, keyed by network name (SSID). The first connection to a freshly updated device may therefore still apply the previously cached DNS setting, and one residual delay may still be observed on the following switch. From the second connection onwards the improvement takes full effect. No manual action is required — the cache updates by itself. Please keep this in mind when validating the fix.

IT Workaround for Existing Devices (Field-Deployed Firmware)

For existing devices currently deployed in the field, Network Administrators can apply a quick, one-time configuration change on domain-joined PCs to disable dynamic DNS registration specifically on the Wi-Fi network adapter used to communicate with the instruments.

Step-by-Step IT Workaround for Existing Devices

Disabling dynamic DNS registration on the Wi-Fi adapter prevents Windows from attempting AD DNS updates when joining or leaving AiM Wi-Fi networks.

Method 1: PowerShell Command (Recommended)

Run the following command in an Elevated PowerShell window (Run as Administrator):

Set-DnsClient -InterfaceAlias "Wi-Fi" -RegisterThisConnectionsAddress $false

Note

Replace "Wi-Fi" with the exact name of the wireless adapter if it has been renamed, e.g. "Wi-Fi 2".

The change takes effect immediately; no reboot is required.

Automated script for physical wireless adapters:

# Run as Administrator
$wifiAdapters = Get-NetAdapter -Physical | Where-Object { $_.MediaType -eq "Native 802.11" -or $_.InterfaceDescription -match "Wi-Fi|Wireless|802.11" }

foreach ($adapter in $wifiAdapters) {
    Set-DnsClient -InterfaceAlias $adapter.Name -RegisterThisConnectionsAddress $false
}

Method 2: Windows Graphical Interface (GUI)

Press Win + R, type ncpa.cpl, and press Enter to open Network Connections.
Right-click the Wi-Fi adapter and select Properties.
Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.
Click Advanced… and select the DNS tab.
Uncheck the option Register this connection’s addresses in DNS.
Click OK on all open dialogs to save the changes.

Method 3: Central Deployment (GPO / Intune)

To deploy the setting fleet-wide, distribute the PowerShell command above as a GPO startup script or as an Intune Platform script / remediation running in SYSTEM context, targeted at the PCs that connect to AiM instruments.

Warning

Do not use the built-in Group Policy Dynamic update setting under Computer Configuration → Administrative Templates → Network → DNS Client for this purpose. That policy is machine-wide: it would disable DNS registration on the corporate Ethernet adapter as well. There is no built-in per-adapter policy — the per-adapter change requires the scripted method above.

Safety and Side-Effects

Corporate LAN functionality retained: The change applies exclusively to the Wi-Fi adapter. The corporate wired Ethernet adapter retains dynamic DNS registration (RegisterThisConnectionsAddress = True), so the PC continues to register its Host A/AAAA records on corporate Active Directory DNS servers without interruption.
No impact on AiM software communication: RaceStudio 3 communicates with AiM hardware using direct IP socket connections (10.0.0.1). Disabling DNS registration on the Wi-Fi adapter has no impact on device discovery, data transfer, live telemetry, or firmware updates.
Future-proof: This setting is fully compatible with both current and future AiM firmware releases. Once updated firmware is installed on devices in the field, the setting remains a beneficial defense-in-depth practice, preventing unnecessary background DNS registration traffic on wireless adapters.

Important

One case to evaluate before deploying: a laptop that uses the same Wi-Fi adapter to join the corporate wireless network (with no Ethernet cable connected) will stop registering its host record in AD DNS while on corporate Wi-Fi. If your organization relies on resolving workstation names for remote assistance, inventory or similar tooling, apply this workaround only to the PCs (or to the dedicated Wi-Fi adapters, e.g. USB dongles) used for instrument communication, and evaluate laptop cases individually.

Verification and Rollback

Verification

To verify that the workaround is active, run the following PowerShell command (no administrative privileges required):

Get-DnsClient -InterfaceAlias "Wi-Fi" | Select-Object InterfaceAlias, RegisterThisConnectionsAddress

Expected output:

InterfaceAlias RegisterThisConnectionsAddress
-------------- ------------------------------
Wi-Fi                                   False

Rollback

To restore the default Windows setting at any time:

Set-DnsClient -InterfaceAlias "Wi-Fi" -RegisterThisConnectionsAddress $true