So far so good.
And I'm going to right‑click and create a new file called test_pb.yml.
How's that?
And I'm going to throw that code into that file.
Good deal.
So what does this mean?
Well, I want to end this demo doing some real work.
It's enough we've got our system.
I know we've got some work to do on that one host to get it ping ponging.
But we're going to continue marching forward. And I've got this use case
where these machines need to have that print spooler stopped.
They need to have an environment variable in memory to do certain jobs.
And just, by the way, our compliance people need to know the auto start.
And so, this is an exact great example of why the playbook is the solution.
It is the heart and soul of Ansible.
And using this YAML format, we start the file and then we determine,
in this particular example, the playbook is going to have three plays.
Now this is actually‑‑‑ I would want to go back and forth with GitHub
Copilot a little bit because I'd want these to have names.
So this is a good example of where turning to AI you, as a
human, want to step behind the AI and see,
okay, maybe we need to refine this a little bit. We probably do.
But what this ultimately does is, in these three plays,
it invokes various modules, in this case built‑in modules.
And it's going to go through and perform each one of those
tasks using some, again,
some module. Win_environment is the built‑in module that
allows you to manage environment variables.
Win_service is for managing services, obviously enough.
And if we're going to print auto starts,
it would make sense, at least Ansible thinks it makes sense, to do a win_shell.
In other words,
send a PowerShell command that will actually tap into the CIM
database on that machine and compile a report for you.
That's pretty handy, isn't it?
So the idea is once you've got that playbook, you know who you're going to hit.
In this case, all three of these plays are targeting the control group.