Install RSAT on Windows 11 and Manage Active Directory Remotely

Your Windows 11 workstation already trusts the domain controller the moment it joins the domain, but it can’t manage anything on it yet. Remote Server Administration Tools close that gap: they put Active Directory Users and Computers, Group Policy Management and the DNS console on your own desk, so you stop opening an RDP session to a DC every time someone needs a new account. You install RSAT on Windows 11 as Features on Demand pulled from Windows Update, there’s no separate download any more, and only Pro and Enterprise get them.

Original content from computingforgeeks.com - post 180525

We installed the tools with PowerShell, timed each one, found the Settings route, then used them against a Windows Server 2025 domain to create a user, a DNS record and a linked GPO. We also pointed the client at WSUS to break the install on purpose, and the usual Group Policy fix didn’t repair it. We confirmed the PowerShell install and every management step below working on Windows 11 Enterprise 24H2 against a Windows Server 2025 domain controller in October 2026, and we say plainly where a step did not work.

Check the edition and the lab before you start

RSAT installs on Windows 11 Pro and Enterprise only. Microsoft’s RSAT install page lists those two editions for Windows 11 and nothing else, so a Home machine needs an edition upgrade before any of this applies. Arm64 is a separate case: Microsoft’s Features on Demand list notes that RSAT FODs aren’t supported on Windows 11 25H2 Arm64, so this guide covers x64 only. The client also has to reach Windows Update during the install, because the payload is not on the disk until you ask for it.

Our lab had two Windows machines on one network plus an Ubuntu host for the comparison at the end. Everything in the RSAT sections runs on the Windows 11 side, and the domain controller only answers. The DC is a Windows Server 2025 Datacenter box running AD DS and DNS for corp.example.com at the Windows2025Domain functional level; building one is covered in our Active Directory Domain Services install guide. Line up these three pieces before the first command:

1. Promote dc01.corp.example.com and confirm DNS answers for the domain.
2. Join win11-lab (24H2, build 26100.9457) to the domain with dc01 as its DNS server.
3. Sign in with a Domain Admins account for the writes.

Our client had 4 vCPUs and 8 GB of RAM, which matters for the timings later on. Read-only lookups work with any domain user, so a help-desk account without admin rights can still run every Get- command in this guide.

The diagram shows how the pieces talk once the tools are in. The install itself is the only step that leaves the network, and every console after that goes straight to dc01 on its own port:

The port numbers on the arrows are the TCP connections we saw open from the client while each module worked. They’re not the whole firewall story, since short-lived and UDP traffic (Kerberos, DNS) never showed up in those snapshots. The GPO section lists the rest. Confirm the edition first, because that one fact decides whether the rest of this page applies to you. Open PowerShell as administrator on the client:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsEditionId, OsBuildNumber, OsDisplayVersion

Our client printed this, and the first line is not a typo. It came from the same Windows 11 machine whose edition ID reads Enterprise:

WindowsProductName : Windows 10 Enterprise Evaluation
WindowsEditionId   : EnterpriseEval
OsBuildNumber      : 26100
OSDisplayVersion   : 24H2

Windows 11 still carries “Windows 10” in the product name that Get-ComputerInfo reports, so trust WindowsEditionId and the build number instead. Build 26100 is 24H2. An edition ID of Professional, Enterprise or EnterpriseEval means RSAT is available to you; Core is the Home edition, and you can stop here.

List the RSAT features on demand

Every RSAT tool is a separate Windows capability with a name like Rsat.Dns.Tools~~~~0.0.1.0, and you install only the ones you manage. Listing them first gives you the exact names to paste into the install command, and it tells you whether the client can see the feature catalogue at all:

Get-WindowsCapability -Online | Where-Object Name -like 'RSAT*' | Format-Table Name, State -AutoSize

On 24H2 the catalogue holds 21 RSAT capabilities, all of them NotPresent on a fresh machine. Nothing ships preinstalled, so every tool you want is a separate download:

