# PowerShell Specific Collection **URL:** \ **Category:** Project Discussions\ **Tags:** powershell, windows, aap\ **Created:** [April 20, 2026, 12:55am UTC](https://forum.ansible.com/t/powershell-specific-collection/45708 "2026-04-20T00:55:13Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![jborean](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jborean/32/1525_2.png) [@jborean](https://forum.ansible.com/u/jborean)\ **Post date:** [April 20, 2026, 12:55am UTC](https://forum.ansible.com/t/powershell-specific-collection/45708/1 "2026-04-20T00:55:13Z")
With the upcoming release of Ansible 2.22 it is now possible to run PowerShell modules through the common exec wrapper. Currently only a small subset of modules in `ansible.windows` support this once [Support for non-Windows targets by jborean93 · Pull Request #888 · ansible-collections/ansible.windows · GitHub](https://github.com/ansible-collections/ansible.windows/pull/888) lands into a new release but I’m wondering whether I should take this opportunity to create a new collection like `ansible.powershell` that offers a supported set of PowerShell based modules that can run on Windows and Posix hosts. For example `win_ping`, `win_powershell`, `win_stat`, `win_file`, and other modules that aren’t Windows specific could be in this module under names like `ansible.powershell.ping`, `ansible.powershell.shell`, `ansible.powershell.stat`, etc. A benefit to this approach is - a nice baseline of modules that can be used for PowerShell test targets - easy to see what PowerShell modules are platform agnostic and what is Windows specific - breaking up `ansible.windows` into smaller chunks and being Windows specific per its name The downsides I see are - another collection Windows users now need to include - redirection of plugins helps but it’s still extra work on top of what people do today - ansible.windows needs to add this as a dependency or have it continue to include the old modules with a deprecation notice - just more work in general to set this up and get it included in the community package and AAP’s Execution Environments I’m curious to see what others think about this and whether I should - just continue to use `ansible.windows` and rely on documentation to make what is and isn’t compatible on Posix - create a new collection like `ansible.powershell` (or other related name) If I was to create the new collection it also opens up the question whether I redirect the exiting `ansible.windows` modules that are going into the new collection or deprecate the old ones over a long period of time. The deprecation is certainly cleaner but these are such a core set of plugins and with the builtin redirections from before the core split this may be a step too far in terms of breaking people’s playbooks. cc @dag @briantist as you’ve worked in this area before and have some good instincts around what the community may want around this. ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [April 20, 2026, 3:45pm UTC](https://forum.ansible.com/t/powershell-specific-collection/45708/2 "2026-04-20T15:45:17Z")
Hey @jborean Assuming this is somewhat related to [Documentation Attributes for PowerShell versions](https://forum.ansible.com/t/documentation-attributes-for-powershell-versions/45649), right? In my mind, it makes sense to have these modules that support PowerShell 5+ (working on both Windows and POSIX) into a separate collection given they’re not Windows specific anymore. However, at the same time as you rightly point out, it has maintenance and UX downsides. It would also mean `ansible.powershell` would need to be certified separately to, adding to the maintenance. I could help with maintenance if needed. I have experience with writing quite a bit of PowerShell too. Let me know if I can help 🙂 ---
**Author:** ![jborean](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jborean/32/1525_2.png) [@jborean](https://forum.ansible.com/u/jborean)\ **Post date:** [April 20, 2026, 7:34pm UTC](https://forum.ansible.com/t/powershell-specific-collection/45708/3 "2026-04-20T19:34:36Z")
> [@dbrennand](#): > > Assuming this is somewhat related to [Documentation Attributes for PowerShell versions](https://forum.ansible.com/t/documentation-attributes-for-powershell-versions/45649), right? Somewhat related, that post is more about how we can try and improve the documentation in general for all collections and wanting to indicate requirements in a more structured manner. > [@dbrennand](#): > > However, at the same time as you rightly point out, it has maintenance and UX downsides. It would also mean `ansible.powershell` would need to be certified separately to, adding to the maintenance. It’s definitely more work to set up the collection but in my mind the maintenance going forward is probably going to be easier. It reduces the load on `ansible.windows` and the number of tests it needs to run which is always a good thing and focuses this hypothetical new collection on a specific set of tasks rather than lumping it in with “Windows”. Certification is another question that I do need to follow up internally but based on previous attempts to split up `ansible.windows` and promote modules from `community.windows` to a supported/certified collection I don’t see any immediate blockers. The UX side is probably the part I’m more concerned with. Using redirections in `ansible.windows` to point to this new collection certainly papers over this a bit more but modules like `win_ping`, `win_file`, `win_stat`, `win_powershell` are pretty fundamental that any change in where they are located could have some unforeseen consequences. From my perspective if we were to go ahead with this I see 3 possible options around this 1. Do nothing, keep the `ansible.windows` modules as is and maintain both for the foreseeable future 2. Add a redirection so `ansible.windows.win_ping -> ansible.powershell.ping` 3. Same as above but add a deprecation for the redirection so it is not kept around indefinition My money would be on 2 with maybe adding the deprecation years into the future if there is a desire to remove the dependency that `ansible.windows` would have on this new collection at runtime. > [@dbrennand](#): > > I could help with maintenance if needed. I have experience with writing quite a bit of PowerShell too. Let me know if I can help 🙂 Appreciate it, will definitely let you know if I do get started on this. ---
**Author:** ![briantist](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/briantist/32/130_2.png) [@briantist](https://forum.ansible.com/u/briantist)\ **Post date:** [April 20, 2026, 10:33pm UTC](https://forum.ansible.com/t/powershell-specific-collection/45708/4 "2026-04-20T22:33:07Z")
Very cool, looking forward to this. > [@jborean](#): > > Same as above but add a deprecation for the redirection so it is not kept around indefinition I actually think this is the better option. I know we’re concerned about backward compatibility and breaking existing things, but at some point something’s gotta give if we want to improve and move forward, and papering over the changes indefinitely is probably more likely to have unforeseen consequences than not. I can understand if the deprecation date/version is years in the future, but maybe like.. 2 years max and set right away so the warnings are around for a long time. > [@jborean](#): > > The downsides I see are > > - another collection Windows users now need to include To me this isn’t much of a downside. Once you need to include any external collection, adding more just isn’t a big deal imo. > [@jborean](#): > > breaking up `ansible.windows` into smaller chunks and being Windows specific per its name I’ll be honest I don’t love the collection being `ansible.powershell`, much in the same way that I don’t love `windows` as a grouping for a collection or the `win_` prefix on modules. We wouldn’t really make other collections like `ansible.python` or `ansible.linux`. I mean I get why, I understand the history we’re working with and all that, and I have no better suggestion whatsoever so I’m not really rejecting the idea. It’d be nice if one day non-python runtimes were less of the distinction they are now. mini rant aside: a new collection makes sense where we are today, and especially as it relates to what will potentially be new testing challenges, it’ll probably be nice to have that separation. * * * cc @lowlydba who maintains the [sqlserver collection](https://github.com/lowlydba/lowlydba.sqlserver), which is already an OS-agnostic set of PowerShell modules (and can maybe finally run on Linux without the hacked core plugins we put together 😅) ---
**Author:** ![jborean](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jborean/32/1525_2.png) [@jborean](https://forum.ansible.com/u/jborean)\ **Post date:** [April 21, 2026, 12:22am UTC](https://forum.ansible.com/t/powershell-specific-collection/45708/5 "2026-04-21T00:22:58Z")
> [@briantist](#): > > I actually think this is the better option. I know we’re concerned about backward compatibility and breaking existing things, but at some point something’s gotta give if we want to improve and move forward, and papering over the changes indefinitely is probably more likely to have unforeseen consequences than not. I can understand this perspective and typically I would agree, I’m just quite reluctant here due to how core these modules are to using Ansible on Windows. The removal of the redirection would result in playbooks that have worked since the 2.0 days ultimately breaking and while things do change and removing tech debt is good I’m unsure whether it’s worth it in this scenario or at least not until this hypothetical new collection has been around for longer. > [@briantist](#): > > To me this isn’t much of a downside. Once you need to include any external collection, adding more just isn’t a big deal imo. In this case this would be the first dependency to `ansible.windows`. It’s not a deal breaker but with Galaxy and the tooling being what they are it’s just extra work and potential issues where we don’t have today. > [@briantist](#): > > I’ll be honest I don’t love the collection being `ansible.powershell`, much in the same way that I don’t love `windows` as a grouping for a collection or the `win_` prefix on modules. I can agree with this but I keep coming up short on a potential name to use here. The modules that would be included in this are meant to be “core” modules that provide a base set of functionality that works cross platform so there isn’t really a grouping that is ideal except the language. As you’ve said we don’t really have a good story around language. We could instead try and lump them together with the other Python based modules and use the prefix `pwsh_` like `ansible.builtin.pwsh_ping` but - I doubt core will want to bring these back in - Just trades the `win_` prefix for `pwsh_` prefix anyway > [@briantist](#): > > We wouldn’t really make other collections like `ansible.python` or `ansible.linux`. As a side note we do have `ansible.posix` already which contains modules that we didn’t want to keep in core but still had to “support” them. One of the main drivers behind this was from some of the issues I had with testing the existing PowerShell modules across the various platforms. I found that I needed a core set of things like `stat`, `file`, `command/shell`, `tempfile` like modules but either had to fix up the existing `win_` ones to fix whatever Windows specific logic it had, use `when` conditions to change the module to run with, or have 2 different test targets and duplicate the tests. ---
**Author:** ![briantist](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/briantist/32/130_2.png) [@briantist](https://forum.ansible.com/u/briantist)\ **Post date:** [April 21, 2026, 12:36am UTC](https://forum.ansible.com/t/powershell-specific-collection/45708/6 "2026-04-21T00:36:05Z")
Yeah, I agree with you on all these points, despite any drawbacks I think what you proposed is still the best option available.