Tag: Infrastructure

Centralized Logging for Windows and Linux: A Practical Blueprint for IT Ops

Centralized Logging for Windows and Linux: A Practical Blueprint for IT Ops

When something breaks at 02:13 AM, logs are either your best friend—or completely useless.

In mixed environments (Windows + Linux + on-prem + cloud), logs are often:

  • scattered across servers,

  • overwritten too quickly,

  • inaccessible during incidents,

  • or never reviewed until after an outage.

A centralized logging strategy transforms logs from passive files into an operational control system.

This guide outlines how to design a scalable, secure, and useful logging architecture for real-world IT environments.

Why Centralized Logging Is Not Optional Anymore

Incident response speed

Without centralized logs:

  • You SSH/RDP into multiple machines.

  • You manually grep or search Event Viewer.

  • You lose precious time correlating events.

With centralized logging:

  • You search once.

  • You correlate across systems instantly.

  • You reduce Mean Time To Resolution (MTTR).

Security visibility

Modern attacks move laterally.
If logs stay local, detection becomes nearly impossible.

Central logs enable:

  • suspicious login pattern detection

  • privilege escalation tracing

  • anomaly identification across hosts

Compliance and audit

Many standards require:

  • log retention policies

  • tamper-resistant storage

  • traceability of admin actions

Step 1: Define What to Log (Not Everything Is Equal)

Logging everything blindly leads to noise.

Windows (Recommended Sources)

  • Security Event Logs (logon events, privilege use)

  • System logs

  • Application logs

  • PowerShell logs (script block logging)

  • Sysmon (for deeper visibility)

Linux (Recommended Sources)

  • auth.log / secure

  • syslog / journald

  • sudo logs

  • SSH logs

  • application-specific logs (nginx, apache, docker, etc.)

Key Principle

Log based on:

  • security relevance

  • operational value

  • troubleshooting frequency

  • compliance needs

Step 2: Choose an Architecture Model

Option A: Agent-Based Collection

Each server runs a lightweight agent:

  • forwards logs securely

  • buffers during outages

  • supports filtering and parsing

Pros:

  • reliable delivery

  • fine-grained control

Cons:

  • agent lifecycle management required

Option B: Agentless / Pull-Based

Central system pulls logs via:

  • Windows Event Forwarding (WEF)

  • Syslog forwarding

  • API-based integrations

Pros:

  • fewer components per host

Cons:

  • less flexible filtering

  • scaling challenges in large environments

In most real infrastructures, agent-based models scale better.

Step 3: Standardize Log Structure

If Windows logs and Linux logs look completely different, correlation becomes painful.

Normalize Fields

Ensure consistent fields such as:

  • hostname

  • environment (dev/stage/prod)

  • IP address

  • user

  • severity

  • timestamp (UTC strongly recommended)

Add Context

Tag logs with:

  • service name

  • business criticality

  • region

  • patch group or cluster

Context is what turns logs into intelligence.

Step 4: Secure the Logging Pipeline

Logs contain sensitive data:

  • usernames

  • internal IPs

  • command history

  • sometimes secrets (misconfigured apps)

Security Requirements

  • TLS encryption in transit

  • role-based access control

  • separation of admin vs read-only roles

  • immutable or append-only storage

  • log retention policies

Protect Against Log Tampering

Attackers often:

  • delete logs

  • modify local log files

  • disable logging services

Centralized and restricted storage prevents this.

Step 5: Retention and Storage Strategy

Define retention by tier.

Example:

  • Security logs: 180–365 days

  • Operational logs: 30–90 days

  • Debug logs: short-term (7–14 days)

Consider:

  • storage cost vs compliance

  • hot vs cold storage

  • searchable vs archived logs

Step 6: Build Operational Use Cases

Logging is useless without queries and alerts.

Operational Use Cases

  • Service crash detection

  • Repeated restart loops

  • Disk error patterns

  • Failed scheduled tasks

Security Use Cases

  • Multiple failed login attempts

  • Admin group membership changes

  • New service installation

  • Suspicious PowerShell execution

Create dashboards per:

  • infrastructure tier

  • business service

  • security monitoring

Step 7: Avoid Common Logging Mistakes

Logging without monitoring

Collecting logs without alerts or dashboards = expensive storage.

Over-collecting

Too much noise hides real signals.

No ownership

Define:

  • who reviews alerts

  • who maintains parsers

  • who manages retention policies

Logging must be part of operations—not an afterthought.

Conclusion

Centralized logging is not a “SIEM project.”
It is core infrastructure hygiene.

Done correctly, it provides:

  • faster incident response

  • stronger security posture

  • audit readiness

  • operational clarity

Logs are not just records.
They are your infrastructure memory.

Secrets Management in DevOps — From .env Files to Enterprise-Grade Control

Secrets Management in DevOps: From .env Files to Enterprise-Grade Control

API keys. Database passwords. SSH private keys. OAuth tokens.
Secrets are everywhere in modern infrastructure—and they are one of the most common breach vectors.

In many environments, secrets still live in:

  • .env files

  • CI/CD variables

  • shared password managers

  • copied Slack messages

  • or worse… Git repositories

As infrastructure scales, this approach becomes dangerous.

This guide explains how to evolve from ad-hoc secret handling to structured, auditable, and secure secrets management—without breaking pipelines or slowing teams down.

Why Secrets Become a Hidden Risk

1) Secrets Spread Faster Than Code

Developers copy:

  • .env files between machines

  • API tokens into scripts

  • credentials into automation workflows

Soon, you lose track of:

  • where secrets are stored

  • who has access

  • which ones are still valid

2) Long-Lived Credentials = Long-Term Risk

Static secrets:

  • rarely rotated

  • shared across environments

  • reused in multiple systems

If leaked once, they remain valid until manually revoked.

3) Automation Amplifies Exposure

CI/CD pipelines, infrastructure-as-code, and workflow tools (like n8n) increase the number of systems that require credentials.

More automation = more secret sprawl if unmanaged.

The Principles of Modern Secrets Management

A mature approach is based on five principles:

1) Centralization

Secrets must live in a centralized secret store, not:

  • Git

  • local files

  • environment variables scattered across hosts

Centralization provides:

  • single control point

  • audit logs

  • policy enforcement

2) Least Privilege Access

Each system or service should only access:

  • the specific secret it needs

  • for the minimum duration required

Not:

  • “full access to all secrets in prod”

3) Short-Lived Credentials

Instead of static credentials:

  • use dynamic, time-limited secrets

  • generate database credentials on demand

  • issue temporary cloud tokens

If compromised, the blast radius is limited.

4) Automatic Rotation

Rotation should be:

  • scheduled

  • automated

  • transparent to applications

Manual rotation does not scale.

5) Full Auditability

You should be able to answer:

  • Who accessed which secret?

  • From which system?

  • At what time?

  • For what purpose?

If you can’t answer this, you have governance gaps.

Practical Architecture for DevOps Teams

You don’t need a massive transformation to improve security.

Phase 1: Remove Secrets from Git

  • Scan repositories for leaked credentials

  • Revoke exposed secrets immediately

  • Replace with environment injection from a secure store

This is the fastest risk reduction step.

Phase 2: Introduce a Central Secret Store

Adopt:

  • Vault-style systems

  • Cloud-native secret managers

  • Encrypted secret backends integrated with CI/CD

All pipelines should fetch secrets at runtime—not store them permanently.

Phase 3: Implement Dynamic Secrets for High-Risk Systems

Especially for:

  • databases

  • cloud IAM roles

  • production SSH access

  • automation service accounts

Dynamic credentials dramatically reduce breach impact.

Phase 4: Secure Automation Platforms (Including n8n)

Automation tools often become secret hubs.

Best practices:

  • store credentials in encrypted backend

  • restrict workflow-level access

  • separate dev/stage/prod secrets

  • audit workflow changes

  • restrict export permissions

Automation must not become a secret leakage vector.

Common Anti-Patterns

“Base64 encoding is enough.”

It is not encryption.

“Only Dev has access, so it’s safe.”

Internal threats and compromised laptops are real risks.

“We rotate once per year.”

In modern threat models, that is effectively static.

Incident Reality: Secrets Leak

When—not if—a secret leaks:

  1. You must detect it quickly.

  2. You must rotate immediately.

  3. You must understand blast radius.

  4. You must audit historical usage.

Without centralized management, this becomes chaos.

With structured secrets management, it becomes a controlled response.

Conclusion

DevOps accelerates delivery—but unmanaged secrets accelerate breaches.

Mature secrets management enables:

  • safer automation

  • reduced blast radius

  • audit-ready infrastructure

  • stronger Zero Trust posture

