In this article

OpenMetal bare metal supports Windows Server installed via IPMI, with no pre-installed OS required. This article covers the full path from installation through Hyper-V configuration, edition selection, and core licensing on dedicated hardware.


An IT director at a mid-sized professional services firm recently ran the numbers on their Azure environment. Fifty users on Remote Desktop Services, a SQL Server instance, and several internal application VMs, spread across multiple VM sizes, billed hourly, with metered egress every time a report generates or a file transfers between services. The monthly bill was predictable only in the sense that it was always higher than expected.

Moving those workloads to a single dedicated bare metal server running Hyper-V put everything on physical cores that belong entirely to that deployment. Fixed monthly cost. No shared hypervisor. No neighboring tenant workloads competing for the same NUMA node. The licensing math also changed: on dedicated hardware, the core count is known and fixed, which simplifies Windows Server license planning considerably.

This is a well-worn path for Windows shops moving off public cloud or consolidating aging on-premises hardware. What it requires is a bare metal provider that allows custom OS installs. OpenMetal does, via IPMI.

What IPMI Install Means in Practice

OpenMetal bare metal servers don’t ship with a pre-installed OS. You choose your operating system. For Windows Server, the path is through the IPMI KVM console, accessible from OpenMetal Central.

IPMI (Intelligent Platform Management Interface) provides out-of-band access to the server’s hardware: keyboard, video, and mouse redirection over the network, independent of any installed operating system. Through the KVM console, you mount a Windows Server ISO as virtual media and proceed through a standard installation just as you would with physical access to the machine.

The IPMI KVM setup process requires Java on your local machine. Once connected, mount your Windows Server ISO through the virtual media interface, set the boot order to the virtual drive, and install. The process is the same as any bare metal Windows Server installation: boot, partition, configure, activate. Your existing Windows Server license key activates during or after setup.

One thing to plan for: IPMI console sessions can be slow for an OS installer, since video is rendered over the network connection. The installation itself is not slow, but the console experience is. Many administrators do the initial install over IPMI and then switch to RDP for everything after first boot.

Choosing Your Windows Server Edition

Windows Server is available in two main editions relevant to bare metal deployments: Standard and Datacenter. The right choice depends on how many virtual machines you plan to run on the host.

Standard edition covers two virtual machines per fully licensed server, plus the host OS instance. If you’re running a small number of Windows VMs on dedicated hardware, Standard is typically the economical choice.

Datacenter edition covers unlimited virtual machines on a fully licensed server. The upfront license cost is significantly higher than Standard, but it becomes the better option once VM density climbs past roughly 8-10 VMs per host. For dense Hyper-V consolidation scenarios where you’re migrating 20 or 30 Azure VMs onto one server, Datacenter is the edition to evaluate.

Both editions use Microsoft’s core-based licensing model. Every physical core on the server must be covered by a core license. Two minimums apply regardless of actual core count:

  • Minimum 8 core licenses per physical processor
  • Minimum 16 core licenses per server

Core licenses are sold in 2-core packs. The practical implication for a 2-socket server: if each processor has 8 or fewer cores, you still license as if it has 8. On higher-core-count servers (the XL configurations with 32 cores per socket), you license all 64 physical cores.

For RDS workloads specifically: Remote Desktop Services access beyond two concurrent administrative sessions requires Remote Desktop Services Client Access Licenses (RDS CALs), purchased separately per user or per device. This is one of the most common Windows licensing oversights when sizing a migration. Factor it into your licensing plan before the move.

OpenMetal does not provide Windows Server licenses or RDS CALs. You bring your own licenses. On dedicated single-tenant hardware, you can deploy your existing perpetual licenses under Microsoft’s standard licensing terms for dedicated hosting environments.

Setting Up Hyper-V for VM Consolidation

Hyper-V is a role within Windows Server, not a separate product. The standalone free Hyper-V Server was discontinued after the 2019 version; current deployments use Hyper-V enabled through Server Manager or PowerShell on a licensed Windows Server installation.

Enabling Hyper-V on Windows Server 2022 or 2025 is straightforward via Server Manager or Install-WindowsFeature -Name Hyper-V. Once enabled, the host becomes a Type-1 hypervisor, running directly on the hardware.

A few architectural points worth planning before migration:

  • Virtual switch configuration: Hyper-V virtual switches bind to the host’s physical network adapters. For OpenMetal bare metal, you have two network interfaces: the public uplink and the private network. The typical configuration creates an external virtual switch bound to the public NIC and an internal or private switch for VM-to-VM traffic. The 20 Gbps private network between servers is available for VM traffic that needs to stay off the public interface.
  • Storage layout: OpenMetal bare metal ships with NVMe drives: the v5 lineup uses Micron 7500 MAX NVMe, and v4 uses Micron 7450 MAX NVMe. VM disk images (VHD or VHDX files) sit directly on these drives. For deployments that need redundancy across multiple drives, Windows Storage Spaces provides software-defined striping and mirroring without requiring a hardware RAID controller. The large NVMe capacities on XL and Large configurations (25.6TB on XL v5) give significant headroom for dense VM libraries.
  • Memory allocation: Hyper-V supports dynamic memory, which lets VMs expand and contract their memory allocation within defined bounds. On a server with 512GB or 1TB of RAM, this matters less than on commodity hardware, and there’s headroom to give VMs generous static allocations. Static allocation simplifies performance troubleshooting and is often preferable for production workloads.
  • VM generation selection: Use Generation 2 VMs for Windows Server 2012 R2 and later guests. Generation 2 supports Secure Boot, UEFI, and faster synthetic adapters. Generation 1 remains available for compatibility with older guests or non-Windows operating systems that require legacy BIOS.

