Windows Support Stage 2: Engage Battlestations!

[Michael DeHaan]

A while back we introduced some Windows support on the devel branch.

http://docs.ansible.com/intro_windows.html

http://docs.ansible.com/list_of_windows_modules.html

http://www.ansible.com/blog/windows-is-coming

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
- Configure compression for a virtual site
- Install an ISAPI Filter
- Enable/disable/configure ASP.NET tracing

SNMP Service

- Set SNMP R/O and R/W community
- Enable WMI-over-SNMP

Services for NFS

- Configure server settings
- Export an NFS share
- Create a Unix-to-Windows username mapping

Client for NFS

- Map an NFS share

AD DC

- Promote server to domain controller (dcpromo)
- Force synchronization between two sites

DHCP

- Create a scope with options
- Add a reservation

DNS

- Create a zone file
- Add an A/PTR record, CNAME, etc

WSUS

- 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!

--Michael

[David Carmean]

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.

[Michael DeHaan]

We're not really looking to implement running Ansible from Windows, this is about managing Windows remotes.

--

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/c81da360-f2d6-46a7-89b0-14cdabed44f1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Andrew Udvare]

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.

[Michael DeHaan]

On Wed, Jul 9, 2014 at 5:08 AM, Andrew Udvare <aud...@gmail.com> wrote:

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.

Lots of admins make heavy use of Powershell.

See also SCCM.

 

On Monday, 7 July 2014 08:08:03 UTC-7, David Carmean wrote:

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.




On Thursday, July 3, 2014 3:10:18 PM UTC-7, Michael DeHaan wrote:

A while back we introduced some Windows support on the devel branch.

http://docs.ansible.com/intro_windows.html

http://docs.ansible.com/list_of_windows_modules.html

http://www.ansible.com/blog/windows-is-coming

 

--

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/3db0ce96-783b-4624-a72e-3a47c25aacbf%40googlegroups.com.

[Ash Caire]

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.

[Michael DeHaan]

Not to my knowledge!   That would be great.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/3d84de1f-2a65-4852-b170-7302c52ba41d%40googlegroups.com.

[Damon Overboe]

Porting the file module would be huge, especially:

• create / remove directories (including forcefully)
  
• transfer (from Controller) / fetch (from web) / create / remove files ""

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.

[Steffen Prince]

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 think you can please the first group 

[Damon Overboe]

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.

[Damon Overboe]

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.

[Michael DeHaan]

I've recently updated the windows intro docs to reference Trond's helpful setup script, see here:

https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/17f8b6e7-11cb-4db7-9173-7521c398b4e7%40googlegroups.com.

[Ash Caire]

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.

[Glenn]

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.

[Chris Church]

Hi Glenn,

Thanks for the feedback.  The use cases you've indicated help us to determine what Windows users need.

First of all, Windows modules are written in PowerShell, so there's no need to learn Python to contribute in that area.

We do support dropping to PowerShell if you have existing scripts you'd like to use, or there's not yet a module to do what you want. The raw module (http://docs.ansible.com/raw_module.html) allows for running simple commands directly, while the script module (http://docs.ansible.com/script_module.html) can be used to run most any PowerShell script.  The integration tests may offer you some good examples for using those modules and checking the results (https://github.com/ansible/ansible/blob/devel/test/integration/roles/test_win_raw/tasks/main.yml and https://github.com/ansible/ansible/blob/devel/test/integration/roles/test_win_script/tasks/main.yml).

Basic MSI installs are supported via the win_msi module (http://docs.ansible.com/win_msi_module.html).  There was also some work done on a more capable win_package module, which may be revisited in the future (https://github.com/ansible/ansible/pull/8860), as well as support for using the chocolatey package manager (https://github.com/ansible/ansible-modules-extras/pull/37).

File management support has recently been submitted (https://github.com/ansible/ansible/pull/9611 and https://github.com/ansible/ansible-modules-core/pull/384).

User management is supported via the win_user module (http://docs.ansible.com/win_user_module.html), and I have some pending updates for that one as well (https://github.com/ansible/ansible-modules-core/pull/84).

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.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/c2f19187-bcee-4b7f-a80f-7425604bf240%40googlegroups.com.

[Michael DeHaan]

Hi Glenn,

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).

On Tue, Nov 25, 2014 at 10:53 AM, Glenn <glen...@gmail.com> wrote: