Add ability to find LocalDB instances with Find-DbaInstance

[JohnNelsonNumber2]

Summarize Functionality

Find-DbaInstance doesn't seem to detect any localdb instances, which to me should be in scope since localdb is basically service-less express edition. It would be great to see this functionality in Find-DbaInstance. (see technical details)

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

No

Technical Details

One can run sqllocaldb info and get info on localdb instances owned by the current user and all shared instances.

and one can also run sqllocaldb info 'instance name' and get more info about them

So...here's a very VERY rough attempt at showing all the pieces I think are needed to detect LocalDb instances

# attempt to get the path to SqlLocalDb.exe
$localDbExe = (Get-Command SqlLocalDb.exe -ErrorAction SilentlyContinue).Path;
#if it wasn't immediately found, attempt to get it from the registry
if(-not $localDbExe) {
    $localDbExe = try {
        #attempt to get the location for the sql tools from the registry
        Join-Path (Get-Item (Join-Path (Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server' |
            #get only number-based subkeys which represent different versions (130,140,150) and where ..\tools\ClientSetup exists
            Where-Object {$_.PSChildName -match '^\d+$' -and (Test-Path (Join-Path $_.PSPath 'tools\ClientSetup'))} |
                #sort by the name and get the last one (should be the latest version), then get the Path value from it and add SqlLocalDb.exe to the end
                Sort-Object -Property Name | Select-Object -Last 1).PSPath '\tools\ClientSetup')).GetValue('Path') 'SqlLocalDb.exe'
    }
    catch {}
}
#if we've got a SqlLocalDb.exe path and it exists...
if(Test-Path $localDbExe -ErrorAction SilentlyContinue) {
    #get localdb instances from the command
    $instances = Invoke-Command {& $localDbExe info};
    #for each localdb instance (owned by or shared with current user)...
    foreach($instance in $instances) {
        $currObject = @{}
        #get all the <name> : <value> pairs from ' SqlLocalDb.exe info <instance> '
        Invoke-Command {& $localDbExe info $instance} | ForEach-Object {
            $parts = $_.Split(':',2);
            if($parts.Count -eq 2) {
                $currObject."$($parts[0].Trim())" = "$($parts[1].Trim())"
            }
        }
        #and output them        
        [PSCustomObject]$currObject;
    }
}

And here's the output

[potatoqualitee]

This is very cool. @FriedrichWeinmann any interest in adding this? if not, maybe we can do it in pure powershell after the dll processing.

[potatoqualitee]

this sounds fun as hell, @claude your suggestion? any downsides?

[claude]

Claude finished @potatoqualitee's task in 1m 9s —— View job

---

Tasks

• Read trigger comment and gather context
• Review Find-DbaInstance architecture (discovery model, scan types)
• Evaluate feasibility of LocalDB discovery within that architecture
• Post suggestion + downsides

My take

I'd steer away from bolting LocalDB onto Find-DbaInstance itself, and instead build it as a small, separate command. Here's why.

Find-DbaInstance's model doesn't fit LocalDB

Every -ScanType it has (Browser, SQLService, SPN, TCPPort, DNSResolve, Ping, SqlConnect) assumes a network-addressable, service-based SQL Server: something with a Windows service, a listening port, maybe a browser/SPN registration, reachable on a ComputerName. LocalDB breaks basically all of those assumptions:

• It's not a Windows service — sqllocaldb.exe spins up a per-user child process on demand, so it won't show up via Get-DbaService/CIM Win32_Service enumeration.
• It's not network reachable by default — shared memory/named pipes, no TCP listener, no Browser registration, no SPN.
• It's inherently per-user/per-session, not per-machine. "Instances" are scoped to the Windows user profile that owns them (sqllocaldb.exe info only shows the calling user's instances + shared ones), which has no real analogue in Find-DbaInstance's computer-centric, confidence-scored model (DbaInstanceReport, DbaInstanceConfidenceLevel, etc.).
• Remote enumeration means invoking sqllocaldb.exe inside a remote PowerShell session as a specific user — very different plumbing than WMI/CIM/TCP probing.

Also worth noting: the report object types (Dataplat.Dbatools.Discovery.DbaInstanceReport, DbaInstanceScanType, DbaInstanceConfidenceLevel) are compiled types that live in the separate dbatools-library repo, not in this PowerShell repo. Adding a LocalDB scan flag "properly" would mean changing that library, cutting a new release, and bumping the pinned version here — a much heavier, slower loop than a normal PR. That's the "dll processing" @potatoqualitee mentioned.

Suggested approach: a new, pure-PowerShell command

Something like Find-DbaLocalDbInstance (or similar) that:

1. Locates SqlLocalDb.exe — Get-Command, falling back to the registry probe in the issue (or just well-known install paths under %ProgramFiles%\Microsoft SQL Server\**\Tools\Binn\SqlLocalDB.exe).
2. Runs sqllocaldb.exe info to list instance names, then sqllocaldb.exe info <name> per instance for details, parsing the colon-delimited output into a proper [PSCustomObject].
3. Emits typed objects immediately per instance (per repo convention — no array collection), with normalized property names (e.g. Name, State, Version, SharedName, Owner, NamedPipe, AutoCreated) instead of raw parsed key strings.
4. Supports -ComputerName/-Credential for remote enumeration via Invoke-Command, since local-only would be a fairly narrow win.
5. Ideally, its output should be pipeable into Connect-DbaInstance (build a computername\localdb#instancename-style connection string) so it composes with the rest of the module — Connect-DbaInstance already special-cases localdb in its connection string handling.

Downsides / open questions either way

• Parsing sqllocaldb.exe text output is inherently fragile — it's locale-dependent (label text changes with Windows display language) and undocumented/unversioned across SQL LocalDB releases. Needs defensive parsing and probably an -EnableException-guarded skip when the exe isn't found, rather than hard failure.
• Remote enumeration requires either WinRM (Invoke-Command) or CIM, and only works for user profiles that are loaded/accessible on the remote box — you can't reliably discover LocalDB instances for every user on a remote machine without their profile being loaded, so "discovery" is inherently partial/best-effort.
• LocalDB is Windows + SQL Server client tools only (no Linux/macOS relevance), so this would be another Windows-only surface in a cross-platform module — should be gated the same way other Windows-only features are.
• If it stays a separate command rather than folding into Find-DbaInstance, users scanning a whole network won't get LocalDB results "for free" as part of a broad Find-DbaInstance -DiscoveryType All run — that's an intentional tradeoff for correctness over completeness, but worth calling out.

Net: I think this is a reasonable, self-contained feature, but it should ship as its own command (pure PowerShell, no library changes needed) rather than as a new Find-DbaInstance scan type. I haven't implemented anything here since the ask was for a recommendation — happy to build it out if there's agreement on the approach.

[JohnNelsonNumber2]

LOL, well when you put it that way 😃