KMS Activation Error 0xC004F074: A Read-First SRV Record, Port 1688, Host, Count, and Clock Triage

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 /dlv shows 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 1: Capture the symptom (read-only)

Write these on the ticket first:

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:

Then branch on what you see:

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):

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).

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):

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

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."

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).

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:

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.").

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.

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).

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

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

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:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=kms-activation-error-0xc004f074

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.