• Thread Author
Support for Remote Server Administration Tools on Arm-based Windows 11 clients is no longer a roadmap promise — it’s a reality you can enable today, and it changes what IT teams can expect from Arm-powered endpoints in the field.

Background​

For years, Windows on Arm has promised the appeal of longer battery life, built‑in connectivity, and thin‑and‑light designs that suit mobile professionals. The tradeoff was perennial: many server‑management utilities and advanced administrative tools were compiled only for x64, forcing IT teams to carry a second device, use jump hosts, or rely on web consoles like Windows Admin Center when they needed to perform day‑to‑day server administration tasks.
That gap has been a frequent blocker in enterprise rollouts. Administrators want to run the same GUIs and PowerShell tooling they use on x64 laptops — Active Directory Users and Computers (ADUC), Group Policy Management Console (GPMC), DNS and DHCP consoles, and certificate management utilities — directly on their endpoint. With the February 2026 non‑security preview update Microsoft shipped into the mainstream servicing pipeline and with the targeted 26H1 release, several of those RSAT components have now been compiled natively for Arm64 and exposed to Windows 11 on Arm as installable features.
This is not a cosmetic change. It rewrites several operational assumptions about endpoint parity, manageability, and the acceptability of Arm devices in production IT environments.

What Microsoft delivered (and what it means)​

The initial RSAT lineup on Arm64​

Microsoft exposed five commonly used RSAT components for Arm‑based Windows 11 clients in the February 2026 preview update. Administrators will recognize the set immediately:
  • Active Directory Domain Services & AD LDS Tools — ADUC, delegation and domain object management, and tools for AD Lightweight Directory Services.
  • Active Directory Certificate Services (AD CS) Tools — consoles and snap‑ins for managing certificate authorities and PKI.
  • Group Policy Management Console (GPMC) — the familiar GPO authoring and troubleshooting interface.
  • DNS Server Tools — DNS Manager and command‑line DNS utilities for zone and record management.
  • DHCP Server Tools — DHCP console and scope management utilities.
Each of these components is now compiled natively for the 64‑bit Arm architecture, meaning they run as Arm64 binaries rather than under x64 emulation. For administrators that equate usability with native responsiveness and correct system integration, that is an important detail.

Where the features show up​

Microsoft exposes the Arm64 RSAT components differently depending on the Windows 11 release:
  • On broadly released builds — Windows 11 versions 24H2 and 25H2 — RSAT support for Arm64 arrives via the February 2026 non‑security preview update and appears as Optional Features (the same mechanism you’d use to add traditional RSAT modules on x64 clients).
  • On the targeted Windows 11, version 26H1 release, Microsoft integrates RSAT components as Features on Demand (FODs), which aligns the Arm experience more closely with how x64 devices already consume RSAT.
Microsoft documented the rollout as a staged delivery, and the initial exposure is anchored to the optional/preview update footprint before broader, production‑targeted availability.

Why this matters for enterprise IT​

This change collapses friction in multiple practical ways.
  • Single‑device admin workflows. Administrators who prefer using the device in their bag — including Arm laptops offering better battery life and cellular connectivity — can now run the same GUI and PowerShell flows directly, without a secondary x64 machine or remote jump host.
  • Pilots and hardware diversification. Organizations testing new Arm‑based models (Qualcomm‑based platforms and other Arm silicon) can evaluate manageability and administrative ergonomics without workarounds that distort the pilot outcomes.
  • Operational parity. Native RSAT binaries remove some of the subtle behavioral differences you get when tools run under emulation. That reduces hard‑to‑diagnose issues and makes supportability assumptions simpler.
  • Modern deployment alignment. By packaging RSAT as Optional Features and FODs, Microsoft lets IT teams adopt existing servicing and feature‑management workflows to provision admin tools.
Put plainly: for many organizations the arrival of RSAT on Arm reduces a non‑technical, procedural barrier to broader Arm adoption.

How to enable RSAT on Arm-based Windows 11 PCs​

Below are practical, step‑by‑step options for administrators and helpdesk technicians who want to enable RSAT on Arm64 devices today. These instructions reflect what Microsoft published for the February 2026 preview update and the 26H1 provisioning model.

Prerequisites and notes​

  • Your device must be running Windows 11 on an Arm64 processor.
  • For Optional Feature delivery, the device must be on Windows 11, version 24H2 or 25H2 and updated with the February 2026 non‑security preview update (the optional KB preview that contains the feature bits).
  • The new RSAT bits are fully integrated as FODs in Windows 11, version 26H1.
  • Microsoft referenced support for Windows 11 Pro and Enterprise editions — verify your device edition before proceeding on managed endpoints.
If you manage a fleet with imaging or offline servicing, plan for CAB‑based or package‑based distribution rather than per‑device UI installs.

GUI: Control Panel (for 24H2/25H2 optional update)​

  • Press Win + R, type optionalfeatures.exe, and press Enter to open the classic Turn Windows features on or off dialog.
  • Locate the desired RSAT entries — they appear under the RSAT display names — and check the boxes for the components you need.
  • Apply and restart if prompted.