You don’t need perfection to start.
You need centralization, rotation, and visibility.

From .env files to enterprise-grade control—this is one of the highest ROI security upgrades any infrastructure team can implement.

GitOps for Infrastructure Teams: From Manual Changes to Declarative Control

GitOps for Infrastructure Teams: From Manual Changes to Declarative Control

Infrastructure teams are under constant pressure: faster deployments, tighter security, more environments, more automation. Yet in many organizations, infrastructure changes still happen through SSH sessions, manual edits, and undocumented tweaks.

This is where GitOps changes the game.

GitOps is not just for Kubernetes-native startups. It is a powerful operating model for infrastructure, security baselines, configuration management, and even automation workflows.

This article explains how infrastructure teams can adopt GitOps pragmatically—without disrupting operations.

What Is GitOps (Beyond the Buzzword)?

At its core, GitOps means:

  • Git is the single source of truth

  • Desired system state is declared in code

  • Changes happen via pull requests

  • Automation reconciles actual state to desired state

  • Drift is detected and corrected automatically

It replaces:

  • “I logged into the server and changed it”
    with:

  • “I submitted a PR that changed the declared state”

Why Infrastructure Teams Struggle Without GitOps

1) Configuration Drift

Two servers built from the same template end up different over time.

Manual fixes, hot patches, and undocumented changes create invisible risk.

2) No Change Traceability

When an incident happens:

  • Who changed the firewall rule?

  • When was that service modified?

  • Why was that port opened?

Without Git history, answers are guesswork.

3) Security Blind Spots

Manual changes often bypass:

  • peer review

  • policy checks

  • security scanning

This creates compliance and audit risks.

Core Components of GitOps for Infra

You don’t need to start with Kubernetes to do GitOps.

1) Infrastructure as Code (IaC)

Use declarative tools like:

  • Terraform

  • Ansible (declarative mode)

  • Pulumi

  • CloudFormation

Infrastructure becomes version-controlled code.

2) Pull Request Workflow

Every change:

  • goes through PR

  • is reviewed

  • is validated automatically

  • is merged only if compliant

This adds:

  • accountability

  • collaboration

  • rollback capability

3) Automated Reconciliation

Automation ensures the real environment matches Git.

Examples:

  • CI/CD pipelines apply Terraform

  • Scheduled drift detection jobs

  • Controllers continuously reconciling state

No more silent drift.

GitOps in Real Infrastructure Scenarios

Scenario 1: Firewall Changes

Old way:

  • SSH into firewall

  • Add rule

  • Forget to document it

GitOps way:

  • Modify firewall rule in code

  • PR reviewed

  • Automated validation checks policy

  • Change applied through pipeline

  • Audit trail preserved

Scenario 2: Linux Server Baseline Hardening

Instead of manually:

  • disabling services

  • editing sysctl

  • adjusting SSH configs

Define:

  • baseline role in Ansible

  • security profile in code

  • versioned config

Drift detection alerts if someone changes settings manually.

Scenario 3: n8n Workflow Deployment

Even automation platforms benefit from GitOps.

Instead of:

  • editing workflows directly in UI

You:

  • export workflows as JSON

  • store in Git

  • review changes

  • deploy via pipeline

Now automation itself is controlled and auditable.

The Security Benefits of GitOps

1) Least Privilege Enforcement

Direct production access can be reduced:

  • Engineers don’t need SSH for routine changes.

  • Pipelines execute approved changes.

2) Audit-Ready by Design

Git history becomes:

  • change log

  • approval record

  • rollback mechanism

3) Faster Incident Recovery

Rollback = revert commit + pipeline run.

No guessing what “used to work.”

A Practical Adoption Roadmap

Phase 1: Version Everything

  • Move infra configs to Git

  • Protect main branch

  • Enforce PR reviews

No automation changes yet—just discipline.

Phase 2: Add Automated Validation

  • Linting

  • Policy-as-code checks

  • Security scanning

  • Plan previews (e.g., Terraform plan in PR)

Phase 3: Restrict Manual Production Changes

  • Limit direct SSH

  • Require pipeline for infra updates

  • Monitor drift

Phase 4: Continuous Reconciliation

  • Scheduled drift detection

  • Automated correction (where safe)

  • Alerting on unauthorized changes

Common Mistakes

“GitOps means no humans touch prod.”

