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. On Tue, Nov 25, 2014 at 10:53 AM, Glenn <[email protected]> wrote: > 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. > > > On Thursday, July 31, 2014 2:42:35 PM UTC-5, Damon Overboe wrote: >> >> 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. >> >> On Thursday, July 31, 2014 1:40:51 PM UTC-5, Damon Overboe wrote: >>> >>> 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. >>> >>> On Thursday, July 31, 2014 10:51:24 AM UTC-5, Steffen Prince wrote: >>>> >>>> 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 >>>> >>>> On Wednesday, July 30, 2014 2:56:13 PM UTC-7, Damon Overboe wrote: >>>>> >>>>> 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. >>>>> >>>>> On Thursday, July 3, 2014 5:10:18 PM UTC-5, 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 >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> -- > 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/c2f19187-bcee-4b7f-a80f-7425604bf240%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/c2f19187-bcee-4b7f-a80f-7425604bf240%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAH%2BKTJ62Zv5Au1Z202nrYKBEuau%3DoP1ySVoOSnq2j1DHoJv0sA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