When you use the Control Panel UI the DisplayName shows the RSAT labels; when automating, use the FeatureName values described below.

Settings UI: Optional Features (for 26H1 FODs)​

  • Open Settings > System > Optional features > Add an optional feature.
  • Search for the RSAT label you want (for example, “RSAT: Active Directory Domain Services and LDS Tools”).
  • Select and install. The package installs as a Feature on Demand.

Command line: PowerShell and DISM​

For scripting and remote provisioning, use the PowerShell and DISM patterns familiar to Windows admins. Use the feature’s FeatureName when scripting.
  • List optional features:
  • dism /online /get-features /format:table | findstr /i "Enabled"
  • Get-WindowsOptionalFeature -Online | Where-Object State -eq "Enabled"
  • Install a specific RSAT feature with PowerShell:
  • Enable-WindowsOptionalFeature -Online -FeatureName ActiveDirectory-DS-LDS-Tools -All -NoRestart
  • Enable-WindowsOptionalFeature -Online -FeatureName CertificateServices-Tools -All -NoRestart
  • Query an individual feature:
  • Get-WindowsOptionalFeature -Online -FeatureName <FeatureName>
For image servicing or offline deployments, export the required FOD/CAB and install it into your images using DISM or your established SCCM/MDT/Intune packaging workflows.

Deployment guidance and best practices​

Rolling RSAT to a fleet requires the usual planning steps plus a few Arm‑specific checks.
  • Pilot first. Test the RSAT modules on representative Arm hardware before broad deployment. Even native binaries can surface device‑specific driver or UEFI differences that affect functionality.
  • Audit module parity. Confirm the exact RSAT modules you need are available on Arm64. Microsoft’s initial rollout included five widely used modules; some niche or legacy RSAT components may not be present yet.
  • Use existing servicing pipelines. Distribute RSAT FODs via your normal Feature on Demand packaging or deploy Optional Feature installs through automated scripts where appropriate.
  • Credential hygiene. Don’t treat mobile Arm devices as equivalent to physically secured office laptops — enforce MFA, disk encryption, strong local policies and limit the use of cached domain credentials on unmanaged endpoints.
  • Monitoring and telemetry. Watch for event logs and application compatibility issues after deploy; gather feedback from helpdesk and escalate reproducible errors to Microsoft support channels as needed.

Limitations, risks, and caveats​

No rollout is risk‑free. Here are practical issues to consider and mitigate.
  • Staged rollout and availability. Microsoft used a preview/non‑security update channel to deliver the initial Arm64 RSAT capability. That means not every device will see the components immediately; some organizations reported the feature wasn’t visible on certain builds until the corresponding preview package installed. Expect a staged rollout.
  • Not full RSAT parity today. Microsoft’s initial announcement highlighted five key RSAT tools. If your workflows rely on additional or less‑common RSAT modules, verify availability before relying on Arm clients exclusively.
  • UI vs. headless server scenarios. RSAT GUIs are useful, but some administers prefer PowerShell and remote management APIs. Confirm that any PowerShell modules and underlying cmdlets behave identically on Arm64 binaries as on x64, particularly when automating cross‑architecture tasks.
  • Emulation confusion. While these RSAT modules are Arm64‑native, other management utilities you use (or older installs) might still be x64 and rely on emulation. That mixed environment can complicate troubleshooting.
  • Third‑party tools and plugins. Some enterprise management tools or extensions that integrate with RSAT may not be Arm‑aware. Validate any 3rd‑party console extensions or MMC snap‑ins you rely on.
  • Visibility in management consoles. Some admins reported that RSAT features didn’t appear in Optional Features until the device had the specific preview update installed. If you manage images centrally, ensure the correct package versions are present in your image or deployment pipeline.
  • Potential conflicts with previously installed equivalents. Microsoft recommended uninstalling previously installed standalone variants of certain tools (for example, Sysmon) before enabling built‑in or in‑box variants. Treat RSAT similarly: avoid overlapping installs that could cause versioning or DLL conflicts.

Security implications​

Giving more devices the ability to run administrative consoles widens the attack surface if not controlled. Consider these defensive measures:
  • Least privilege. Limit who can install or use RSAT on endpoints through group policies, device configuration policies, or role‑based access in your device management platform.
  • Endpoint protection posture. Arm‑based endpoints should meet the same baseline security posture as x64 devices: system hardening, disk encryption (BitLocker), EDR in kernel mode, and host firewall policies.
  • Conditional Access. When enabling RSAT on mobile devices (especially if they use cellular connections), require conditional access policies for administrative operations, including MFA and device compliance checks.
  • Audit trails. Ensure you retain logs of administrative actions and monitor for abnormal activity. RSAT actions often translate to AD or PKI changes — those must be tracked by SIEM and incident response playbooks.
  • User education. Operational convenience should not replace control. Train local admins on secure usage patterns, like avoiding persistent privileged sessions on personally owned or unmanaged Arm laptops.

Testing checklist for IT teams​