Not realistic. Break-glass access must exist—but logged and controlled.

“We need Kubernetes first.”

False. GitOps is an operational model, not a platform requirement.

“It slows us down.”

Initially, yes.
Long term: fewer outages, faster rollbacks, stronger security.

Conclusion

GitOps is not about tools.
It’s about control, visibility, and repeatability.

For infrastructure teams, it means:

  • fewer midnight surprises

  • better audit posture

  • safer automation

  • and less reliance on fragile tribal knowledge

Manual changes scale chaos.
Declarative control scales stability.

Zero Trust SSH: Hardening Linux Access Without Breaking Operations

Zero Trust SSH: Hardening Linux Access Without Breaking Operations

SSH is still the backbone of Linux operations—incident response, patching, break-glass access, automation, and day-to-day administration. But in many environments, SSH access is treated as a binary switch: either “you can log in” or “you can’t.” That model doesn’t scale in modern organizations where identities change, devices roam, and the blast radius of compromised credentials is massive.

A “Zero Trust” approach to SSH doesn’t mean you stop using SSH. It means you stop trusting networks, long-lived keys, and static access by default—and start validating identity, device posture, intent, and session context every time.

This guide shows a practical hardening path you can roll out incrementally—without crippling your on-call team or breaking automation.

What “Zero Trust” Means for SSH

In practice, Zero Trust SSH is built on four principles:

1) Strong identity over static credentials

Prefer short-lived credentials tied to a real identity and centralized policy.

2) Least privilege by default

Access is constrained to the minimum commands, hosts, time windows, and environments.

3) Continuous verification

Authentication is necessary, but not sufficient—authorization, posture, and session behavior matter too.

4) Auditability and revocability

You should be able to answer: Who accessed what, when, why, from where, using which device—and what did they do? And you should be able to revoke access instantly.

Baseline Hardening in sshd_config (Low-Risk, High-Impact)

Start by making SSH safer without changing workflows.

Disable password auth (or phase it out)

Passwords are phishable and reused.

  • Target state: PasswordAuthentication no

  • Transition: restrict password auth to a bastion or limited group temporarily.

Disallow root SSH login

Require named accounts + privilege escalation.

  • PermitRootLogin no

Reduce attack surface

  • AllowUsers / AllowGroups to explicitly constrain who can log in

  • MaxAuthTries 3

  • LoginGraceTime 30

  • X11Forwarding no (unless truly needed)

  • AllowTcpForwarding no (enable only for specific roles)

  • PermitTunnel no (unless required)

Use modern cryptography

If you maintain older systems, align carefully, but aim for modern KEX/ciphers/MACs and disable legacy algorithms.

Key Management: Stop Treating Keys as Forever Credentials

Traditional SSH keys tend to live for years, get copied between laptops, and are rarely rotated. That’s the opposite of Zero Trust.

Use short-lived SSH certificates (preferred)

Instead of distributing public keys everywhere, you issue SSH certificates that expire (e.g., 8 hours).

  • Central authority signs user keys.

  • Servers trust the CA.

  • Revocation becomes manageable (short TTL + CA policy).

Operational win: You don’t have to chase keys on every server. You control access centrally.

If you must use authorized_keys, lock them down

At minimum:

  • Enforce key rotation (e.g., quarterly)

  • Ban shared keys

  • Ban copying prod keys to personal devices

  • Add from= restrictions when feasible

  • Use separate keys per environment (dev/stage/prod)

Identity-Aware Access: Tie SSH to Your SSO and MFA

SSH should not be the last holdout that bypasses MFA.

Options to achieve MFA + centralized policy

  • Identity-aware proxies / gateways for SSH

  • SSO-integrated access platforms

  • PAM modules and centralized authentication stacks

Goal: When a user leaves the company, access is gone instantly. No lingering keys.

Device Posture: Not All Laptops Are Equal

Zero Trust assumes compromise is possible—so you validate the client, not just the user.

Practical posture checks for SSH access

  • Corporate-managed device requirement for prod

  • Disk encryption enabled

  • EDR running

  • OS patch level within policy

  • MDM compliance state

Even if your SSH stack can’t enforce posture natively, you can enforce it at the access gateway/bastion layer.

Authorization: Don’t Grant Shell When You Only Need a Command

Many operational tasks don’t require full shell access.

Use role-based access patterns

  • Prod read-only role for logs/metrics checks

  • Deployment role limited to CI/CD runners or restricted commands

  • Break-glass role time-bound and heavily audited

