Steve Lee (@SteveL-MSFT) Dongbo Wang (@daxian-dbw) Travis Plunk (@TravisEz13) Could you help me? Currently I port to AccountManagement API most of the code and fix tests but FindByIdentity() method works extremely slow (up to 100x(!) slower than PrincipalSearcher). I replace the method with PrincipalSearcher to search by name but I have to use the method to search by SID. Could you please point me better way? (I guess original code can resolve domain and Azure SIDs ...)

I don't think this work should be part of PowerShell itself. The inbox module loads for me without issue.

Expectations are to get the module working on Unix.
The used API is potentially portable and provider based. A request to add PAM support is in .Net Runtime repository.

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Mainainer, Please provide feedback and/or mark it as Waiting on Author

Request to port AccountManagement API to Linux dotnet/runtime#37100

Why should this not be introduced as a module outside PowerShell first, then when it's working, brought into PowerShell?

Travis Plunk (@TravisEz13) It is minor details. Main question is how MSFT team sees a future of the module. If as open source and ported today is best time to do this - while .Net 5.0 is under development we could move to the public API for PowerShell 7.1. Then in .Net 6.0 timeline we could get portable API for next PowerShell 7.2 LTS.
If MSFT team want to keep the module as Windows-only and deprecated I could work on new AcoountManagement module (I already pulled example PR) with more modern design and features.

The question was already answered, by the committee in a previous PR, that this should be a new module, published separately. Then we can answer the question about bringing back into PowerShell. That answer implies that the namespace should be separate.

If MSFT team has clear understanding about future of LocalAccounts module I'd expect that MSFT team share this in new issue like:

• LocalAccounts module is deprecated
• new module should be designed
• no concerns about backward compatibility
• the new module should be community/personal, not Microsoft module
• the new module should be published on PowerShellGet site, not in PowerShell/Module repository

Since my intention was to increase backward compatibility and to simplify migration to PowerShell Core I close the PR because I have no plans to develop a personal module.

The localaccounts module in windows continues to be supported, but otherwise, I think this is accurate. Basically, I think this falls under point 2 of Joey's slide here: