Taking dbatools further

Posted On: In: Powershell

Last week I wrote about how I was getting started with dbatools a lot has happened since then, I mean I have done some more reading and tried a few new things and I wanted to expand on some of the really cool things this module can do.

Tables here, tables there

Some times for whatever reason I need to be able to script a table out, this involves loading up SSMS, connecting to the instance, getting to the database, right clicking…you get the idea it is a long drawn out task, but what if I could do that with just one line of code? Well with dbatools I can do just that, let’s have a look.

So the script has executed, but what exactly has it done? If I navigate to C:\temp\tables and open up so-users.sql I will find the following;

Now I can take this and run it on another server.

I can also use the following, which will specify specific options for the export including adding the database context into the exported script.

Table Data

In some situations, I may need to get all of the reference data from one table and load it into another, however just like scripting out the table I need to load up SSMS, connect to the instance, find the database it is quite an involved task. Let’s see how we can do this with dbatools.

The script finished, and in C:\temp\tables there is a file called so-users-data.sql just like what I asked for, I can now take this script to another server run it and import all of the data into another table with the same schema. 

I could even go one further and just copy the data directly from PowerShell, at the moment my destination table is empty, it resides on the same server as the source table inside the same database.

If I execute the following line of code

dbatools is going to go and get all of that data, and copy it into the new table, just like I asked

But is the data actually there?

Of course, it is!

Copy Copy Copy

So I just got my new SQL Server from the infrastructure team but I want to move some jobs and alerts maybe even some database mail configuration from another server in the estate to this one. Of course, I could script out each object individually or, yep you guessed it, I could use dbatools to copy them from the existing instance to the new one.

Let’s see how I can do this with dbatools for various objects within the instance.

Agent Operator

Agent Operators are useful for notifications when jobs fail or when an alert is triggered, but sometimes I need to make sure the same operator exists on every server. With dbatools this is really easy.

If I want to copy the operator to more than one server all I need to do is comma separate the servers passed to the -destination flag.

If the operator already exists on the destination but I would like to replace it with the one from source all I need to do is pass the -force flag which will drop the operator from the destination before copying it, which is demonstrated below.

Agent Jobs

I have a situation quite often where people outside of the team I work will load up a SQL Agent Job onto one of the Availability Group (AG) members and fail to add it to one of the secondary members when the AG fails over the job doesn’t run as it doesn’t exist.

To fix this, I have to script the job out, take the T-SQL that the scripting function in SSMS creates and run it onto the server where the job is missing, it all takes a little bit of time, however with dbatools I can simplify this and do it with just one line

I want to copy the dbatools test job from localhost\sql2016 to localhost\sql2014

The job has been successfully copied from localhost\sql2016 to localhost\sql2014

Now then, let’s say that your job has a notification setup, when it fails I want an operator to be notified, what if that operator doesn’t exist on the destination server? Well, let’s find out.

As you can see dbatools will not copy the job as it has a dependency, pretty neat huh.

Database Mail

In a lot of cases, the database mail profiles and accounts that are in use across the estate I manage are the same, I need the same database profiles & accounts on every server I manage but setting them up takes time. We can simplify this with dbatools by copying all of the profiles & accounts from an existing server to a server with no database mail.

In this configuration I have purposely configured one of our SQL Server instances to have no database mail configuration, as shown below

I want to copy all of the database mail configurations from an existing server in the estate to this instance. Word of warning though, by default, copy-dbadbmail will copy all database mail accounts and profiles.

Now if I go back to SSMS I will see that all the database mail configuration has been copied


Sometimes I need to copy all or some of the logins from one server to another, you can do that with dbatools

If I hope into C:\temp\cred.sql I will see that the SID is even copied which is great for Availability Group situations where I need the same SQL Account with the same SID spread over multiple availability group members.

However, let’s say I want to export just one login from the server this can be done with the following line of code

What about multiple accounts? They can be passed to -login with a comma, separating each login as shown below.

It is also worth noting, if you don’t want your logins to be overwritten each time you execute this command, specify the -append flag and dbatools will pop the logins onto the end of the existing file, but if the login already exists in the file dbatools will not tell you about it, it will just keep adding.


This one is really cool! So I have a database on servera (localhost\sql2014) that I need to copy to serverb (localhost\sql2016) maybe for some testing or some other scenario.

As you can see bwlow the database exists on servera but not on serverb

To copy if we need to execute one line of code

What has happened behind the scenes here is that dbatools has taken a copy only backup of the MigrationTest database and popped it into C:\temp\migration it has then taken that backup and restored it to the specified destination which in this case is serverb, I am able to see that it was successful by looking directly inside SSMS

Once dbatools was happy that the restore had completed successfully, the backup that it initially took is removed unless you explicitly tell it not to delete it by passing the -NoBackupCleanUp flag.

In a production environment the -SharedPath will need to be a valid UNC path accessible by both instances.

Note: You can only copy a database from a SQL Server instance which has a version less than or equal to the version of the SQL Server you are restoring to. You can’t copy a database from a SQL Server with a version greater than the version of the SQL Server you are restoring to.

The Wrap Up

I really think that dbatools is going to find a home in my day to day toolkit, once I learn a little bit more about how various part of it work and how it can solve some of the common problems I am faced with on a daily basis I will be sure to get it onto my work laptop.