I write a lot about SQL Server automation, and dbatools comes up constantly. Instead of rewriting the install steps in every post, I’m putting them here once so I can point back to them.
The full instructions live on the official site at dbatools.io/install. If you’re new to dbatools, follow those first, since they’re maintained by the project and this page is only my summary of them. Their Getting Started page is worth a look while you’re there. It’s mostly examples, which is a good way to see what the module can do.
The install the dbatools site recommends is one line, and it doesn’t need an admin session:
Install-Module dbatools -Scope CurrentUser
-Scope CurrentUser puts the module in a folder under your own profile, and Microsoft’s Install-Module documentation describes that location as “accessible only to the current user of the computer.” One side effect follows from that. A scheduled task or SQL Agent job running under a different account, like a service account, won’t find a module you installed this way, and it needs its own copy or an install for all users.
Installing for all users is Install-Module dbatools from an administrator PowerShell session. Leaving -Scope off doesn’t always mean all users, though. The same documentation says the default depends on the PowerShellGet version. Version 1.x defaults to all users, while 2.0 and later on PowerShell 6 or higher default to the current user unless the session is elevated. Writing the scope out avoids having to know which one you’re on.
If you’re prompted about trusting the repository, say yes, since it’s the official source. On older systems you may also need to trust PSGallery explicitly:
Set-PSRepository -Name PSGallery -InstallationPolicy Trusted
To check that it worked:
Get-Command -Module dbatools
And to pick up a newer release later:
Update-Module dbatools
Note: If you get errors about script execution policy, you may need to let PowerShell run the module’s scripts. The simplest way is:
Set-ExecutionPolicy RemoteSigned -Scope CurrentUserMicrosoft’s execution policy documentation explains the setting.
RemoteSignedruns scripts written on the local machine and requires a trusted signature on scripts downloaded from the internet. The same page points out that execution policy “isn’t a security boundary,” so it’s there to stop accidents rather than attacks.
That covers most modern setups. For machines without internet access, the dbatools site has an offline install guide, and it also lists Chocolatey (choco install dbatools) as another option.