PowerShell 7+ module is Windows-only module for local account management.
It is a port of Windows PowerShell Microsoft.PowerShell.LocalAccounts
module to .Net 8.0+ for using with PowerShell 7.4+ based on LocalAccounts-MS.
While LocalAccounts-MS
is a port of the original Microsoft.PowerShell.LocalAccounts
module for maintaining maximum backward compatibility and it is frozen, the LocalAccounts
project is open for development.
Install-Module LocalAccounts -Scope AllUsers [-AllowPrerelease]
Check you get right module:
start
pwsh
run
Get-LocalUser
(Get-Module -Name LocalAccounts).Path
The original module uses non-public APIs and therefore cannot be part of an open source project.
-
The
Microsoft.PowerShell.LocalAccounts
original module is frozen. Microsoft has no plans to change anything in the original module. -
Meanwhile, this project is open for development.
-
Currently, PowerShell 7 can use
Microsoft.PowerShell.LocalAccounts
only usingCompatibility feature
, i.e. cmdlets from this module are executed in Windows PowerShell, after which the results are returned in serialized form. This works well for simple scenarios, but in complex ones it may not work as expected.The module from this repository can be imported to
pwsh
directly. In addition, cmdlet objects can also be directly used in .Net applications. -
There are some issues in the original module, which is fixed in this repository:
-
an annoying bug (the same) (
Get-LocalGroupMember : Failed to compare two elements in the array
) -
an issue (impossible to clear
Description
property) -
an issue (
Description
property length limitation) -
an issue (incorrect
PasswordRequired
property) -
There are some reports about telemetry loading error, which are not present in this repository:
-
Could not load type 'Microsoft.PowerShell.Telemetry.Internal.TelemetryAPI' from assembly 'System.Management.Automation, Version=7.4.2.500, Culture=neutral, PublicKeyToken=*****'.
-
New-LocalUser: Could not load type 'Microsoft.PowerShell.Telemetry.Internal.TelemetryAPI' from assembly 'System.Management.Automation, Version=7.3.0.500, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
-
New-LocalUser: Could not load type 'Microsoft.PowerShell.Telemetry.Internal.TelemetryAPI' from assembly 'System.Management.Automation, Version=7.2.6.500, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
-
-
Obviously, there is no binary compatibility with Microsoft.PowerShell.LocalAccounts
.
This project maintains backward compatibility with its predecessor at the script level, existing Windows PowerShell scripts should work unchanged in most cases. Nevertheless, the project is open to innovations that can be accepted even if backward compatibility cannot be ensured. Maintaining full backward compatibility is not a strict requirement if the changes fix bugs or introduce significant new features.
There are two reasons for this:
-
PrincipalSource
property was based on non-public APILsaLookupUserAccountType
fromapi-ms-win-security-lsalookup-l1-1-2.dll
(the official documentation does not contain a description of this point. In addition, the current version of this dll is listed in the documentation asapi-ms-win-security-lsalookup-l2-1-0.dll
). -
PrincipalSource
property does not look useful. Microsoft added this property only when Windows 10 was introduced. The reason is unknown. Microsoft's comment in code saids that logic of theLsaLookupUserAccountType
function is in question and too complex to reproduce on C#. But why do we need this information in a module that should work only with local accounts.
The only possible replacement in future versions could be the Identifier Authority
value from SID.
See https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/f992ad60-0fe4-4b87-9fed-beb478836861
and https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/c6ce4275-3d90-4890-ab3a-514745e4637e
The problem here is that the values 10 (MS Passport
),11 (Microsoft
), and 12 (AzureAD
) are not specified in the official documentation. Of course, this only matters if we want to replace the numeric value with its name.
Specific of System.DirectoryServices.AccountManagement
API is that there may be delays due to name recognition on the network, since this API uses NetBIOS names inside. Disabling NetBIOS and LLMNR protocols on the computer could help to fix the problem.
This project is open for development.
Is there any intention to distribute this ported module with PowerShell 7 or to bring it back to the PowerShell repository?
It is a question for PowerShell team. (There are no technical obstacles.)