DAC behaviour in Connect-DbaInstance on localhost

[Phaere]

Verified issue does not already exist?

I have searched and found no existing issue

What error did you receive?

Export-DbaLinkedServer in specific cases keeps spamming in the SQL server log with error below:
"Could not connect because the maximum number of '1' dedicated administrator connections already exists. Before a new connection can be made, the existing dedicated administrator connection must be dropped, either by logging off or ending the process."

Steps to Reproduce

1. Connect to SQL server via RDP or PSRemoteSession
2. Run Export-DbaLinkedServer -SqlInstance SERVERNAME -LinkedServer LINKEDNAME
3. Look at SQL server logs, you should see error about multiple DAC connections not allowed
4. Issue does not reproduce when command executed from another PC, only at SQL server itself

Please confirm that you are running the most recent version of dbatools

2.7.23-2.7.25

Other details or mentions

Issue exists in Connect-DbaInstance function called from Export-DbaLinkedServer with $DedicatedAdminConnection parameter.
It builds up connection string to servername passed from user input and produces multiple connections attempts to all resolved IP addresses.

In #10106 issue was fixed for all connections from outside, but still persist when dbatools executed locally.

What PowerShell host was used when producing this error

Windows PowerShell (powershell.exe)

PowerShell Host Version

Name Value

---

PSVersion 5.1.20348.4294
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.20348.4294
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

SQL Server Edition and Build number

Microsoft SQL Server 2022 (RTM-CU20) (KB5059390) - 16.0.4205.1 (X64) Jun 13 2025 13:38:45 Copyright (C) 2022 Microsoft Corporation Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2022 Datacenter 10.0 (Build 20348: )

.NET Framework Version

PSChildName Version

---

Client 4.8.04161
Full 4.8.04161
Client 4.0.0.0

[andreasjordan]

We changed the dac handling in the last release. Please try to reproduce the issue with 2.7.25.

[Phaere]

Issue reproduced at version 2.7.25 if running on same server (as described above)

[andreasjordan]

@claude please look at this issue. Can you give me more details about the root cause? Do you see a good way to solve the issue?

[claude]

Claude finished @andreasjordan's task in 6m 4s —— View job

---

Root Cause Analysis & Fix Recommendation

• Gather context from issue
• Read Connect-DbaInstance source code
• Analyze DAC connection string building logic
• Review Export-DbaLinkedServer code
• Formulate root cause explanation and fix recommendation

---

Root Cause

The bug is in Connect-DbaInstance.ps1 at lines 641–644:

if ($DedicatedAdminConnection -and $serverName) {
    Write-Message -Level Debug -Message "Parameter DedicatedAdminConnection is used, so serverName will be changed and NonPooledConnection will be set."
    $serverName = 'ADMIN:' + $serverName
    $NonPooledConnection = $true
}

When Export-DbaLinkedServer -SqlInstance SERVERNAME is run from the SQL Server itself, the call chain is:

1. Export-DbaLinkedServer determines it needs a DAC connection to read encrypted linked server passwords
2. It calls Connect-DbaInstance -SqlInstance SERVERNAME -DedicatedAdminConnection
3. Connect-DbaInstance builds $serverName = 'ADMIN:' + $instance.FullSmoName → e.g. ADMIN:MYSERVER

The problem: When the SQL client library connects to ADMIN:MYSERVER from the same machine, the hostname MYSERVER resolves to all of the machine's IP addresses (one per network adapter). The client attempts to establish a DAC connection to each resolved IP. As confirmed by the SQL Server error log screenshot, connection attempts arrive from multiple distinct client IPs (169.254.1.24, 10.252.0.14, fe80::..., 10.0.0.241) — these are the server's own network adapter addresses.

Why it works remotely: When connecting from a different machine, MYSERVER typically resolves to only the server's primary/external IP (or whichever IPs are published in DNS for that remote network path). So only one connection attempt is made, and the DAC succeeds.

Why it fails locally: On the server itself, OS name resolution for the machine's own hostname returns all its local network interface IPs. The SQL driver tries each in turn. The first succeeds and opens the DAC; the remaining attempts hit the "maximum 1 DAC connection" limit and are rejected — generating the log spam.

This is a fundamental difference in how hostname resolution behaves on localhost vs. remotely. The fix in #10106 addressed remote connections but not local ones, because the local resolution behavior is different.

---

Proposed Fix

When DedicatedAdminConnection is set and the target is the local machine ($instance.IsLocalHost), replace the server hostname with localhost (which always resolves to a single loopback address) before prepending ADMIN:.

Location: public/Connect-DbaInstance.ps1, lines 641–644

# BEFORE (current code):
if ($DedicatedAdminConnection -and $serverName) {
    Write-Message -Level Debug -Message "Parameter DedicatedAdminConnection is used, so serverName will be changed and NonPooledConnection will be set."
    $serverName = 'ADMIN:' + $serverName
    $NonPooledConnection = $true
}

# AFTER (proposed fix):
if ($DedicatedAdminConnection -and $serverName) {
    Write-Message -Level Debug -Message "Parameter DedicatedAdminConnection is used, so serverName will be changed and NonPooledConnection will be set."
    if ($instance.IsLocalHost) {
        # Use localhost to avoid multiple IP resolution on multi-homed servers (issue #10151)
        $dacServerName = if ($instance.InstanceName -and $instance.InstanceName -ne 'MSSQLSERVER') {
            "localhost\$($instance.InstanceName)"
        } else {
            "localhost"
        }
        Write-Message -Level Debug -Message "IsLocalHost is true, using '$dacServerName' for DAC to avoid multi-IP resolution."
        $serverName = "ADMIN:$dacServerName"
    } else {
        $serverName = 'ADMIN:' + $serverName
    }
    $NonPooledConnection = $true
}

