All posts in category Windows Server 2022

Application Compatibility Feature on Demand for Server Core

If you know me, you know that I’m a big fan of Windows Server Core. Server Core is a refactored and streamlined version of Windows Server that offers a smaller attack surface and reduced maintenance requirements. It’s ideally suited for roles like domain controllers (DCs), certification authority servers (CAs), DHCP and DNS servers, and file servers that can easily be managed remotely. Server Core lacks a Graphical User Interface (GUI), which can make administrative tasks more difficult. To support Server Core, administrators must have a firm grasp of the command line and PowerShell. Many organizations are reluctant to deploy Windows Server Core for this reason. For example, network interface configuration and disk management are common pain points for command-line administration. However, I’ve recently discovered something that might reduce this barrier to adoption.

GUI for Server Core?

I honestly don’t know how I missed this, but recently I learned of the Application Compatibility Feature on Demand for Windows Server Core. First introduced in October 2018 for Windows Server 2019 Core and supported through Windows Server 2025, the Application Compatibility Feature on Demand enables important GUI management consoles that help administrators configure and deploy Windows Server Core. It does not add the entire Windows Desktop Experience, of course, but it does introduce support for some critical GUI tools that administrators will find very helpful for installing and configuring various workloads on Server Core. Here are some examples.

Installation

To install the Application Compatibility Feature on Demand for Windows Server Core, open an elevated PowerShell command window and run the following PowerShell command.

Add-WindowsCapability -Online -Name ServerCore.AppCompatibility~~~~0.0.1.0

After running the command, restart the server to complete the installation.

Features and Capabilities

After installing the Application Compatibility Feature on Demand for Windows Server Core, administrators can perform local administration using many GUI tools they are already experienced with. Here are a few examples.

Network Control Panel

Having a GUI for network interface configuration is arguably the most essential benefit of this feature. Many administrators struggle with assigning IP addresses, DNS servers, DNS suffixes, and other network configuration-related tasks using the command line. Here, the classic Network Control Panel applet (ncpa.cpl) gives administrators the familiar GUI experience for managing network settings in Windows Server Core.

Disk Management

Right behind network configuration, disk configuration in Windows Server Core is one of the most challenging administrative tasks using the command line. The Application Compatibility Feature on Demand for Windows Server Core adds support for the well-known Disk Management GUI (diskmgmt.msc), which many administrators have used before.

Event Viewer

While using PowerShell is effective for parsing event log information on Windows Server Core, it’s sometimes easier to view event log information using the GUI (eventvwr.msc).

File Explorer

Copying files to and from a Windows Server Core instance is much easier with the Application Compatibility Feature on Demand for Windows Server Core installed. To perform file operations on Windows Server Core, simply open the Windows File Explorer (explorer.exe) as you would on Windows Server GUI.

Device Manager

Working with device drivers on Windows Server Core can be challenging even for the most experienced command-line administrators. Thankfully, the Application Compatibility Feature on Demand for Windows Server Core adds support for the Device Manager GUI (devmgmt.msc), which significantly simplifies this task.

Task Scheduler

Creating basic scheduled tasks using PowerShell isn’t terribly difficult. However, things become much more difficult when creating tasks with complicated requirements, such as odd schedules, and when using event-based triggers. The familiar Task Scheduler GUI (taskschd.msc) reduces this complexity, allowing administrators to use the GUI they are likely already experienced with.

Resource and Performance Monitor

Both the Resource Monitor (resmon.exe) and Performance Monitor (perfmon.exe) are essential tools for troubleshooting resource consumption and performance bottleneck issues on Windows Server. Both tools are included with this feature.

Resource Monitor (resmon.exe)

Performance Monitor (perfmon.exe)

What’s Missing

Sadly, installing the Application Compatibility Feature on Demand for Windows Server Core does not add GUI support for user and device certificate stores (certmgr.msc and certlm.msc, respectively). Administrators must continue to use certutil.exe or PowerShell to manage certificate stores on Windows Server Core. Alternatively, administrators can use a remote management workstation to perform these tasks using the GUI. However, even with this limitation, the Application Compatibility Feature on Demand greatly improves the Server Core administration experience.

