It doesn't hurt to ask, but expect to receive at the mercy of the author +
contributors.
Unless many windows admin contributors appear I don't see windows support
in the near future. The majority of ansible users (and contributors) are
running Linux, mostly RHEL and derivatives.
Support for other distros/platforms depends on demand among contributors,
expertise, the ability to make patches that don't break other platforms and
are able to meet with the approval of the original author.
The code is generally easy to expand for different platforms, with current
efforts to make it even easier, but most platforms are unix like, windows
is a big departure and might not be that easy to integrate.
Unless many windows admin contributors appear I don't see windows support in
the near future. The majority of ansible users (and contributors) are
running Linux, mostly RHEL and derivatives.
It may not be a majority, but it's a large group.
We have a pretty large amount of Debian/*BSD folks now, and some
amount of Solaris.
We definitely don't have many people managing OS X though.
Let me clarify. I’m not interested in managing windows servers, I merely want to administer my remote *nix servers from Cygwin or some other console.
If I can make it work, I’ll contribute a recipe.
Hi,
This is nice.
My suggestion would be rather than creating the ansible-win, we try
and get these changes encapsulated in utils and other functions, using
try/except ImportError and so forth as neccessary.
This will prevent the need to dual maintain these in the future.
Can you make this happen? If so, that would be outstanding.
ansible and ansible-win do not look that different, in other words,
and you've got most everything abstracted elsewhere.
Obviously we'd want ansible-playbook, and hopefully ansible-doc, too
Thanks!
--Michael
That’s awesome I will try it later. We will probably need to create commands that play nice with ms install too
If you're talking about managing windows from ansible, that's another
animal entirely, and would theoretically require something like a WMI
transport type to maintain the 'no bootstrapping' philosophy.
I am not entirely convinced Windows admins really want this, or that
various attempts of traditional Unix tools to fit in that space are
accepted by Windows admin teams.
This is why we don't do it.
--Michael
I have both windows and Linux servers. I love ansible and find the windows management environments overkill for most things. I would definitely like to use ansible to manage windows if possible.
Sorry got confused though that this was running ansible from windows to manage linux not windows management 
Hi,
This is nice.
My suggestion would be rather than creating the ansible-win, we try
and get these changes encapsulated in utils and other functions, using
try/except ImportError and so forth as neccessary.
Just to clarify: ansible-win.py is identical to ansible. I had to rename it
for 2 reasons:
- windows requires a .py extension, otherwise imp.find_module will not find
the script when forking (multiprocessing module does this)
- if the script is renamed to ansible.py, attempting to import ansible from
within the script causes the script itself to be imported (ansible.py)
instead of the package (ansible/__init.py__)
So I renamed it to ansible-win.py. This is obviously the wrong way to do
it, I will try getting setup.py to rename the ansible script when
installing in windows.
This will prevent the need to dual maintain these in the future.
Can you make this happen? If so, that would be outstanding.
ansible and ansible-win do not look that different, in other words,
and you've got most everything abstracted elsewhere.
Obviously we'd want ansible-playbook, and hopefully ansible-doc, too
I will be looking at these later today. Hopefully I'll be running full
playbooks from windows soon
ansible.bat or ansible.cmd as an additional file that invokes
"python.exe ansible" should also work and avoid the rename.
There might be new nicer ways, but I haven't touched windows in about 10yrs
+1 to that.
like "python.exe ansible.cmd $*"
Replacing "$*" with whatever it is windows means all arguments given
to the program in Windows, lest that be $1 $2 $3 $4 ... etc
it's been a while for me too
I've never really done much python reading, but this looks like the ssh
transport; looks like a class with 5 public methods (I assume a method
starting with _ is not public...?), of which fetch_file and put_file of
which WinRM cannot readily support (I gather there are hoops to jump through
to get or put files to windows boxes - this guy explains it better than me,
search for "share"). That might be a reasonable thing to create a winrm.py
equivalent, or am I missing something fundamental?
I think there are probably going to be reasonable simple ways to ship
Powershell to a remote box and execute them.
Trick is doing it nicely, in a way that does not require installing a
Ruby (or other daemon) on the box -- and just using, say, the .NET
framework.
--Michael
That’s just it, though, without ****ing around with network shares, I don’t think there are ways to send scripts (as in, script files, which is how I read your reply) to the victim boxes to run.
However, to run just commands, one doesn’t need ruby etc on the box, just to have winrm active and listening, which one can do via winrm quickconfig (in its most basic form) or active directory group policy so it happens when a server joins the AD (assuming there is one). winrm commands can then be anything; cmd invocations, powershell cmdlets, whatever - but from what I gather, that part is up to the ansible playbooks, which get written bespoke anyhow. (?)
I haven't done windows admin in a while, but if you are a admin on the
target machine you used to have a share to C: (actually all drives).
So it would be easy to copy scripts over netbios.
Another roundabout way is by setting a policy that downloads the
scripts from a netlogon share.
Yes, the administrative shares exist, but that requires that port 135 be open for netbios traffic. Opening netbios on public facing boxes involves living with some security vulnerabilites (not least of which the fact that windows LAN manager still doesn’t store passwords securely). WinRM requires either 5985 (default http) or 5986 (default https) to be open (or whatever non-default one might choose).
Powershell’s Invoke-Command cmdlet allows a script to exist locally, and be transformed into a scriptblock to run remotely on the list of victim computers, however: https://blogs.technet.com/b/heyscriptingguy/archive/2012/07/25/an-introduction-to-powershell-remoting-part-three-interactive-and-fan-out-remoting.aspx
Aside from restricting port access to specific IPs the only other
thing I can think of to help you with this is installing an ssh server
on windows. There is even a openssh version IIRC.
The issue with that is because I (currently) work in a Microsoft environment, some colleagues knee-jerk forbid non-MS methods for doing things when there is an MS-way. It’s … frustrating, but also difficult to circumvent.
Please post it, yes. And yes, devops on Windows is like trying to brush your teeth using a tiger’s tail.