Lab Guide: Standardized System Consistency

A guide to using pre-built Ansible playbooks and workflows to deploy and configure environments consistently.

Scenario: Standardized Consistency

Ready to perform some automation? Your team has been given a new environment to configure. Luckily, various technology teams have already provided playbooks to get the job done. You will use these templates to deploy and configure everything consistently.

First, log into the Ansible Automation Platform instance using the credentials below. Your DNS domain for this lab is lab.{dns_domain}.

Table 1. Login Credentials
Username	`admin`
Password	`ansible123!`

Table 2. Server FQDNs
Server	FQDN
Domain Controller	`windows.lab.{dns_domain}`
Dev Windows Server	`dbserver.lab.{dns_domain}`

Baseline Configuration and Applications

A support ticket has arrived requesting configuration updates for two Windows servers in the UAT environment. The request involves deploying standard applications and making specific registry changes. You will use a workflow template to tie multiple jobs together and address the entire request in a consistent, repeatable process.

Create the "Windows Apps and Settings" workflow.

Navigate to Automation Execution → Templates. Click the Create template button and select Create workflow job template. Configure it with the following details:
- Name: Windows Apps and Settings
- Description: Required Applications and Settings
- Organization: Default
- Inventory: Windows Servers
  
  Click Create workflow template to open the Workflow Visualizer.
Add the first node (Registry Keys).

Click Add Step to open the side panel. Configure the first node as follows:
- Node Type: Job Template
- Job Template: Windows Registry keys
- Convergence: Any
  
  Click Next, then Finish.
Add the second node (Server Applications).

Hover over the node you just created, click the ... menu, and select Add step and link. Configure the second node as follows:
- Node Type: Job Template
- Job Template: Windows Server Applications
- Status: Always run
- Convergence: Any
  
  Click Next, then Finish. Finally, click Save in the top right of the Visualizer to save the entire workflow.
Launch the workflow.

Navigate back to Automation Execution → Templates and launch the Windows Apps and Settings workflow you just created.
Observe the workflow in action.

In the Output view, you can see the progress as each job template runs in sequence.

Once the workflow is complete (after 3-4 minutes), click on the Windows Server Applications node and review the job output. You can verify that packages like windirstat and 7zip were installed.

Configuring the Windows Domain Controller

A new request has arrived to configure a Windows server as a domain controller. Your Windows SMEs have provided a Job Template to ensure the deployment is consistent and compliant.

Verify the server’s initial state.

Navigate to the windows tab in your lab environment. On the Windows Server desktop, open Server Manager, select Local Server, and verify that the server is part of the default WORKGROUP.

Add the Vault Credential to the Job Template.

Navigate to your aap tab. Go to Automation Execution → Templates and edit the Windows Domain Controller template. The Windows team has supplied an Ansible Vault to securely store the Active Directory credentials.

In edit mode, click on Credentials and add the Windows Vault credential. By using a vault, you can run the job without ever seeing the sensitive passwords directly.

Save the job template after adding the credential.

Adding a vault credential to a job template

Launch the Job Template.

Launch the Windows Domain Controller job template. As the job runs, it will display the domain it is configuring. Be sure to note this domain name.

This process will take several minutes to deploy Active Directory and reboot the system. You can proceed to deploy the RHEL node. You will need the Active Directory for the next module.
Verify the final state.

Once the Windows server has rebooted, return to the windows tab and open Server Manager. You should now see that the server is part of the new domain and that the AD DS and DNS services are running.

Provisioning a New RHEL Server

Now that your Windows infrastructure is set, the next step is to deploy a RHEL system for your streaming applications using a standardized template.

Observe the initial inventory state.

Navigate to Automation Execution → Infrastructure → Inventories and select the Video Platform Inventory. Notice that it currently only contains a loadbalancer group.
Deploy the new node.

Navigate to Automation Execution → Templates and launch the Deploy Node template. When prompted by the survey, enter the node name node01 and submit the job.

This is a simulated provisioning task. In a real-world scenario, you could customize the instance configuration.
Observe the final inventory state.

Once the job is complete, return to the Video Platform Inventory. You will see that a webservers group has been added, containing your new node01.

Appendix: Code Snippets

If you’re interested, here are some key code snippets from the playbooks used in this lab.

Installing Windows Applications with Chocolatey

tasks:
- name: Ensure Chocolatey is installed
  win_chocolatey:
    name: chocolatey
    state: present

- name: Install multiple packages sequentially
  win_chocolatey:
    name: '{{ item }}'
    state: present
  loop:
    - windirstat
    - 7zip
    - git
    - python

- name: Check python version
  ansible.windows.win_command: python --version
  register: check_python_version

- name: Show python version
  ansible.builtin.debug:
    msg: Python Version is {{ check_python_version.stdout_lines[0] }}

Promoting Windows to a Domain Controller

- name: Ensure local Administrator account has a password
  ansible.windows.win_user:
    name: "{{ username }}"
    password: "{{ user_password }}"

- name: Promote system to a domain Controller
  microsoft.ad.domain:
    dns_domain_name: "{{ wins_domain }}"
    safe_mode_password: "{{ safe_password }}"
    domain_mode: Win2012R2
    forest_mode: Win2012R2
    reboot: true

- name: Firewall rule to allow RDP on TCP port 5986
  win_firewall_rule:
    name: WinRM
    localport: 5986
    action: allow
    direction: in
    protocol: tcp
    profiles: domain,private,public
    state: present
    enabled: yes

Troubleshooting

If you have encountered an issue or have noticed something not quite right, please open an issue on GitHub.