Before declaring “RSAT on Arm is supported,” run a focused test plan:
  • Verify the device edition, OS version, and presence of the February 2026 preview package (or 26H1 FODs).
  • Install the required RSAT modules via the UI and via scripted methods to confirm consistent behavior.
  • Validate GUI functionality: open ADUC, GPMC, DNS Manager and exercise routine tasks (create user, edit GPO, add DNS records).
  • Test PowerShell cmdlets and remote management scripts that depend on RSAT modules.
  • Confirm interoperability with your identity and PKI infrastructure (enroll certificates, manage CA templates).
  • Run stress and logging scenarios to ensure no unexpected resource spikes on smaller Arm devices.
  • Document any functionality gaps and communicate them to stakeholders before broad rollout.

Operational examples and automation tips​

Automation scales efficiency for admin tool distribution. Use these patterns:
  • For a one‑off enable via PowerShell:
  • Enable-WindowsOptionalFeature -Online -FeatureName ActiveDirectory-DS-LDS-Tools -All -NoRestart
  • For image servicing at scale:
  • Export the required FOD CABs, add them to your reference image with DISM /Add-Package, and capture a new image for deployment.
  • For Intune/SCCM:
  • Package the enablement script as a device configuration script, or deploy the FOD as part of your Windows feature management workflow. Use detection logic to avoid re-applying packages to devices that already have the feature.
Document the FeatureName and DisplayName mapping in your automation templates to avoid mismatches between UI labels and script parameters.

What to watch next​

The RSAT arrival on Arm is a first major step. Expect the following in the near to mid term:
  • Broader RSAT coverage. Microsoft will likely expand the set of Arm64 RSAT modules over subsequent releases as feedback comes in. Track optional preview release notes and 26H1 guidance closely.
  • Enterprise packaging improvements. Expect Microsoft to surface clearer FOD packaging details and CAB downloads for offline servicing that align with current Windows feature management tooling.
  • Vendor and tooling compatibility work. Third‑party management suites and plugins will need updates to work seamlessly in Arm environments; plan for integration testing with vendors that ship MMC extensions or RSAT add‑ins.
  • Operational guidance and best‑practice updates. As organizations adopt the capability, communal patterns (Win‑Win) around secure provisioning, remote admin workstations, and conditional access policies will converge into recommended playbooks.

Conclusion​

The native arrival of RSAT on Arm‑based Windows 11 clients removes a conspicuous barrier that steered many IT organizations away from Arm endpoints. By delivering commonly used AD, PKI, Group Policy, DNS and DHCP tools as Arm64 binaries and packaging them as Optional Features and Features on Demand, Microsoft offers a concrete path to operational parity for administrators who prefer to work directly from the device in their hands.
This is a practical, meaningful change — but it’s not an automatic green light for fleet‑wide Arm migrations. The first release delivers the most widely used RSAT modules, but not necessarily every conceivable tooling scenario. Administrators must pilot, validate automation and security controls, and confirm the exact feature set they depend on before swapping out standard x64 management endpoints.
If you manage Windows infrastructure, plan a measured test: enable the new RSAT modules in a controlled environment, validate your PowerShell automation, and confirm security posture before scaling. Do that, and you’ll be able to reap the mobility and battery advantages of Arm devices while keeping the full administrative toolkit you rely on.

Source: Microsoft - Message Center RSAT capabilities arrive on Arm-based Windows 11 PCs - Windows IT Pro Blog
 
Remote Server Administration Tools (RSAT) are finally available natively on Arm-based Windows 11 PCs, closing a long‑standing capability gap that prevented many administrators from using Arm laptops and tablets as first‑class management endpoints in corporate environments.

Background​

For years, administrators who wanted to manage Windows Server infrastructure from an Arm‑based Windows client faced a painful compromise: use alternative management channels such as Windows Admin Center or remote into an x64 machine, run RSAT on x64 hardware, or rely on slower emulation and unsupported workarounds. Those constraints have been a material roadblock to deploying Arm‑based PCs more broadly within enterprises, especially for IT staff who need to perform day‑to‑day tasks like editing Group Policy, managing Active Directory, or administering DNS/DHCP from the desktop.
This changed with the February 2026 non‑security preview cumulative update for Windows 11 (the KB5077241 preview package). Microsoft compiled key RSAT components for the Arm64 architecture and exposed them as installable optional components on current Windows 11 builds, and as Features on Demand (FODs) in the forthcoming 26H1 release. That engineering work brings a subset of the most widely used RSAT modules — with native Arm64 binaries — to Windows 11 Pro and Enterprise devices running on Arm processors.

What exactly landed for Arm64 users​

Microsoft’s rollout initially delivers five of the most commonly used RSAT components compiled natively for Arm64. Administrators will now find these tools available for installation on Arm‑based Windows 11 devices after applying the February 2026 update:
  • Active Directory Domain Services & AD LDS Tools — GUI and cmdlets for managing users, computers, OUs, and Lightweight Directory Services instances.
  • Active Directory Certificate Services (AD CS) Tools — management consoles and utilities for certificate services and PKI administration.
  • Group Policy Management Console (GPMC) — the classic MMC snap‑in to create, link, and edit Group Policy Objects.
  • DNS Server Tools — DNS Manager and command‑line utilities for configuring and troubleshooting DNS servers.
  • DHCP Server Tools — consoles and tools to configure scopes, reservations, and DHCP server settings.