Command restriction patterns

  • sudo with tight sudoers rules

  • ForceCommand for narrow workflows

  • Separate service accounts for automation with scoped permissions

Result: even if a credential leaks, the attacker doesn’t get free roam.

Session Controls: Recording, Auditing, and Alerting

Hardening isn’t only about preventing access—it’s also about detecting misuse.

Minimum viable auditability

  • Centralize SSH logs (auth + command where possible)

  • Forward to SIEM

  • Alert on:

    • new source IP / geo anomaly

    • unusual login times

    • first-time access to sensitive hosts

    • repeated failed logins / brute patterns

Session recording (for sensitive environments)

For prod and privileged roles, session recording can be a game-changer—especially in regulated environments.

Automation & CI/CD: Secure SSH Without Breaking Pipelines

Automation is often the reason teams avoid tightening SSH. The key is to treat automation identities properly.

Use distinct machine identities

  • Separate credentials per pipeline / per environment

  • Don’t reuse human keys for automation

Prefer ephemeral credentials for runners

  • Short-lived certs or tokens for CI jobs

  • Rotate secrets automatically

  • Restrict what the runner identity can do (commands/hosts/network)

Add guardrails

  • Only allow automation access from known runner networks

  • Require code review for changes affecting prod access workflows

  • Alert on automation identity used outside pipeline windows

A Rollout Plan That Won’t Cause Pager Fatigue

Phase 1: Baseline hardening (1–2 weeks)

  • Root login off

  • Passwords phased down

  • AllowGroups / allowlists

  • Logging centralized

Phase 2: Centralize identity and MFA (2–6 weeks)

  • SSO integration or gateway

  • Remove shared keys

  • Define roles (read-only / deploy / break-glass)

Phase 3: Ephemeral access + posture (1–3 months)

  • SSH certs with short TTL

  • Device compliance enforcement for prod

  • Session recording for privileged access

Phase 4: Continuous improvement

  • Access reviews

  • Automated key/credential lifecycle

  • Better detections and response playbooks

Common Pitfalls to Avoid

“We’ll just block SSH from the internet”

Good start, but not Zero Trust. Internal networks can be compromised.

“We’ll enforce MFA but keep permanent keys”

MFA helps at login time; permanent keys can still leak and live forever.

“We’ll lock it down later”

SSH is one of the highest-impact attack paths. Hardening is one of the best ROI security projects you can do.

Conclusion

Zero Trust SSH is not one product or one config. It’s a practical shift:

  • from static keys to short-lived credentials,

  • from network trust to identity + device trust,

  • from broad shell access to least privilege,

  • from “hope nothing happens” to auditable, revocable access.

You can start today with baseline sshd hardening and a clear rollout plan—then move to centralized identity, ephemeral access, and posture enforcement without disrupting operations.

Windows OS Deployment via Ansible AWX Server on ESX Enviroment

Windows OS Deployment via Ansible AWX Server on ESX Enviroment

Hi all, yes it has been a while since my last publish but believe me, in this days , I mean at home office working times. I am working harder and much busy than office working times.

This post I would like to share how to automatize my Windows OS installations on ESX environment via Ansible AWX system.

For this automation steps we need some knowledge about the tools and environment. I will not explain how to install the system or detailed explanation about the systems, I will give you some descriptions , you need follow the documents and learn the tools basics.

What is AWX;

You can find many documents at the internet about it but github project page simple explanation is ; “AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is the upstream project for Tower, a commercial derivative of AWX. ” You will find many detailed how to documents about it at “https://github.com/ansible/awx”

What is Ansible ;

Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates.  Source Ansible Documentation page

What is VMware ESX;

Most of IT people has deep knowledge what is this and how to manage it. Yes most popular Hardware Virtualization solution for corporate IT environment . You can find the latest updates on this page about it.

Lets Continue with the Windows OS Installation steps;

This is the general view of the AWX dashboard.

First things first , Lets start with ESX Vcenter access credentials, that user need to have full admin rights on ESX system.

Now for source code management we need to create a project on AWX. I am storing the yaml codes on our corporate github.

You need  also create credentials for github access to download yaml codes. Same as esxvcenter access cred.

Now we need a dummy inventory group for esx server access .  Dummy inventory is just an empty inventory group.

