Server editions and SKUs: Standard, Datacenter, Core — what's actually different?

Five distinct concepts share one conversation: the release, the edition, the SKU, the install option, and the license. Most edition-related mistakes are just two of these five being conflated, so this section pins each one down with a concrete example before anything else on this page builds on them.

Version (release). The product generation you install: Windows Server 2025, 2022, 2019, going back through 2016 and 2012 R2. Modern releases are long-term support generations — 2022 and 2025 each get roughly five years of mainstream support followed by extended support — and feature availability, requirements (Windows Server 2025, for example, requires TPM 2.0 and specific CPU instructions for new deployments), and even which install options exist change from generation to generation. Windows Server also had a separate semi-annual channel that shipped newer feature updates on a faster cadence; that channel ended with version 23H2, so for new builds the 2022/2025 generations are the relevant choice. When someone says "which Server are you on," that's the question they're asking — and it's the first thing to establish, because several answers on this page depend on it.

Edition. The entitlement tier within a release: Standard and Datacenter. (Older releases also shipped Essentials for small businesses and Web for web workloads; those are gone from recent generations.) The edition decides what you're licensed to do — chiefly the virtualization entitlements covered in Tutorials 2 and 5 — and it's selected during setup and reported by the system afterward. Two servers running the identical version can be different editions, which is why "we run Windows Server 2022" is not a complete answer in a licensing conversation.

SKU. The specific product identifier attached to a particular purchase channel, media image, or OEM configuration. The edition is the entitlement; the SKU is how that entitlement is packaged and sold — a retail box, an OEM license tied to a server, a volume-license SKU, an evaluation image. SKUs can differ in packaging and channel while mapping to the same edition, and the same edition can appear under many SKUs. In practice you rarely choose a SKU directly; you choose a channel, and the SKU comes with it. What matters operationally is that the SKU you purchased is the one your license documentation references — a mismatch there is what shows up in activation and audit conversations.

Install option. How the OS presents itself after installation: Desktop Experience (full local graphical shell) or Server Core (command-line-first, no local GUI). This is the concept most often mistaken for an edition — it is not one. You don't buy Server Core separately; you select it at install time within whichever edition you licensed. Tutorial 3 covers what each option actually changes, and Tutorial 9 covers the important fact that, on recent releases, this choice is made at install and not freely reversible afterward.

Licensing entitlement. The legal right to use the software under specific terms: on current releases, a per-physical-core license for the physical server plus the OS environments (VMs) it hosts, together with Client Access Licenses (CALs) for the users or devices that access it. Activation is the separate technical process — KMS or MAK — that ties an installed copy to that entitlement. A machine can be technically activated and still be out of compliance with the underlying terms (enough cores, correct edition rights, CALs in place), and understanding that gap is what Tutorial 4 is for.

Which distinction matters when? Purchasing: edition + SKU + core count. Installing: edition + install option. Administering: install option (it dictates your tooling) and version (it dictates your commands and behavior). Auditing or licensing review: license entitlement, core counts, CALs, and virtualization rights — the edition is the input, not the answer. Hold those four mappings in mind and almost every "which do I need" question sorts itself into the right section below.

Takeaway: version = release, edition = entitlement tier, SKU = packaging, install option = local presentation, license = what you may run. The rest of this guide is about the decisions those five make together.

Both editions run the same operating system day to day — the same Active Directory, the same file services, the same PowerShell. The differences are in rights (what virtualization the license covers) and in advanced infrastructure features that are gated to Datacenter. Neither edition is "better"; they're priced and shaped for different points on the virtualization density curve.

Intended deployment. Standard is aimed at physical servers, containers, and modest virtualization — a file server, a domain controller, an application host, or a Hyper-V host with a small number of Windows guests. Datacenter is aimed at the highly virtualized and software-defined end: dense Hyper-V clusters, storage spaces direct fabrics, shielded-VM environments, and anything where you'd otherwise be stacking multiple Standard licenses just to make the VM count legal. The honest test is the one in Tutorial 5: count the OS environments you actually intend to run per host.

