0xC004F02C: Phone Activation Rejects Your Confirmation ID Format

Fix it now

Microsoft publishes this as the Software Protection Service reporting that the format for the offline activation data is incorrect, and its resolution is to check the ID entered during phone activation. The check happens locally, before anything is sent, so your key is fine and nothing on the machine needs repairing.

slmgr /dti
slmgr /atp <Confirmation ID>
slmgr /dli
slmgr /xpr

1. slmgr /dti prints the Installation ID, which you can copy rather than reading off a dialog. That removes the transcription step where this error is usually created.
2. Obtain the Confirmation ID for that exact Installation ID, then submit it with slmgr /atp rather than typing it into boxes.
3. If you are using the dialog instead, open it with slui 4, or search for SLUI 04 from Start.
4. If you are pasting a value, strip spaces, dashes and line breaks first; punctuation that came with a copy is the second most common cause.
5. Do the whole exchange in one sitting on one machine, without rebooting or changing the key in between.

Nothing in this article costs money. If you are being asked to pay for a tool that generates a Confirmation ID, that is not a route worth taking at any price.

If activation completes, you are done. If the value is refused again, the next section covers what is actually being checked and what the neighbouring codes mean.

Why it happens

Phone activation is the manual version of the exchange the machine normally does over the internet. Windows computes an Installation ID from the installed key and the installation itself; you pass that to Microsoft; Microsoft computes a matching Confirmation ID and passes it back; you give it to Windows. Two long numbers, moved between two systems by a human being, which is why the failure mode is what it is.

Microsoft’s published text for 0xC004F02C is that the Software Protection Service reported the format for the offline activation data is incorrect, and its listed resolution is to make sure the ID was entered correctly during phone activation. That is a local check on what you supplied, which is why the error is instant: there is no server involved at that point, no timeout to wait out, and no network fault to chase.

Because the check is local and about shape rather than content, it does not tell you whether the value is the right one. A perfectly formed Confirmation ID belonging to a different machine passes this check and fails the next one. That is useful information: when the code changes after you fix the formatting, you have moved on to a pairing problem rather than made things worse.

0xC004F02F, 0x803FA08E and 0x803FA08F are reported in the same situations and Microsoft publishes no meaning for any of them. There is no basis for treating the 0x803FA0 pair as the Settings-app rendering of the slmgr code; that mapping is asserted widely and is not documented.

Full reference

The two commands that make this easier

Most of the pain in phone activation comes from the dialog rather than from the process. slmgr /dti and slmgr /atp let you copy and paste both halves, which removes the step where this error is created.

What usually went wrong, and how it shows

When the format is right and it still fails

1. Read the Installation ID again with slmgr /dti and compare it with the one the Confirmation ID was issued against. If they differ, the pair is broken and a fresh exchange is the answer.
2. Check nothing regenerated the Installation ID in between: a key reinstall, a rearm, a rebuild or a snapshot restore will all do it.
3. Confirm which product the value belongs to. A ticket covering both Windows and Office is an easy way to use the wrong one.
4. Confirm the machine is the one you collected from. In a batch, this is the mistake that repeats.
5. If the code has changed rather than repeated, follow the new code; it is more specific than this one.

Doing this at scale

Beyond a handful of machines, the manual exchange stops being reasonable. VAMT proxy activation collects Installation IDs from clients over WMI, sends them from a machine that has internet access, receives the Confirmation IDs and writes them back, pairing the two halves automatically. The documented run is Activate, then Proxy activate, then Apply Confirmation ID, apply to selected machine(s) and activate.

It needs VAMT on an internet-connected machine, an eligible key installed on the targets, administrative permissions on them, and WMI reachable through the firewall. That is more setup than one phone call, and it pays for itself the second time you would otherwise be reading numbers aloud.

What this code says about your licence

• Nothing has been rejected. The key has not been refused; the data you typed was not in the expected shape.
• Nothing has been consumed. A failed attempt does not spend an activation.
• Nothing needs buying. This is a formatting check on a value you can re-enter.
• Nothing is damaged. No repair, reinstall or licence-store rebuild is called for.

Availability of the telephone route

The offline route exists for machines with no internet connection, and the dialog is still part of Windows. What varies is the automated telephone service itself, which is not offered identically in every country and for every product. If the number you have does not lead anywhere useful, that is a reason to look at VAMT proxy activation or at getting the machine a route to the internet, rather than a sign that something on the PC is broken.

Every code this article covers

Confirm the fix worked

1. The activation completes rather than returning you to the entry boxes.
2. slmgr /dli reports Licence Status: Licensed.
3. slmgr /xpr reports the machine as permanently activated rather than in a grace window.
4. Start, Settings, System, Activation shows no remediation link.
5. Reboot and re-check, so you know the state survived a restart.

Questions people ask about this