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 😎
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.
- Windows 7 with PowerShell v3
- 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).
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 dbatools requires Windows 10 or PackageManagement on lower clients such as Windows 7 and Windows 8.
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.
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:
- Just specifying the module name – dbatools
- Specifying the dbatools directory
- 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.
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.