These tools are available as optional components for Windows 11 versions 24H2 and 25H2 once the preview update is installed. On Windows 11 version 26H1, they will be exposed as Features on Demand (FODs) surfaced through Settings > System > Optional Features > Add an optional feature, which aligns Arm64 behavior with how non‑Arm (x64) RSAT is presented.

Why this matters — practical implications for IT​

The arrival of RSAT on Arm64 is more than a checkbox on a compatibility list; it changes how organizations can treat Arm devices.
  • Management parity for administrators. IT professionals can now use familiar GUIs and PowerShell RSAT modules from their preferred Arm laptop or tablet without relying on emulation or remote access to x64 hardware.
  • Better device choice for mobility and battery life. Arm‑based devices typically shine on battery life and cellular connectivity; making RSAT available removes a key reason IT would avoid issuing Arm devices to helpdesk and server administrators.
  • Simpler lab and test workflows. QA and testing teams that use Arm hardware to evaluate power profiles and application behavior can perform server administration locally without maintaining a separate x64 workstation.
  • Consistency across mixed environments. Organizations that already run a mix of x64 and Arm clients gain a unified management model, simplifying documentation and admin training.
That said, this release is pragmatic rather than exhaustive. Microsoft compiled a subset of RSAT modules for Arm64 with the goal of addressing the highest‑impact scenarios first. Administrators should expect incremental expansion over time rather than immediate feature parity with every legacy RSAT snap‑in.

How to get and install RSAT on Arm64 Windows 11​

There are two primary paths depending on your Windows 11 release:

For Windows 11 versions 24H2 and 25H2 (current stable builds)​

RSAT components arrive as optional Windows components included in the February 2026 non‑security preview cumulative update. Steps to enable:
  • Confirm your device is running Windows 11 version 24H2 or 25H2, and install the February 2026 preview update (the optional KB package).
  • Open the Control Panel and go to Programs > Turn Windows features on or off (or run optionalfeatures.exe).
  • Locate the RSAT entries (they may show as DisplayName entries such as “RSAT: Active Directory Domain Services and LDS Tools”) and check the boxes for the tools you need.
  • Reboot if prompted. The tools should appear in Administrative Tools, or the corresponding PowerShell modules will be available.
Command‑line installation examples (use elevated PowerShell or an elevated command prompt):
  • To list available optional features:
  • Get‑WindowsOptionalFeature ‑Online | Where‑Object State ‑eq "Disabled"
  • To enable AD DS tools:
  • Enable‑WindowsOptionalFeature ‑Online ‑FeatureName ActiveDirectory‑DS‑LDS‑Tools ‑All ‑NoRestart
DISM can also be used to query and add features if you prefer scripted deployment.

For Windows 11 version 26H1 (targeted behavior)​

Starting in 26H1, RSAT components will be distributed as Features on Demand (FODs) and manageable through Settings:
  • Settings > System > Optional Features > Add an optional feature.
  • Search for "RSAT" and select the specific RSAT modules you need (e.g., RSAT: DNS Server Tools).
  • Install and restart as required.
For enterprise offline scenarios, use the Features on Demand ISO or Microsoft Update Catalog packages. The combined servicing stack update and LCU packaging means you may need the correct servicing stack version installed before applying some packages; the preview KB includes instructions for both online and offline installation using DISM and Add‑WindowsPackage.

Deployment and management considerations for enterprises​

Rolling RSAT out to many Arm devices in production requires planning. Here are the key operational points administrators should consider:
  • Confirm build and update availability. The initial delivery was packaged in the February 2026 non‑security preview (OS build identifiers were published with the KB). Devices must receive that update before RSAT components are visible.
  • Windows Update vs WSUS/ConfigMgr. If your environment uses WSUS or a managed update pipeline, ensure the preview/non‑security update is approved or that clients are configured to get Optional Preview updates where necessary. Some organizations delay optional updates; RSAT will not appear until the prerequisite packages are present.
  • Feature on Demand ISO for offline installs. If your devices cannot reach Windows Update, prepare the Features on Demand ISO as part of your offline deployment strategy. Extract the FOD packages and use DISM with Add‑Package to stage required components.
  • Language pack parity. Historically, RSAT components required matching UI language packs. Confirm language settings if you see features missing in the optional features list.
  • WSUS/UseWUServer registry traps. Environments where UseWUServer is enabled may require adjusted procedures to let clients pull optional features from Microsoft Update or to import necessary packages into WSUS.
  • Automation-friendly names. When scripting, use the feature names (FeatureName) rather than DisplayName. FeatureName values are stable for automation and appear in Get‑WindowsOptionalFeature and DISM outputs.
  • Testing matrix. Test on a small set of Arm devices first — include the exact Windows version, update channel, and any device management agent (ConfigMgr/Intune) you use.

