Dbatools configuration profiles

[wsmelton]

Summarize Functionality

Right now, we default a few configurations that are meant to be for pure interaction and not automation (non-interactive) uses with the module. Big example is the TEPP configuration, by default tabexpansion.disable is set to false.

The average use of our module I think now-a-days is purely non-interactive. Those that use it for interactive purposes to check things here-and-there is less than those writing scripts and automating workflows against SQL Server.

I think one of two things can be done:

• We default all configurations to assume non-interactive use of the module, those that want to perform interactive task can enable features if they want but we cater to automation and non-interactive sessions by default.
• Create a parameter on Set-DbatoolsConfig to allow for two profiles: interactive and non-interactive.

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

Yes

Technical Details

If we go the route of profiles...

Create a parameter that would be used like: Set-DbatoolsConfig -Profile Interactive or Set-DbatoolsConfig -Profile NonInteractive

The workflow for each parameter value would set the associated configurations to disable (NonInteractive) or enable (Interactive).

We have some values that for example the configuration item is to disable it, so by default it is enabled (Get-DbatoolsConfig -Module tabexpansion). In the scenario of non-interactive, that profile would set tabexpansion.disable to true, and opposite the interactive profile setting this would be set to false.

[mattcargile]

Though, I am in the more interactive usage camp lately. I do like this behavior.

It would be neat to have some module sanctioned aliases potentially too in the Interactive profile? Or another feature? Considering it appears we have tried to create these types of aliases. The scope of this generation doesn't appear to function correctly though.

dbatools/dbatools.psm1

Lines 276 to 282 in 0433f32

	$shortcuts = @{
	'ivq' = 'Invoke-DbaQuery'
	'cdi' = 'Connect-DbaInstance'
	}
	foreach ($sc in $shortcuts.GetEnumerator()) {
	New-Alias -Name $sc.Key -Value $sc.Value
	}

Just commenting on these, I would prefer to follow the usage from Get-Verb. So I would rather idq and ccdi.

[andreasjordan]

@claude please give me some advice on this.

[claude]

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

---

Advice on Configuration Profiles

Here's my analysis and recommendations based on looking at the current configuration system.

---

Key architectural constraint

Set-DbatoolsConfig is a compiled C# cmdlet (from dbatools.library.dll) — there is no Set-DbatoolsConfig.ps1 to edit. Adding -Profile to it would require modifying the C# library. This makes the option proposed in the issue harder than it appears.

---

Recommended approach: new Set-DbatoolsProfile function

Instead of modifying the compiled cmdlet, create a standalone pure-PowerShell function that applies a named profile by calling Set-DbatoolsConfig internally. This requires zero C# changes and follows dbatools naming conventions:

function Set-DbatoolsProfile {
    [CmdletBinding(SupportsShouldProcess)]
    param(
        [Parameter(Mandatory)]
        [ValidateSet("Interactive", "NonInteractive")]
        [string]$Profile,

        [switch]$EnableException
    )

    switch ($Profile) {
        "Interactive" {
            Set-DbatoolsConfig -FullName "TabExpansion.Disable"            -Value $false
            Set-DbatoolsConfig -FullName "TabExpansion.Disable.Asynchronous" -Value $false
            Set-DbatoolsConfig -FullName "message.consoleoutput.disable"   -Value $false
            Set-DbatoolsConfig -FullName "message.style.functionname"      -Value $true
            Set-DbatoolsConfig -FullName "message.style.timestamp"         -Value $true
        }
        "NonInteractive" {
            Set-DbatoolsConfig -FullName "TabExpansion.Disable"            -Value $true
            Set-DbatoolsConfig -FullName "TabExpansion.Disable.Asynchronous" -Value $true
            Set-DbatoolsConfig -FullName "message.consoleoutput.disable"   -Value $false
            Set-DbatoolsConfig -FullName "message.style.functionname"      -Value $false
            Set-DbatoolsConfig -FullName "message.style.timestamp"         -Value $false
        }
    }
}

---

Auto-detection at module load (the real win)

The biggest improvement would be auto-detecting the session type at module import time and applying the right defaults automatically, so users don't need to do anything at all. PowerShell already exposes this:

# In dbatools.psm1 (after configurations are loaded)
$isInteractive = [Environment]::UserInteractive -and
    ($null -eq [Environment]::GetCommandLineArgs() -or
     -not ([Environment]::GetCommandLineArgs() | Where-Object { $_ -match "-NonInteractive" }))

if (-not $isInteractive) {
    Set-DbatoolsConfig -FullName "TabExpansion.Disable"            -Value $true
    Set-DbatoolsConfig -FullName "TabExpansion.Disable.Asynchronous" -Value $true
}

This stops TEPP from spinning up background runspaces in CI pipelines, Azure Automation, scheduled tasks, etc. — zero user action required.

---

What configs should be in each profile

Based on the current config files:

Config	Interactive default	NonInteractive override
TabExpansion.Disable	$false	$true
TabExpansion.Disable.Asynchronous	$false	$true
message.style.functionname	$true	optional $false
message.style.timestamp	$true	optional $false
message.style.breadcrumbs	$false	leave as-is