The same fix should also be applied to the Server-type input path at lines 706–708, where an existing SMO server object is being upgraded to a DAC connection:

# BEFORE:
if ($DedicatedAdminConnection -and $inputObject.ConnectionContext.ServerInstance -notmatch '^ADMIN:') {
    $connContext.ServerInstance = 'ADMIN:' + $connContext.ServerInstance
    $connContext.NonPooledConnection = $true
}

# AFTER:
if ($DedicatedAdminConnection -and $inputObject.ConnectionContext.ServerInstance -notmatch '^ADMIN:') {
    if ($instance.IsLocalHost) {
        $dacServerName = if ($instance.InstanceName -and $instance.InstanceName -ne 'MSSQLSERVER') {
            "localhost\$($instance.InstanceName)"
        } else {
            "localhost"
        }
        $connContext.ServerInstance = "ADMIN:$dacServerName"
    } else {
        $connContext.ServerInstance = 'ADMIN:' + $connContext.ServerInstance
    }
    $connContext.NonPooledConnection = $true
}

Why This Works

• ADMIN:localhost always resolves to 127.0.0.1 — a single loopback address — regardless of how many NICs the machine has
• For named instances: ADMIN:localhost\INSTANCENAME preserves the instance routing
• For default instances: ADMIN:localhost is used
• Connections from remote machines are unaffected (the else branch keeps the current behavior)
• $instance.IsLocalHost is already computed by DbaInstanceParameter and is available throughout the foreach ($instance in $SqlInstance) loop

Testing Suggestion

Reproduce with: Export-DbaLinkedServer -SqlInstance $env:COMPUTERNAME -LinkedServer SomeLinkName from a PowerShell session on the SQL Server itself. After the fix, no DAC-related errors should appear in the SQL Server log.

[Phaere]

Proposed Fix

When DedicatedAdminConnection is set and the target is the local machine ($instance.IsLocalHost), replace the server hostname with localhost (which always resolves to a single loopback address) before prepending ADMIN:.

"Localhost" resolved to two addresses by default, 127.0.0.1 and ::1 as IPv6 enabled by default in Windows.
So maybe connection should be opened to 127.0.0.1 instead of localhost?

[andreasjordan]

Good question. But what about systems with only IPv6?

[andreasjordan]

@claude please read the last two comments. What do you suggest?

[claude]

Claude finished @andreasjordan's task in 2m 15s —— View job

---

Analysis of localhost vs. IPv6 concern

• Read last two comments
• Review current DAC connection code
• Formulate recommendation

---

Summary of the concern

Both commenters correctly identify a flaw with using localhost:

• Phaere: localhost resolves to two addresses by default on Windows: 127.0.0.1 (IPv4) and ::1 (IPv6). This would still cause two DAC connection attempts, which SQL Server rejects.
• andreasjordan: Using hardcoded 127.0.0.1 would fail on IPv6-only systems.

Both are right. Using a hardcoded string (localhost, 127.0.0.1, or ::1) alone won't work universally.

---

Recommendation: Dynamic single-loopback resolution

The fix is to resolve the right loopback address dynamically at runtime, selecting exactly one address. This avoids both problems:

if ($DedicatedAdminConnection -and $serverName) {
    Write-Message -Level Debug -Message "Parameter DedicatedAdminConnection is used, so serverName will be changed and NonPooledConnection will be set."
    if ($instance.IsLocalHost) {
        # Use a single loopback IP to avoid multi-IP resolution on multi-homed servers (issue #10151)
        # Prefer IPv4 (127.0.0.1) but fall back to IPv6 (::1) for IPv6-only systems
        $dacLoopbackIp = try {
            $loopbackAddrs = [System.Net.Dns]::GetHostAddresses("localhost")
            $ipv4Addr = $loopbackAddrs | Where-Object { $_.AddressFamily -eq [System.Net.Sockets.AddressFamily]::InterNetwork } | Select-Object -First 1
            if ($ipv4Addr) { $ipv4Addr.IPAddressToString } else { ($loopbackAddrs | Select-Object -First 1).IPAddressToString }
        } catch { "127.0.0.1" }

        $dacServerName = if ($instance.InstanceName -and $instance.InstanceName -ne "MSSQLSERVER") {
            "$dacLoopbackIp\$($instance.InstanceName)"
        } else {
            $dacLoopbackIp
        }
        Write-Message -Level Debug -Message "IsLocalHost is true, using '$dacServerName' for DAC to avoid multi-IP resolution."
        $serverName = "ADMIN:$dacServerName"
    } else {
        $serverName = "ADMIN:$serverName"
    }
    $NonPooledConnection = $true
}

How this works:

1. Calls [System.Net.Dns]::GetHostAddresses("localhost") → returns 127.0.0.1 and/or ::1 (the loopback addresses only, guaranteed by the OS hosts file)
2. Picks the first IPv4 address → 127.0.0.1 on systems with IPv4 (the vast majority)
3. Falls back to the first available address → ::1 on IPv6-only systems
4. Falls back to hardcoded "127.0.0.1" if DNS resolution fails entirely
5. The same single-IP logic is applied for named instances: 127.0.0.1\INSTANCENAME

Why this solves both concerns:

• localhost as a connection string → 2 DNS results → 2 DAC attempts → broken ❌
• Hardcoded 127.0.0.1 → IPv6-only systems → broken ❌
• Dynamic resolution picking one IPv4/IPv6 loopback IP → single address → works everywhere ✅

The same approach should be applied at lines 706–709 (the Server-type input path) for the same reason.

---

One more note

[System.Net.Dns]::GetHostAddresses is a standard .NET method compatible with PowerShell v3 and above, so it fits the project's compatibility requirements.

---

If you'd like me to implement this fix, I can do that.