Helpdesk: "Since Monday, every new laptop from the latest image says Windows isn't activated, and two Windows Server 2025 VMs we built last week show error 0xC004F074. slmgr /ato says no Key Management Service (KMS) could be contacted. The old KMS server was retired over the summer and someone stood up a new one. A forum post says to point every machine at the new server with slmgr /skms, rearm them all, and if that fails, switch everything to a MAK key. Can we start with that?"
Not yet. 0xC004F074 doesn't mean the KMS host is broken. It means every KMS host the client tried, found, or was pointed at returned an error, and the client log records each attempt. Microsoft's 0xC004F074 article lists three causes for the "No Key Management Service (KMS) could be contacted" form: "The Software Protection Platform Service (sppsvc service) on the KMS host has stopped running.", "There are networking issues between the KMS client and the KMS host server.", and "There's an incorrect or old KMS host server record in the Domain Name System (DNS)." Its other form adds "A time difference between the KMS client and the KMS host machine" and "A support version mismatch between the KMS client and the KMS host machine". A retired KMS host is the textbook case: its _vlmcs._tcp SRV record is still in DNS, the clients keep asking it, and the new host never published a record, or it can't activate the newer OS. Pinning every machine to one server with /skms turns off the discovery that would have found the next host, and rearming resets timers without fixing anything the client can't reach. Work through it as a chain: which machine, which product, which code, since when → what the client thinks it is (slmgr /dlv) → what the client tried (Event 12288 and 12289) → what DNS hands it (_vlmcs._tcp) → can it reach TCP 1688 on that host? → is the host licensed, listening, publishing, and new enough for this client? → is the count high enough? → are the clocks within four hours? → Office, AD-based activation, Azure, and other paths. slmgr.vbs, Get-WinEvent, nslookup, Resolve-DnsName, Test-NetConnection, Get-CimInstance, and w32tm are the sources for that chain. Pin everything with /skms and rearm, and you'll be undoing it one machine at a time when the next KMS host moves.
If domain controllers show the same DNS and port symptoms, Active Directory Replication Error 1722 covers the DC side of the same name-and-port reads. If the stale record is one of many, DNS Scavenging Not Working covers why old records outlive their hosts. This post covers "Windows clients or servers with a KMS client setup key (GVLK) fail to activate with 0xC004F074, 'No Key Management Service (KMS) could be contacted', or a related KMS code, and you need a read-first path before you pin hosts, rearm, change keys, or rebuild the KMS host."
TL;DR
-
Read the client before you touch the host.
slmgr /dlvshows whether this is even a KMS client: Microsoft says "VOLUME_KMSCLIENT indicates that the system installed the KMS Client Setup Key, or GVLK, which is the default configuration for volume license media." (Step 2). - The Application log names the host it tried. Microsoft's 0xC004F074 fix: "Identify each event associated with the activation attempt that has an Event ID of 12288." Its Info field carries the result code and the host and port (Step 3).
- DNS finding a record isn't the client finding it. Microsoft: "If the nslookup command finds the KMS host, it does not mean that the DNS client can find the KMS host." Read the suffix search list and the record's target (Step 4).
- Test TCP 1688 from the failing client. Microsoft: "Review the TcpTestSucceeded output parameter. If it's False, it means that port 1688 is blocked between the KMS client and the KMS server." (Step 5).
- A new host has to be licensed, published, and new enough. Microsoft: "Windows Updates might be required on the KMS server to support activation of newer clients." (Step 6).
- Clocks matter. Microsoft: the related 0xC004F06C error "may occur if the difference between system time on the client computer and the system time on the KMS host is more than 4 hours." (Step 8).
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Which machine, product, code, network, since when | "Activation is broken" with no code |
| 2. Client is a KMS client | GVLK installed (VOLUME_KMSCLIENT), right edition |
MAK, retail, or the wrong edition's key |
| 3. Client events read | Event 12288 names the host and the result | Nobody opened the Application log |
| 4. DNS answers |
_vlmcs._tcp in the client's zone points at a live, current host |
SRV record for the retired server |
| 5. Port open | The client reaches TCP 1688 on that host | Works on the LAN, fails from the server VLAN or VPN |
| 6. Host healthy | Licensed, sppsvc running, listening, publishing, supports this OS | New host never activated, or too old for Server 2025 |
| 7. Count met | 25 for Windows clients, 5 for servers and Office | Count stuck at 1 after a new image |
| 8. Time | Client and host within four hours (UTC) | VM restored from an old checkpoint |
| 9. Office | Office VL pack on the host, Office client set up | Windows activates, Office doesn't |
| 10. Other paths | AD-based activation, Azure KMS, activation type known | Domain clients use AD; Azure VMs can't reach Azure's KMS |
| 11. Change | Only after Steps 1-10 agree: one link, one change |
/skms on every machine, same stale record |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| Which machines, and how many | One machine is a client problem; a whole OU, VLAN, or image is DNS, the host, the count, or the image |
| Which product | Windows (slmgr.vbs) and volume Office (ospp.vbs) activate separately against the same host |
The exact code and text from slmgr /ato |
The Settings page wording varies; the code doesn't (table below) |
| OS edition and build | A new OS needs a host that supports it (Step 6) |
| Which network | LAN, VPN, a server VLAN, Azure. Microsoft: "The KMS host must reside on your local network." |
| Since when, and what changed | KMS host retired or rebuilt, DNS zone change, new image, firewall change, VM restore |
Run activation once, from an elevated prompt, and copy the full message. Microsoft on /ato: "For systems that have a Generic Volume License Key (GVLK) installed, /ato prompts a KMS activation attempt." It also says "KMS activation doesn't require elevated privileges." Elevate anyway so the rest of this post's commands work (our habit).
:: Low-risk (one activation attempt, which also logs Events 12288 and 12289). Copy the full result
cscript %windir%\system32\slmgr.vbs /ato
The codes, each from Microsoft's error-code table:
| Code | Microsoft's text | Usually points at (our reading unless noted) |
|---|---|---|
| 0xC004F074 | "No Key Management Service (KMS) could be contacted." | Every host it tried failed; Event 12288 says why (Step 3) |
| 0x8007232B | "DNS name does not exist." | No _vlmcs SRV record in the zones the client searches (Step 4) |
| 0x8007007B | "0x8007007b DNS name does not exist." | Microsoft: "This issue can occur if the KMS client can't find the KMS SRV resource records in DNS." (Step 4) |
| 0x800706BA | "The RPC server is unavailable." | Microsoft's causes: the host's firewall and "DNS SRV records are stale." (Steps 4, 5) |
| 0xC004F038 | "The count reported by your Key Management Service (KMS) is insufficient." | Below 25 clients or 5 servers (Step 7) |
| 0xC004F06C | "The Key Management Service (KMS) determined that the request timestamp is invalid." | Clock skew (Step 8) |
| 0xC004F039 | "The Key Management Service (KMS) is not enabled." | Microsoft: "This issue occurs when KMS doesn't respond to a KMS request." (Step 5) |
| 0xC004F041 | "The Software Protection Service determined that the Key Management Server (KMS) is not activated." | Microsoft: "This issue occurs when the KMS host hasn't been activated." (Step 6) |
| 0xC004F042 | "The Software Protection Service determined that the specified Key Management Service (KMS) cannot be used." | Wrong host for this product: "This scenario is common in mixed environments with application-specific and operating system-specific KMS hosts." (Steps 6, 9) |
Then branch on what you see:
| What you see | What it usually means (our reading unless noted) | Start at |
|---|---|---|
| Every machine fails since the old host was retired | Stale _vlmcs record, new host not published |
Steps 3, 4 |
| Only the newest OS fails (Server 2025, latest Windows 11) | Host OS or CSVLK too old, or missing the required update | Step 6 |
| Only one VLAN, site, or the VPN fails | TCP 1688 blocked, or a different DNS zone | Steps 4, 5 |
| Clients fail with 0xC004F038, host count stuck low | Threshold not met, or duplicate CMIDs from the image | Step 7 |
| One VM fails after a restore | Clock more than four hours off | Step 8 |
| Windows activates, Office doesn't | Office VL pack missing on the host | Step 9 |
| An Azure VM fails | Azure's KMS endpoint or a forced-tunnel route | Step 10 |
| A home or personal PC shows 0xC004F074 | Not a KMS problem in your network: a volume key on a device that never belonged to one (Step 10) | Step 10 |
Step 2: Read what the client thinks it is (read-only)
Microsoft's KMS guidelines start here: "To see verbose output from the Software Licensing service, open an elevated Command Prompt window, or PowerShell window, and run slmgr.vbs /dlv." /dlv will "Display detailed license information." and "This operation doesn't require elevated privileges."
:: Read-only (writes local files). Detailed and short license info, plus the expiration date
cscript %windir%\system32\slmgr.vbs /dlv > C:\Temp\dlv-client.txt
cscript %windir%\system32\slmgr.vbs /dli
cscript %windir%\system32\slmgr.vbs /xpr
/xpr will "Display the activation expiration date for the product." and Microsoft adds that it's "primarily useful for KMS clients, because MAK and retail activation is perpetual." What to read in /dlv (field names from Microsoft's guidelines):
| Field | What it tells you (Microsoft's text unless noted) |
|---|---|
| Name | "The Name tells you which edition of Windows the system is using." |
| Description |
VOLUME_KMSCLIENT is a KMS client. "If you see a different value here, such as MAK, you must reinstall the GVLK to configure this system as a KMS client." |
| Partial Product Key | "The Partial Product Key determines whether the KMS Client Setup Key matches the OS the KMS client is using." |
| License Status | "For a system activated by KMS, this value should be Licensed." Grace means it hasn't reached a host yet |
| KMS Machine Name from DNS | "The KMS Machine Name from DNS shows both the FQDN of the KMS host that the client successfully used for activation and which TCP port it used to communicate." |
| KMS Host Caching | "If the client can't contact the cached KMS host, it queries DNS to discover a new KMS host." |
| Client Machine ID (CMID) | "The CMID should be unique in every KMS client that the KMS host is able to activate." (Step 7) |
The same data from WMI, which is easier to compare across machines (class and property names from Microsoft's SoftwareLicensingProduct and SoftwareLicensingService pages; the filter is ours):
# Read-only. The Windows license that has a key installed, then the client-side KMS settings
Get-CimInstance -ClassName SoftwareLicensingProduct -Filter "PartialProductKey IS NOT NULL" |
Where-Object Name -like 'Windows*' |
Select-Object Name, Description, LicenseStatus, GracePeriodRemaining, PartialProductKey,
KeyManagementServiceMachine, KeyManagementServicePort,
DiscoveredKeyManagementServiceMachineName, DiscoveredKeyManagementServiceMachinePort
Get-CimInstance -ClassName SoftwareLicensingService |
Select-Object Version, ClientMachineID, KeyManagementServiceHostCaching
LicenseStatus values, from Microsoft's SoftwareLicensingProduct page: 0 Unlicensed, 1 Licensed, 2 OOBGrace, 3 OOTGrace, 4 NonGenuineGrace, 5 Notification, 6 ExtendedGrace. DiscoveredKeyManagementServiceMachineName "Specifies the last discovered KMS host name through DNS." KeyManagementServiceMachine is the host set by hand; empty means auto-discovery (our reading of "Returns null if SetKeyManagementServiceMachine has not been called.").
Where the client looks, in order. Microsoft's timing and discovery reference lists it: the SKU-specific KeyManagementServiceName registry value, the AppID-specific value, the global value, the "SKU-specific cached KMS host", then "DNS auto-discovery (weight and priority honored)". And: "If a cached KMS does not respond, discovery is performed." A forgotten /skms from years ago sits at the top of that list:
:: Read-only. A hand-set KMS host or port on this client (no value = auto-discovery; error if absent is expected)
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform" /v KeyManagementServiceName
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform" /v KeyManagementServicePort
Microsoft's registry reference on that value: "Set this value to force the use of a specific KMS host by the KMS client." The SKU- and AppID-specific copies live in subkeys under the same path (Microsoft's reference); reg query with /s reads them too (our form).
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| Description says MAK or RETAIL | Not a KMS client; KMS isn't involved | Step 10, or install the right GVLK (Step 11) |
| Name shows a Home edition | Microsoft's KMS client setup key tables list no Home edition, so KMS can't activate it (our reading) | Step 10 |
KeyManagementServiceName set to an old host |
Pinned to the retired server; DNS never consulted | Step 11: /ckms
|
DiscoveredKeyManagementServiceMachineName is the retired host |
The last host it found; DNS may still hand it out | Step 4 |
| LicenseStatus 1, ticket says not activated | Look at the right product: Office or another edition | Step 9 |
| Same CMID on two machines | Image not generalized | Step 7 |
Step 3: Read Events 12288 and 12289 on the client (read-only)
Microsoft's fix for 0xC004F074 starts in this log: "Open the Application Event Log." and "Identify each event associated with the activation attempt that has an Event ID of 12288." Microsoft's known-issues page names the source: "Except for KMS events that have event ID 12290, Windows logs all activation events to the Application event log under the event provider name Microsoft-Windows-Security-SPP."
# Read-only. Activation requests (12288) and host responses (12289) on this client, newest first
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'Microsoft-Windows-Security-SPP'; Id = 12288, 12289 } -MaxEvents 20 |
Select-Object TimeCreated, Id, Message | Format-List
How to read them (Microsoft's text; the field order is our reading of Microsoft's sample event):
| Event | What it says | What to read |
|---|---|---|
| 12288 | "The client has sent an activation request to the key management service machine." | The Info line: the first value is the result code, then the host FQDN and port it tried (Microsoft's sample shows 0xC004F06C, 0x00000000, <KMS Host FQDN>:1688, ...) |
| 12288 with no 12289 | "If you see only event ID 12288 without a corresponding event ID 12289, either the KMS client couldn't reach the KMS host, the KMS host didn't respond, or the client didn't receive the host's response." | Steps 4-6: name, port, host |
| 12288 and 12289 | "A failed activation or reactivation might also have both events." | 12289's result |
| 12289 | "Activation Flag, which indicates whether the activation succeeded (1) or failed (0)." It also shows the "Current Count on the KMS Host" | Step 7 if the count is low |
Microsoft's known-issues checklist for 12289: "Is the result code 0? Anything else is an error." Then "Is the KMS host name in the event correct?" and "Is the KMS port correct?" To turn a result code into words, Microsoft: "IT pros can run Slui.exe to display a description of most activation-related error codes."
:: Read-only. Describe a result code taken from the 12288 or 12289 Info line (code is an example)
slui.exe 0x2a 0xC004F06C
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| 12288 names the retired host | DNS or the cache still hands it out | Step 4 |
| 12288 names the right host, no 12289 | Port, firewall, or the host itself | Steps 5, 6 |
| Result 0xC004F06C | Timestamp invalid: clock skew | Step 8 |
| Result 0xC004F038 in 12289, low count shown | Threshold not met | Step 7 |
| Result 0xC004F042 | That host can't activate this product | Steps 6, 9 |
No 12288 at all after /ato
|
The client found no host to ask: DNS (0x8007232B) | Step 4 |
Step 4: What does DNS hand this client? (read-only)
KMS clients find hosts through SRV records. Microsoft's guidelines: "The KMS clients use Domain Name System (DNS) SRV records ( _vlmcs._tcp) to identify the KMS host." And, from the DNS troubleshooting guide: "If the wizard queries DNS and does not find the DNS entry for the KMS host computer, the wizard reports an error." Microsoft's own read is nslookup -type=all _vlmcs._tcp>kms.txt; asking for SRV only is the same lookup with less output (our form, -type= per Microsoft's nslookup page):
:: Read-only. SRV records the client's resolver returns for its own suffix, then for a named zone (zone is an example)
nslookup -type=srv _vlmcs._tcp
nslookup -type=srv _vlmcs._tcp.contoso.com
Microsoft's expected answer looks like _vlmcs._tcp.contoso.com SRV service location: followed by priority, weight, port = 1688 and svr hostname = kms-server.contoso.com. Then check that each target is a live host on the current address:
# Read-only. Every KMS SRV record for the zone, then each target's address (zone is an example)
$srv = Resolve-DnsName -Name '_vlmcs._tcp.contoso.com' -Type SRV -DnsOnly | Where-Object Type -eq 'SRV'
$srv | Select-Object Name, NameTarget, Port, Priority, Weight
foreach ($r in $srv) { Resolve-DnsName -Name $r.NameTarget -Type A -DnsOnly | Select-Object Name, IPAddress }
The suffix the client searches. Microsoft: "If the nslookup command finds the KMS host, it does not mean that the DNS client can find the KMS host." Its next check: "Verify that the search list of the primary DNS suffix contains the DNS domain suffix that is associated with the KMS host." The zone a client searches is its primary DNS suffix or, for domain members, "the computer's domain as assigned by the DNS system (such as Active Directory Domain Services (AD DS) DNS)"; for workgroup machines it's the DHCP-assigned domain (Microsoft's guide).
:: Read-only. Primary DNS suffix, suffix search list, and DNS servers this client uses
ipconfig /all
# Read-only. The suffix search list as PowerShell sees it
Get-DnsClientGlobalSetting | Select-Object SuffixSearchList, UseSuffixSearchList
On the DNS server, read the records themselves. A retired host's record stays until someone removes it. Microsoft's known-issues page on a failed host: "If the new host has a different computer name, you can manually remove the DNS SRV RR of the failed host or (if scavenging is enabled in DNS) let DNS automatically remove it." If scavenging is on and the record is still there, DNS Scavenging Not Working covers why.
# Read-only. On a DNS server: the _vlmcs SRV records in the zone, with their timestamps (zone is an example)
Get-DnsServerResourceRecord -ZoneName 'contoso.com' -Name '_vlmcs._tcp' -RRType Srv |
Select-Object HostName, Timestamp, TimeToLive, @{ n = 'Target'; e = { $_.RecordData.DomainName } }, @{ n = 'Port'; e = { $_.RecordData.Port } }
The RecordData field names are our reading (read them with Format-List * first). A Timestamp means the record was registered dynamically; an empty one means static (our reading, from DNS aging). Microsoft on registration: "By default, a KMS host server dynamically registers a DNS SRV record one time every 24 hours." A dynamic record that stopped refreshing a day after the host died is the retired-host fingerprint (our reading).
More hosts than you think. Microsoft: "DNS returns the list of KMS hosts in a random order." and "If the session setup fails, the client randomly picks another KMS host." 0xC004F074 means all of them failed. Extra hosts also split the count: Microsoft warns "if there are too many KMS hosts available to the clients (either legitimate or unsupported systems), then the count might be distributed over all of them."
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| No SRV record (0x8007232B) | The host never published, or publishes to another zone | Step 6: DNS publishing |
| SRV record targets the retired host | Stale record (Microsoft's "incorrect or old" cause) | Step 11: remove it |
| SRV record right, A record old | Host moved; its A record didn't | Step 11: fix the A record |
Record in corp.contoso.com, clients search contoso.com
|
Different zones | Step 11: multi-domain publishing or /skms-domain
|
| An unknown host in the list | Someone's lab host or an unsupported system | Find its owner before deleting anything |
nslookup finds it, /ato still says DNS |
Suffix search list | Step 11: suffix list or /skms-domain
|
Step 5: Can the client reach TCP 1688 on that host? (read-only)
Microsoft's 0xC004F074 article gives the test: "use the Test-NetConnection PowerShell cmdlet to check if the port is open between the client and server." Use the host name from Event 12288 or the SRV target:
# Read-only. From the failing client: TCP 1688 on the KMS host (host name is an example)
Test-NetConnection -ComputerName kms01.contoso.com -Port 1688 |
Select-Object ComputerName, RemoteAddress, RemotePort, TcpTestSucceeded
Microsoft: "Review the TcpTestSucceeded output parameter. If it's False, it means that port 1688 is blocked between the KMS client and the KMS server." And from the DNS guide: "The firewalls on both the KMS client and the KMS host must allow communication over port 1688." Microsoft's known-issues page adds the network in between: "Make sure that routers do not block traffic using TCP port 1688 (if the default port is used) and that stateful traffic to the KMS client is allowed."
On the host, read the listener and its firewall rule. Microsoft: "By default, the KMS host has a firewall exception for KMS, but this exception isn't automatically enabled." Microsoft's host setup page uses the rule name SPPSVC-In-TCP:
# Read-only. On the KMS host: is anything listening on 1688, and is the KMS firewall rule enabled and for which profiles?
Get-NetTCPConnection -LocalPort 1688 -State Listen -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-NetFirewallRule -Name SPPSVC-In-TCP | Select-Object Name, DisplayName, Enabled, Profile, Direction
Get-NetFirewallRule -Name SPPSVC-In-TCP | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort
Get-NetConnectionProfile | Select-Object InterfaceAlias, NetworkCategory
A rule enabled only for Domain while the host's NIC is on Public blocks the clients (our reading; Get-NetConnectionProfile shows the category). Microsoft's guidelines also say "Communication with KMS uses anonymous RPC." and include an inbound TCP 135 rule next to the 1688 one in their firewall example; treat 135 as Microsoft's example, not a documented requirement for every client (our reading). Microsoft's VAMT KMS page: "Clients require RPC over TCP/IP connectivity to the KMS host to successfully activate."
A port other than 1688. /sprt "sets the port on which the KMS host listens for client activation requests. The default TCP port is 1688." Microsoft: "If you change the default port number in the KMS host configuration, also adjust the port number that you use for the resource records."
Name vs SRV, without changing anything permanent yet. Microsoft's DNS guide isolates the two by pointing one client at the host by name, then by IP, and running /ato each time: "If these commands resolve the problem, this is an SRV record issue." and, for the IP form, "If these commands resolve the problem, this is most likely a name resolution issue." That sets a registry value on the client, so it's in Step 11 with its undo (/ckms).
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
TcpTestSucceeded False from one VLAN or the VPN |
Network ACL or firewall between them | Network change for that one port |
| False from everywhere, host listening | Host firewall rule disabled or wrong profile | Step 11: enable the rule |
| Nothing listening on 1688 | sppsvc stopped, KMS not enabled, or a different port | Step 6 |
True, /ato still 0xC004F074 |
The host answers but refuses: licensing, version, count, time | Steps 6-8 |
Step 6: Is the host licensed, publishing, and new enough? (read-only)
Run the same /dlv on the host. Microsoft's guidelines: "The License Status shows the status of the KMS host system. The value should be Licensed. Any other value means you should reactivate the host." Microsoft's Office host page shows the KMS section of that output: Key Management Service is enabled on this machine, Current count, Listening on Port: 1688, DNS publishing enabled, KMS priority: Normal.
:: Read-only (writes one local file). On the KMS host: detailed license info for every installed product (Windows and any Office host keys)
cscript %windir%\system32\slmgr.vbs /dlv all > C:\Temp\dlv-host.txt
# Read-only. On the KMS host: the Software Protection service, KMS settings from WMI, and the KMS registry values
Get-Service -Name sppsvc | Select-Object Name, Status, StartType
Get-CimInstance -ClassName SoftwareLicensingService |
Select-Object Version, KeyManagementServiceListeningPort, KeyManagementServiceDnsPublishing, KeyManagementServiceLowPriority
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform' |
Select-Object DisableDnsPublishing, DnsDomainPublishList, KeyManagementServiceListeningPort, EnableKmsLowPriority
Microsoft's first 0xC004F074 cause is the service: "Check if the sppsvc service is running on the KMS server. If the service is stopped, start it." The registry values, from Microsoft's registry reference: DisableDnsPublishing "Set this to a non-zero value to block auto-publishing to DNS by the KMS host."; DnsDomainPublishList lists extra zones and "The KMS home domain is always used, so it is not necessary to include it here."; EnableKmsLowPriority carries a warning: "Note that on a busy system, this can prevent the KMS host from maintaining a sufficient count."
The host's own log. Microsoft: "If you're troubleshooting a client and can't find a corresponding event ID 12290 on the KMS host, then the client isn't connecting to the KMS host." The reasons it lists include "The firewall is blocking TCP 1688." and "The event log is full." And Event 12293: "This event indicates that the host didn't publish the required records in DNS."
# Read-only. On the KMS host: recent activation requests (12290) and DNS publishing failures (12293)
Get-WinEvent -FilterHashtable @{ LogName = 'Key Management Service'; Id = 12290, 12293 } -MaxEvents 50 -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, Message | Format-List
Get-WinEvent -ListLog 'Key Management Service' | Select-Object LogName, RecordCount, MaximumSizeInBytes, LogMode
For a 12290 from the failing client, Microsoft lists what to read: "The Minimum count needed to activate", "The CMID, which is a unique value on each system.", and "The License State and Time to State Expiration". For 12293, Microsoft's known-issues page: "Domain Name System (DNS) may restrict Write access or may not support dynamic DNS (DDNS)." It also says a second host may not be able to update the existing SRV record unless the SRV default permissions are changed.
Can this host activate this client? The CSVLK installed on the host decides which editions it can activate, and the host's OS decides which CSVLKs it can hold (Microsoft's activation versions table). Microsoft: "Updates are required when you want to activate a version of Windows that is newer than the version your KMS host is running." From Microsoft's required-updates table:
| KMS host OS | To activate | Required update (Microsoft's table) |
|---|---|---|
| Windows Server 2022 | Windows Server 2025 | February 13, 2024 - KB5034765 or later cumulative update |
| Windows Server 2019 | Windows Server 2025 | February 13, 2024 - KB5034768 or later cumulative update |
| Windows Server 2019 | Windows Server 2022 | June 8, 2021 - KB5003646 or later cumulative update |
| Windows Server 2016 | Windows Server 2022, Windows Server 2019 | June 8, 2021 - KB5003638 or later cumulative update |
The update is half of it. The host also needs a CSVLK from a group that covers the client: Microsoft's table lists "Volume License for Windows Server 2025" as hostable on Windows Server 2025, 2022 and 2019, and it activates Windows Server 2025 down to 2008 plus current Windows clients. Microsoft's planning page also limits client-OS hosts: "a KMS host running on a Windows client operating system can only activate computers also running client operating systems". The /dlv Description and Name lines show which CSVLK the host carries (Microsoft's guidelines: "The Description shows you which key is currently installed.").
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| License Status not Licensed | Host never activated (0xC004F041 on clients) | Step 11: activate the host |
| sppsvc stopped | Microsoft's first cause | Step 11: start it |
| No "Key Management Service is enabled" section | No CSVLK installed; it's just another client | Step 11: install and activate the CSVLK |
| No 12290 for the failing client | Request never arrived: DNS, port, or the log is full | Steps 4, 5 |
| 12293 present | Publishing failed: DNS permissions or no dynamic updates | Step 11: DNS permissions or manual record |
DisableDnsPublishing = 1 |
Publishing off by design; someone owns a manual record | Step 4: is that record current? |
| Host is Server 2019 with a 2019 CSVLK, client is Server 2025 | CSVLK group too old | Step 11: a newer CSVLK on a supported host |
| Host is missing the update in the table | Can't activate the newer OS | Step 11: patch the host |
Step 7: Is the count high enough? (read-only)
A host that answers can still refuse to activate. Microsoft's planning page: "Clients activate if the count is 25 or higher. Servers and volume editions of Microsoft Office products activate if the count is five or greater." And: "The KMS only counts unique connections from the past 30 days, and only stores the 50 most recent contacts." Below the threshold, clients get 0xC004F038, and Microsoft's fix is "Add computers to the KMS pool." Microsoft's guidelines on the counter: "If the count is 0, either the service was recently activated or no valid clients are connected to the KMS host."
# Read-only. On the KMS host: current count and the minimum this host requires (Windows host license only; filter is ours)
Get-CimInstance -ClassName SoftwareLicensingProduct -Filter "PartialProductKey IS NOT NULL" |
Where-Object { $_.Name -like 'Windows*' -and $_.IsKeyManagementServiceMachine } |
Select-Object Name, KeyManagementServiceCurrentCount, RequiredClientCount, KeyManagementServiceTotalRequests, KeyManagementServiceFailedRequests
KeyManagementServiceCurrentCount: "A value of -1 indicates the host is not enabled as a KMS or that it has not received any client-licensing requests." RequiredClientCount "Specifies the minimum number of clients that are required to connect to a KMS host to enable volume licensing." The /dlv cumulative-request section is usually noise; Microsoft: "Generally, this data isn't helpful for troubleshooting." The exception it names: if the count isn't rising, "you should see the number of failed requests increasing."
Count stuck at 1. Microsoft's guidelines: "A common issue related to the count happens when the environment has an activated KMS host and enough clients, but the count doesn't increase beyond one." The cause is the image: "If this value isn't unique, it's because the image wasn't correctly configured for distribution using sysprep." Compare CMIDs across two machines from the same image:
# Read-only. CMID on several clients from the same image (computer names are examples; needs WinRM/WMI access)
'PC001', 'PC002', 'PC003' | ForEach-Object {
Get-CimInstance -ComputerName $_ -ClassName SoftwareLicensingService | Select-Object PSComputerName, ClientMachineID
}
Microsoft's other count cause: "Another reason why the count might not be increasing is that there are too many KMS hosts in the environment and the count is distributed over all of them." Step 4's SRV list shows how many hosts the clients see.
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| Count under 25, Windows clients failing | Not enough unique clients in 30 days | Step 11: wait for the pool, or use AD-based activation or MAK for small sites |
| Count under 5, servers failing | Same, for servers | Step 11 |
| Count stuck at 1 or 2 | Duplicate CMIDs | Step 11: fix the image |
| Two hosts each with half the count | Count split across hosts | Step 11: retire the extra host and its record |
| Count -1 | KMS not enabled, or no requests yet | Step 6 |
Step 8: Are the clocks within four hours? (read-only)
Microsoft's 0xC004F074 article ties the time case to the code in the 12288 Info line: "The error 0xC004F06C listed in the info section may occur if the difference between system time on the client computer and the system time on the KMS host is more than 4 hours." And: "The time zone set on the client computer doesn't affect the activation since it's based on UTC." A VM restored from an old checkpoint, or a host with a dead CMOS battery, is the usual setup (our reading).
:: Read-only. This machine's time source and state, then its offset from the KMS host (host name is an example)
w32tm /query /status
w32tm /stripchart /computer:kms01.contoso.com /dataonly /samples:3
/stripchart with /dataonly "Displays the data only, without graphics." Microsoft's fix: "We recommend that you use a Network Time Protocol (NTP) time source or the Active Directory service to synchronize the time between computers." If a domain member's time is wrong, Windows Time Not Syncing With Domain Controller is the read-first path for the cause; resync only after you know why it drifted (our habit).
Step 9: Office volume activation (read-only)
Volume Office uses the same KMS host but its own client tool. Microsoft: "Any changes you make affect only Office client products. Configure the Windows client separately by using the slmgr.vbs script." The ospp.vbs script is in Program Files\Microsoft Office\root\Office16 (or Program Files (x86) for 32-bit Office on 64-bit Windows). Microsoft also notes "The ospp.vbs script doesn't work for Microsoft 365 Apps or subscription versions of Project and Visio." Those aren't KMS-activated, so they're out of this post's scope.
:: Read-only. On the Office client (64-bit Office path shown): license status, KMS activation history, CMID, and an error code's description
cd /d "%ProgramFiles%\Microsoft Office\root\Office16"
cscript ospp.vbs /dstatus
cscript ospp.vbs /dhistorykms
cscript ospp.vbs /dcmid
cscript ospp.vbs /ddescr:0xC004F074
/dstatus "Displays license information for installed product keys." and /dhistorykms "Displays KMS client activation history." On the host, Office needs its own pack and key: "To enable the KMS host computer to activate Office, you must install the Office Volume License Pack and enter your KMS key on the KMS host computer." Microsoft's Office host page also lists the minimum host OS per Office version (for example, Office LTSC 2024 needs "At least Windows Server 2019 or at least Windows 10 (volume editions)"). Step 6's /dlv all output on the host shows an Office KMS host entry when the pack and key are in place (Microsoft's sample: Name: Office 16, OfficeKMSHostVL_KMS_Host edition).
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
No Office entry in the host's /dlv all
|
VL pack or Office CSVLK not installed | Step 11 |
| Office 0xC004F042 | The host Office reached can't activate this Office version | Step 11: the right pack on the right host |
/dhistorykms shows an old host name |
Office pinned with /sethst
|
Step 11: /remhst
|
| Product is Microsoft 365 Apps | Not KMS | Microsoft 365 licensing, not this post |
Step 10: Other activation paths (read-only)
Active Directory-based activation. If the forest has an activation object, domain members with a GVLK activate from AD, not KMS. Microsoft: "If the ADDS object can't be retrieved, client computers use KMS activation." and "The slmgr.vbs /dlv command also indicates if KMS was used." slmgr /ao-list "Displays all of the activation objects that are available to the local computer." Microsoft calls it "the best option for activating client computers and servers" where every machine is domain joined and supported, but a KMS host is still needed for "Workgroup computers outside the domain".
:: Read-only. AD activation objects this machine can see
cscript %windir%\system32\slmgr.vbs /ao-list
An activation type set by policy. /act-type "sets a value in the registry that limits volume activation to a single type. Activation type 1 limits activation to Active Directory only." A machine limited to type 1 never tries KMS (our reading). The value is VLActivationType under the product's AppID and SKU subkeys (Microsoft's registry reference); reg query with /s /f VLActivationType on the SoftwareProtectionPlatform key finds it (our form).
Disjoint namespaces. /skms-domain exists for exactly this: "Use this option, especially in disjoint namespace environments, to force KMS to ignore the DNS suffix search list and look for KMS host records in the specified DNS domain instead."
Azure VMs. Azure VMs activate against Azure's KMS (azkms.core.windows.net:1688 in the public cloud, per Microsoft's table), not yours. Microsoft's forced-tunneling article: "The activation requires that the activation request come from an Azure public IP address." Test that endpoint with Step 5's Test-NetConnection, from the VM.
A device that isn't on the work network, or isn't a work device. Microsoft's consumer help lists 0xC004F074 with two causes: "You might see this error if you entered a product key for the Enterprise edition of Windows to activate Windows 11 Home or Windows 11 Pro." and "you're trying to activate your work device but aren't connected to your workplace's network". For an off-network work laptop, connect it (or the VPN) and rerun Steps 4-5. For a personal device, the fix is a key for that edition; Microsoft's KMS guide says "If this is incorrect, obtain a Retail key from the Microsoft Store." Third-party KMS activator tools and public KMS servers aren't a fix: they activate against a host you don't control and outside your licence (our view).
Common false starts
| What people try | Why it misleads (our reading unless noted) |
|---|---|
slmgr /skms on every machine |
/skms "disables auto-detection of the KMS host." Every pinned machine breaks again when that host moves (Microsoft's failed-host note) |
slmgr /rearm across the fleet |
"This option resets the activation timers." It doesn't find a host; rearms are limited |
| Installing the KMS host key on clients | Microsoft: "KMS keys should be installed only on KMS hosts, not on KMS clients." |
| Switching everything to MAK | Uses up MAK activations to work around a DNS record |
| Rebuilding the KMS host first | A new host with the old record still in DNS fails the same way |
| Opening 1688 to the internet | Microsoft's planning page: "The KMS host must reside on your local network." |
Deleting every _vlmcs record |
Removes the working host along with the stale one |
| A public KMS server or activator script | Activates against a host you don't control (our view) |
Step 11: Change one link, then prove it
Save what you'll change first:
:: Read-only (writes local files). On the client and on the KMS host: license output and the SoftwareProtectionPlatform key
cscript %windir%\system32\slmgr.vbs /dlv all > C:\Temp\dlv-before.txt
reg export "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform" C:\Temp\spp-before.reg /y
# Read-only (writes a local file). On a DNS server: the current _vlmcs records (zone is an example)
Get-DnsServerResourceRecord -ZoneName 'contoso.com' -Name '_vlmcs._tcp' -RRType Srv | Format-List * > C:\Temp\vlmcs-before.txt
Host service stopped (Step 6). Microsoft's step: "If the service is stopped, start it."
# Change, on the KMS host. Start the Software Protection service (dry run first)
Start-Service -Name sppsvc -WhatIf
Host firewall rule disabled (Step 5). Microsoft's host setup form, scoped to the profiles your clients use, dry-run first:
# Change, on the KMS host. Enable the built-in KMS rule for Domain and Private (Microsoft's form plus -WhatIf)
Set-NetFirewallRule -Name SPPSVC-In-TCP -Profile Domain,Private -Enabled True -WhatIf
Host too old for the client (Step 6). Install the update from Microsoft's table, or move the CSVLK to a supported host OS with a CSVLK group that covers the client. Then rerun Step 6's /dlv on the host.
Host not activated (Step 6). Microsoft's VAMT KMS page activates the host key with cscript.exe slmgr.vbs /ato on the host (or by phone with /dti and /atp). That's the one place /ato is a host step (our reading).
Stale SRV record (Step 4). Remove only the record for the retired host. Microsoft's warning on Remove-DnsServerResourceRecord: "If you do not specify RecordData, the cmdlet deletes all records that match RRtype and Name for the specified zone." For SRV, Microsoft's example passes priority, weight, port, and target in that order:
# Change, on a DNS server. Remove the one SRV record that targets the retired host (zone and target are examples; dry run)
Remove-DnsServerResourceRecord -ZoneName 'contoso.com' -RRType Srv -Name '_vlmcs._tcp' -RecordData '0', '0', '1688', 'kms-old.contoso.com.' -WhatIf
Microsoft's known-issues page also says to "delete any unnecessary SRV RRs from DNS, and then restart the computers." Clients that cached the old host fall back to discovery when it doesn't answer, per the timing reference; restarting the test client speeds that up (our reading).
No SRV record, DNS without dynamic updates (Steps 4, 6). Microsoft's manual record is _vlmcs, _tcp, priority 0, weight 0, port 1688, the host's FQDN. Microsoft's PowerShell example for an SRV record uses -Srv -Name -ZoneName -DomainName -Priority -Weight -Port; with KMS values (our form):
# Change, on a DNS server. Create the KMS SRV record by hand (zone and host are examples; dry run)
Add-DnsServerResourceRecord -Srv -Name '_vlmcs._tcp' -ZoneName 'contoso.com' -DomainName 'kms01.contoso.com' -Priority 0 -Weight 0 -Port 1688 -WhatIf
If you create records by hand, Microsoft says to turn off publishing on the hosts: "By disabling publishing, you prevent event logs from collecting failed DNS publishing events." /cdns will "Disable DNS publishing by the KMS host."
Clients in another zone (Step 4). Either publish there or point the clients there. Microsoft: "If the KMS host and KMS clients use different DNS zones, you must configure the KMS host to automatically publish its SRV records in multiple DNS domains." That's DnsDomainPublishList (REG_MULTI_SZ) on the host, then a restart of the Software Protection service: Microsoft: "This operation creates the SRV records." Or, per client or by policy, /skms-domain:
:: Change, on a client. Look for KMS SRV records in one named zone instead of the suffix list (zone is an example)
cscript %windir%\system32\slmgr.vbs /skms-domain contoso.com
Isolate name vs SRV, or bridge while DNS is fixed (Steps 4, 5). Microsoft's test, on one client, followed by its undo:
:: Change, on one client (temporary). Point at the host by name, try activation; then restore auto-discovery
cscript %windir%\system32\slmgr.vbs /skms kms01.contoso.com:1688
cscript %windir%\system32\slmgr.vbs /ato
cscript %windir%\system32\slmgr.vbs /ckms
/ckms "removes the specified KMS host name, address, and port information from the registry and restores KMS autodiscovery behavior." Microsoft on discovery: "We highly recommend that you use the automatic discovery process." If /skms by name fails, repeat with the host's IPv4 address to split name resolution from the SRV record (Microsoft's sequence).
Count too low (Step 7). Wait for more unique clients inside 30 days, or use AD-based activation for domain members. For a small site that will never reach 25 Windows clients, MAK is Microsoft's alternative: "If you cannot install a KMS host or if you cannot use KMS activation, try the Change the product key to an MAK procedure."
Duplicate CMIDs (Step 7). Fix the image, then the machines already deployed from it. Microsoft: "To reset the client computer ID (CMID) and other product-activation information, run sysprep /generalize or slmgr /rearm." Generalize the reference image before capture, not production machines (our habit). Microsoft's Sysprep page: "Generalizing the image removes computer-specific information such as installed drivers and the computer security identifier (SID)." For machines already deployed:
:: Change, on one deployed client with a duplicate CMID. Reset activation info, restart, then try KMS again
cscript %windir%\system32\slmgr.vbs /rearm
:: restart the machine, then:
cscript %windir%\system32\slmgr.vbs /ato
Clock skew (Step 8). Fix the time source first; then Microsoft's command on the client: "Run the w32tm /resync command to resync the time on the client."
Wrong key type (Step 2). For a machine that should be a KMS client, install the GVLK for its edition from Microsoft's KMS client setup keys page with slmgr /ipk, then /ato. Microsoft on /ipk: "If a key is already installed, it's silently replaced." Note the current key type in the ticket before you replace it (our habit).
Office (Step 9). On the host, the Office Volume License Pack and the Office KMS key. On a client pinned to an old host, Microsoft's /remhst "Removes the KMS host name and resets the port to the default (1688)." Then cscript ospp.vbs /act and /dhistorykms.
Then prove it. On the client, one activation and the two events; on the host, the matching 12290 and a count that moved:
:: Low-risk. On the client: one activation, then the license state (expect License Status: Licensed)
cscript %windir%\system32\slmgr.vbs /ato
cscript %windir%\system32\slmgr.vbs /dli
# Read-only. On the client: the newest 12288/12289 pair. On the host: the newest 12290 entries
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'Microsoft-Windows-Security-SPP'; Id = 12288, 12289 } -MaxEvents 2 |
Select-Object TimeCreated, Id, Message | Format-List
Get-WinEvent -FilterHashtable @{ LogName = 'Key Management Service'; Id = 12290 } -MaxEvents 5 |
Select-Object TimeCreated, Message | Format-List
The 12289 should show Activation Flag 1 (Microsoft: "whether the activation succeeded (1) or failed (0)"), and /dlv should show the expected host under KMS Machine Name from DNS. Then the next machine from the same VLAN, image, or site, because one machine passing doesn't clear the others (our habit).
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| SRV record for a retired host | Remove that one record (-RecordData, -WhatIf) |
Deleting every _vlmcs record |
| No record, DNS has no dynamic updates | A manual SRV record and /cdns on hosts |
/skms on every machine |
| Clients in another zone |
DnsDomainPublishList or /skms-domain
|
Hand-pinning each client |
| TCP 1688 blocked | One rule for 1688 from the client networks | Opening the host to every network |
| Host too old for the client | The update from Microsoft's table, or a newer host and CSVLK | Converting the new servers to MAK |
| Count stuck at 1 | Fix the image, then reset the deployed machines | Adding more hosts |
| Clock off by hours | Fix the time source, then resync | Rearming |
FAQ
What does error 0xC004F074 mean?
"No Key Management Service (KMS) could be contacted." The client tried every KMS host it found or was pointed at, and none activated it. Microsoft's causes: the host's Software Protection service stopped, a network block on TCP 1688, an incorrect or old SRV record in DNS, a clock difference of more than four hours, or a host that doesn't support the client's version. Event 12288 in the client's Application log names the host it tried and the result.
How do I find the KMS server from a client?
Run slmgr /dlv and read KMS Machine Name from DNS, or query DNS with nslookup -type=srv _vlmcs._tcp. Resolve-DnsName -Name _vlmcs._tcp.<your domain> -Type SRV shows every published host with its port.
Does KMS use TCP or UDP on port 1688?
TCP. Microsoft: "Any activation communications that occur between KMS clients and the KMS host use the 1688 TCP port." Test it from the client with Test-NetConnection -ComputerName <host> -Port 1688.
How many clients does KMS need before it activates?
25 for Windows client editions, 5 for Windows Server and volume Office, counted as unique machines over the past 30 days. Below that, clients get 0xC004F038. A count stuck at 1 usually means duplicate CMIDs from an image that wasn't generalized.
Should I use slmgr /skms to fix 0xC004F074?
As a test on one machine, yes: it splits SRV problems from name and port problems, and /ckms undoes it. As the fix, no: it turns off auto-discovery, so every pinned machine breaks again when that host changes. Fix the SRV record or the publishing zone instead.
Related posts
- DNS Scavenging Not Working (why a retired KMS host's SRV record can outlive the host)
- Active Directory Replication Error 1722 (the same DNS record and port reads, between domain controllers)
- Windows Time Not Syncing With Domain Controller (the clock behind 0xC004F06C and the four-hour rule)
- Netlogon Event ID 5719 (DNS and the DC locator, when a domain member can't find anything at all)
- Windows Server DHCP Not Assigning IP Addresses (DHCP hands workgroup clients the domain they search for SRV records)
Free checklist
Pointing every machine at one KMS host with slmgr /skms before one client was tested against the fixed SRV record is a change nobody tested where the activations happen. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=kms-activation-error-0xc004f074
Admin Pack Studio; not affiliated with Microsoft. Steps 1-10 favor read-only checks: slmgr /dlv, /dli, /xpr, /ao-list, ospp.vbs /dstatus, /dhistorykms, /dcmid, /ddescr, slui 0x2a, Get-CimInstance, Get-WinEvent, reg query, nslookup, Resolve-DnsName, ipconfig /all, Get-DnsClientGlobalSetting, Get-DnsServerResourceRecord, Test-NetConnection, Get-NetTCPConnection, Get-NetFirewallRule, Get-NetFirewallPortFilter, Get-NetConnectionProfile, Get-Service, Get-ItemProperty, and w32tm /query and /stripchart. slmgr /ato makes one activation attempt; output redirection and reg export write local files. Starting sppsvc, firewall rules, host updates and keys, SRV record changes, /cdns, DnsDomainPublishList, /skms, /skms-domain, /ckms, /rearm, /ipk, w32tm /resync, Office packs and ospp.vbs /remhst are deliberate changes. Change one link at a time, test from the failing network, and check current Microsoft Learn for version-specific behavior.
Top comments (0)