Name                                                          State
----                                                          -----
Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0             NotPresent
Rsat.AzureStack.HCI.Management.Tools~~~~0.0.1.0          NotPresent
Rsat.BitLocker.Recovery.Tools~~~~0.0.1.0                 NotPresent
Rsat.CertificateServices.Tools~~~~0.0.1.0                NotPresent
Rsat.DHCP.Tools~~~~0.0.1.0                               NotPresent
Rsat.Dns.Tools~~~~0.0.1.0                                NotPresent
Rsat.FailoverCluster.Management.Tools~~~~0.0.1.0         NotPresent
Rsat.FileServices.Tools~~~~0.0.1.0                       NotPresent
Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0             NotPresent
Rsat.IPAM.Client.Tools~~~~0.0.1.0                        NotPresent
Rsat.LLDP.Tools~~~~0.0.1.0                               NotPresent
Rsat.NetworkController.Tools~~~~0.0.1.0                  NotPresent
Rsat.NetworkLoadBalancing.Tools~~~~0.0.1.0               NotPresent
Rsat.RemoteAccess.Management.Tools~~~~0.0.1.0            NotPresent
Rsat.RemoteDesktop.Services.Tools~~~~0.0.1.0             NotPresent
Rsat.ServerManager.Tools~~~~0.0.1.0                      NotPresent
Rsat.StorageMigrationService.Management.Tools~~~~0.0.1.0 NotPresent
Rsat.StorageReplica.Tools~~~~0.0.1.0                     NotPresent
Rsat.SystemInsights.Management.Tools~~~~0.0.1.0          NotPresent
Rsat.VolumeActivation.Tools~~~~0.0.1.0                   NotPresent
Rsat.WSUS.Tools~~~~0.0.1.0                               NotPresent

The capability name is what you pass to the install command, including the ~~~~0.0.1.0 suffix. On our VM the listing alone took several minutes, so a slow first query is normal. Hyper-V Manager is missing on purpose, because Microsoft ships it on Windows clients as an optional Windows feature rather than an RSAT capability, and you enable it from “Turn Windows features on or off” instead.

Install RSAT on Windows 11 with PowerShell

PowerShell is the route we’d take on more than one machine, because the same lines drop into a script or a task sequence without change. Add-WindowsCapability hands the request to the Windows Update client, which downloads the payload and passes it to the servicing stack to install. Install the three tools most domain admins use daily: Active Directory (ADUC plus the ActiveDirectory module), Group Policy Management and DNS:

Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0
Add-WindowsCapability -Online -Name Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0
Add-WindowsCapability -Online -Name Rsat.Dns.Tools~~~~0.0.1.0

Each call returns this block when it finishes, and RestartNeeded : False means the tool works right away without a reboot:

Path          :
Online        : True
RestartNeeded : False

Budget real time for this. We wrapped each call in Measure-Command, and on our 4 vCPU VM the three installs took 3,437, 3,854 and 3,730 seconds, close to an hour each. Treat those numbers as a slow case, not the norm: this was a freshly cloned evaluation VM, and Windows Update was also working through its own backlog (Defender platform, the malicious software removal tool and Store app updates) while our installs waited. On a machine that is already patched and idle, expect less.

RSAT install stuck at 50% or 100%

That hour does not move smoothly, and it is the reason so many people think RSAT is broken on Windows 11. Our installs sat at 50% for 20 minutes or more, then at 100% for another 20 before the servicing stack picked the payload up. Watch the progress in the CBS log rather than the PowerShell window:

Get-Content C:\Windows\Logs\CBS\CBS.log -Tail 3

A new DownloadProgress line every few seconds means Windows Update is still working on it, even when the number hasn’t changed for twenty minutes. Leave it alone while lines like this keep arriving:

2026-10-30 15:25:13, Info                  CBS    FC:   FCAcquirerWUClient: WULib DownloadProgress: [100 / 100]