Additional Tools

This feature update includes many other GUI tools in addition to the popular administrative GUI tools listed above. These are available ad hoc using the generic Microsoft Management Console (mmc.exe). Here are a few more GUI tools you might find helpful.

Routing and Remote Access Management Console – This will be especially helpful for Always On VPN administrators using RRAS in their environments.

Windows Firewall with Advanced Security – Managing Windows Firewall and IPsec Connection Security policies is now much easier using the same GUI included with Windows Server Desktop Experience.

Local Users and Groups – Local user and group administration tasks can now be performed using the same GUI that administrators are already comfortable with.

Group Policy, Security Policy, and Resultant Set of Policy (RSoP) – GUI management tools are now available for common local group and security policy administration. In addition, administrators have access to the RSoP policy GUI for GPO troubleshooting.

Other Tools – Administrators will also find the Hyper-V Manager and Failover Cluster Manager GUI consoles are included with this feature update.

Run mmc.exe at the command line and choose File > Add/Remove Snap-in to access these GUI tools.

Summary

Don’t let the lack of a full GUI stop you from deploying Server Core! The Application Compatibility Feature on Demand makes Server Core accessible without sacrificing its core benefits. If command-line concerns have held you back from deploying Server Core, this feature removes that barrier. Start with a test deployment on a non-critical server and experience how Server Core’s reduced attack surface and lower maintenance overhead can work in your environment—without abandoning the GUI tools you rely on.

Additional Information

Application Compatibility Feature on Demand for Windows Server Core

Always On VPN and RRAS on Windows Server Core

10 PowerShell Commands Always On VPN Administrators Should Know

Leave a comment
by Richard M. Hicks on October 14, 2025  •  Permalink
Posted in administration, Microsoft, Server Core, systems management, Windows Server 2019, Windows Server 2022, Windows Server 2025
Tagged , , , , , , , ,

Posted by Richard M. Hicks on October 14, 2025

https://directaccess.richardhicks.com/2025/10/14/application-compatibility-feature-on-demand-for-server-core/

Always On VPN RRAS and PowerShell 7

PowerShell is an essential tool for administrators supporting Microsoft Always On VPN. It is critical for configuring supporting infrastructure services, such as Routing and Remote Access (RRAS) and Network Policy Server (NPS), as well as provisioning and managing Always On VPN client configuration settings on endpoints. The current version of PowerShell, PowerShell 7.5.3, is a game-changer for scripting and automation, bringing a host of improvements over its predecessors. PowerShell 7 offers better performance, lower memory usage, and cross-platform support (Windows, macOS, and Linux), making it more versatile than ever.

Problem in PowerShell 7

Recently, I discovered an oddity with PowerShell 7 when reviewing the configuration of an RRAS server. Specifically, PowerShell 7 differs in the way it produces output for the Get-RemoteAccess command, preventing administrators from viewing the details of the currently configured TLS certificate used for SSTP VPN connections in RRAS.

PowerShell 5

Running Get-RemoteAccess in PowerShell 5 provides detailed information about the SslCertificate property in the output of the command, as shown here.

Note that the data returned in the SslCertificate property is of the type X509Certificate2.

PowerShell 7

In PowerShell 7, Get-RemoteAccess displays only a string of numbers instead of detailed certificate information.

Notably, the data returned in the SslCertificate property is of the type System.Byte.

Solution

While PowerShell 7 doesn’t output the certificate details in human-readable form, you can easily convert the data using the following PowerShell command.

[System.Security.Cryptography.X509Certificates.X509Certificate2]::new((Get-RemoteAccess).SslCertificate) | Format-List

AovpnTools Module

To simplify administration, I’ve added a function to my AovpnTools PowerShell module called Get-VpnServerTlsCertificate. This function allows you to view the currently configured SSTP certificate details directly with a single command. In addition, you have the option to save the certificate to a file for further inspection and troubleshooting.

