0xC004F047: VAMT Proxy Activation Fails on a Stale Policy Cache

Fix it now

Microsoft publishes no meaning for 0xC004F047, but it appears during VAMT proxy activation and one of its companions is documented: 0xC004F072 is SL_E_APPLICATION_POLICIES_MISSING, the licence policies for fast query could not be found. Treat this as state that has gone stale on one side or the other, and refresh it. Nothing here costs money.

slmgr /rilc
net stop sppsvc
net start sppsvc
slmgr /dli

1. In VAMT, use Refresh product key data online so the tool updates its own view of your keys and what they cover.
2. Re-read the affected clients in VAMT so it collects live state rather than what it cached earlier.
3. Collect fresh Installation IDs for those clients. A Confirmation ID is only valid against the ID it was issued for.
4. Re-run the proxy job for that subset only: Activate, then Proxy activate, then Apply Confirmation ID, apply to selected machine(s) and activate.

If a client was rekeyed since collection, reinstall the key with slmgr /ipk first and collect a fresh Installation ID afterwards, in that order.

If the subset activates, re-run the full job and you are done. If the same clients fail again, the next section covers where the staleness actually sits.

Why it happens

VAMT proxy activation exists for networks with no direct route to Microsoft. The tool reaches each client over WMI, collects its Installation ID, sends the batch from a machine that does have internet access, receives Confirmation IDs back, and writes them onto the clients. That is two machines and a database in the middle, all of which have to agree about the state of each device, and the run stops the moment they do not.

0xC004F047 is not published by Microsoft. Searching Microsoft’s documentation for it returns nothing, so anything that tells you precisely what it means is inferring. What is published is 0xC004F072, which the Software Licensing API documents as SL_E_APPLICATION_POLICIES_MISSING – the licence policies for fast query could not be found. Policy that the licensing service expected to have loaded is not there, and that is a real, documented failure of exactly the kind this article is about.

The client’s half of the state is that policy: licence files and policy data the Software Protection service loaded when the key was installed. It is cached deliberately, because reading it fresh on every operation would be slow. If the installed key, the edition or the build has changed since the cache was built, the cached policy no longer describes the machine VAMT is trying to activate.

VAMT’s half is the product information in its own database, which is populated when you add products and refreshed with Refresh product key data online. 0xC004D702, 0xC004F053 and 0xC004E001 all appear in the same runs and none of them is published either. They respond to the same treatment: refresh both sides rather than reinstalling keys or rebuilding machines.

Full reference

Where the staleness usually sits

The documented proxy activation run

1. Install product keys on the targets if they do not have them, using Install a product key or Install a KMS Client Key.
2. In the Products list, select the machines you intend to activate.
3. Use Filter in the right-hand pane if you need to narrow by computer name, product name, key type or licence status.
4. Choose Activate, then Proxy activate.
5. In the Proxy Activate dialog, choose Apply Confirmation ID, apply to selected machine(s) and activate.
6. Tick Use Alternate Credentials if the account running VAMT is not an administrator on the targets, then click OK.

VAMT itself needs to be on a machine with internet access, the products need an eligible key installed – MAK, KMS host key or retail – and the account has to have administrative permissions on every target with WMI reachable through the firewall. Where a target is in a workgroup, a registry setting has to allow remote administrative actions under User Account Control. Any one of those missing produces failures that look like policy problems and are not.

Commands, and what they do to local state

slmgr /dti and slmgr /atp are worth knowing even in a VAMT environment. When one machine refuses to cooperate with the batch, they let you complete that single exchange by hand and get on with the rest of the run.

Things not to do to fix this

• Do not delete or rename files in the licensing token store as a first step. It discards the machine’s local licensing state, and every licensed Microsoft product on it then needs activating again. slmgr /rilc is the supported way to rebuild licence files.
• Do not reinstall Windows. Nothing about the installation is damaged in the ordinary case.
• Do not re-key the whole estate. If the key was right yesterday it is right today; what has drifted is the cached state describing it.
• Do not collect Installation IDs in advance of a change window. They are only valid while the machine stays as it was.

Nothing here is a licensing shortfall

None of these codes says anything about your entitlement. Your keys, your seats and your agreement are unaffected, and no purchase makes any of them go away, because nothing about your licensing is wrong. If you are being sold something to resolve a proxy activation failure, it is not the fix.

The one exception worth checking before you start is the remaining activation count on the key itself. VAMT reports it after Refresh product key data online, and a MAK with nothing left produces a different code entirely – 0xC004C020, the Multiple Activation Key having exceeded its limit. That is a real licensing question and a different article.

Every code this article covers

Confirm the fix worked

1. In VAMT, the affected clients report an activated status read live from the machine rather than from the database.
2. On one of those clients, slmgr /dli reports Licence Status: Licensed.
3. slmgr /xpr on the same client confirms it is not sitting in a grace window.
4. The full proxy job completes with no remaining errors when re-run.
5. Refresh product key data online shows the remaining activation count falling by the number of machines you activated, and no more.

Questions people ask about this