Now time to create a template for our windows OS deploy job. In this section we need to choose which inventory group will use for this,  which project will use for the yaml codes group and which yaml playbook code file should use for it.

Let me share my playbook yaml file with you for give you some idea about the Virtual Windows OS deployment.

I am sharing the code as downloadable file because yaml file indents very important so web site copy paste could harm the indents.

VM_Deploy_Cetin_20012020.yml

 

---

- name: Create VM Instance
  hosts: localhost
  connection: local
  gather_facts: false


  tasks:

    - name: Check if all variables have been defined
      fail:
        msg: "{{ item }} is not defined"
      when: "{{ item }} is not defined"
      with_items:
        - datacenter
        - cluster
        - folder
        - vmname
        - datastore
        - vlan_name
        - template
        - ip
        - netmask
        - gateway
        - dns1
        - dns2
        - template
        - vm_password
        - fqdn_domain
        - domain_join_account
        - domain_join_password


    - name: Create a VM from a template
      vmware_guest:
        hostname: '{{ lookup("env", "VMWARE_HOST") }}'
        username: '{{ lookup("env", "VMWARE_USER") }}'
        password: '{{ lookup("env", "VMWARE_PASSWORD") }}'
        datacenter: "{{ datacenter }}"
        cluster: "{{ cluster }}"
        folder: "{{ folder }}"
        validate_certs: no
        name: "{{ vmname }}"
        template: "{{ template }}"
#        wait_for_ip_address: no
        datastore: "{{ datastore }}"
#        - name: Add NIC to VM
#          ovirt_nic:
#          state: present
#          vm: "{{ vmname }}"
#          name: "{{ vlan_name }}"
#          interface: vmxnet3
#         mac_address: 00:1a:4a:16:01:56
#          profile: ovirtmgmt
#          network: ovirtmgmt
        state: poweredon
        networks:
        - name: "{{ vlan_name }}"
          device_type: vmxnet3
          start_connected: yes
          ip: '{{ ip }}'
          netmask: "{{ netmask }}"
          gateway: "{{ gateway }}"
          dns_servers:
           - "{{dns1}}"
           - "{{dns2}}"
          wait_for_ip_address: yes

        customization:
          autologon: yes
          hostname: "{{ vmname }}"
          password: "{{ vm_password }}"
          domainadmin: "{{ domain_join_account }}"
          domainadminpassword: "{{ domain_join_password }}"
          joindomain: "{{ fqdn_domain }}"
          runonce:
          - C:\Windows\System32\cmd.exe /c "C:\Ansible_Workaround\domain_group.cmd"

      register: deploy_vm
      ignore_errors: yes

    - name: Result of Virtual machine
      debug:
        var: deploy_vm

when you check the code you will see defined couple of variables in this code like ; datacenter,cluster,folder,ip,template etc..

We need the answer this variables at the AWX system. For this purpose we need to reedit the template and define  survey for it. Every step of this survey need to answer in the code.  for example “fqdn_domain” check the screenshot.

Now we need a Virtual Machine Template for the deployment usage. I have created many templates for this purpose for every Windows OS versions.

As you know ESX enviroment can generalize the cloned template to machine. We are triggering  this option automatically while cloning the machine.

The important point is in that template you need to install vmtools. Because awx tells the operation steps to  the esx, esx customizing the  Windows OS via vmtools.

On my environment I am not a domain admin group member. I am a member of specific OU admin group , that’s why I have put a small run ones script to template machine “C:\Ansible_Workaround\domain_group.cmd”

@echo off
net localgroup administrators domain\OU_Admins /ADD
TZUTIL /s "Turkey Standard Time"

Lets demonstrate a deployment;

First go to template and check it ones more; If everything seems OK, press the rocket icon and start the deployment. Answer the questions about the VM name, Ip,Gateway,LocalAdmin Passwords etc.

After it click the deploy. It start to deploy and depend about your environment speed , it will take time about ten minutes.

If you success you will see a screen like that;

I hope , This document  will help you have an idea about the ansible AWX and Windows deployment process.

Conclusion ;

Ansible is a big sea in IT world. If you learn how to sail in it , you will find many automation variations for your daily job. For example; I am using it take Cisco Switch backups in every week more than hundred device. May be it will be another  story on this blog.

I would like to special thanks to my colleague Tolga Asik for his cooperation with his VM knowladge  and also Mustafa  Sarı with his storage knowledge.