The GetVpnServerTlsCertificate function is included in AovpnTools v1.9.8 and later. You can install AovpnTools from the PowerShell gallery by running the following command.

Install-Module -Name AovpnTools

You can also find the AovpnTools PowerShell module on GitHub.

Summary

With PowerShell 7, RRAS certificate details display differently, but administrators can quickly resolve this using a simple conversion or the Get-VpnServerTlsCertificate function in the AovpnTools module. Either way, administrators can continue to use PowerShell 7 to manage their Windows Server RRAS servers.

Additional Information

Installing PowerShell 7 on Windows

AovpnTools in the PowerShell Gallery

AovpnTools on GitHub

Leave a comment
by Richard M. Hicks on September 16, 2025  •  Permalink
Posted in administration, Always On VPN, AOVPN, certificates, Microsoft, PowerShell, PowerShell 7, routing and remote access service, RRAS, Secure Socket Tunneling Protocol, Server Core, SSL, SSL and TLS, SSTP, TLS, VPN, Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2025
Tagged , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on September 16, 2025

https://directaccess.richardhicks.com/2025/09/16/always-on-vpn-rras-and-powershell-7/

Windows Server DNS64 and IPv6 Only

Many organizations are modernizing their networks by migrating from legacy IPv4 to IPv6. The goal is to replace IPv4 with IPv6 entirely. However, even though an organization can successfully migrate to IPv6-only networks internally, they do not control networks outside its boundaries. In some cases, a host on an IPv6-only network may need to communicate with an IPv4 resource. Administrators must deploy an IPv6 transition technology to support this scenario. A common solution to address this need is DNS64 and NAT64.

What are DNS64 and NAT64?

DNS64 and NAT64, defined in RFCs 6147 and 6146, respectively, work together to ensure endpoints on an IPv6-only network can still communicate with IPv4-only resources. DNS64 enables IPv6-only clients to communicate with IPv4-only servers by synthesizing AAAA DNS records from A records. When an IPv6-only client queries a domain with only an IPv4 address (A record), the DNS64 server creates a synthetic IPv6 address by embedding the IPv4 address within an administrator-defined NAT64 IPv6 prefix. The default (referred to as ‘well known’) prefix is 64:ff9b::/96. In the example below, the IPv4-only resource ipv4.test-ipv6.com is resolved using the Cloudflare public DNS64 resolver.

Using the synthetic DNS64 address allows the client to send IPv6 packets to a NAT64 gateway, which translates them to IPv4 for the destination server. DNS64 ensures seamless address resolution for IPv6-only networks accessing IPv4 resources without requiring actual IPv6 addresses for the target.

Caveat