Known limitations and cautionary notes​

While this is a long‑anticipated step forward, administrators should be realistic about scope and risk.
  • Not all RSAT modules are available yet. The initial release focused on the most commonly required tools (AD, AD CS, GPMC, DNS, DHCP, Server Manager). Other modules — Hyper‑V Manager, Storage Replica, and niche snap‑ins — may not yet be compiled for Arm64 or exposed in Optional Features.
  • Behavioral parity is likely but not guaranteed. Microsoft compiled native Arm64 binaries for the delivered modules, but some behaviors and integrations can differ slightly from x64 equivalents. Edge cases may emerge in GUI rendering, snap‑in extensions, or interactions with third‑party MMC plugins.
  • Enterprise tooling dependencies. Third‑party management utilities and custom MMC extensions may still be x64‑only and may not load or may behave unpredictably when hosted inside Arm‑native MMC instances.
  • Installation and rollout pain points. Administrators in early adopter forums reported installation quirks and, in a small number of cases, instability. These anecdotal reports highlight the importance of testing before broad deployment.
  • Apple Silicon caveat. While Arm support enables scenarios with Arm‑based devices, running Windows 11 Arm on Apple Silicon remains a virtualization/ecosystem edge case — not a generic, native platform. Parallels and similar virtualization on Apple Silicon may allow Windows 11 Arm VMs to host RSAT, but that arrangement has additional considerations and is not equivalent to buying a supported Windows on Arm laptop from a PC OEM.
Flagging unverifiable or community‑sourced claims: community posts and some early adopters have reported crashes or incomplete availability on certain builds; those reports are anecdotal and often hinge on specific device drivers, prerelease builds, or update sequencing. Treat those community reports as signals to test rather than categorical showstoppers.

Troubleshooting checklist​

If RSAT components are not visible or do not install on an Arm device, work through this checklist:
  • 1.) Verify Windows 11 version and build. RSAT support requires the February 2026 update (or later) and specific servicing stack versions.
  • 2.) Confirm the update is installed. Some organizations disable optional preview updates by policy; ensure the KB is present in Windows Update history or installed via MSU/DISM.
  • 3.) Check the Optional Features UI and Control Panel. Use optionalfeatures.exe for the Control Panel view and Settings > Optional Features for FODs in 26H1.
  • 4.) Use PowerShell/DISM to enumerate features and attempt install with verbose logging. Inspect DISM logs for package errors.
  • 5.) If your environment uses WSUS or an internal update cache, import the update packages into WSUS or use the FOD ISO for offline installs.
  • 6.) Verify language settings and ensure matching language packs are installed if necessary.
  • 7.) For scripted deployments, use the FeatureName values (for example, ActiveDirectory‑DS‑LDS‑Tools) with Enable‑WindowsOptionalFeature or DISM.
  • 8.) If a module installs but misbehaves, gather Event Viewer entries and RSAT logs, and reproduce the issue on a clean test device before escalating to Microsoft support.

Security and operational hygiene​

Adding management tools to endpoint devices increases the attack surface in ways administrators must treat intentionally.
  • Least privilege and role separation. Avoid giving day‑to‑day admin accounts full domain privileges on mobile devices. Use just‑in‑time elevation or dedicated admin workstations where policy requires.
  • Device hardening. Ensure Arm devices that will host RSAT are fully patched, use disk encryption, and follow corporate device configuration baselines. Treat them as potential jump hosts.
  • Network and MFA protections. Use strong network segmentation, conditional access, and multi‑factor authentication for accounts used with RSAT tools.
  • Audit and logging. Ensure privileged actions taken from Arm machines are logged and monitored through your existing SIEM strategy. The presence of RSAT should trigger visibility rules in environments that previously blocked local management tools on mobile endpoints.

What this means for the Windows on Arm ecosystem​

This is a strategic step for Microsoft and for organizations considering Arm at scale. RSAT availability:
  • Lowers a practical barrier that previously forced administrators to keep an x64 management device just for server administration.
  • Strengthens the case for Arm devices in enterprise deployments where mobile productivity and battery life are important.
  • Signals Microsoft’s ongoing investment in feature parity across CPU architectures rather than relegating Arm to second‑class client status.
However, adoption will not flip overnight. Device procurement cycles, enterprise validation processes, and ISV support requirements still govern most purchasing decisions. Organizations with strict compliance or legacy tooling requirements may continue to prefer x64 endpoints until they validate the full ecosystem on Arm.

Recommendations for IT teams​

If you manage or advise on enterprise PC fleets, follow these recommended steps before rolling RSAT out widely:
  • Build a test plan that includes representative server roles you manage (AD, DNS, DHCP, PKI).
  • Update a small ring of Arm devices with the February 2026 preview update or wait for the tracked monthly rollup if you prefer non‑preview channels.
  • Validate both GUI and PowerShell workflows on Arm clients, testing common tasks and scripts for command and module compatibility.
  • Ensure you have a fallback plan (x64 admin station or remote‑in option) during pilot testing.
  • Review update deployment strategy for WSUS/ConfigMgr/Intune to make RSAT packages and prerequisites available.
  • Update documentation and automation to use FeatureName values for consistent scripting across architectures.
  • Monitor vendor forums and official release notes for subsequent RSAT module additions and bug fixes.

