PowerShell modules on every SQL Server

Reading Time: 3 minutes

Recently I’ve seen recommendations about putting PowerShell modules on every SQL Server. I must admit it has got me thinking if this is indeed worthwhile.

In addition, it makes me wonder if it’s actually better to put the Powershell modules on a select number of management servers instead?

If you are wondering which modules I could be talking about, I mention some in a previous post which you can read in detail here.

I’m going to look at this from various angles in this post.

Every SQL Server

I can see the appeal to put it on every SQL Server in certain situations.

Especially if you have a relatively small number of SQL Servers. Because the Powershell modules are easier to maintain for a small number of them.

In addition, if for some reason you must connect to the server remotely and run something locally it’s easier if the modules are on that server.

However, if the issue is on a new server that has been delivered it may be easier to create a new server instead. Especially if you are deploying servers using a delivery pipeline.

Different Operating Systems

Another thing to consider is that you might end up managing SQL Server running two Operating Systems. Both Windows Server and Linux.

Managing updates for both Operating Systems could introduce more complexity.

Management servers

However, from a manageability perspective installing them on a select number of management servers has its advantages. For instance, it makes version control for them easier.

In reality, it’s a lot easier to update the PowerShell modules on a handful of servers instead of hundreds or even thousands.

In addition, the more servers you must update your PowerShell modules on the more potential there is for issues. For instance, issues due to permissions, firewall settings, etc.

Team laptops

Now if you work as part of a team you can end up having the modules running on your own laptops.

If you are doing this than you are probably running the modules when needed. In addition, running all the scripts locally.

Now, there are some advantages to doing this. For example, portability because you can all work on scripts when you are not connected to the network.

However, it does mean that you could run into potential issues if you have different versions of the same modules.

In addition, if you want to introduce some level of automated deployment using PowerShell you will need to have the modules somewhere on your network.

One good idea if doing this is to also have the modules on a select number of management servers as well.

Laptop

Now, if your estate is relatively small you may even only manage the PowerShell modules on your own laptop.

I can see the appeal of this because it means that you only must manage one set of modules.

However, it does mean that every time you change your laptop you must make sure you install the relevant modules again.

In addition, it does restrict where you can run your PowerShell cmdlets from. Because they are only on your local machine.

Final word

I’m certainly curious to know where people stand with this. For instance, do you install all your PowerShell modules on every SQL Server?

Alternatively, do you keep your PowerShell modules updated on a select number of management servers or your own computer instead?

I’m sure others are keen to know as well, so please feel free to comment about how you use Powershell modules below.