Don’t kill a slow install. The one time we stopped a stuck attempt, the servicing stack carried on without its caller and later closed the session with finalize status: 0x80070102, a wait timeout, and nothing was installed. Two other things held our installs up: a pending servicing reboot and a queued cumulative update. We rebooted twice to clear them before the run that completed. Check for the pending reboot before you start; True means reboot first:

Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'

Our client returned True twice during the stalled attempts and False after the reboot that preceded the successful run.

Once all three finish, confirm what landed. Check the module list as well as the capability state, because every cmdlet in the rest of this guide comes from those modules:

Get-WindowsCapability -Online | Where-Object { $_.Name -like 'RSAT*' -and $_.State -eq 'Installed' } | Format-Table Name, State -AutoSize
Get-Module -ListAvailable ActiveDirectory, GroupPolicy, DnsServer, DhcpServer | Format-Table Name, Version -AutoSize

Four capabilities show as installed, not three, and only three modules answer. Both surprises have a reason, explained right after the output:

Name                                             State
----                                             -----
Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 Installed
Rsat.Dns.Tools~~~~0.0.1.0                    Installed
Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0 Installed
Rsat.ServerManager.Tools~~~~0.0.1.0          Installed

Name            Version
----            -------
ActiveDirectory 1.0.1.0
DnsServer       2.0.0.0
GroupPolicy     1.0.0.0

Server Manager came along because the AD tools depend on it (CBS.log plans it as a “capability dependency” of the AD install), so it shows as installed even though you never asked for it. DhcpServer is missing from the module list because we didn’t install Rsat.DHCP.Tools in this round, and that missing module is exactly what the WSUS test below tries to add.

Install RSAT from Settings

The Settings app reaches the same capabilities through a dialog, which suits a one-off install on your own laptop. On 24H2 the page is Settings > System > Optional features, and the dialog behaves differently from the older “Add an optional feature” screen that most guides still describe:

1. Click View features next to “View or edit optional features”.

The dialog that opens lists the features you already have, not the ones you can add. Ours showed 16 added features and no RSAT at all, which is easy to misread as “RSAT isn’t available here”:

2. Click See available features at the top of the dialog to switch from the added list to the catalogue of features you can add.

From there, Microsoft’s instructions are to search for the tool, select it, then choose Next and Install. We stopped at the screen above and ran every install through PowerShell instead, because it gives you the elapsed time and an error code when something fails, and the Settings dialog gives you neither. Whichever route you take, the payload comes from the same Windows Update source, so expect the same long wait and watch CBS.log the same way.

Test RSAT on a WSUS-managed PC

Most corporate Windows 11 machines do not talk to Windows Update directly. A GPO points them at an internal WSUS server, and Add-WindowsCapability then asks that server for the RSAT payload instead of Microsoft’s. To reproduce it, we set the same three registry values a WSUS GPO writes, pointing at a WSUS host name the client couldn’t reach (a decommissioned or misconfigured WSUS), and asked for the DHCP tools. Run this only on a throwaway lab VM, never on a production client: as the next section shows, deleting the values afterwards did not give us a working Windows Update back.

$wu = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate'
New-Item -Path "$wu\AU" -Force | Out-Null
Set-ItemProperty $wu WUServer 'http://wsus01.corp.example.com:8530'
Set-ItemProperty $wu WUStatusServer 'http://wsus01.corp.example.com:8530'
Set-ItemProperty "$wu\AU" UseWUServer 1 -Type DWord
Restart-Service wuauserv -Force
Add-WindowsCapability -Online -Name Rsat.DHCP.Tools~~~~0.0.1.0

The failure shows up much faster than a successful install does, and the error code is the first clue to where the request went.

Error: “Add-WindowsCapability failed. Error code = 0x80240438”

Instead of the hour the earlier installs needed, this one gave up after 71 seconds. PowerShell reported it as a COM exception with this message:

Add-WindowsCapability failed. Error code = 0x80240438

