Export-DbaLinkedServer not exposing passwords if DAC is blocked for remote connections

[edbmfo]

Summarize Functionality

Export-DbaLinkedServer over the network does not expose passwords if DAC is not enabled for remote access.
This (DAC for remote access) should not be needed as shown in the technical details below.

My question is, can the current code be changed so that Export-DbaLinkedServer here does not need port 1434
to be open in the same way, or is the current situation intended.

Is there a command that is similiar or close to what you are looking for?

Yes

Technical Details

On version 2.7.20 of dbatools there was an issue where
Export-DbaLinkedServerdid not expose passwords for SQL servers in clusters since
the the DAC connection might be be busy since DAC might be available on multiple ipadresses.

A possible fix was discussed here where the Get-DecryptedObject.ps1 could be changed to
access 127.0.0.1 instead of $sourceName, making sure only that connection/ip was used.

This was the issue I commented on regarding DAC and Export-DbaLinkedServer:
#10040

I tested this my self on a dbatools clone from 2.7.2.0, and it worked perfectly.

Now that code did not end up in the public dbatools on its own; as several changes were
introduced, multiple rewrites of a lot of code. I could not follow the trail,
the refactiroing was done in multiple stages and i just waited it out and tried each released
version to check if this functionality worked for me.

It never did. So I kept on using my local fixed version for this functionality.

Current version 2.8.4 still does not work.

I've narrowed it down in that that code fails if DAC connection is not available
over the network - as in, if port 1434 is blocked, it fails, if port 1434 is open, it works as expected.

On that version 2.7.20 with the changed Get-DecryptedObject.ps1 to use 127.0.0.1 instead of $sourcename,
it still works without exposing 1434 over the network.

My understanding was and still is that the DAC portion was happening through psremoting, effectively
running locally on the sql server and so 127.0.0.1 was fine.

My question is, can the current code be changed so that export-dblink here does not need port 1434
to be open in the same way, or is the current situation intended.

Regards,
Marco

[andreasjordan]

Thanks for the detailed write-up, Marco — your analysis is correct, and I can show exactly where the behaviour changed.

Your 127.0.0.1 fix did land: PR #10106 on 2026-01-25, commit a0d6a67f8, credited to you. It was removed on 2026-02-19 by PR #10174, "Part 2 of refactoring of Get-DecryptedObject" (1a510a12d), which deleted the whole Invoke-Command2 block that opened the DAC on the SQL Server host.

Your understanding of the mechanism is also right. Before that refactor, Get-DecryptedObject opened the DAC inside the PowerShell remoting session on the SQL Server itself, connecting to ADMIN:127.0.0.1\<instance>. That is a local DAC, which needs neither remote admin connections nor a reachable DAC port. Today the calling command opens the DAC from your machine (Connect-DbaInstance -DedicatedAdminConnection) and passes it in, which is a remote DAC and needs both.

Why it changed. The old design opened and closed a DAC per command, from inside a WinRM session. SQL Server allows exactly one DAC at a time, and that combination produced a steady stream of failures — your own #10040 among them, plus #9921 and, more recently, #10475 where Sync-DbaAvailabilityGroup was opening three DACs for one operation. The strategy we settled on is: open one DAC as early as possible and share it across all the commands that need it. Local-DAC-over-WinRM was also a recurring source of trouble in its own right. So the current situation is a deliberate trade — a stricter network prerequisite in exchange for DAC handling that behaves predictably.

That means the honest answer to "can this be changed?" is: technically yes, but it isn't a change we'd make on a single request. Reintroducing a second DAC path costs us reliability in the area we just spent several releases stabilising, and reliability with fewer moving parts is worth more here than the extra flexibility.

So this is a question for contributors rather than something to just implement:

Should a remote DAC be a documented, fixed prerequisite for the password-decrypting commands, with this issue resolved by documentation only?

That would mean stating plainly in the help for Export-DbaLinkedServer, Export-DbaCredential, Copy-DbaLinkedServer, Copy-DbaCredential and Copy-DbaDbMail (and by extension Export-DbaInstance, Start-DbaMigration and Sync-DbaAvailabilityGroup) that exporting or copying passwords requires:

• sp_configure 'remote admin connections', 1 on the source instance
• the DAC port reachable from the client — TCP 1434 for a default instance, a dynamic port published via SQL Browser for a named one
• PowerShell remoting to the host, which is already required for reading the service master key

None of that is documented today; Export-DbaLinkedServer only mentions "accesses the local registry", which is why this came as a surprise.

Marco, in the meantime there's a third option beyond your two that needs no firewall change: run the export inside a remoting session on the SQL Server itself, where the DAC is local. Your patched copy obviously also stays valid.

Views welcome — particularly from anyone running dbatools against instances where opening the DAC port isn't an option.

---

This comment was written by Claude and reviewed by Andreas Jordan.

[edbmfo]

Thanks for your response and time used .

views welcome

Well I am biased and would prefer remote DAC implemented. One open port less might be trivial, but its one port less

I understand though that if that may introduce those recurring
troubles again that the maintainers prefer to just update documentation/requirements.

I'll just await yours and others decision on it.

Marco