The road ahead​

Microsoft’s initial Arm64 RSAT delivery focuses on the essentials, with a clear path to broader parity through the Features on Demand model in 26H1. Expect a phased approach: more RSAT modules, refinements to FOD packaging, and enterprise‑oriented guidance that addresses the practicalities of large‑scale rollout.
For admins, the immediate opportunity is tangible: a more flexible choice of management endpoints and a reduction in friction for organizations evaluating or deploying Arm‑based Windows devices. For Microsoft and PC OEMs, this bridges a gap that will be watched closely by enterprises weighing performance, battery life, and manageability.

Conclusion​

The native arrival of RSAT on Windows 11 Arm64 devices is a consequential milestone that removes a key administrative obstacle and improves the operational viability of Arm PCs in enterprise settings. By shipping the most used RSAT components as Arm64 binaries and integrating them into the Optional Features/FOD framework, Microsoft has made it feasible to manage servers directly from modern, energy‑efficient Arm laptops and tablets.
That said, this is a pragmatic first wave rather than a finish line. Administrators should test carefully, confirm compatibility with their management workflows, and roll changes out with the usual staged approach. If your device fleet or lab includes Arm machines, treat this release as the signal to start validating Arm as a first‑class management client — but do so with controlled testing, proper patching, and security practices in place.
Happy testing — and expect more RSAT modules and polish in subsequent Windows 11 releases as Microsoft moves toward fuller parity across CPU architectures.

Source: Neowin Windows 11 Arm PCs finally get RSAT support
 
Microsoft has quietly closed one of the longest-standing capability gaps for Windows on Arm: Remote Server Administration Tools (RSAT) are now available natively on Arm‑based Windows 11 devices, letting administrators install and run familiar server management utilities directly on Arm64 laptops and tablets without emulation workarounds. ([blogs.windows.com]s.com/windows-insider/2026/02/27/announcing-windows-11-insider-preview-build-28020-1673-canary-channel/)

Background / Overview​

For years, Windows on Arm promised longer battery life, integrated connectivity, and thin‑and‑light hardware designs — but it also carried a persistent caveat for IT teams: many enterprise administration tools lagged behind, often requiring x86 emulation, remote consoles, or heavy-duty workarounds. That gap made Arm devices awkward as first‑class management endpoints for domain administrators who depend on tools like Active Directory Users and Computers, Group Policy Management, DNS and DHCP consoles, and Server Manager.
Microsoft's recent Canary‑channel update (Windows 11 Insider Preview Build 28020.1673) adds RSAT support to Arm64 systems, and the Windows IT Pro channels now confirm a broader preview rollout that brings RSAT to supported Windows 11 versions as optional features or Features on Demand (FODs).
This article explains what changed, which RSAT components are included, how to install and deploy RSAT on Arm64 clients, the enterprise implications, operational caveats observed in early rollouts, and practical recommendations for IT teams planning to make Arm devices part of their management toolbox.

What Microsoft announced (the short version)​

  • Microsoft added native RSAT support for Arm64 devices in the Windows 11 Insider Canary build 28020.1673 and in the February 2026 non‑security preview for broadly supported Windows 11 versions.
  • Common RSAT components — Active Directory Domain Services (AD DS) & AD LDS Tools, Active Directory Certificate Services Tools, Group Policy Management Tools, DNS Server Tools, DHCP Server Tools, and Server Manager — are listed as installable optional features on Arm64.
  • On shipping releases, Microsoft plans to make RSAT available either as optional features for existing builds (24H2/25H2) or as integrated FODs in upcoming 26H1 images for new Arm devices.
These are not cosmetic changes: native Arm64 RSAT removes the need to rely on emulated x86 tools, remote consoles, or clumsy management device swaps for routine directory and server administration.

Why this matters: practical benefits for admins​

  • First‑class local administration on Arm devices. IT pros can now use a single laptop (including fanless Arm ultraportables) to perform server tasks locally — without remote desktoping into an x64 VM or relying solely on browser‑based tools.
  • Lower latency for GUI tasks. Native tools run without x86 emulation, improving responsiveness when browsing directory objects, editing Group Policy Objects (GPOs), or managing certificate stores.
  • Better battery and mobility profile. Admins who prefer lightweight hardware (for travel or fieldwork) now have options that don’t force heavy x64 hardware just to run admin consoles.
  • Unified management workflows. Organizations already using tools like Intune, Microsoft Endpoint Configuration Manager, or Windows Admin Center can augment those workflows with locally installed RSAT tools on Arm endpoints where needed. Community discussions and forum threads show early adopters valuing this parity.

Which RSAT components are available now​