The capability stayed NotPresent, and CBS.log logged Failed to perform operation. [HRESULT = 0x80240438 - Unknown Error] when it closed the session. Where WSUS does answer but has nothing to offer, admins report the same install failing with 0x800f0954 instead (one example is this Microsoft Q&A thread). Our lab had no working WSUS, so we didn’t reproduce 0x800f0954. To see which server Windows Update actually called, decode its log. We ran this during a later retry, after we had already removed the WSUS policy and rebooted, which makes the result even more telling:

Get-WindowsUpdateLog -LogPath C:\lab\wu.log
Select-String -Path C:\lab\wu.log -Pattern 'Server URL|WS error'

The decode took about two minutes on our VM. The lines around the failure name the WSUS endpoint and the reason the call died:

2026/10/30 18:34:28.9300621 5064  9360  ProtocolTalker  ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://wsus01.corp.example.com:8530/ClientWebService/client.asmx (cV = bfVhgDbvsU6aossF.1.1.0.0.2.0)
2026/10/30 18:34:28.9830528 5064  9360  WebServices     WS error: There was an error communicating with the endpoint at 'http://wsus01.corp.example.com:8530/ClientWebService/client.asmx'.
2026/10/30 18:34:28.9830629 5064  9360  WebServices     WS error: The given proxy cannot be reached.
2026/10/30 18:34:28.9833748 5064  9360  WebServices     MapToSusHResult mapped Nws error 0x803d0010 to 0x80240438

That confirms the cause: the request for the RSAT payload still went to WSUS, not Windows Update, even with the policy gone. If your log shows Microsoft’s endpoints instead, WSUS is not your problem and the stuck-install section above is the one to read.

Point optional features back at Windows Update

The fix every guide gives is the “Specify settings for optional component installation and component repair” policy under Computer Configuration > Administrative Templates > System, with a checkbox that reads “Download repair content and optional features directly from Windows Update instead of WSUS”. On our Windows 11 24H2 client and our Server 2025 DC, that checkbox does not exist any more. The Servicing.admx both machines ship defines exactly one element for the policy:

<text id="LocalSourcePath_TextBox" valueName="LocalSourcePath" expandable="true"/>

So the Group Policy editor shows only an “Alternate source file path” box, which takes a folder or a WIM file holding the payload. The registry value the old checkbox used to write is RepairContentServerSource = 2, and you can still push it with the GroupPolicy module. We tried exactly that, linked at the domain root so it reached the client in the default Computers container. In a real domain, link it to an OU that holds only your test machines, because a root link applies to every computer including the DCs:

New-GPO -Name "Optional features from Windows Update"
Set-GPRegistryValue -Name "Optional features from Windows Update" -Key "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Servicing" -ValueName RepairContentServerSource -Type DWord -Value 2
New-GPLink -Name "Optional features from Windows Update" -Target "DC=corp,DC=example,DC=com"

On the client, pull the policy and check that the value landed before retrying the install. Skipping this check means a failed retry could just be a policy that never arrived:

gpupdate /target:computer /force
Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing

gpupdate reported “Computer Policy update has completed successfully”, and the key held the value. So the policy itself reached the client:

CountryCode               : KE
RepairContentServerSource : 2

It didn’t help. The DHCP tools install failed again with 0x80240438 after 35 seconds, again after a wuauserv restart (27 seconds) and again after a full reboot (28 seconds). We also tried the workaround most forum threads give, setting UseWUServer to 0 and restarting wuauserv, and that failed the same way in 20 seconds. With an unreachable WSUS, Windows Update ignored the old value and kept sending the payload request to WSUS. We didn’t have a working WSUS server to test against, so we can’t say whether the value behaves differently when WSUS answers.

Taking the client off WSUS didn’t fix it straight away either. We deleted the whole WindowsUpdate policy key, which is the undo for the repro above, and rebooted:

Remove-Item HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate -Recurse -Force

The next install attempt still failed with 0x80240438 after 30 seconds. Asking Windows Update which service it treats as the default shows why:

(New-Object -ComObject Microsoft.Update.ServiceManager).Services | Select-Object Name, IsDefaultAUService, IsManaged

