Many of us, Windows Admins and DBAs struggle with automation. We often cobble together PowerShell and T-SQL scripts to manage our environments, or worse, we remote into machines to perform repetitive tasks manually.  These approaches create problems:

• Scripts become difficult to maintain
• Documentation falls behind
• New team members struggle to understand the automation framework

There's a better way.

I want to introduce you to another automation tool you may be unfamiliar with. 

Ansible. 

In this post, I'll explain why Ansible is worth considering for Windows and SQL Server automation.

What Makes Ansible Different?

Unlike traditional Windows automation tools, Ansible takes a different approach.  It uses a Linux control node (or macOS) to manage your Windows environments.  An easy way to get started is to use Windows Subsystem for Linux and the Ubuntu distribution.  No need to become a Linux expert.  The control node connects to your Windows servers using protocols you're already familiar with: WinRM or SSH.

Here's what makes Ansible stand out:

• No agents to install on your Windows servers.
• Uses simple YAML files that read like plain English.
• Handles both Windows and Linux servers from one tool.
• Manages configurations, deployments, and updates consistently.

Why This Matters?

Ansible fits in the following two areas of the "as Code" concepts:

• Infrastructure as Code (IaC) - Automates provisioning and consistency checks.
• Configuration as Code (CaC) - Storing application or service configurations (e.g., database settings, environment variables, SQL Server configurations) in version-controlled code so that deployments are repeatable and consistent.  

It doesn't matter if you're supporting an entirely on-premises environment, cloud environment, or both.  Ansible can be utilized to manage all three scenarios.  Storing environment definitions in source control aligns devs, ops, and DBAs on a single source of truth.

Breaking Down Silos

We work in silos, creating scripts and automation processes using languages unique to us.  For example, Windows sysadmins may rely solely on PowerShell, whereas DBAs may rely on T-SQL, PowerShell, and well-known modules such as dbatools. When a DBA needs to provision new SQL Servers, they often have to coordinate with Windows admins, network teams, and storage teams - each using their own tools and processes. 

Ansible helps to break down these silos. 

But it does so without requiring these roles to do away with their well-established toolset. Using a common tool across all of these roles, along with Linux, network, and storage administration, allows the organization to become more efficient, remove silos, and dramatically reduce deployment times. For example, what used to take 4-5 hours to set up and configure a single SQL Server instance can now be done in minutes - and you can deploy multiple instances simultaneously. This kind of efficiency becomes crucial when scaling your environment or recovering from failures.

Conclusion

Windows administrators and DBAs have been slower in adopting IaC and CaC concepts. This has led us to think of our servers as pets instead of cattle. This impacts how fast we can replace a system because most are considered "special cases," making them difficult to rebuild.

Want to learn more? Check out Ansible-core or read what others say about Ansible Automation Platform on Gartner.

How about you? Are you thinking of your servers this way, or are you considering tools like Ansible to scale and build environments for your organization easily?