installing and importing dbatools – minimum requirements, methods and more

When I first started coding dbatools, one of my primary goals was to make it as easy as possible to install. This is both because I think things should just work and I wanted to ensure SQL Server pros who were new to PowerShell did not get discouraged in any way.

I also wanted the module to work on reasonably old machines, especially since initially, its primary function was to perform migrations of both older and newer systems.

Fortunately, both goals were easily accomplished šŸ˜Ž

Minimum requirements

We understand that not everyone has the luxury of running Windows 10 with SQL Server vNext libraries, especially in work environments. For those of you restricted to using older software, we’ve got you covered.

Client

  • Windows 7 with PowerShell v3
  • SQL Server 2008 SMO or SSMS

You can get by with SQL Shared Management Objects (SMO) but a small number of commands may error out. SQL Server Management Studio, which also provides the required libraries, is several hundred MB and SMO is less than 10. If you’d like to skip the SSMS install and just go with SMO, install the 2016 SqlClrTypes (x86, x64) and then 2016 SQL Management Objects (x86, x64).

Now, while the minimum required is SQL Server 2008 (and maybe even 2005, never tried it) on the client, the experience may suck if you’re trying to manage higher versions of SQL Server. I recommend SQL Server 2012 SMO/SSMS or higher if possible.

Server

  • No PowerShell needed on the host for SQL Server-only commands šŸ˜®
  • PowerShell 2.0 with remoting enabled needed on the host for Windows commands
  • SQL Server 2000

Check out this video where I backup some databases on a Windows 2000 server running SQL Server 2000. Note that PowerShell can’t even install on Windows 2000. This is to emphasize the fact that it’s really the client that counts when it comes to commands that interact strictly with the SQL Service (Windows-based commands are a different story).

 

Installing dbatools

I also wanted to make installing dbatools as easy as possible and came up with a few ways. The first is using Install-Module which is natively available in Windows 10. The second way is a really easy scripted installer that you just paste into PowerShell from the download page.

Install-Module

Using Install-Module dbatools requires Windows 10 or PackageManagement on lower clients such as Windows 7 and Windows 8.

Scripted installer

Just execute Invoke-Expression (Invoke-WebRequest https://dbatools.io/in) from the command line. This will work on Windows 7-10 and all versions of Windows Server.

Watch in this video how easy it is to install dbatools on Windows 7 (then make some backups) using this method.

Download the zip

Just want the zip? Download it here.

Speed

I hate waiting and try to ensure that each release loads in 1.5 seconds or less on my machine. Our git and debugger guy, Constantine Kokkinos (CK), shocked me when he told me the module loads in as little as 650 milliseconds on his machine! We have nearly the same specs but my box is virtualized and his is pure physical.

Fred Weinmann has worked to make this happen, even as we add incredibly robust features to the module. Thank you, Fred šŸ† Also, ck, as someone who is obsessed with performance, I LOVE that prompt!

It is important to note that it is not normal for the module to take more than a few seconds to load. If you’re experiencing multi-minute load issues, it may be the Execution Policy on your domain. Check out Dr. Tobias Weltner’s blog post, Understanding Execution Policy, which was prompted by our team member Klaas Vandenberghe who was looking to reduce his load times.

A note about illegal characters

One of the techniques we previously used to speed up the load times actually broke Install-Module on many non-Win10 systems with a vague error that complained about illegal characters. It took CK a few days and even some DLL compiling to figure it out, but he persevered. Check out his blog post, Troubleshooting PowerShell and .NET: When error messages are not enough, for in-depth information about how he figure this all out.

Properly importing the module

PowerShell v3+ automatically loads modules in $env:PSModulePath as needed so you shouldn’t need to import the module, but there are some cases when you may need to perform a manual import or force a reimport.

First, I’d like to clarify and emphasize that when you’re manually importing dbatools using
Import-Module, you should never import the psm1 file – only the module name itself, the module manifest (.psd1) or module directory. So just to be clear, only the following 3 import methods are supported:

  1. Just specifying the module name – dbatools
  2. Specifying the dbatools directory
  3. Specifying the path to the psd1 file

The reason is because importing the psm1 exposes our internal commands which are unsupported, undocumented and unintended for public use. Worse, there may be name collisions which could cause you to run dbatools\Restore-SqlDatabase (an internal function) as opposed to SqlServer\Restore-SqlDatabase, which is what you were expecting, since our external command is Restore-DbaDatabase and Microsoft’s is Restore-SqlDatabase.

1.0 update

Just a real quick update – getting the PRs resolved for 1.0 is progressing a little slower than I expected. The backend rework is progressing quickly, but the testing is being held up by me. I hope to be back on track next week.

2 thoughts on “installing and importing dbatools – minimum requirements, methods and more

  1. raj Reply

    Hi ,

    Question : Trying to move linked servers.
    Source server in diff domain
    destination with diff domain ,

    is there a way where I can use credentials to connect to each server make the move work out .

    Can’t connect to rcdoptdbsql001.OneSiteDev.Realpage.com: System.Data.SqlClient.SqlException (0x80131904): A network-related or
    instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible.
    Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes
    Provider, error: 40 – Could not open a connection to SQL Server)

    • Chrissy LeMaire Post authorReply

      Hey Raj,
      Please ensure you can connect using SSMS — what you pasted is a common error that basically says “server not found.” If SSMS works, use Test-SqlConnection and email me the results at [email protected]

      All of our commands support alternative SQL credentials using SourceSqlCredential and DesintationSqlCredential parameter but currently, it does not support alternative Windows credentials that you’ll need for accessing the remote registry of the source server. Either use a Windows account that has access or run the command from the source serer itself.

Leave a Reply

Your email address will not be published. Required fields are marked *