- Change Windows startup programs with Sysinternals Autoruns - Fri, Sep 16 2022
- Robocopy examples - Wed, Aug 10 2022
- Patch management tips: Updating IT systems in large and small networks - Wed, Oct 20 2021
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.
Since we're discussing PowerShell here, let's stick to it and install the feature with PowerShell a command:
Note that I'm doing this in PowerShell 7. If you don't have PowerShell 7 yet, follow this post to get it.
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.
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.
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.
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.
OK, so let's go further and install the WMF 5.1 Framework. After the installation and reboot, I made another attempt.
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.
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:
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).
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?