Check this before you blame anything else, because it is the reason the next install attempt fails exactly like the last one:

Name                          IsDefaultAUService IsManaged
----                          ------------------ ---------
DCat Flighting Prod                        False     False
Windows Store (Prod)                       False     False
Windows Server Update Service               True      True
Windows Update                             False     False

The three installs that worked here all ran before the WSUS policy existed, and that ordering is the most useful thing this test produced. We also started a full Windows Update component reset on the lab client (stopping the services and renaming SoftwareDistribution and catroot2), but lost access to the lab before we could read its result, so we can’t offer it as a tested recovery. When you finish testing, remove the GPO with Remove-GPO -Name "Optional features from Windows Update", which also deletes its links. Do not trust the old checkbox advice on a 24H2 WSUS client without checking the result. Work through it in this order:

1. Install RSAT before the PC lands in a WSUS-managed OU, or bake it into your image.
2. On a WSUS client, run the ServiceManager query; WSUS as default means the install will fail.
3. Decode the Windows Update log to confirm which endpoint the request went to.
4. Plan on the “Alternate source file path” with Features on Demand media (we did not test it).

Step 4 is the only source option the current policy still exposes, which is why we’d budget for it rather than for the checkbox. Our WSUS on Windows Server 2025 guide covers the server side if you’re setting one up.

Manage Active Directory users and groups from Windows 11

With the tools installed, the client talks to the domain controller directly. The ActiveDirectory module finds a DC through DNS, so there’s no server name to pass, and every cmdlet runs as the signed-in user. Sign in to Windows 11 with a domain admin account and check that the module reaches the domain:

Get-ADDomain | Select-Object DNSRoot, NetBIOSName, DomainMode, PDCEmulator

A domain name, its functional level and the PDC emulator coming back means the client found a DC and authenticated to it. If it errors instead, check that the client resolves the domain name first, since that lookup is how the module finds a DC:

DNSRoot          NetBIOSName        DomainMode PDCEmulator
-------          -----------        ---------- -----------
corp.example.com CORP        Windows2025Domain dc01.corp.example.com

Now create an OU for lab accounts, a user inside it, a group, and the membership that ties them together. These writes are most of daily help-desk work, and doing them from your own desk is the point of RSAT. The plain-text password is a throwaway lab value. In a real script, swap that line for $pw = Read-Host -AsSecureString so the password never lands in your history:

New-ADOrganizationalUnit -Name "Lab Users" -Path "DC=corp,DC=example,DC=com"
$pw = ConvertTo-SecureString "Lab-Only-Pass2!" -AsPlainText -Force
New-ADUser -Name "Jane Doe" -SamAccountName jdoe -UserPrincipalName [email protected] -Path "OU=Lab Users,DC=corp,DC=example,DC=com" -AccountPassword $pw -Enabled $true
New-ADGroup -Name "Helpdesk" -GroupScope Global -Path "OU=Lab Users,DC=corp,DC=example,DC=com"
Add-ADGroupMember -Identity Helpdesk -Members jdoe

None of those commands prints anything when it succeeds, which is normal for the AD module, so read the user back to confirm all of it landed. One query covers all four writes:

Get-ADUser jdoe -Properties MemberOf | Select-Object SamAccountName, Enabled, DistinguishedName, MemberOf

The account sits in the new OU, it’s enabled, and its MemberOf list carries the Helpdesk group, which proves the group write and the membership write both reached the directory:

SamAccountName Enabled DistinguishedName                                  MemberOf
-------------- ------- -----------------                                  --------
jdoe              True CN=Jane Doe,OU=Lab Users,DC=corp,DC=example,DC=com {CN=Helpdesk,OU=Lab Users,DC=corp,DC=example,DC=com}

The graphical console needs no extra setup either. Type dsa.msc in the Start menu and Active Directory Users and Computers opens already attached to the domain the PC belongs to:

