The Ansible Ask an Expert webinar series continues to be one of the most popular series we’ve ever hosted. During these Q&A style webinars, our Ansible experts take questions from the audience about specific topics.
In April, we covered Ask an Expert: Windows. We’ve compiled the questions and answers below for your reference.
Interested in more? Our next Ask an Expert: Windows webinar is scheduled for August 10th at 2PM EDT. Register here.
Q: Any update on support for Windows machine as the control machine? This would make a lot of sense for Windows-only administrators who don't use Linux all the time.
A: There are several technical limitations that prevent the Ansible controller from running as a native Win32 application. However, Ansible does work under the new Windows Subsystem for Linux on Windows 10. While we don't officially support it for production workloads (nor does Microsoft), it does work quite well for developing and testing Ansible content.
Q: Is it possible to manage MySQL under Windows with Ansible?
A: Yes, the MySQL modules can manage Windows-hosted MySQL the same way as Linux-hosted MySQL. The modules themselves still need to actually run on a Linux/Mac host, but they're usually run from the Ansible controller anyway.
Q: Will win_copy work as expected with large files and timeouts?
A: The win_copy module has been successfully tested with multi-gigabyte files. However, performance is not great. WinRM doesn't natively support file transfers, so there are a lot of "moving parts" involved, including a number of buffering and transformation steps that significantly impede the transfer throughout. If you need maximum performance on large file transfers, win_get_url is probably a better choice. If you're seeing timeouts during win_copy, they're probably coming from a buggy OpenSSL cipher implementation that we've seen floating around out there, not WinRM itself.
Q: Can I use WinRM / NTLM to connect to server A and from there set CredSSP on the Windows server to hop to server B?
A: Sorry, that won't work. CredSSP requires that you authenticate with a plaintext password, which it will then securely delegate to 2nd-hop hosts. NTLM only authenticates with a hash of the password, so there's nothing for CredSSP to pass along to the next host. If you want to use CredSSP, you'll have to use it all the way through.
Q: Can you explain how the coming automatic Kerberos authentication will work instead of needing to do kinit manually?
A: It works transparently- simply provide a username and password to Ansible (in any of the usual ways: -u/-k, ansible_username/ansible_password, etc.) when ansible_winrm_transport is set to Kerberos, and we'll create the ticket for you in an ephemeral credential cache. Right now, to avoid ticket timeouts and other issues, we reauthenticate for each host and each task. We'll probably optimize this down the line to support shared and reused credential caches.
Q: Is there going to be support to manage Windows workstatons in later releases?
A: Windows workstation management works today, but it's not something we spend a lot of time testing or optimizing for, and support for workstations will likely continue to be "best effort" rather than SLA-based. Initial setup of workstations works great with Ansible, but ongoing maintenance is not always the best fit. Unlike servers, workstations are often sleeping/powered down, or disconnected (think laptops), so "push-mode" management isn't always a great choice. If there are specific features that aren't working as you'd expect on a workstation, feel free to create a GitHub issue (or even better, fix it and submit a pull request!).
Q: Does Ansible support older versions of Windows (for example WinXP, Win2000 server)?
A: Not directly- our Powershell support is limited to Powershell 3 and higher, which is only supported on Windows 7+/Server 2008+. That said, in 2.3, we've shipped the win_psexec module, which allows you to run items remotely over Windows RPC on older hosts (albeit in a very limited way). Still, those OSs have been out of support for a very long time- you really should get them upgraded!
Q: I have recently started using Ansible for Windows. Can I add multiple windows hosts in inventory?
A: Absolutely- just like any other Ansible inventory, you can effectively list as many hosts as you want and group them by function, geography, lifecycle state, or anything else you like. You can then target lists of hosts or groups with your Playbooks to do your management at a massively parallel scale.
Q: Does the Ansible control host need to have an internet connection? Can all the modules be downloaded locally and installed?
A: No, the control host only needs to be able to see the target nodes- there is no internet connectivity requirement (assuming you've got some other way to get Ansible installed in the first place, of course!).
Q: How do you automate rotating Windows admin password in Tower? Does this mean hitting every target machine and then updating the Tower cred?
A: Assuming you're using local users (where you'd need to adjust the password on many hosts), the easiest way to do this is actually to rotate the user instead. Ensure that all your management permissions are expressed in terms of local groups (not specific users), then build a Tower job to create a new user in the management group on each host. Once the new user exists everywhere, update the single Tower machine credential to use the new user (which can also be easily automated with the new Tower management modules shipped in 2.3). Otherwise, you'll always be in a situation where you're trying to change your own password under WinRM, or in situations where a partially-failed job might leave some machines unmanageable.
Q: If you are using Kerberos, is the recommended practice still to run kinit via cron to get a ticket for use with Ansible Tower?
A: As of Ansible 2.3, you can now use Tower machine credentials normally with Kerberos. Just set ansible_winrm_transport to Kerberos in your inventory, and set a Tower machine credential with username/password on the job normally- Ansible will transparently manage the Kerberos tickets for you.
Q: Would you go about using Ansible to create an entire VM (including operating system) from scratch or just adding the applications on top of an OS template (for example)?
A: Ansible is not a bare-metal provisioning tool- we expect that there's already an OS to connect with. That said, there are a number of bare-metal deployment solutions out there that can be integrated with and driven by Ansible to bootstrap hosts dynamically to a point where Ansible can manage them directly. In that respect, the process is very similar to how cloud hosts are bootstrapped. Use Ansible to request creation of a new resource (using EC2/Azure/GCE/VMWare/etc.), get the connection details for the new host and use add_host or a dynamic inventory refresh. Then, target the new host with another Ansible play to do whatever further configuration is required. You just need to be able to script whatever your bare-metal provisioning solution is.
Q: Did you say that "runas" doesn't work with Kerberos?
A: Correct: the new runas become method that ships in Ansible 2.3 currently only works if you've authenticated to WinRM with Basic or CredSSP. There appears to be a restriction on the use of an underlying API (CreateProcessWithLogonW) where that API cannot be called if the caller is running under a login session without a password (eg, NTLM/Kerberos). We've reached out to Microsoft for clarification, but in the meantime, the runas become method has been marked as experimental. We have other ways to enable it for use with Kerberos and NTLM, but they'll require that the user authenticating to WinRM have some more esoteric permissions granted, which we'd like to avoid.
Q: Is there any documentation for setting up authentication using certificates? I'm curious if this is a good solution for mixed domain/workgroup environments.
A: While Ansible and pywinrm support certificate authentication over WinRM, we believe that the way it was implemented by Microsoft doesn't fit most users' needs, and we generally discourage its use. The biggest limitations are that it only works with local users (no domain capabilities), and that it's not really a username/password replacement (merely a mapping of a certificate to a username and password on each managed host). An additional downside is that, due to restrictions of the underlying urllib3 HTTP library used by requests/pywinrm, encrypted private keys are not supported, so they must be stored and passed through Ansible in the clear. All that said, if you really want to try it, Matt Wrock has put together the most comprehensive walkthrough we've seen of setting up certificate auth on WinRM at http://www.hurryupandwait.io/blog/certificate-password-less-based-authentication-in-winrm. Once you have everything configured and working on the server-side, just pass the certificate and private key through Ansible by setting ansible_winrm_transport=certificate, and the ansible_winrm_cert_pem and ansible_winrm_cert_key_pem inventory variables to the locations of the cert and key files on the Ansible control host.
Q: Is there a link that I can go to and review all the new Windows updates and features in 2.3?
A: The GitHub changelog is where we document new features, enhancements, and deprecations for each release. It can be found at https://github.com/ansible/ansible/blob/devel/CHANGELOG.md
Q: For an in place upgrade from 2.2.2 to 2.3, are there any "gotchas" that need to be planned for?
A: So long as you've been keeping up to date with deprecations (ie, under 2.2.2 you're not seeing deprecation warnings from any of your Ansible content), there aren't any breaking changes that I'm aware of. It's very important to act on deprecation warnings, as in each major release, we'll typically remove items that have been deprecated for at least the two previous releases.
Q: I'm trying to use the win_feature module with restart=yes, but it usually fails, even though the feature gets properly installed. What's going on?
A:We'll be deprecating the automatic restart feature in win_feature. It suffers from several race conditions and causes lots of issues- restarts should always be managed by Ansible with win_reboot. Otherwise, the target host may reboot before Ansible has collected the results of the current operation, which is likely the failure you're seeing.
Q: Is Ansible Windows management production ready? Can you name some customers that use it?
A: We're definitely production-ready. While we can't share specific names, rest assured that Ansible is being used with great success to manage Windows hosts in mission-critical applications by companies and governments, large and small.
Q: Are the facts generated by Windows similar to Linux?
A: Yes, most of the common fact keys are the same between Windows and Linux. To see if the key you're interested in is available, run `ansible windowshost -m setup` (where "windowshost" is the name of a Windows host in your inventory) and you'll get a full dump of the facts available.
Q: Can Windows passwords be specified on the command-line with -k like in Linux?
A: Absolutely- all of the same options for specifying passwords exist for Windows as for Linux (-k, ansible_password, vault).
Q: How is Ansible's Windows management different from SCCM and DSC?
A: This answer could easily fill its own post or two. We'll try to hit a few of the big differentiators, though... SCCM is generally considered a legacy workstation-flavored management technology, dating from the mid 1990s (though many places use it for server management, too). It uses agents on the managed hosts, which must be installed, configured, and kept up-to-date. SCCM executes many operations locally and asynchronously from the server, so it's often difficult to orchestrate changes and reason about system state as part of larger deployments. DSC is a much more modern management technology, supporting both an agent-based "pull" architecture (the agent is built into Powershell 5+ so is generally kept up-to-date with Windows) as well as a synchronous "push" architecture, similar to Ansible. DSC resources are a close analogue to Ansible's modules for managing specific types of resources- in fact, with Ansible 2.4, you'll be able to apply DSC resource configurations from Ansible Playbooks via the win_dsc module. We believe Ansible adds some great capabilities over the top of DSC with things like Playbooks, inventories, and multi-platform orchestration.
Q: Is it possible to use Ansible in combination with Microsoft AzureStack?
A: Not yet- Ansible 2.3 doesn't yet expose the ability to override the Azure endpoints necessary to use Azure Stack (and other specialty Azure endpoints like AzureChinaCloud and Azure Government). These features are already in progress, and should be available in Ansible 2.4.
Q: For software installation on Windows, does the development team recommend using Chocolatey or something else?
A: We can't recommend Chocolatey highly enough. It's by far the smoothest package management solution available on Windows today. It allows for first-class versioning and location-agnostic installation of packages, similar to what's been available on most Linux distros for years. If you need to install internal packages, or for some reason don't trust the public instance, NuGet/Chocolatey can easily run behind your firewall. Ansible also works well with it using the win_chocolatey module! If Chocolatey isn't an option for you, we'd suggest using the win_package module for idempotent installation of software packages that you've already downloaded.
Q: Can you connect to a custom PowerShell WinRM endpoint?
A: Not yet- pywinrm is currently using the old WinRS remote shell protocol, not the newer PSRP protocol that custom Powershell configuration endpoints use. Some work is being done to support PSRP in the pywinrm project, at which point this might become a possibility, but the typical use cases for them (constrained configuration and JEA) are not yet supported by Ansible, as there are significant technical limitations to overcome first (similar to why constrained sudo is not yet supported by Ansible under Linux).
Q: Is building a Windows domain and connecting hosts to it complicated in Ansible 2.3?
A: The new win_domain and win_domain_membership modules in Ansible 2.3 make it very easy to stand up a Windows domain from scratch. Simply run the win_domain module against the host you want to create the new domain on, then use the win_dns_client module to configure DNS for all the hosts that should join the new domain (they have to see the new domain controller's DNS unless you've preconfigured that with DHCP). Then, simply use a win_domain_membership task to ensure they've joined the domain, followed by a conditional win_reboot task that will perform the required reboot if the domain membership changed (check the reboot_required response from win_domain_membership). Four tasks that execute in a matter of seconds, and you'll have a shiny new Windows domain!
Q: Which modules have the "dry run" (check mode) functionality?
A: As of Ansible 2.3, most Windows modules have check_mode support (many thanks to community member Dag Wieers for filling out our check mode support!). We don't specifically call it out in the documentation (though perhaps we should)- the easiest way to ensure that is to set check_mode: yes on a Playbook task, or -- check to Ansible or Ansible Playbook. If the task is skipped, it doesn't support check mode.
Q: How does Windows Update work through Ansible?
A: Check out the win_updates module- it takes care of all the ugliness of getting Windows Update to work over WinRM behind the scenes.
Q: Has Ansible 2.3 taken care of double escaping in paths with backslashes?
A: You should almost never need to escape Windows paths in modern versions of Ansible when writing Playbooks or templates. Just stay away from the key=value syntax; if you must quote a value, use single quotes instead of double quotes wherever possible. If you stick to those rules, un-escaped backslashed paths should pretty much always work.
Q: Can Ansible run if UAC is enabled on Windows?
A: Yes- in nearly all cases, UAC settings have no effect on WinRM management sessions. As of Ansible 2.3, the new become runas feature is currently restricted by UAC, so if the target host is running in Admin Approval mode, the become user will only be able to run things at medium integrity (ie, not elevated). We've got several potential solutions to this in the works, which is one of the reasons that become runas is marked experimental for Ansible 2.3.
Q: When using become/runas on Windows, are the credentials secure over the wire?
A: The become credentials are sent over the same connection used for WinRM, so if you're using a secure connection there (currently HTTPS, soon-to-be NTLM/Kerberos message encryption over HTTP), then yes. If you've explicitly defeated Ansible and Windows' secure defaults (by enabling AllowUnencrypted on the target host), then no.
Need more info on Ansible and Windows?
Keep an eye on the Ask Ansible page for upcoming sessions.
If you have any comments or ideas for other Ask an Expert sessions, feel free to tweet at @Ansible.