0xC004F06B: The Licensing Service Will Not Make This Machine a KMS Host

Fix it now

This code appears when you install or activate a KMS host key, not later, and it stops the machine becoming a host. Microsoft publishes no meaning for it, so start by ruling out the two things that are documented: the edition you are running, and whether a host key belongs on this machine at all.

slmgr /dlv
DISM /Online /Get-CurrentEdition

1. Read the description line from slmgr /dlv. It says whether a KMS host key or an ordinary client key is installed, which is the first thing to establish.
2. Check the edition. An evaluation installation will not take a production key, and converting one is a planned change rather than a quick fix.
3. Confirm the key you hold is the KMS host key for the product family you mean to serve, not a client key and not a MAK. Your licensing portal labels them differently.
4. On Windows Server, stand the role up the documented way rather than with slmgr /ipk alone: Install-WindowsFeature -Name VolumeActivation -IncludeManagementTools, then run vmw.exe and follow the Volume Activation Tools wizard.
5. If the estate is domain-joined, look at Active Directory-Based Activation in the same wizard before building a host at all.

Being a virtual machine is not the cause. Microsoft states you can run a KMS host on any physical or virtual system running a supported Windows Server or Windows client operating system.

If the wizard completes and the key activates, you have a host. If it still refuses, the next section covers what else the licensing service is checking.

Why it happens

A KMS host is not something you install from a feature list and then switch on. It is a state the Software Licensing service enters when it is given a host key and that key activates against Microsoft. Before it enters that state it checks the machine underneath it, and this code is the check failing. It fires at key installation or key activation time, which is why chasing clients gets nowhere: no client was ever involved.

Microsoft publishes no meaning for 0xC004F06B. A search of Microsoft’s documentation returns nothing at all for it, and the same is true of 0xC004F029, 0xC004F016 and 0xC004FD00, which travel with it. That does not make the code meaningless – Windows is refusing something specific – but it does mean any confident statement about what it points at is somebody’s inference. This article works from what the documentation does say about hosts, and from what you can observe on the machine.

The most widely repeated inference about this code is that KMS cannot be hosted inside a virtual machine. That was true of the first generation of KMS hosts, which required physical hardware, and it has not been true for a long time. Microsoft’s current KMS planning and KMS host articles both state that you can run a KMS host on any physical or virtual system running a supported Windows Server or Windows client operating system. If you have been told to find spare hardware because of this code, check the build you are hosting on first.

What is documented, and worth knowing before you spend time on this, is that a KMS host running Windows Server can activate both server and client operating systems, while a KMS host running a Windows client edition can activate only client operating systems. For a mixed estate that settles which machine should hold the role.

Full reference

Three ways to activate a volume estate

What the documentation actually says about hosts

• A KMS host can run on any physical or virtual system running a supported Windows Server or Windows client operating system.
• A host on Windows Server can activate both server and client operating systems. A host on a Windows client edition can activate only client operating systems.
• The count thresholds are 25 or higher for client editions and 5 or greater for servers and volume Office editions, and the count includes virtual machines.
• The host counts only unique connections from the past 30 days and stores the 50 most recent contacts.
• Active Directory-Based Activation requires the forest schema to be updated with adprep.exe on a supported server operating system, and serves domain-joined devices only.

Standing the role up properly

1. Install-WindowsFeature -Name VolumeActivation -IncludeManagementTools in an elevated PowerShell session.
2. Set-NetFirewallRule -Name SPPSVC-In-TCP -Profile Domain,Private -Enabled True.
3. vmw.exe to launch the Volume Activation Tools wizard.
4. Choose Key Management Service, or Active Directory-Based Activation if you would rather not run a host.
5. Enter the KMS host key from the Microsoft 365 admin centre and activate it online or by telephone.
6. Commit, close, and confirm with slmgr /dlv that the machine now describes itself as a host and reads Licensed.

Doing it this way rather than with slmgr /ipk alone is worth the extra two minutes. The wizard configures the role as well as installing the key, and it is the route Microsoft documents, so when something does fail you are failing in a state the documentation describes.

Codes that keep this company

Four unpublished codes in one article is unusual and worth saying out loud. It means the honest diagnostic path is the machine in front of you – edition, key type, role state – rather than a lookup table. Anything that tells you precisely what 0xC004F06B means is guessing.

Deciding before you build anything

Most of the time this code is met by someone building a KMS host who did not need one. The threshold is the thing to check first: KMS will not activate a client edition until 25 machines have contacted the host, and that number is not adjustable. Below it, a host is not a slow solution, it is not a solution.

For a domain-joined estate of any size, Active Directory-Based Activation removes the host, the DNS record, the port and the threshold in one move, and it uses the same host key you already hold. For machines that are not domain-joined and rarely reach your network, MAK is the answer and always was. The middle case – a domain-joined estate above 25 machines that wants a single point of control – is where a KMS host genuinely earns its keep.

Every code this article covers

Confirm the fix worked

1. On the host, slmgr /dlv names a KMS host key and Licence Status reads Licensed.
2. netstat -ano | findstr :1688 on the host returns a LISTENING line.
3. A client runs slmgr /ato successfully and slmgr /dlv on it names the host you built.
4. If you took the Active Directory route instead, a domain-joined client activates without any KMS machine name appearing in its slmgr /dlv output.
5. The host still reads Licensed a week later, which confirms its own activation held rather than sitting in a grace window.

Questions people ask about this