TLDR: dbatools is moving to Azure Trusted Signing, which means Microsoft backs our reputation and dbatools won’t trigger as many antivirus false positives.
Users upgrading from older signed versions will need -SkipPublisherCheck only once during the initial transition. PowerShell users with strict ExecutionPolicies (AllSigned/RemoteSigned) will need to trust each new certificate after every update due to Azure Trusted Signing’s daily cert rotation (but you can use the automation script provided below).
TLDR: This error is expected and the change is legitimate. To update, switch to Install-Module, then slap on the -SkipPublisherCheck and -Force parameters and continue your update.
Install-Module dbatools -Force -SkipPublisherCheck I’ve always been very proud that dbatools is Code Signed like a “real” application. These certs prove the identity of the creator and help prevent tampering. The certificates cost a bunch of money and are hard to obtain. You gotta send in tons of paperwork, including your passport and business papers.
If you work in an offline environment, you’re probably familiar with how painful it can be to install anything, including PowerShell modules like dbatools.
In the past, dbatools had no dependencies, so the installation process was somewhat straightforward — you could even download a zip from our GitHub repo. However, with the introduction of the new dbatools.library dependency, the installation process has become a smidge more complex. In this post, I’ll walk you through the steps to install dbatools (and with it, dbatools.
If you work in an offline environment, you’re probably familiar with how painful it can be to install anything, including PowerShell modules like dbatools.
In the past, dbatools had no dependencies, so the installation process was somewhat straightforward — you could even download a zip from our GitHub repo. However, with the introduction of the new dbatools.library dependency, the installation process has become a smidge more complex. In this post, I’ll walk you through the steps to install dbatools (and with it, dbatools.
So much is new and different! If you’d like to try it while you read this blog post, you can currently install dbatools 2.0 by executing the following command:
Install-Module dbatools Requirements dbatools still works on PowerShell v3 an v4! Thanks to Microsoft for making that possible with SMO.
PowerShell v5.1 is still supported, of course. That’s what I use and develop on. But when it comes to PowerShell v7, we did up the requirements to 7.
This post is about Import-DbaCsv, a command within the dbatools PowerShell module for SQL Server.
I’ve been writing about CSV imports using PowerShell for a pretty long time and in VBScript for even longer. Initially, my primary concerns were ease-of-use and speed. Over time, I realized that what mattered most was:
Ease-of-use Reliability Data quality management I learned a ton about performance from my speed experiments but in the end, I threw most of that out in favor of a higher quality and mildly slower solution using a .
SQL Client Aliases allow you to connect to a SQL Server instance using another name. This is especially useful during migrations. Want your servers to connect to the new SQL Server without modifying connection strings within your application? Or what if you could use easy-to-remember names for your docker containers? SQL Client Aliases can help.
For the longest time, I managed these aliases using cliconfg for 64-bit applications (C:\Windows\System32\cliconfg.exe) or cliconfg for 32-bit applications (C:\Windows\SysWOW64\cliconfg.
Within dbatools, you may notice file sizes are pretty and human-readable.
That was some C# based magic created by Microsoft PFE and creator of PSFramework, Fred Weinmann. In the background, SQL Server often gives us different types of numbers to represent file sizes. Sometimes it’s bytes, sometimes it’s megabytes. We wanted to standardize the sizing in dbatools, and thus the dbasize type was born.
Usage This size type is cool because it looks beautiful, showing KB, MB, GB, TB and PB.
After nearly 10 months of work, early access to Learn dbatools in a Month of Lunches is now available from our favorite publisher, Manning Publications!
For years, people have asked if any dbatools books are available and the answer now can finally be yes, mostly 😊. Learn dbatools in a Month of Lunches, written by me and Rob Sewell (the DBA with the beard), is now available for purchase, even as we’re still writing it.
Some dbatools functionality that has not been talked about much on the blog are our internal configuration options. This functionality was added back in October 2017. Kind of like how in ADS or SSMS, you can go to File -> Preferences -> Settings or Edit -> Preferences to edit advanced preferences and options, you can do something similar in dbatools!
Since dbatools is command-line based, you can view/modify your current options using our various config commands.
Today’s article is part of T-SQL Tuesday. T-SQL Tuesday is the brainchild of Adam Machanic. It is a blog party on the second Tuesday of each month and everyone is welcome to participate.
This month’s T-SQL Tuesday is hosted by Tracy Boggiano (blog), is all about Linux.
dbatools and Linux As a long-time Linux user and open-source advocate, I was beyond excited when PowerShell and SQL Server came to Linux.
Hi, I am Gareth N - a SQL Server DBA in the UK. I have started to blog over at ifexists.blog - today I want to share some information around how dbatools can cache connection information, and how to reset it.
dbatools is smart. It can do things in the background when you’re using the commands, like cache connections and also cache the results of those connections. This can help speed things up as it will re-use the existing object.
We are so super excited to announce that after 5 long years, dbatools 1.0 is publicly available!
Our team had some lofty goals and met a vast majority of them 🏅. In the end, my personal goal for dbatools 1.0 was to have a tool that is not only useful and fun to use but trusted and stable as well. Mission accomplished: over the years, hundreds of thousands of people have used dbatools and dbatools is even recommended by Microsoft.
Recently, a colleague asked me to assist with the migration of some older, customized application databases to a SQL Server 2017 instance. Most of the migrations I perform are rather vanilla, but this one was a bit more involved.
Setup Imagine this scenario:
Source (APPSQL1) Dedicated SQL Server 2008 R2 failover clustered instance with a non-default collation (SQL_Latin1_General_CP1_CI_AI) Custom .NET application with an intense database containing a non-default collation (also SQL_Latin1_General_CP1_CI_AI), multiple CLR assemblies, and thousands of tables, views, stored procedures, functions Nearly 30 SQL Agent jobs, many of which had to be disabled over the years due to compatibility issues and scope changes Out-of-support for both Microsoft and the application vendor Destination (APPSQL2) Shared server SQL Server 2017 Default collation (SQL_Latin1_General_CP1_CI_AS) There was even a linked server in the mix, but our biggest concerns revolved around the changing collation and the Agent jobs, which were known to be brittle.
Today marks the 30 day countdown to dbatools 1.0, which we will be debuting at Data Grillen in Lingen, Germany! These next 30 days are important and I’m writing to ask for your help.
Integration Tests We could still use a hand getting in those last few Integration tests. If you’re interested in adding a couple tests, I did a quick lil livestream on Twitch about writing integration tests for dbatools that could be useful to you.
I am Andreas Schubert and I am working as a Principal Consultant and Database Reliability Engineer for SQL Server & Azure for multiple national and international companies. My focus is on implementing and operating complex 24/7 SQL environments with tens and hundreds of servers and multi-terabyte databases.
Welcome to a quick post that should help you operate your SQL Server environment more consistently and reduce manual, repetitive work.
The Problem When you are running SQL Server Availability Groups, one of the most cumbersome tasks is to ensure that all logins are synchronised between all replicas.
The Situation Hey all, I am Andreas Schubert and I am working as a Principal Consultant and Database Reliability Engineer for SQL Server & Azure for multiple national and international companies. My focus is on implementing and operating complex 24/7 SQL environments with tens and hundreds of servers and multi-terrabyte databases.
With the multitude of environments that I am operating, it’s impossible to remember every server, every database or the multiple different ways they are interacting with each other.
Recently, dbatools contributor Jess Pomfret teamed up with Bert Wager for a super cool video about dbatools.
Check it out!
They also wrote accompanying blog posts too! Jess wrote a post titled dbatools with Bert where she talks more in-depth about Backing up your databases and changing your recovery model. Bert penned a post titled Automating Database Maintenance with Jess Pomfret and dbatools 😄👍
How incredibly cool! Thank you Jess and Bert for the awesome and fun video 🍕
This post originally appeared in two parts on my personal blog at flxsql.com and has been reposted here by request.
A bit over a year ago, I blogged about my experience migrating a test SQL Server instance from a VM to a physical machine with a little help from my friends. That migration went well and the instance has been running trouble-free ever since. But it’s small potatoes. A modest instance, it’s only about 5% the size of production.
In this age of many companies adopting the ideas of either DevOps or SRE (Site Reliability Engineer) roles, there is constant need for automation. Mundane tasks like collecting metrics, alerts, server and database asset info into a central database on which you can do reporting is now a common task that many DBAs or system admins are performing.
In SQL Server world, we are fortunate to have a vibrant community of PowerShell enthusiasts that have open sourced dbatools - a community driven PowerShell module to automate database development and administration.
dbatools