Remote Desktop Services on Bare Metal

RDS is one of the most common reasons Windows shops look at bare metal consolidation. Running RDS on Azure is expensive: the Windows Server licensing, the VM cost, the per-user RDS SAL for Azure Virtual Desktop, and the egress charges whenever sessions transfer files. Consolidating onto a dedicated bare metal host replaces that variable cost with a fixed monthly hardware rate.

On bare metal running Hyper-V, RDS can be deployed either directly on the host or on dedicated VMs within the Hyper-V environment. The VM-per-role architecture with separate VMs for the RD Session Host, RD Connection Broker, and RD Web Access, is the approach Microsoft recommends for production deployments and is straightforward to configure on a high-memory host.

RDS requires Windows Server Datacenter or Standard edition, plus RDS CALs for each connecting user or device. The Session Host role specifically requires the RDS CAL; administrative RDP sessions (up to two concurrent) do not. Plan your CAL count based on concurrent user peaks, not total headcount.

Hardware That Fits Windows Workloads

The right hardware tier depends on the VM density and workload profile.

Medium v4 or Medium v5 (24 cores, 256GB RAM) suits single-instance deployments: one Windows Server installation running directly on the hardware, or a small number of VMs (two to four) where Hyper-V overhead doesn’t justify a larger investment. The 256GB RAM ceiling means this tier fills up quickly in dense scenarios.

Large v4 or Large v5 (32 cores, 512GB RAM) fits medium-density deployments: 8 to 15 VMs, or a Windows Server running SQL Server alongside a handful of application VMs. The 512GB RAM gives reasonable headroom for mixed workloads, and the NVMe storage handles database I/O well.

XL v4 or XL v5 (64 cores, 1TB RAM) is the right tier for dense Hyper-V consolidation. At 64 physical cores, Windows Server Datacenter licensing becomes the practical choice. The 1TB RAM supports 20 to 40 VMs at typical enterprise memory allocations, and the 25.6TB NVMe storage on XL v5 gives extensive capacity for VM disk libraries. This is the natural landing zone for teams migrating 20 or more Azure VMs onto dedicated infrastructure.

Current v5 hardware is available in Ashburn and Los Angeles. v4 is available across all data center locations. Full hardware specs and current pricing are on the hardware details page.

Who This Fits

Teams consolidating Azure or cloud RDS deployments

Per-user licensing on Azure Virtual Desktop plus the underlying VM costs add up quickly. A dedicated bare metal host running RDS via Hyper-V replaces the variable cloud bill with a fixed infrastructure cost, provided CAL licensing is properly accounted for.

Organizations migrating aging on-premises Windows infrastructure

End-of-life hardware running Hyper-V clusters or standalone Windows Servers can be migrated to dedicated bare metal without changing the OS, the application stack, or the management tools. The environment looks the same to administrators; the underlying hardware is newer and faster.

IT teams that already own Windows Server licenses

BYOL on dedicated hardware is straightforward. If your organization has perpetual licenses under a volume licensing agreement, single-tenant bare metal is the clean deployment scenario.

Shops running SQL Server on Windows

SQL Server is also licensed per physical core on dedicated hardware. A server whose core count you own entirely is the simplest SQL Server licensing scenario, and the NVMe-backed storage handles transactional I/O at low latency.

Who This Doesn’t Fit

Teams without existing Windows Server expertise

OpenMetal provides bare metal infrastructure and IPMI access; Windows Server administration, configuration, and support are your responsibility. There is no managed Windows offering.

Deployments that need Microsoft support on the underlying hardware

Support relationships with Microsoft for Windows Server workloads run through your licensing agreement and apply to the software, not the bare metal platform.

Small deployments where the economics don’t work

A single low-traffic Windows application on Azure may cost less than a dedicated bare metal server plus a Windows Server license. The math shifts when you have multiple workloads to consolidate onto one host.

Frequently Asked Questions

Does OpenMetal provide Windows Server licenses?

No. OpenMetal bare metal is bring-your-own-license. You bring your own Windows Server ISO and license key. OpenMetal does not offer SPLA licensing or Microsoft-managed activation.

How do I install Windows Server on an OpenMetal bare metal server?

Through the IPMI KVM console in OpenMetal Central. You mount your Windows Server ISO as virtual media, boot the server from it, and proceed through a standard installation. Java is required on your local machine to use the KVM console. The full process is documented here.

Which Windows Server edition should I use for Hyper-V?

