Now I'm doing some live real‑world troubleshooting with you because
I guarantee you're going to see this as well.
So let's take a look.
When I ran this command, we first got a deprecation warning.
So I intentionally included the old include language when
include_tasks is the more descriptive and accurate one.
So we can fix‑‑‑ That's not an error, but that's a warning,
and we can fix that by coming back into our main.yml for
our tasks and make that include_tasks.
Let me save that. Regarding the error, couldn't resolve the
module in action ansible.windows.win_timezone.
So it could be a misspelling, a missing collection.
Do you have win_timezone installed?
And we can use ansible‑doc ‑l for that.
We could,
if perchance we might not have installed the ansible.windows collection,
here's another case where we can use ansible‑galaxy actually.
Ansible‑galaxy collection install ansible.windows.
It's already installed here, but that's something to keep in mind.
Easy.
Collection is a gathering of modules and roles.
It's the highest‑level abstraction unit when it comes to these units of work.
I think the error with win_timezone is that Ansible was getting
confused with my calls to fully qualified module names.
I probably shouldn't have done that.
It's really just enough to give the name.
And as long as Ansible knows where to find the modules,
it's good to go as far as that goes.
So now I've got just win_feature, win_timezone, and template.
Again, let me save that change,
and let's come back where I've got the ansible‑playbook role running already,
so ansible‑playbook prepare_web_server.
We're gathering tasks.
Who are we targeting here?
We are targeting in our prepare_web_server,
it looks like right now we're operating on just my node1 machine,
not all of them in the inventory.
And what's cool about this process is that after the
Windows features are installed, if a reboot is required,
and also that applies to updating the system.
If a reboot is required,
that's absolutely going to happen because in our Windows Server role,
if we take a look at it again and go under handlers,
we've got this call to, again, and I'll fix this by making it just win_reboot.
The win_reboot module will issue a console message,
wait 5 seconds, and go for it.
And after reboot, wait 60 seconds to reevaluate.
And by the way,
a common place to put your module file or to verify that your
module file is in the correct location, it's in your ansible.cfg file.
You'll want to set the library property.
So this is a colon‑separated path list where Ansible will search for modules.
And you may want to override or just leave with what Ansible actually uses.
Okay, so to look at the recap, just in summary,
we've got three ok operations, one change,
one fail.
I want to go immediately to the failed task.
It looks like updating the system timezone failed because the
timezone that I specified isn't valid in Windows.
That makes sense.
I should have just specified UTC.
So this would be a good example of idempotency actually to
where we can go back to our work file.
First of all,
let me right‑click and close all my editor tabs and
let's go back into the Windows server.
Let's go back into our defaults.
And let me change this to UTC.
And then, again, in the name of idempotency,
we can just simply rerun that playbook.
And any configuration that it's already performed on the machine
will take place and any that it has yet to do.
In fact, you can just see that,
that the web server and ASP.NET roles were already
successfully installed, so it passed right over that.
And now the system timezone update is passed successfully
because I corrected it in the source.
And now we're able to continue to the deploy configuration file.
I don't actually remember whether this task completed
successfully previously or not.
We'll find out momentarily for sure.
All right, well, yet again, we see another failure.
This is fine.
This is telling us that the destination directory
C:\config does not exist on the host.
So this would be very much akin to my real‑life work.
And I could either manually touch the directory and create it
on the machine, or I could add an entry using, say, win_file
in the playbook to create it.
Or I could add logic. If the config folder doesn't exist,
add it. All of this is eminently reachable and doable.
What I'm doing because I'm running out of time on my demo is that I
opened up PowerShell on my domain controller,
ran a new item to create that directory on the remote node, and
then I can up arrow and try this one more time.
I want this to complete successfully. And there we
have it, mission accomplished.
Looks like we don't need to reboot in this case. Updates are
all installed. Our config file, no problem.