PowerShell Core cannot execute certain cmdlets because it is a cross-platform implementation that excludes Windows-specific modules like ActiveDirectory, DnsClient, and NetTCPIP. These legacy components rely on .NET Framework APIs unavailable in the cross-platform .NET runtime. To resolve this, you must either use PowerShell 5.1 for Windows-only tasks or find cross-platform alternatives compatible with PowerShell Core.
The Fundamental Difference Between Editions
The confusion often arises from assuming that "PowerShell" and "PowerShell Core" are interchangeable terms for the same engine. They are not. The version of PowerShell pre-installed on Windows (versions 3 through 5.1) is built on the .NET Framework. This older runtime includes deep integration with Windows operating system components, allowing it to load modules that interact directly with Windows internals, such as registry management, WMI, and specific network configurations. PowerShell Core (versions 6.0 and later, now unified under PowerShell 7+) is built on .NET Core (and subsequently .NET 5/6/7+). It is designed to be cross-platform, running on Linux, macOS, and Windows. Because it aims for portability, it deliberately strips out dependencies that are exclusive to Windows. Consequently, any cmdlet that requires Windows-specific .NET Framework assemblies will fail to load in PowerShell Core. When you attempt to run a cmdlet likeGet-ADUser or Resolve-DnsName in PowerShell Core, the engine looks for the module but finds no compatible binary, resulting in a "command not found" error.
This distinction is critical for administrators who manage hybrid environments. Scripts written for PowerShell 5.1 may break unexpectedly when executed in a containerized Linux environment or on a Mac using PowerShell Core. Understanding this architectural split prevents wasted time debugging syntax errors that are actually compatibility issues.
Identifying Windows-Specific Cmdlets
Not all cmdlets are available in PowerShell Core. The most common offenders include:- Active Directory Module: Cmdlets like
New-ADUser,Get-ADGroup, andSet-ADAccountPasswordrequire the Active Directory Web Services API, which is strictly Windows-based. - DNS Management: Cmdlets such as
Resolve-DnsNameandAdd-DnsServerPrimaryZonedepend on Windows DNS client libraries. - Network Configuration: Cmdlets like
Get-NetIPConfigurationandNew-NetIPAddressinterface with Windows Network Adapter settings via WMI/CIM providers that do not exist on Linux or macOS. - Registry Access: While basic file operations work, the
Registry:drive provider relies on Windows Registry APIs.
Get-Command cmdlet. If you type Get-Command -Name Resolve-DnsName in PowerShell Core and receive no output, the command is definitively not supported in that environment. In contrast, PowerShell 5.1 will return the full object details for the cmdlet.
Solutions for Cross-Platform Compatibility
If you need to run scripts across different operating systems, you must refactor your code to avoid Windows-specific cmdlets. There are three primary strategies to overcome this limitation. 1. Use Native OS Commands or Aliases Many Windows-specific tasks have equivalents in standard POSIX commands or native tools. For example, instead of usingResolve-DnsName, you can use the nslookup or dig commands if installed. For IP configuration, you might use ipconfig on Windows or ifconfig/ip addr on Linux/macOS. You can detect the operating system within PowerShell using $PSVersionTable.OS and branch your logic accordingly.
2. Leverage Third-Party Modules
The community has developed cross-platform modules that replicate functionality. For instance, while the official Active Directory module is Windows-only, there are open-source implementations like DSInternals (with limitations) or LDAP-based approaches using standard .NET classes. For DNS, you can use .NET's System.Net.Dns class directly, which works across all platforms.
```powershell
Cross-platform DNS resolution using .NET
[System.Net.Dns]::GetHostAddresses("example.com") ``` This approach bypasses the need for a specific PowerShell module entirely, relying on the underlying .NET runtime which is consistent across versions. 3. Run PowerShell 5.1 on Windows If your workflow is strictly Windows-based and requires legacy cmdlets, continue using the Windows PowerShell host (powershell.exe) rather than PowerShell Core (pwsh.exe). You can invoke PowerShell 5.1 explicitly from PowerShell Core if necessary, though this introduces overhead. For daily administration on Windows servers, sticking to PowerShell 5.1 remains the most stable path for AD and DHCP management.
For more context on how command-line behaviors differ between shells, see our guide on Command Prompt Drive Switching Different From PowerShell.
Managing Module Availability
You can inspect which modules are available in your current PowerShell Core installation by runningGet-Module -ListAvailable. You will notice a significantly smaller list compared to PowerShell 5.1. Microsoft provides a curated list of cross-platform modules on the PowerShell Gallery. Searching for modules with the tag "CrossPlatform" or checking their documentation for supported operating systems is essential before adoption.
Additionally, consider using Import-Module with the -ErrorAction SilentlyContinue parameter if you are writing portable scripts that might run on both engines. This prevents the script from terminating if a non-critical Windows module fails to load.
See also: Run Powershell command from cmd with parameters for related shell interoperability issues.
Frequently Asked Questions
Can I install Windows modules into PowerShell Core?
No, you cannot install Windows-specific modules like Active Directory into PowerShell Core because they rely on .NET Framework binaries that do not exist in the cross-platform runtime. You must use PowerShell 5.1 on Windows to access these features.Why does Get-Module show fewer results in PowerShell Core?
PowerShell Core excludes modules that depend on Windows-only technologies such as WMI, COM objects, and the Windows Registry provider. This reduction ensures the engine remains lightweight and portable across Linux and macOS.How do I check my PowerShell version programmatically?
You can check the version by examining the$PSVersionTable automatic variable. The PSEdition property will display "Desktop" for PowerShell 5.1 and "Core" for PowerShell 7+, helping you debug compatibility issues.
Are there alternatives to Resolve-DnsName in PowerShell Core?
Yes, you can use the[System.Net.Dns] static class in .NET to perform DNS lookups. This method is fully cross-platform and does not require any additional modules or Windows-specific cmdlets.