The message.consoleoutput.disable should probably not be toggled by a profile — silencing output in a CI pipeline is unexpected and would swallow errors that users need to see.

---

Recommendation on the two options from the issue

	Option 1 (change defaults)	Option 2 (profile param)
Effort	Low — change Value $false to auto-detected value in tabexpansion.ps1	Medium — new function
UX	Best: zero config for most users	Requires explicit call
Breaking change	Possible if any existing users rely on TEPP being enabled in non-interactive scripts	None
Verdict	Preferred if auto-detection is reliable	Good complement to option 1

Best path forward: Do both. Auto-detect at module load (option 1) so 95% of users get the right behavior automatically, then also provide Set-DbatoolsProfile for the cases where auto-detection gets it wrong or users want explicit control. The profile function is also useful in $PROFILE for interactive users who want to explicitly opt into the Interactive profile.

---

On aliases (from @mattcargile's comment)

Alias generation in dbatools.psm1:276-282 appears to be a separate concern. If pursued, I'd agree that following Get-Verb conventions (idq, ccdi etc.) is cleaner — but that's scoped to a different issue/PR.

[potatoqualitee]

I went through this against current development. Here is where I landed, plus a PR for the part I think is unambiguous.

First, a correction to my own earlier answer. The auto-detection snippet I posted in April should not be used. [Environment]::UserInteractive reports $true for any process in a normal user session, which covers most build agents and most scheduled tasks, and [Environment]::GetCommandLineArgs() never returns $null, so that check would have classified nearly every automation session as interactive. The part that was right is that Set-DbatoolsConfig is a compiled cmdlet listed in CmdletsToExport, so putting -Profile on it means a dbatools.library change and release.

Why I no longer think profiles are the right shape. Going through the settings one at a time, there is only one that actually misbehaves when nobody is at the keyboard:

• TabExpansion.Disable.Synchronous already defaults to $true
• registering the argument completers is inert, since nothing runs unless someone presses Tab
• the message and formatting settings are cosmetic and harmless in a pipeline

That leaves the asynchronous TEPP cache, and it is worse than some wasted CPU. private/scripts/updateTeppAsync.ps1 imports a second copy of dbatools into a background runspace, then opens a fresh SMO connection to every instance the session has connected to, every three minutes, for thirty minutes after last use. An unattended job that touches prod once keeps logging back in afterwards. That shows up in login auditing and session counts, and the person who wrote the script never asked for it.

A two-value profile wrapped around a single real toggle is API surface we would be explaining forever. Better to make the default correct.

The PR: #10494. It registers the runspace at import but leaves it stopped, and starts it from the argument completer the first time someone actually completes a parameter. No session sniffing, no heuristics, no C# change:

• unattended sessions never start the runspace and never open those connections
• interactive sessions behave as before
• TabExpansion.Disable and TabExpansion.Disable.Asynchronous still stop it, and still win over any later completion
• DBATOOLS_DISABLE_TEPP is untouched
• -SqlInstance completion is unaffected, because Connect-DbaInstance fills that cache synchronously

Measured in a fresh process, identical on Windows PowerShell 5.1 and PowerShell 7:

development : Running immediately after import
this PR     : Stopped after import, Running after the first tab completion

Two judgement calls in there worth your eyes. The fifteen second start-up deferral is gone, because it existed to avoid colliding with the foreground import and a keypress cannot happen while that import is still running; keeping it would have left the first completion empty for fifteen seconds. And the config handlers no longer start the runspace when TEPP is re-enabled, so that enabling and starting stay separate decisions.

One thing the PR does not fix: if you import dbatools with TEPP already switched off, updateTeppAsync.ps1 skips registration entirely, so re-enabling in that session still gets you nothing. That is true on development today as well — the handler's if ($starttepp) guard was equally null — so it is not a regression, but fixing it means dedenting that whole file and I would rather that be its own decision.

Still yours to decide:

1. Whether anything else belongs in a non-interactive bucket. I could not find a second setting that does real damage. If you know one, that changes the answer and profiles come back on the table.
2. DBATOOLS_DISABLE_TEPP and DBATOOLS_DISABLE_LOGGING both work today but are documented only in a comment inside dbatools.psm1. Worth an about_ topic whatever happens to this issue.
3. @mattcargile's point about aliases is real but separate. ivq and cdi are created in dbatools.psm1 but are not listed in AliasesToExport in dbatools.psd1, so they never reach anyone. Export them, rename them to follow Get-Verb as suggested, or drop them, but it deserves its own issue rather than riding along here.

I have deliberately not closed this issue. The PR fixes the concrete cost; whether the profile concept is dead is a maintainer call.

[mattcargile]

On the note of interactivity, powerShell does this already in the engine on loading psreadline. I check if those classes are loaded and if they are I know I am interactive and will load my profile interactive code.

https://github.com/PowerShell/PowerShell/blob/master/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHost.cs#L1681