community.windows VS ansible.windows

It seems the community.windows collection doesnt currently accept new modules, so I guess you should just publish your own collection https://github.com/ansible-collections/community.windows

ansible-galaxy collection install git+https://github.com/ansible-collections/community.windows.git

Unfortunately there's not much else you can do really. The time taken is due to the code that's being run and how Windows/PowerShell is sending the info. It taking hours sounds really wrong though it might be worthwhile looking through the code https://github.com/ansible-collections/community.windows/blob/main/plugins/modules/win_domain_group_membership.ps1 to see what it's running and see if you can replicate that manually through an interactive PowerShell prompt.

I just installed the community.windows collection, and try to use it to add objects into the AD. Here is my playbook:

https://github.com/ansible-collections/community.windows/blob/main/galaxy.yml Line 14, has this been installed?

collections: # see https://galaxy.ansible.com/ansible/windows - name: ansible.windows version: 2.2.0 # see https://galaxy.ansible.com/community/general - name: community.general version: 8.1.0

For example the ansible.windows collections has a plugin_utils/_quote.py file https://github.com/ansible-collections/ansible.windows/blob/main/plugins/plugin_utils/_quote.py. It's then imported by some filter plugins with https://github.com/ansible-collections/ansible.windows/blob/5b044e12c93f57a26563264690c633aef97036d6/plugins/filter/quote.py#L11-L15

I'm no expert here, but maybe you're better off using the ansible windows collection instead of just invoking Powershell, as you'll get to rely on all the functionality Ansible provides like checking the outcome, changes, handling errors, providing consistent feedback, etc., instead of being responsible for that yourself. Like, actually use it for more than firing off scripts remotely

I've tried the workarounds provided here but I haven't had any success. I'm persisting with this approach rather than the more tedious copying the script to the server, executing, and then cleaning up etc. as Ansible does the house keeping for me this way. 😅

If you do find any issues we certainly would like to hear about it and try and fix the problem if we can. You can submit an issue with the details at https://github.com/ansible-collections/ansible.windows.

It is but Parse-Args are part of the legacy module utils. Have a look at win_environment for a decent module example. It uses the newer AnsibleModule style that is good to use today. You can ignore the AddType module util if you don’t need that functionality (it doesn’t look like you do).

Here is something that might get you moving In the right direction, its a script to pull and modify the ACL's from ansiblehttps://github.com/ansible-collections/ansible.windows/blob/main/plugins/modules/win_acl.ps1

Which version of Ansible? See https://github.com/ansible-collections/ansible.windows/issues/138. This may or may not be your issue.

Just opened https://github.com/ansible-collections/ansible.windows/pull/320 which should solve this problem for you. If you do get a chance it would be great if you could test it out in your environment to see if it solves it for you.

The issue you are coming across is https://github.com/ansible-collections/ansible.windows/issues/29 which has been fixed in the ansible.windows collection. The fix was very intrusive as it required a massive rewrite in how the module gathered facts, essentially stopped using WMI/CIM. I believe these changes are present in Ansible 2.10.+ but not Ansible 2.9.. The issue here is that WMI/CIM does not allow you to get instances unless you are either an Administrator or are running an Interactive logon. For WinRM users are no longer running an interactive logon so the old code only worked for Administrators.