- AccessChk: View effective permissions on files and folders - Thu, Apr 13 2023
- Read NTFS permissions: View read, write, and deny access information with AccessEnum - Wed, Mar 29 2023
- Kill Windows a process with Tskill and Taskkill - Mon, Mar 13 2023
Managing and interacting with Active Directory is one of the most common tasks for any Windows administrator. For many years, the AD module for Windows PowerShell 5.1 (default PowerShell version in Windows 10) was part of the Remote Server Administration Tools (RSAT). This changed with the Windows 10 October 2018 update, where RSAT was included as a set of "features on demand."
In PowerShell Core 6.0, the first version of cross-platform PowerShell, most of the Windows management modules were available only via the Windows Compatibility module.
This has changed in PowerShell 7, where most of the modules have been updated to work natively, including Active Directory. However, there seems to be one significant drawback. According to the PowerShell 7 module compatibility, these modules are only supported on Windows Server 2019 and Windows 10 systems. So, let's see what Microsoft has prepared for us.
Windows Server 2019
PowerShell 7 AD module support starts with Windows Server 1809, which is a semiannual release version of Windows Server 2019. The installation has not changed from previous versions and is still performed via Server Manager. Go to Add Roles and Features, and click Next until you get to Features. Then select Active Directory module for Windows PowerShell, as shown in the image.
Install AD module on Windows Server 2019 via Server Manager
Since we're discussing PowerShell here, let's stick to it and install the feature with PowerShell a command:
Install-WindowsFeature RSAT-AD-PowerShell
Note that I'm doing this in PowerShell 7. If you don't have PowerShell 7 yet, follow this post to get it.
Install AD module with PowerShell
Windows 10
Support for Windows 10 starts with the same version build as with the server edition: 1809. As I already mentioned, the RSAT tools were shifted from being a standalone package to being a feature on demand in Windows 10. Select App and Features > Optional Features > Add a feature. Type RSAT in the search field and select the second option—RSAT: Active Directory Domain Services and Lightweight Directory Services Tools.
Install the AD module on Windows 10
If you want to add the feature with PowerShell, the command is a bit different from the server version.
Get-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools\~\~\~\~0.0.1.0 | Add-WindowsCapability –Online
Note: You can omit the version number from the Name parameter.
Install the AD module with PowerShell on Windows 10
As you can see, everything works well in both the desktop and the server editions. The module is automatically imported when you run the first command.
Windows Server 2016
According to the documentation, the module is only supported in the Windows versions listed above. Let's see what happens if we try to install and use the module in older versions.
First, I tested it with Windows Server 2016. After installing PowerShell 7, I added the Active Directory module using the Install-WindowsFeature RSAT-AD-PowerShell command and tried to run a query on the computer objects.
Testing the PowerShell 7 AD module on Windows Server 2016
What a surprise! The module works well, even on Windows Server 2016. Is there another inconsistency in Microsoft's own documentation, or is there a specific reason to leave version 2016 out of support?
Windows Server 2012 R2 and Windows 8.1
My last test was done on Windows 8.1, which is the same core as Windows Server 2012 R2. PowerShell 7 is supported on both systems, but the AD module is not. After spinning up the VM and installing PowerShell 7 and the standalone RSAT package for Windows 8.1, I got the following error messages when trying to query AD:
Get-ADComputer: The 'Get-ADComputer' command was found in the module 'ActiveDirectory', but the module could not be loaded. For more information, run 'Import-Module ActiveDirectory'.
Get-ADUser: The 'Get-ADUser' command was found in the module 'ActiveDirectory', but the module could not be loaded. For more information, run 'Import-Module ActiveDirectory'.
When you do as the error message suggests and run the Import-Module ActiveDirectory command, you get another error message.
Import-Module: Detected Windows PowerShell version 4.0. Windows PowerShell 5.1 is required to load modules using Windows PowerShell compatibility feature. Install Windows Management Framework (WMF) 5.1 from https://aka.ms/WMF5Download to enable this feature.
Testing on Windows 8.1
OK, so let's go further and install the WMF 5.1 Framework. After the installation and reboot, I made another attempt.
AD module on unsupported Windows 8.1
Unsurprisingly, it works fine. Wondering why? The answer is simple. PowerShell 7 still uses the same old AD module from Windows PowerShell 5.1 (WMF 5.1). The only difference now is that it is natively supported and can be used without the Windows Compatibility module, as was the case in PowerShell Core 6.
Linux/macOS
So far, it is obvious that the AD module cannot be run on either Linux or macOS. The reason is pretty simple. The module is part of the RSAT tools, which are not available for either platform at all. So if you wish to manage AD from a Linux or macOS machine, you still need to have a Windows machine around to connect to.
In general, the basic remoting principles can be used here:
- Enter-PSSession
- Invoke-Command
The screen below shows SSH remoting to a Windows machine from CentOS. As you can see, I could use the AD module this way (assuming it is installed on the remote machine).
Using the AD module via Linux SSH remoting
Note: Remoting to a Windows machine from Linux or macOS is only possible via SSH. Instructions on how to set up SSH remoting can be found here.
Final words
In this post, we took a deep dive into where the Active Directory module for PowerShell 7 actually works, although it is stated as unsupported on some of the systems. The inconsistencies in Microsoft's own documentation about PowerShell 7 continue to grow.
Also, the approach from Microsoft with cross-platform compatibility is quite unsatisfying. What kind of cross-platform compatibility is it when you are unable to manage many of the standard Windows features from Linux or macOS? For most of the common administration tasks, you still need a Windows machine around.
Many scripts written for Windows will not work on Linux simply because the needed modules are not available. Considering that the vast majority of admins using PowerShell work on Windows, Microsoft should focus on backward combability instead of cross-platform support because both approaches are inherently incompatible.
What's your take? What is more important for PowerShell? Backward compatibility or cross-platform support?
> What is more important for PowerShell? Backward compatibility or cross-platform support?
Backwards compatibility, hands down. The use cases for cross-platform PS in an enterprise environment are dramatically less compelling when the overall functionality of the framework seems diminished.
I have admins that won’t touch PS7 due to dropped functionality. The ActiveDirectory module and RSAT generally is a nightmare. I still can’t get the AD module to work properly on 2016 Servers (but at least they are honest in saying that it shouldn’t). PS7 should work and cover major 5.1 functionality, which absolutely includes things like ActiveDirectory and SQL. I won’t even get into the whole boondoggle that is SOAP – I’m grateful for the enhanced capability of PS7’s Invoke-*Request cmdlets, but losing SOAP was definitely a pain for lots of platforms that still use it.