It’s the same directory the cmdlets above wrote to, so the console and PowerShell are two views of one set of objects. Use whichever suits the job: the console for one-off fixes, the module for anything you’ll repeat, because a script leaves a record of what it changed and a click doesn’t.

Add DNS records on the domain controller

The DNS tools work differently from the AD module: they talk RPC to one named DNS server, so every cmdlet needs -ComputerName. List the zones on dc01 first:

Get-DnsServerZone -ComputerName dc01 | Select-Object ZoneName, ZoneType, IsDsIntegrated

The AD-integrated zones are the ones that replicate with the directory, and corp.example.com is where host records go. Our DC returned five zones:

ZoneName                ZoneType IsDsIntegrated
--------                -------- --------------
_msdcs.corp.example.com Primary            True
0.in-addr.arpa          Primary           False
127.in-addr.arpa        Primary           False
255.in-addr.arpa        Primary           False
corp.example.com        Primary            True

There’s no reverse zone for the LAN, only the three built-in ones. That’s how our freshly promoted DC came up, so PTR records for the subnet have nowhere to go until you create a reverse zone (our Windows Server DNS guide walks through it). Leaving out -ComputerName is the mistake people make on day one, and the error names the client, not the DC:

Failed to enumerate zones from the server WIN11-LAB.

Add an A record for a new application server, then resolve it against the DC to prove the record is live and not just written:

Add-DnsServerResourceRecordA -ComputerName dc01 -ZoneName corp.example.com -Name app01 -IPv4Address 10.0.1.50
Resolve-DnsName app01.corp.example.com -Server dc01

The add prints nothing on success. The lookup answers from dc01 with the new address and a TTL of 3600 seconds, since we didn’t set one:

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
app01.corp.example.com                         A      3600  Answer     10.0.1.50

A record that resolves from the DC itself is live for every client that uses dc01 as its resolver, so there’s no restart or zone reload to do. The same command works for any record you’d otherwise add by signing in to the DC, which is the whole reason to have the DNS tools on your workstation.

Create and link a GPO from the client

Group Policy Management writes the GPO object into AD and its files into SYSVOL on the DC. Create a GPO, link it to the Lab Users OU and read the link back. What goes inside it (drive maps, printers, an ADMX central store) is a separate job; here the point is that the client can create and link the object at all:

New-GPO -Name "Workstation baseline" -Comment "Created from win11-lab with RSAT"
New-GPLink -Name "Workstation baseline" -Target "OU=Lab Users,DC=corp,DC=example,DC=com"
Get-GPInheritance -Target "OU=Lab Users,DC=corp,DC=example,DC=com" | Select-Object -ExpandProperty GpoLinks

The link read back from the OU is the part to check, because New-GPO on its own only creates an unlinked object that applies to nobody. Ours came back like this:

GpoId       : 2752e2d4-e0a8-496e-8944-9c5a8c281956
DisplayName : Workstation baseline
Enabled     : True
Enforced    : False
Target      : ou=lab users,dc=corp,dc=example,dc=com
Order       : 1

Enabled : True with Order : 1 means the GPO is the only policy linked to Lab Users, so it applies to jdoe once you add settings to it. New-GPO reported the owner as CORP\Domain Admins and the status as AllSettingsEnabled, so neither the user half nor the computer half is switched off.

While each module was working, we listed the client’s open TCP connections to dc01. A snapshot like this only catches connections that are open at that moment, so treat the table as what we observed, not a complete firewall rule set:

Module in use	Ports seen to dc01	What it is
ActiveDirectory	9389, 135, 49682	AD Web Services, plus RPC
GroupPolicy	445, 135, 49682	SMB to SYSVOL, plus RPC
DnsServer	135, 49730	RPC endpoint mapper and a dynamic port

The 49xxx numbers are dynamic RPC ports, so they’ll differ on your DC. Allow the dynamic range rather than those exact values. The AD module is the one that surprises people: its connections went to TCP 9389 (AD Web Services), not to the LDAP port, so a rule set written for LDAP alone does not cover the cmdlets. The authentication and lookups behind every cmdlet also need Kerberos (88), DNS (53) and LDAP (389) to the DC, which Microsoft lists with the RPC range in its AD firewall port reference. Start from that list, which already includes 9389 for AD Web Services.