The entitlement difference (the 2016+ model). On Windows Server 2016 and later, a license for a physical server entitles you to run a number of Windows Server OS environments (OSEs) on it — the hypervisor counts as one. A Standard license covers two OSEs (the host plus one Windows guest, or two guests if the host role doesn't consume one in your configuration); stacking a second Standard license on the same physical server adds two more. A Datacenter license covers unlimited Windows Server OSEs on the licensed host. Note what this means for the earlier model: on 2012/2012 R2 the structure was different (Standard licensed the server itself and guest OSes were licensed separately), so legacy environments need the older rules applied — don't import 2012 assumptions into a 2022 audit.

The feature difference. A set of advanced, mostly infrastructure-scale capabilities have been Datacenter-gated across the 2016+ releases: Storage Spaces Direct, Shielded VMs and shielded hosts, guest clustering (failover clustering inside guest VMs), Hyper-V software load balancing, virtual machine groups, and device partitioning. If your design needs one of those, the edition decision is made for you. If it doesn't — and for the majority of SMB and departmental infrastructure, it doesn't — the edition decision reduces to VM density and cost posture. The full matrix with release qualifications is in Tutorial 6, because this list does shift between releases and must be checked against the documentation for yours.

What stays the same. Everything an administrator touches daily: roles and features (AD DS, DNS, DHCP, file services, IIS), Hyper-V basics including Live Migration, Storage Spaces, SMB Multichannel, iSCSI target, Windows containers support, and remote management. A Standard Desktop Experience server and a Datacenter Desktop Experience server administer identically. The edition difference is a design-time and license-time difference, not a day-to-day one — which is exactly why it's so often decided by habit or vendor default rather than by the actual VM count.

Takeaway: same OS, same admin experience; different rights and different advanced features. Decide edition from VM density and the feature matrix — not from brand preference — and carry the decision into Tutorial 5 for the exact entitlement math.

The most common structural confusion in Windows Server is treating Server Core as an edition. It isn't: Server Core and Desktop Experience are installation options of the same edition. A "Windows Server 2022 Datacenter (Server Core)" install and a "Windows Server 2022 Datacenter (Desktop Experience)" install carry the same entitlements — same virtualization rights, same feature availability — and differ in how much of the local shell exists on the machine.

What Server Core removes. The local graphical shell: no Windows Explorer desktop, no local MMC snap-ins, no local browser-based administration. What it keeps: the same roles and features (AD DS, file services, Hyper-V, IIS — all install and run), the full PowerShell surface, WMI, services, and the same update engine. The practical consequence is that a Server Core box is administered remotely (PowerShell remoting, Windows Admin Center, Server Manager from another GUI machine) or at the console — there is no "right-click" path on the box itself.

Why teams choose it. Three reasons, in rough order of how much they matter: a smaller attack surface (fewer locally reachable components means fewer local exploit paths and a leaner patch surface), a lighter patch and reboot footprint (GUI components are a meaningful share of what security updates touch), and slightly lower idle resource usage. None of these is dramatic for a single server, which is why the choice is often decided by operational culture rather than measured benefit — and that's fine, as long as the culture part is honest: a team that lives in GUI tools and has no remote-management practice will fight Server Core every time.

Compatibility is the real constraint. Some applications and some administrative workflows assume a local shell or GUI components — legacy management consoles, software that expects Explorer, tools that script against desktop components. The rule that works: if the workload and its tooling are scriptable and remotely manageable, Server Core is a clean fit; if anything in the stack needs a local GUI, choose Desktop Experience at install time. Because Tutorial 9 shows this choice is not freely reversible on recent releases, it's the one install-time decision to get deliberately, not by defaulting to whichever option Setup scrolled to.

Takeaway: install option ≠ edition. Pick Core for lean, remotely-administered roles; pick Desktop Experience when local GUI access or GUI-dependent tooling is part of the job. Decide at install time — the recent releases don't switch it back and forth afterward (Tutorial 9).

"Installed edition," "activation," "license," and "CAL" are four different objects that support tickets treat as one. A server can be the right edition, fully activated, and still under-licensed — or correctly licensed and showing an activation warning because KMS is unreachable. This section separates the objects and walks the core-count math that drives actual purchase quantities.

The entitlement model (2016 and later). Windows Server is licensed per physical core of the server's processors, with two minimums: a minimum number of cores licensed per physical processor (8), and a minimum per server (16 cores — i.e., a single-socket 4-core box still licenses as 16 cores). You license the physical hardware; the virtual machines on top are covered by the edition's OSE entitlements (Tutorial 5), not by extra core counts. Core counts come from the hardware as installed — a 2-socket, 16-core-per-socket machine is 32 licensable cores, full stop.

Client Access Licenses. The server license covers running the OS; it does not cover access to it. Every user or every device that connects to the server needs a corresponding Windows Server CAL — User CALs (licensed per person, device-independent) or Device CALs (licensed per device, user-independent) — chosen per environment, with external CALs for outside access. Two common confusions: the built-in Remote Desktop administration of a server is covered by two concurrent admin sessions without RDS CALs (deploying Remote Desktop Services for general user access is a separate CAL regime entirely), and CALs are needed per server role the user/device accesses — a box hosting both file services and a web app still needs the Windows Server CAL for access, just once. CAL structure depends on the release and your agreement, so treat the exact counts as a verification task, not a guess.

Activation is not compliance. Activation (KMS for volume environments, MAK for individual keys) is the technical handshake proving a license exists for the copy; it says nothing about whether core counts, edition rights, and CALs match the deployment. KMS clients contact the KMS host over UDP 1688; a broken DNS name or firewall rule produces "activation will expire" warnings on fully licensed machines, while a machine with a valid MAK can be activated yet non-compliant if it's running more OSEs than its edition covers. Check them as separate questions: is it activated? (slmgr) and is it compliant? (cores, OSEs, CALs — a paperwork and architecture question).

Worked examples — all hypothetical, no pricing. Example A: a 2-socket × 16-core file server → 32 cores to license, Standard edition (no VMs), plus CALs for the users accessing files. Example B: a single-socket 8-core Hyper-V host, Datacenter, running 12 Windows Server VMs → 16 cores (the per-server minimum applies), unlimited-OSE entitlement covers the 12 VMs, CALs per accessing user/device. Example C: a single-socket 6-core box → still 16 cores licensed; buying "just 6" would be under-licensed by the minimum rule alone. These three cover the mistakes that recur in practice: forgetting the per-processor minimum, counting VMs as cores, and assuming activation equals compliance.

Takeaway: license the cores (with the minimums), size the edition from the OSE count (next section), and CAL the access paths — then treat activation as a separate, smaller question. All four together, in that order, is the complete licensing picture.

The single most important sentence in this section: the number of VMs a host can technically run is not the number it is licensed to run. A Standard-edition host will happily host twenty virtual machines — the hypervisor doesn't check your paperwork. The entitlement is a rights question layered over the hardware, and the gap between "it runs" and "it's covered" is where the most expensive compliance findings live.

The 2016+ model, precisely. An "OS environment" (OSE) is one OS installation. The Hyper-V host OS is an OSE. Each Windows Server VM is an OSE. A Standard license on a physical server covers two OSEs — so, with the host running, that's one Windows guest per license. Stacking means purchasing and assigning a second Standard license to the same physical server, which adds two more OSEs (host + three guests total). Stacking must be done on the physical host's license count — you can't patch a Standard license onto one VM and Standard onto another and call the host Datacenter; the host's aggregate entitlement is what matters. A Datacenter license on the host covers unlimited Windows Server OSEs, and the non-Windows guests (Linux, etc.) that run on it aren't "consumed" from that entitlement — they run under their own licensing terms, which is why mixed fleets behave differently from all-Windows fleets.

Worked scenarios (hypothetical — rights only, no pricing). Scenario 1: one host, 4 Windows Server VMs. Standard covers host + 1 guest; you'd stack a second Standard license (host + 3) and still be one guest short — so either a third license or Datacenter. Datacenter covers all four with one. This is the exact density point where the edition question stops being academic. Scenario 2: one host, 2 VMs (one Windows Server, one Linux). Standard's two OSEs cover the host + the Windows guest; the Linux VM runs under its own license. No stacking needed. Scenario 3: two hosts, 2 Windows VMs each. Each host needs its own license covering its own OSEs — entitlements don't pool across hosts. Two Standards suffice; Datacenter on both is only worth it if the trajectory is toward higher density.

Takeaway: count OSEs per physical host, map them to the edition's entitlement, and remember stacking applies to the host — never assume "it boots the VMs" means "the VMs are covered." The decision guide in Tutorial 12 turns this into a workflow.

Feature availability is the edition question's second axis — and the one most prone to stale answers, because the gated set has shifted between releases. A feature matrix written for 2012 R2 is wrong for 2022 in multiple rows. The matrix below reflects the 2016+ pattern, flags the rows that are release-dependent, and — more importantly — shows you how to verify the answer for your release instead of trusting any single matrix, including this one.

The stable pattern across 2016, 2019, 2022 and 2025: the advanced software-defined infrastructure capabilities are the Datacenter-gated group — Storage Spaces Direct, Shielded VMs and shielded hosts, guest clustering, Hyper-V software load balancing, virtual machine groups, and device partitioning. Everything an administrator reaches for daily (Hyper-V itself, Live Migration, dynamic memory, Storage Spaces, SMB Multichannel, iSCSI target, AD DS, containers) is available in both editions. If your workload doesn't touch the gated group, edition choice is a virtualization-density and cost decision, not a feature decision.

How to verify for your release. Two checks, both on the server: Get-WindowsFeature against a specific feature name (e.g., StorageSpacesDirect) tells you whether it's available/installed on this edition — a feature that's gated will report as unavailable regardless of install attempts; and the edition itself via slmgr /dlv tells you which column of the matrix you're actually in. Then cross-check the official feature documentation for your release generation, because the matrix above is a working summary, not a substitute for the release-specific reference. That two-line habit — "what edition am I on, and does this release gate this feature?" — is the whole discipline.

Takeaway: the gated group is small and infrastructure-scale; everything else is edition-neutral. If your design touches the gated group, edition is decided — otherwise it's the Tutorial 5 math.

A Server Core install is the same Setup experience as any Windows Server install with two decisions that matter (edition, install option) followed by a console-first configuration phase. The walkthrough below is release-neutral — the exact screen wording varies between 2019/2022/2025 — and every step states the expected result and the usual failure so you can tell "working as intended" from "needs action."

Step 2 — Select the edition

Setup presents the edition choice: Windows Server [year] Standard (Desktop Experience), … Standard (Server Core), and the Datacenter equivalents. This is the Tutorial-2 decision made concrete — Standard or Datacenter based on your OSE count and the feature matrix. Select it here and the choice is what slmgr /dlv will report for the life of this install. Expected result: the installation option for your chosen edition is preselected and you proceed to partitioning. Common mistake: choosing the edition by which option Setup listed first rather than by the decision from Tutorials 2 and 5 — there is no supported downgrade path later (Tutorial 11 covers this).

Step 3 — Select the install option

The install-option choice — Desktop Experience or Server Core — is where Tutorial 3 becomes real. On recent releases this is presented within the edition selection (the edition screen lists each edition with both options) and, per the supported behavior documented for 2022 and later, it's the point of no return: there is no supported post-install switch after the OS is in place. Choose Server Core only if the remote-management story in Tutorial 8 is actually how you'll run the box. Expected result: Setup proceeds to disk selection. If you're unsure: choose Desktop Experience — adding a GUI later (on releases that support conversion) or reinstalling is far cheaper than discovering a GUI-dependent workload on a Core box.

Step 4 — Install and first console

Complete the disk selection (use the correct disk — on a repurposed server this is where accidental wipes happen), set the administrator password, and let Setup install. After the reboot, a Server Core machine lands at a command prompt, not a desktop: that's the entire local experience from here on. The first-stop tool is sconfig, a numbered local menu covering activation, domain join, renaming, network adapters, Windows Update, RDP, and the admin password. Expected result: a prompt at C:\Users\Administrator> where sconfig opens its menu. If you land at a desktop instead: you installed Desktop Experience — verify with the edition screen in Tutorial 11's checks, and decide deliberately whether to keep it.

Step 5 — Name, network, and connectivity

Give the server its permanent name and address, then prove it can talk to the network before anything else touches it. The commands below are PowerShell 5.1-compatible and work on any recent release; Set-NetIPAddress rewrites the address configuration, so run the Get- commands first and note the interface alias.

PowerShellRename-Computer -NewName "SRV-FILE-01" -Force -RestartCopy

Renames the server and reboots it (the -Restart is deliberate — some components cache the name). Run from an elevated prompt.

PowerShellGet-NetAdapter | Format-Table Name, Status, LinkSpeed Get-NetIPAddress -AddressFamily IPv4 Test-NetConnection -ComputerName 192.168.10.1Copy

Replace 192.168.10.1 with your gateway. Test-NetConnection reports reachability plus the TCP test result — all true means the network path is proven.

PowerShellSet-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.10.21 -PrefixLength 24 -DefaultGateway 192.168.10.1Copy

Only if the environment uses static addressing. Verify the alias with Get-NetAdapter first — a wrong alias edits the wrong adapter. (Alternatively use sconfig's network adapter option.)

Expected result: the new name after reboot (confirm with hostname), the configured IP in Get-NetIPAddress, and a passing Test-NetConnection to the gateway. If the rename "fails": the usual causes are a name already in use in the domain/DNS, or a name violating the 15-character NetBIOS limit for older integrations.

Step 7 — Remote administration and updates

Enable PowerShell remoting (it's the front door for everything in Tutorial 8) and confirm the machine is reachable as a remote endpoint, then bring the install current before it hosts anything — a fresh Server install is missing a backlog of updates.

PowerShellEnable-PSRemoting -Force Test-WSMan -ComputerName "srv-file-01.corp.example"Copy

Run Enable-PSRemoting locally at the console (it's on by default in many images but confirm). Test-WSMan from another machine returns "true" when the endpoint is reachable.

PowerShellGet-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5Copy

Lists recent updates. Trigger updates via sconfig (its Windows Update item) or your update management (WSUS/Config Manager/Group Policy) — run the updates, then re-check with Get-HotFix after any required reboots.

Expected result: a working Invoke-Command from a management machine and an up-to-date update list. If remoting is refused: check the WinRM service is running, the firewall profile for the domain network is allowing it, and (workgroup-only environments) the TrustedHosts configuration in Tutorial 8 — domain-joined boxes don't need TrustedHosts.

Step 8 — Verify the install

Close the loop with the three facts that define this machine: what it is (edition and version), what it's licensed as, and what it reports about itself.

PowerShellGet-ComputerInfo -PropertyName OsName, OsVersion, CsProcessors slmgr /dlvCopy

Get-ComputerInfo reports the OS name/version and processor count (your licensing input from Tutorial 4). slmgr /dlv reports the installed edition and license/activation state. Record both in your documentation — this pair is the first thing you'll need in any later audit conversation.

Expected result: the OS name matches the intended release, the edition matches the purchase, and the license state shows activated (or a clearly-understood pending-KMS state). If the edition reads differently than intended: stop and document it — an edition mismatch at day zero is the single most expensive discovery at audit time, and the fix is a planned reinstall, not a workaround (Tutorial 11).

Takeaway: edition and install option are chosen at setup and verified at the end with two commands; everything in between is naming, network, domain, remoting, updates. A Server Core box that passes Step 8 is a box you can administer the way Tutorial 8 describes.

Server Core isn't "unmanageable" — it's remotely-first. Every operation you'd do through a GUI on a Desktop Experience box has a PowerShell equivalent (that's the design: the GUI was always a front end over the same APIs), and Windows Admin Center provides a browser-based console for the operations you'd rather not script. This section establishes the two access paths and then walks the everyday operations with their prerequisites and failure modes.

Path 1: PowerShell remoting. On a domain-joined box, Enable-PSRemoting -Force (typically already on) plus Kerberos authentication is the whole setup — from any domain machine, Enter-PSSession or Invoke-Command reaches the server. Workgroup-only environments need the HTTP/TrustedHosts path, which is more moving parts and more risk:

Prerequisite for both paths: the WinRM service running and the firewall allowing it (both are the defaults after Enable-PSRemoting); the failure signature is "access is denied" or a timeout, and the first check is Test-WSMan from the management machine.

Path 2: Windows Admin Center. Install WAC on a management machine (a Desktop Experience box, a workstation, or a dedicated admin VM), connect to the Core server by IP/FQDN, and you get a browser UI for hardware health, services, storage, users, updates, and PowerShell — with server-specific capabilities added as WAC features. WAC is the right default for teams that want GUI administration without giving every server a local GUI: the shell lives on the admin machine, the attack surface stays on the server where it belongs. Verify current WAC support for your server release before standardizing on it — its feature coverage changes between versions.

The everyday operations. These are the five you'll run constantly, each with its gotcha:

One operational habit that separates Core environments that work from ones that don't: script the one-offs. The first time you do anything fiddly on a Core box (a feature install, a config change), save it as a script in your team's repository. On a GUI box the muscle memory is the documentation; on Core, the script is the only documentation that survives.

Takeaway: remoting is the primary path, WAC is the GUI path, and every operation has a scriptable form. If an operation "can't be done on Core," the accurate statement is "can't be done by clicking on the box" — and the script or WAC panel is the answer.

The question this section exists to answer correctly: can I switch install options after installation? The honest answer is "it depends on the release — and on recent releases, no." Because the choice is made at install time and the consequences of being wrong are a reinstall, the decision deserves the care this section lays out.

The supported paths by generation. Windows Server 2012 R2 introduced the ability to add the GUI components to a Server Core install (and remove them from Desktop Experience) using the Server-Gui feature set, each direction requiring a reboot; 2016 and 2019 continued to support this pattern. With Windows Server 2022, Microsoft removed the post-install switching: the install option is selected during setup and that's the box you get — the documented path to the other option is a clean install. Windows Server 2025 follows the same no-post-install-switch model. Treat "2019 or earlier: conversion supported (verify per release); 2022 and later: not supported" as the working rule, and confirm against the release documentation before planning anything around a conversion.

When conversion isn't an option, the alternative is migration. The pattern: install the target option on a new machine (same edition), join it to the domain, migrate the workload (roles, shares, configurations — most server roles support moving via their own export/import or by re-creating from documentation), update DNS and clients, decommission the old box. For a domain controller this means the proper DC promotion/demotion sequence; for a file server it's share and permission migration (and a plan for the permission model, which is usually the slow part, not the data).

Preparation checklist for either path. (1) Establish the release and whether conversion is supported at all. (2) Take a full backup or image of the source before touching it — a conversion or migration that goes wrong is recoverable only if the backup is real. (3) Run the compatibility check: list every application and every admin workflow that touches the box, and flag any that assume a local GUI. (4) Plan the cutover window and the DNS/client updates. (5) Verify after: the install option (a Core box has no shell; a DE box does), the edition unchanged (slmgr /dlv — the option switch must not alter the edition), and the workload under real use, not just "services are running."

Takeaway: don't assume the switch exists. Check the release, back up, verify compatibility, and prefer the clean-install/migration path on modern releases — it's slower and it's the supported one.

Workload-to-edition mapping is where Tutorials 2–6 become a purchase line. The pattern that holds across every row: the edition follows the virtualization density and the gated features; the install option follows the management model and the workload's GUI needs. Keep those as two separate decisions — "Datacenter + Server Core" and "Standard + Desktop Experience" are four independent choices collapsed into two words.

Three rows deserve more than a table cell. Domain controllers: AD DS runs identically in both editions and in Core — a Core domain controller is a well-supported, lean configuration; the edition question only becomes real if you're virtualizing the DCs densely (many DC VMs per host pushes toward the Datacenter math in Tutorial 5, though DCs are a case where many organizations deliberately keep counts modest). Highly virtualized environments: this is where the Standard/Datacenter economics actually bite — below roughly two-to-four Windows VMs per host, Standard is the sensible default; above that, run the Tutorial 5 OSE math and compare against current pricing for both editions (in many licensing programs the two editions carry the same per-core price, which makes Datacenter the cheaper answer at density — but that's a property of the licensing program, so verify yours). Dedicated single-role services (DNS, DHCP, NPS, update infrastructure): Standard + Server Core is the canonical configuration — one job, no GUI, minimal surface, remotely managed.

Takeaway: no workload demands a specific edition by itself — density and gated features do. Make the edition and the install option as two explicit decisions, and document the assumption each one rests on.

Edition problems have a distinctive shape: they're rarely crashes, they're mismatches — the box doesn't do what the plan assumed, and the cause is a fact about editions, install options, or licensing that someone skipped. The table below is the recurring set, each with the verification that proves the cause and the supported fix. Two principles hold for all of it: there is no supported edition downgrade or in-place edition change (the fix is a planned reinstall), and there is no "just enable the missing feature" for edition-gated capabilities (the fix is the edition, via licensing — not a hack).

Takeaway: edition problems are mismatches, not malfunctions — identify which of the five concepts (Tutorial 1) is mismatched, verify with the two-line first look, and fix it through the supported path (reinstall, license change, or configuration), never through an unsupported hack.

Everything above collapses into two questions: which edition (driven by VM density and gated features) and which install option (driven by management practice and workload compatibility). The matrix below is the at-a-glance version; the interactive guide under it walks the inputs and produces a recommendation with its reasoning — structured to show its assumptions, because an edition decision made on hidden assumptions is how Tutorial 11's table gets its entries.

Reading the output the way an engineer should. The recommendation states an edition, an install option, and the assumptions it used. Before acting, check the two assumptions that matter most: the VM count is a plan, not a promise — if the trajectory is toward higher density, the Datacenter answer arrives earlier than the count suggests; and "remote management in place" is a capability claim — if it's aspirational, the Desktop Experience recommendation is the honest one until the capability is real. Everything else on this page is the detail to pull when a specific row of the recommendation needs defending in a design review.

Next steps: run the guide, then verify its three load-bearing inputs — the OSE count (Tutorial 5), the feature gating for your release (Tutorial 6), and the current licensing terms (references below). A decision you can re-derive in five minutes is a decision that survives the next architecture review.

Server decisions connect to the physical layer underneath them — the power and storage that a host farm actually runs on — and to the wider library's hardware and how-to coverage.