While DNS64 is great for ensuring IPv4 access on IPv6-only networks, it has one critical limitation. The client must connect to a resource using a hostname or a fully qualified domain name. If a client attempts to connect to an IPv4 resource directly (e.g., https://172.16.21.12 or \\10.21.12.83\data), the resource will be unreachable. To address this limitation, the 464XLAT IPv6 transition technology must be used. For more information about 464XLAT, see my previous article, Windows Server DHCP and Option 108.

Enterprise DNS64

While there are public DNS64 resolves from Cloudflare, Google, and others, they aren’t helpful when trying to resolve internal hostnames in the enterprise. Organizations must deploy their own private DNS64 services in this scenario.

Windows Server and DNS64

Today, Windows Server does not natively support DNS64. Organizations are advised to use an enterprise DNS solution such as Infoblox or BlueCat for DNS64 services. Alternatively, administrators can deploy BIND DNS on the Linux platform of their choice. DNS64 is supported in BIND 9.8.0 and later.

DNS64 Proxy

To support testing and evaluation (and perhaps production deployment for smaller organizations), it is possible to configure any supported version of Windows Server to serve as a DNS64 proxy. In this scenario, a Windows Server is configured as a DNS64 server, but the server itself is not an actual DNS server. It does not have a DNS database or zone file; it is not authoritative for any zones and can’t perform conditional forwarding. It simply forwards DNS queries to the servers defined on its own network interface.

Windows Server DNS64 Configuration

The DNS64 service must be installed using PowerShell and the Set-NetDnsTransitionConfiguration command. Administrators will define some variables, configure DNS64, and create firewall rules to allow DNS traffic inbound to the server.

Configure DNS64

On a Windows Server member server (domain-join is optional), open an elevated PowerShell command window and run the following commands.

# Define variables
$AcceptInterface = ‘Ethernet’ # The interface name or alias that will accept DNS64 traffic
$SendInterface = ‘Ethernet’ # The interface name or alias that will send DNS64 traffic
$Nat64Prefix = ’64:ff9b::/96′ # The NAT64 prefix

# Configure DNS64
Set-NetDnsTransitionConfiguration -State Enabled -AcceptInterface $AcceptInterface -SendInterface $SendInterface -PrefixMapping “$Nat64Prefix,0.0.0.0/0” -PassThru

Configure Windows Firewall

Run the following PowerShell commands to configure the Windows Firewall to allow inbound DNS requests.

# Create firewall rules to allow DNS64 traffic inbound
New-NetFirewallRule -Name ‘DNSSrv-DNS-UDP-In’ -DisplayName ‘DNS (UDP, Incoming)’ -Description ‘Inbound rule to allow remote UDP access to the DNS64 service.’ -Group ‘DNS64 Service’ -Protocol UDP -LocalPort 53 -Direction Inbound -Profile Any -Action Allow -Enabled True

New-NetFirewallRule -Name ‘DNSSrv-DNS-TCP-In’ -DisplayName ‘DNS (TCP, Incoming)’ -Description ‘Inbound rule to allow remote TCP access to the DNS64 service.’ -Group ‘DNS64 Service’ -Protocol TCP -LocalPort 53 -Direction Inbound -Profile Any -Action Allow -Enabled True

GitHub

For reference, I’ve posted the relevant commands for configuring DNS64 on Windows Server on GitHub here.

DNS64 Testing

Once DNS64 is configured on the Windows Server, administrators can test operation by sending a DNS query for an IPv4-only resource to the DNS64 server using the following PowerShell command.

Resolve-DnsName -Name ipv4.test-ipv6.com -Server <DNS64 server IPv6 address>

For example.

Resolve-DnsName -Name ipv4.test-ipv6.com -Server 2001:579:6024:510::64

The DNS64 server responds with the native IPv4 address along with the synthesized IPv6 address. However, if the target resource has only an IPv6 address or has both IPv4 and IPv6 addresses, both are returned, as shown below.

Summary

DNS64 and NAT64 are essential tools for enabling communication between IPv6-only networks and IPv4 resources. While public resolvers exist, enterprises often need their own DNS64 service for internal hostname resolution. Windows Server does not natively support DNS64, but administrators can configure it as a DNS64 proxy for testing and smaller deployments. In this scenario, Windows Server can provide DNS64 functionality, helping organizations transition toward IPv6-only networks while maintaining access to legacy IPv4 systems.

Additional Information

IPv6 Transition Technology Options – IPv6 Buzz Podcast

Set-NetDnsTransitionConfiguration

RFC 6146 – NAT64

RFC 6147 – DNS64

RFC 6877 – 464XLAT

Windows Server DHCP and Option 108

What is IPv6?

Leave a comment
by Richard M. Hicks on September 15, 2025  •  Permalink
Posted in 464XLAT, administration, BIND DNS, DNS, DNS Proxy, DNS64, Enterprise, Infrastructure, IPv6, IPv6 Transition, Linux, Microsoft, Operational Support, PowerShell, Proxy, Security, transition technology, Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2025
Tagged , , , , , , , , , ,

Posted by Richard M. Hicks on September 15, 2025

https://directaccess.richardhicks.com/2025/09/15/windows-server-dns64-and-ipv6-only/

« Older Posts
Newer Posts »