Initial feedback says things work well, and we’re on our way to have a very nice “setup” script in core that can be used to initialize things on Windows 2012+ systems in particular - older systems may need some more configuration, but I think this is a huge start.
We recently ran what we had now (just a few starter modules) by one of our Windows friends, and he suggested the following possible topics for new modules:
Windows Server
Create a registry setting
Create a file
Set a system environment variable
Run a batch file, VBScript or PowerShell script
Install a Windows feature
Install an MSI package
Install unpackaged software (EXE installer)
Set the computer name
Join an AD domain
Set the time zone
Enable Remote Desktop (RDP)
Configure page file size/location
Create a firewall rule
Create a scheduled task
Verify Windows Updates are up-to-date
Configure Windows Updates update policy settings
Map a network drive
Create a network share
Connect to a printer
Configure iSCSI initiator
Start, stop or restart a service
Configure a service to start at boot
Ensure Group Policy is up to date (gpupdate)
IIS
Add/remove a virtual site or application pool
Start/stop a virtual site or application pool
Add a listener on an IP/Port
Run an appcmd.exe config command
Choose an SSL certificate for a virtual site
Add or change a setting in a web.config file
Configure authentication for a virtual site
Configure ASP.NET properties (version) for a virtual site
Enable auto-approval of critical and security updates
Force synchronization of updates from Microsoft
W32TM (time service)
Configure time sync method (syncfromflags)
Configure manual peer list
Database
Add an ODBC data source
Certificate Services
(Server) Add a certificate enrollment policy
(Server) Approve a pending certificate request
(Client) Verify a computer certificate exists and autoenroll if not
BitLocker
Apply BitLocker to a drive
Suspend/Resume BitLocker
For those interested and that have Windows fleets to manage, we’d totally welcome additions. Shall we see what’s possible?
If you add something, submit a github pull request to add a module to the library/windows directory, and we can continue to build/test/refine these over the course of the 1.7 release cycle.
I’d be very curious what folks might find interesting and would be up for working on!
What I’m primarily interested in is being able to use Ansible as a Vagrant provisioner on Win7 hosts. At the moment I’m kind of resigned to running it locally on the VM, though, as I’d have to do with Packer anyway.
I would find this interesting (even though I only have a few boxes for real Windows) but due to how different things are between Windows and basically everything else, I think it pretty much requires a new project. The other issue is reliability handling errors and pre-provisioning (which maybe you could slipstream into your installation disc, or just use an image). If you’ve ever dealt with Batch scripts in the past (because you are generally just running commands), it gets really difficult especially since so many installers require a GUI interaction (such as scrolling down the text before accepting a license). So while some are easy that are listed above (creating a registry entry, importing a registry file, even adding certificates and activating the general Windows license against a KVM server). Sometimes you use msiexec /q and the MSI can still ignore you or just pop up a message about anything.
The majority of Windows systems I have seen on big deployments are brought up via disk images (that have almost everything completed and installed) and then fixed after the fact (licensing, etc). This of course requires having an image for every ‘type’ of machine you have on your infrastructure but is far easier and faster than provisioning.
I would find this interesting (even though I only have a few boxes for
real Windows) but due to how different things are between Windows and
basically everything else, I think it pretty much requires a new project.
If you mean not Ansible, I strongly disagree.
The other issue is reliability handling errors and pre-provisioning (which
maybe you could slipstream into your installation disc, or just use an
image). If you've ever dealt with Batch scripts in the past (because you
are generally just running commands), it gets really difficult especially
since so many installers require a GUI interaction (such as scrolling down
the text before accepting a license). So while some are easy that are
listed above (creating a registry entry, importing a registry file, even
adding certificates and activating the general Windows license against a
KVM server). Sometimes you use msiexec /q and the MSI can still ignore you
or just pop up a message about anything.
The majority of Windows systems I have seen on big deployments are brought
up via disk images (that have almost everything completed and installed)
and then fixed after the fact (licensing, etc). This of course requires
having an image for every 'type' of machine you have on your infrastructure
but is far easier and faster than provisioning.
Loving the Windows support! Sure beats all of my attempted efforts with Chef to date - I’m going to be needing a fair few of the features listed in the immediate future.
I’ve started on a Registry module, please let me know if this clashes with work done by anyone else thus far.
I suppose I could use the map network drive on the clients to have the .msi’s available in one place instead, but taking them from a store, whether local to the Controller or somewhere on the web, seems to model what you can do on the Linux side and less clunky.
I see there being three very different user groups for this:
*nix admins who for whatever reason have some services in their herd that are tied to Windows
Windows Server/IIS admins
Corporate desktop admins
I think the first group would be pleased with little more than the basic file and service modules.
Given that Ansible must be run from a *nix machine, I’m not sure there’s a big audience in the second two groups. The automation culture is definitely to spin up virtual machine images that have been configured by hand. And the third group already has a plethora of GUI tools for remotely configuring a desktop fleet.
We have one Windows service that is production-critical: a “transient energy system simulation tool” written in non-portable Fortran. Everything having to do with it has been awful… but being able to manage deploys with Ansible would be a big step forwards.
I wonder if the automation group is going to stay as spinning up VMs from manually configured starting points?
I’m coming from the development side; I’ve traditionally been in the .net stack but as there is so much bleed-over between the different disciplines now, I feel like we’re finally starting to get excellent glimpses into what continuous delivery should be, although I know that can be subjective as well.
But I have a client that does everything manually, and I mean everything! I’m putting something in place on the development / testing side to start, and trying to pick that off a piece at a time to improve it. I’ve seen this at a lot of Windows / .net shops too; they all are extremely immature in their abilities to install / update a product.
And the point that I try to make is I would rather be able to take a clean VM with the absolute bare minimums and use that as a starting point, rather than configuring a base VM image and then just pushing updates to it.
I may not have a lot of people on the Windows side that agree with that right now, but I know there are people that do agree, and I think we’ll see more and more of them. I have met people that use Puppet seem to take the same approach.
To me, the cleanest starting point you can get helps ensure a solid yet flexible install / upgrade plan, whereas starting with a heavily configured or set up starting point just feels fragile to me, and it also makes it harder to support newer versions of Windows, because you have to go back through the entire process on each new version.
Totally agree with you in regards to there being three groups - My
background is a *nix admin and in the middle of trying to convince two
separate teams that fall into the second category, that they need to start
using Ansible to manage their Windows infrastructure going forward.
Thankfully Tower exists to bridge the gap for Windows SysAdmins.
I’m in a Windows IIS shop that is trying to convert from using a using a VM master image that is continually updated to a bare OS install starting point. There is a lot of manual playbooking and simple scripting currently. We are implementing a more robust system for configuration management. Ansible is being shot down as a option to use for configuration management and orchestration because it is too immature on the Windows side compared to Chef or Puppet. The view of simpler concepts and setup with no agent was trumped by existing code and market share. The killer features that would make Ansible viable for us are msi and exe installs, file managment, user management, WMI and registry edits, granular IIS and SQL configuration modules. There isn’t an appetite here to learn Python and write the Ansible modules to make it mature enough for our use. Since The other options also allow dropping to Powershell to execute code, there wasn’t much else I could offer for arguments for Ansible.
The win_feature module (http://docs.ansible.com/win_feature_module.html)
should at least allow you to get IIS and other built-in roles/features
working, but we don't yet have any support for IIS config.
I like to keep tool X vs Y out there out of the equation, but maturity should not be a factor - rather than building it’s own agent, Ansible is relying on native Microsoft management systems - the powershell standard library and windows remoting.
If there are particular modules you’d like to see, that would be interesting - active directory auth we’ll admit is still incoming (but soon).