{"id":400512,"date":"2024-06-29T15:18:52","date_gmt":"2024-06-29T15:18:52","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=400512"},"modified":"-0001-11-30T00:00:00","modified_gmt":"2024-06-29T15:18:52","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=400512","title":{"rendered":"\u00abNo Windows no problems\u00bb What?<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n
<\/figcaption><\/figure>\n

Hi, My name is Alex and I am a DevOps engineer at Altenar. \u201cNo Windows, no problems.\u201d — that is the answer I got by asking a guru of Ansible «How do you manage Windows?» on one of the local Ansible meetups. Although we have been running a modern stack (k8s, helm, .net core, etc) in production for about two years, that\u2019s not how it has always been. <\/p>\n

Our first version of Sportsbook was Windows-based (.NET + MSSQL) <\/strong>and we managed 100+ servers via Ansible. In this article, I would like to share some insights we learned through years of managing Windows infrastructure via Ansible. \u00a0<\/p>\n\n

Prepare servers for Ansible<\/h2>\n

Unlike Linux, Windows requires you to prepare for Ansible to connect to it (more details available here<\/u><\/a> and all the details are out of the scope of this article). However, there is one key point I would like to stress here. The ConfigureRemotingForAnsible.ps1<\/code> script — that is pretty much what you need to run before you’ll be able to connect to a VM via Ansible. <\/p>\n

It’s worth mentioning that we use Terraform for VM provisioning and this is where run_once_command_list<\/u><\/a> becomes very handy. We saved ConfigureRemotingForAnsible.ps1<\/code> on the C:\/<\/code> of the base VM template and used the following option in Terraform: <\/p>\n

resource \"vsphere_virtual_machine\" \"vm\" {   # ... other configuration ...    clone {     # ... other configuration ...      customize {       # ... other configuration ...        windows_options {         computer_name         = \"${lower(var.envname)}${var.vmname}${format(\"%03d\", count.index)}\"         organization_name     = \"Altenar\"         join_domain           = \"${var.domain}\"         domain_admin_user     = \"${var.domain_user}\"         domain_admin_password = \"${var.domain_password}\"         admin_password        = \"${var.admin_password}\"         auto_logon            = true          run_once_command_list = [     \"powershell.exe -version 4 -ExecutionPolicy Bypass -File C:\\\\ConfigureRemotingForAnsible.ps1\", ]       }     }   } } <\/code><\/pre>\n
Once a new server is provisioned it is ready to be set up by Ansible according to the role we assign to the server.  <\/p>\n
Setting up Ansible<\/h2>\n
From the Ansible side, a few initial preparations are also required.<\/p>\n
    \n
  1. \n
    Make sure all Windows servers belong to the «Windows» group in your inventory, we use groups but you can list each server individually here or automate the inventory creation process. Inventory management is out of this article scope, but it is well described in Ansible documentation<\/u><\/a>: <\/p>\n
    [windows:children] frontend client_api backoffice<\/code><\/pre>\n<\/li>\n
  2. \n
    Create windows.yaml<\/code> file in group_vars <\/em>folder of each environment and\/or in the main group_vars <\/em>folder and add the following content:<\/p>\n
    ansible_user: \"{{ windows_user|default ('Administrator') }}\" ansible_password: \"{{ windows_password }}\" ansible_port: 5986 ansible_connection: winrm ansible_winrm_transport: credssp<\/code><\/pre>\n<\/li>\n
  3. \n
    Include this<\/u><\/a> role as dependent into the meta\/main.yaml<\/code> file of any of the roles you are planning to execute, for instance:  <\/p>\n
    # cat roles\/infra\/IIS\/meta\/main.yml --- dependencies:   - { role: infra\/fetch-credentials\/windows } <\/code><\/pre>\n
    This role checks appropriate environment variables and fails if a Username or Password is not provided. These environment variables are then copied to Ansible variables and used in the settings we defined in p2. <\/p>\n<\/li>\n
  4. \n
    At this time, we have our servers configured and Ansible set up. We are good to go, the only thing left is actually setting up Windows username and password.  <\/p>\n
      \n
    1. \n
      You can do it using export WINDOWS_USERNAMEand export WINDOWS_PASSWORD commands:  <\/p>\n
      export WINDOWS_USERNAME=Administrator export WINDOWS_PASSWORD=******<\/code><\/pre>\n<\/li>\n
    2. \n
      or if you have more than one set of credentials you can use a small bash script-helper<\/a>:<\/p>\n
      # source set_env.sh Set Value for WINDOWS_DOMAIN_USER: Administrator Set Value for WINDOWS_DOMAIN_PASSWORD: Set Value for WINDOWS_USER: Administrator Set Value for WINDOWS_PASSWORD:<\/code><\/pre>\n<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
      Our preparations are done. We are ready to start Ansibling. <\/p>\n
      Windows tips and tricks<\/h2>\n
      Ansible has much fewer modules for Windows than for Linux. There are 104 modules for windows<\/strong> out of 2832 in total yet it is enough for most of the common cases.  But sometimes we have to be creative. <\/p>\n
      DSL is your friend<\/strong><\/p>\n
      The first thing to remember — DSL is your friend. There are many DSL modules<\/a> for windows<\/strong>, for example using this module<\/a> you can install MSSQL by just one task:<\/p>\n
      - name: Configure SqlSetup   win_dsc:     resource_name: SqlSetup     ForceReboot: False     UpdateEnabled: False     SourcePath: \"{{ disk_image_out.mount_path|default(database_settings.mssql_installation_source) }}\"     InstanceName: \"{{ db_settings.instance_name|upper }}\"     Features: \"{{ sql_setup_components }}\"     InstallSharedDir: \"{{ db_settings.instance_dir_drive }}Program Files\\\\Microsoft SQL Server\"     InstallSharedWOWDir: \"{{ db_settings.instance_dir_drive }}Program Files (x86)\\\\Microsoft SQL Server\"     InstanceDir: \"{{ db_settings.instance_dir_drive }}SQL\"     SQLCollation: 'Latin1_General_CI_AS'     SQLSvcAccount_username: \"{{ ad_settings_domain }}\\\\{{ db_settings.sqlsvcaccount }}$\"     SQLSvcAccount_password: '***'     AgtSvcAccount_username: \"{{ ad_settings_domain }}\\\\{{ db_settings.agtsvcaccount }}$\"     AgtSvcAccount_password: '***'     SQLSysAdminAccounts: \"{{ ad_settings_domain|upper }}\\\\SQL Administrators\"     InstallSQLDataDir:  \"{{db_settings.data_dir_drive}}SQL\\\\{{ db_settings.instance_name|upper }}\\\\MSSQL\\\\Data\"     SQLUserDBDir:       \"{{db_settings.data_dir_drive}}SQL\\\\{{ db_settings.instance_name|upper }}\\\\MSSQL\\\\Data\"     SQLUserDBLogDir:    \"{{db_settings.log_dir_drive }}SQL\\\\{{ db_settings.instance_name|upper }}\\\\MSSQL\\\\Log\"     SQLTempDBDir:       \"{{db_settings.temp_dir_drive}}SQL\\\\{{ db_settings.instance_name|upper }}\\\\MSSQL\\\\Data\\\\Tempdb\"     SQLTempDBLogDir:    \"{{db_settings.temp_dir_drive}}SQL\\\\{{ db_settings.instance_name|upper }}\\\\MSSQL\\\\Log\\\\Tempdb\"     SQLBackupDir:       \"{{db_settings.backup_dir_drive}}SQL\\\\{{ db_settings.instance_name|upper }}\\\\MSSQL\\\\Backup\"     PsDscRunAsCredential_username: \"{{ad_settings_adminuser}}@{{ad_settings_domain}}\"     PsDscRunAsCredential_password: \"{{ad_settings_adminpassword}}\"   tags:   - install_db<\/code><\/pre>\n
      Use the win_psmodule<\/a> first to install the required DSC modules on the server first:<\/p>\n
      - name: install DSC Modules   win_psmodule:     name: \"{{ item }}\"     state: present   with_items:     - \"PSDesiredStateConfiguration\"     - \"SqlServerDsc\"     - \"ServerManager\"     - \"StorageDsc\"     - \"ComputerManagementDsc\"<\/code><\/pre>\n
      Another big advantage of DSC is that you can run it as a different user, you could’ve spotted «PsDscRunAsCredential_username<\/em>» and «PsDscRunAsCredential_password<\/em>» directives on the example above. It especially helps when some tasks have to be run from the Domain Administrator account. <\/p>\n
      DIY modules<\/strong><\/p>\n
      Didn’t find an appropriate DSC module? Not a big deal, there are two possible workarounds (apart from the obvious — using win_shell <\/em>ansible module):<\/p>\n
        \n
      1. \n
        Use DSC resource «Script<\/a>«:<\/p>\n
        #Part of MSSQL setup playbook. Here we test if created service accounts  #have already been added to the server from AD #if not, we reboot the servers first. - name: Configure and Test the gMSA account   win_dsc:     resource_name: Script     GetScript: \"@{ Result = '{{ item }}'| Use-ServiceAccount -Test }\"     TestScript: \"(iwr https:\/\/raw.githubusercontent.com\/beatcracker\/Powershell-Misc\/master\/Use-ServiceAccount.ps1 -UseBasicParsing).Content | iex; '{{ item }}'| Use-ServiceAccount -Test\"     SetScript: '$global:DSCMachineStatus = 1'     PsDscRunAsCredential_username: \"{{ad_settings_adminuser}}@{{ad_settings_domain}}\"     PsDscRunAsCredential_password: \"{{ad_settings_adminpassword}}\"   with_items:     - \"{{ db_settings.sqlsvcaccount }}\"     - \"{{ db_settings.agtsvcaccount }}\"   register: TestADServiceAccount_result<\/code><\/pre>\n
        Ansible is an imperative tool, so we have to make sure that any task can be executed multiple times providing us with the same result. Play with «GetScrypt», «TestScrypt» and «SetScrypt» fields according to your needs. Having it played right should allow you to be able to identify the current state of the resource, change it if required and pass if not. <\/p>\n<\/li>\n
      2. \n
        Create a module yourself. It’s not that hard, the only difference with making a module for Linux is you need to write code on PowerShell. We encountered a problem where there was no module KDS Root Key creation which is required for MSSQL<\/u><\/a> installation. So we created it<\/u><\/a>. Look here<\/u><\/a> <\/u>for more details regarding win module development.   <\/p>\n<\/li>\n<\/ol>\n
        Conclusion<\/h2>\n
        I’ve provided the key aspects related to Ansible usage with Windows. Having Windows servers configured for Ansible we can manage them nearly the same way as we manage Linux servers using Ansible. By using the approaches described in this article we successfully manage Windows servers for jobs like:<\/p>\n