Microsoft and corroborating blogs have listed the initial set of commonly used RSAT tools that are included in the Arm64 rollout. Expect the following to be available as optional features in the preview channels:
  • Active Directory Domain Services & AD LDS Tools
  • Active Directory Certificate Services Tools
  • Group Policy Management Tools
  • DNS Server Tools
  • DHCP Server Tools
  • Server Manager
This is not necessarily an exhaustive list for the final release; Microsoft’s initial notes emphasize the most widely used modules first. Administrators should validate the exact module list on the target build before planning mass deployment.

How RSAT is delivered on Windows 11 Arm64​

Microsoft has been moving RSAT into Windows’ Optional Features / Features on Demand (FOD) framework for Windows 11, which changes both how administrators install RSAT and how it behaves in managed environments.
Key delivery channels and mechanics:
  • Optional Features in Settings: On consumer and managed clients, RSAT modules appear under Settings > System > Optional features > Add a feature or via the classic Control Panel path Programs and Features > Turn Windows features on or off. This is the simplest interactive route.
  • PowerShell / DISM: For automation and repeatable deployments, PowerShell cmdlets such as Get-WindowsCapability and Add-WindowsCapability -Online -Name <RSAT.FeatureName> remain the supported method. These commands work with the online Windows Update source or with a Features on Demand (SxS) source for offline installs.
  • Features on Demand (FOD) ISO: For air‑gapped or WSUS‑managed environments, Microsoft’s Features on Demand ISO (or the Language and Optional Features ISO) can be used as the offline Source path for Add-WindowsCapability/DISM installs. This is essential where clients are prevented from reaching Microsoft Update.

Step‑by‑step: install RSAT on an Arm64 Windows 11 client​

Use this sequence for manual or scripted installation (adapt for your environment):
  • Confirm Windows 11 build and channel — RSAT on Arm64 was introduced in Canary (Build 28020.1673) and is available in the February 2026 preview for supported branches; ensure your device is on a build that includes RSAT.
  • Interactive install (quick): Settings > System > Optional features > Add a feature > search “Remote Server Administration” and install the RSAT module(s) you need.
  • PowerShell (recommended for automation):
  • List RSAT capabilities: Get-WindowsCapability -Online | Where-Object Name -like 'Rsat*'
  • Install specific component: Add-WindowsCapability -Online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0"
  • For an offline or FOD ISO source, use -Source with the mounted ISO path and -LimitAccess.
  • Validate: Confirm installed state with Get-WindowsCapability -Online -Name 'RSAT*' and verify the GUI console (e.g., Acnd Computers) opens and functions.
  • For mass deployment, script the PowerShell commands or package through Intune/Configuration Manager, ensuring FOD sources are available to clients if Microsoft Update is blocked. Community reports note that RSAT requires access to Windows Update unless the FOD files are mirrored internally.

Caveats and deployment friction — what to watch for​

The initial public rollout is promising, but administrators should plan for operational edge cases and known friction points observed in early deployments and community testing.
  • WSUS and update source behavior: RSAT FODs are delivered via the Optional Features framework and often require Microsoft Update access. Environments that block Microsoft Update via WSUS or Group Policy may fail to install RSAT unless FOD content is provided locally. Multiple community threads and troubleshooting posts document that disabling Windows Update or enforcing WSUS without the proper settings can lead to installation failures or persistent “Not present” states. Plan to mirror FOD content or enable the policy “Download repair content and optional features directly from Windows Update instead of Windows Server Update Services” for target systems where appropriate.
  • Partial availability across SKUs and builds: Not all RSAT modules may appear on every build or SKU immediately. Some admins report only a subset of RSAT modules visible on specific images or when certain servicing metadata is missing. Validate on the exact build and OS edition you are targeting (Pro vs Enterprise vs Education).
  • Timing and staged rollouts: Microsoft is rolling RSAT to Arm64 in preview channels and pilot updates; enterprise liberation to all supported branches may lag. The Canary/preview notes mention feature toggles and phased rollouts — expect staggered availability.
  • Historic articles and guides may be outdated: Several guides (older WindowsReport and community threads) continue to state “RSAT is not available on ARM,” reflecting the pre‑2026 reality. Ensure you consult the build‑specific Microsoft notes or the Windows IT Pro guier blog posts when planning deployments.
If you encounter “Couldn’t add the feature” or error codes (e.g., 0x80240438) during installation, the common troubleshooting steps are: enable Microsoft Update access or provide FOD source, restart the Windows Update services, check Group Policy related to Optional Features, and install via PowerShell with the correct -Source and -LimitAccess parameters.

Security and operational implications​

Adding RSAT to Arm64 clients does not change server‑side security posture, but it affects operational risk and convenience in meaningful ways:
  • Attack surface and client hardening: More admins using mobile Arm devices to manage servers increases the importance of securing those endpoints. Treat Arm laptops with the same security baseline as x64 admin workstations: enforce BitLocker, Windows Hello for Business or hardware MFA, managed device compliance, endpoint protection, and conditional access policies.
  • Audit and logging: RSAT consoles produce local log events and administrative activity; ensure proper auditing (Sysmon, Event Log forwarding) and that the devices are included in your SIEM/monitoring scope. Microsoft’s broader February preview also introduced Sysmon as an in‑box optional feature — a useful pairing for auditing administrative activity.
  • Remote management overlap: Many organizations already rely heavily on web‑based management (Windows Admin Center, Azure Portal, Microsoft 365 admin centers). RSAT on Arm provides GUI parity for local tasks, but it should complement, not replace, centralized and auditable workflows for automation and scale. Forum discussions show admins balancing local RSAT usage with scriptable PowerShell and remote automation to reduce manual GUI changes.