Standard edition covers two VMs per fully licensed server. Datacenter covers unlimited VMs. For dense VM consolidation (roughly 8 or more VMs), Datacenter is typically more economical on a per-VM basis. Consult Microsoft’s licensing documentation for the exact math on your core count and VM count.

Does Windows Server core licensing apply to all physical cores on the server?

Yes. All physical cores on the server must be covered, with a minimum of 8 core licenses per processor and 16 per server. Core licenses are sold in 2-core packs. A 2-socket server with 32 cores per socket requires 64 core licenses total. See Microsoft’s Windows Server licensing page for current details.

Do I need RDS CALs for Remote Desktop Services?

Yes, if users are connecting to RDS sessions for work use. Windows Server allows two concurrent administrative RDP sessions without CALs. Any user connecting for productivity use requires an RDS CAL. This applies regardless of whether RDS runs on a VM or directly on the host.

Can I run multiple Windows Server VMs on one OpenMetal bare metal server?

Yes, using Hyper-V as the hypervisor. The number of VMs covered by your license depends on the edition: Standard covers two VMs per fully licensed server; Datacenter covers unlimited. Additional Windows Server VMs beyond what your edition covers require additional licenses.

What happens to my Windows Server license if I cancel my OpenMetal contract?

Your licenses are yours. Windows Server perpetual licenses are not tied to the infrastructure provider. If you move workloads elsewhere, your licenses move with you.


The case for dedicated bare metal for Windows workloads comes down to a simple trade: variable cloud infrastructure costs and shared hardware for a fixed monthly rate and physical cores that belong entirely to your deployment. The licensing arithmetic is straightforward on single-tenant hardware, and the IPMI path into OpenMetal’s servers is the same installation process Windows administrators have always used on bare metal.

To scope a configuration, contact the team or apply for a proof of concept.


Chat With Our Team

We’re available to answer questions and provide information.

Reach Out

Schedule a Consultation

Get a deeper assessment and discuss your unique requirements.

Schedule Consultation

Try It Out

Take a peek under the hood of our cloud platform or launch a trial.

Trial Options

 

 

 Read More on the OpenMetal Blog

Running Windows Server and Hyper-V on Dedicated Bare Metal

Sep 22, 2026

OpenMetal bare metal servers support custom OS installs via IPMI, including Windows Server. This article covers the installation path, edition selection and core licensing on dedicated hardware, Hyper-V setup for VM consolidation, and which hardware configurations suit different Windows workloads.

Self-Hosting Temporal Is a Postgres and Private Networking Decision Before Anything Else

Sep 17, 2026

How Temporal Cloud’s per-action billing model works and where it compounds, what the official Temporal documentation says self-hosted deployments require, the infrastructure stack a production cluster needs, and where OpenMetal’s bare metal fits into that.

Your LangGraph Agent Loses Everything When the Server Restarts

Sep 15, 2026

What LangGraph manages and what it explicitly does not, why MemorySaver is not a production checkpointer, what PostgresSaver requires from your infrastructure, the compute profile of long-running agent workflows, and where dedicated bare metal fits.

What the EU AI Act’s Article 12 Requires From Your Log Infrastructure

Sep 14, 2026

What Article 12 of the EU AI Act actually requires, why the obligation is an infrastructure problem before it is a software problem, what compliant log storage needs to look like in practice, the current enforcement timeline, and how private cloud in the EU addresses the requirement.

A Technical Guide to Every CPU Generation in OpenMetal’s Lineup

Sep 04, 2026

The four distinct Intel Xeon generations running across OpenMetal’s bare metal and hosted private cloud lineup, what actually changes between them beyond core count, and which generation fits which kind of workload, including where confidential computing eligibility depends on generation and hardware configuration together.

Why Shared HPC Access Gets Unpredictable for Life Sciences Computing

Sep 02, 2026

We look at why shared, allocation-based HPC access becomes a real operational problem for life sciences computational research, what changes on dedicated infrastructure that you administer yourself, and how to structure a transition that scales up gradually rather than requiring a large upfront commitment.

Infrastructure for Real-Time Bidding and Programmatic Advertising Platforms

Aug 21, 2026

We look at the real timing constraint behind real-time bidding auctions, why shared cloud infrastructure quietly eats into that budget through virtualization and cross-zone network hops, and where dedicated bare metal removes that variance directly.

Index-Time and Query-Time Account Discovery Want Different Memory

Aug 21, 2026

An account-intelligence system that pre-embeds ten million companies into a resident vector index, and one that dispatches agents to research those same companies live on demand, look like the same

Utilization Is a Tenancy Decision: Why Sustained MFU Lives Below the Kernel

Aug 13, 2026

On latency-bound inference, the Model FLOPs Utilization your optimization stack can actually hold is capped by who else shares the box, not by the kernel that runs on it. Sustained

The Real Cost Math Behind Self-Hosted GitHub Actions Runners

Aug 11, 2026

We work through the actual cost crossover between GitHub-hosted Actions runners and self-hosted runners on dedicated bare metal, using GitHub’s current 2026 rates, correct a common misconception about a self-hosted runner fee that never took effect, and cover what a self-hosted build pipeline needs beyond just cheaper compute.