Compare RSAT with samba-tool and net ads on Linux

Plenty of AD shops run their tooling from Linux boxes, so we pointed the Samba client tools on an Ubuntu 26.04 machine (Samba 4.23.6 from the Ubuntu archive) at the same dc01 and tried the same jobs. The result split by protocol: the RPC-based DNS commands worked first time, and the LDAP-based samba-tool user commands did not. samba-tool dns manages the Windows DNS server over RPC, so adding a record from Linux is one line. Our DC sat at 192.168.1.144, so swap in your own DC’s address (or its name, if the Linux box resolves it):

samba-tool dns add 192.168.1.144 corp.example.com app02 A 10.0.1.51 -U 'CORP\Administrator'
samba-tool dns query 192.168.1.144 corp.example.com app02 A -U 'CORP\Administrator'

Both commands prompt for the password, and the query reads the new record straight back from dc01. Note the 900-second TTL, shorter than the 3600 seconds the PowerShell record got:

Record added successfully
  Name=, Records=1, Children=0
    A: 10.0.1.51 (flags=f0, serial=0, ttl=900)

Listing users is where Linux got awkward. samba-tool user list -H ldap://192.168.1.144 -U 'CORP\Administrator' failed against the Windows DC with an LDAP bind error, even though the same domain admin credentials had just worked for samba-tool dns. Adding --use-kerberos=required only changed the error to ldb_search: invalid basedn '(null)'. We didn’t isolate the cause, but the same credentials worked against the same DC over RPC and through net ads, which points at samba-tool’s LDAP path on this Ubuntu build rather than at the DC. The first error looked like this:

ERROR(ldb): uncaught exception - 000004DC: LdapErr: DSID-0C090D44, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v65f4

The older net ads tool from the same Samba package completed the bind with the same account, so for read-only queries it’s the Linux command we’d reach for:

net ads search -S 192.168.1.144 -U Administrator --realm=CORP.EXAMPLE.COM -W CORP '(objectClass=user)' sAMAccountName

It returned every user object in the domain, including the jdoe account we created from Windows 11 a few minutes earlier. Seven replies came back:

Got 7 replies

sAMAccountName: Administrator

sAMAccountName: Guest

sAMAccountName: cloudbase-init

sAMAccountName: DC01$

sAMAccountName: krbtgt

sAMAccountName: WIN11-LAB$

sAMAccountName: jdoe

Computer accounts (the names ending in $) show up because they are user-class objects too, and cloudbase-init is a service account our server template left behind. Linux machines that only need to authenticate against the domain are a different job, covered in our guides to join Rocky Linux and RHEL to Active Directory and Ubuntu and Debian to AD. For management, the two toolsets came out like this against the same DC:

Job against dc01	RSAT on Windows 11	Samba tools on Ubuntu 26.04
Create a user, group and membership	Worked (ActiveDirectory module)	Not done: samba-tool user failed to bind over LDAP
List users	Worked (Get-ADUser, ADUC)	Worked with net ads search
Add and query a DNS record	Worked (DnsServer module)	Worked with samba-tool dns
Create and link a GPO	Worked (GroupPolicy module)	Not tested
Manage DHCP	Tools didn’t install in our WSUS test	No DHCP subcommand in samba-tool

Our verdict from the two sessions: Linux covers DNS records and read-only directory queries well enough for scripts and monitoring, so a Linux admin who only adds the odd A record can skip Windows entirely. Anyone who creates accounts or edits Group Policy on a Windows domain should run RSAT on a Windows 11 Pro or Enterprise machine, because that’s the only toolset here that did those jobs without a workaround. Everything in the table ran against a Windows Server 2025 DC; a Samba-based DC is a different target, and we didn’t test either toolset against one.