Testing checklist for IT teams​

Before allowing Arm64 laptops into a management role in production, run this validation plan:
  • 1.) Confirm build and channel compatibility for your planned OS image and edition.
  • 2.) Install and validate each RSAT module you rely on (AD, GPO, DNS, DHCP) on a representative Arm64 device. Open the consoles, perform common tasks, and measure latency and UI behavior.
  • 3.) Test scripted deployments (PowerShell) with and without access to Microsoft Update; verify FOD ISO installs.
  • 4.) Confirm auditing, logging, and endpoint protection are enforced on the device; validate Event Log, Sysmon ingestion, and SIEM indexing.
  • 5.) Validate Group Policy and MDM policies are applied and that the device follows your managed update pipeline (WSUS/Intune). Address any Optional Feature delivery issues (see WSUS caveat above).

Real‑world feedback and community notes​

Public forums and enterprise IT lists show a mixture of enthusiasm and caution. Early adopters praise the convenience of native RSAT on compact Arm hardware, while experienced deployment engineers warn of predictable edge cases: optional feature metadata mismatches, WSUS delivery issues, and varying module visibility across builds. Community threads emphasize the need to prepare FOD sources and to script installations for predictable results in managed environments.
Older troubleshooting guides and articles that declared “RSAT isn’t available on ARM” remain online; those pieces are now outdated and should not be treated as authoritative for the latest Insider/preview builds. Cross‑verify with Microsoft’s Windows Insider announcements and Windows IT Pro notes when planning.

What this means for the Windows on Arm roadmap​

This RSAT milestone is part of a pattern: Microsoft is incrementally removing traditional parity blockers that kept Arm devices out of serious enterprise use. The addition of RSAT, improved Prism emulation and Xbox app support for gaming, and official Arm ISO images signal a broader commitment to parity across workloads. However, parity is a journey: drivers, third‑party software, and some niche admin tools may still lag in Arm64 native builds. Expect continued work across drivers, FOD packaging, and third‑party vendor support.

Recommendations — short, practical advice​

  • If you manage Arm devices now: test RSAT on a pilot group and prepare FOD sources or update policies to allow Microsoft Update for Optional Feature retrieval. Script installatsCapability` for repeatability.
  • If you plan to adopt Arm for admins: require full endpoint hardening (disk encryption, MFA, compliance checks) before granting server admin privileges to Arm laptops.
  • For SCCM/WSUS environments: mirror the Required FOD files and verify the Group Policy setting that allows clients to pull optional feature content directly from Microsoft Update if mirroring isn’t possible. Community troubleshooting threads document this as the most common operational snag.
  • Keep an eye on the official Windows Insider and Windows IT Pro channels for the precise delivery schedule and any post‑preview fixes; staged rollouts mean features may appear at different times across channels.

Final analysis: strengths, risks, and the path forward​

Bringing RSAT to Windows 11 on Arm64 is a meaningful technical and operational milestone. It addresses a long‑standing usability gap, enabling Arm devices to serve as native admin endpoints and simplifying toolchains for mobile IT staff. For organizations pursuing device diversity, the change reduces the need for purpose‑built x64 admin laptops or constant remote VM hops.
Strengths:
  • Native performance and parity for core administrative tasks.
  • Simpler workflows for mobile and remote administrators.
  • Improved platform confidence for enterprises considering Arm endpoints.
Risks and limitations:
  • Deployment friction in WSUS‑managed and offline environments unless FOD content is prepared.
  • Staged availability and per‑build differences may cause inconsistent experiences across an estate.
  • Third‑party tool parity still depends on vendors shipping Arm64 builds or relying on browser/cloud tools.
In short, RSAT on Arm64 is a concrete sign that Windows on Arm is moving from experimental to practical for many enterprise roles. The technical mechanics (Optional Features, FOD, PowerShell automation) align with existing Windows servicing patterns, which helps IT teams reuse established deployment methods — provided they plan for the well‑documented caveats around optional features and update sources. Validate early, script for reproducibility, and treat Arm admin devices as you would any other privileged endpoint from a security and compliance perspective.
Conclusion: RSAT on Arm64 removes a major barrier. It doesn’t magically fix every compatibility or management challenge, but it closes a practical gap that has kept many IT professionals tethered to x64-only admin machines. For organizations willing to pilot and adapt their deployment pipelines, Arm‑first admin workflows are now a viable, supported option.

Source: Windows Report https://windowsreport.com/microsoft-brings-rsat-tools-to-windows-11-on-arm-devices/