Office 0x4004F040: activated, but you must verify your Product Use Rights

Fix it now

Office is activated. The severity bit on 0x4004F040 is clear, which the documented HRESULT layout defines as a success result, so nothing is broken and nothing needs repairing. Microsoft publishes no description for the code itself, so treat it as a prompt to check that what activated is what your agreement grants.

cd "C:\Program Files\Microsoft Office\root\Office16"
cscript ospp.vbs /dstatus
cscript ospp.vbs /dstatusall
cscript ospp.vbs /ddescr:0x4004F040

1. Note three things from /dstatus: the product name, the channel, and the last five characters of the key.
2. Compare the product name against what your agreement actually grants. Professional Plus and Standard are separate licences with separate keys, and installing the wrong one is the usual reason this appears.
3. /ddescr: prints the text Office itself holds for the code, which is the only wording with the vendor behind it.
4. If the installation exceeds what you hold, either redeploy the edition you are licensed for or license the edition you have installed. Both are legitimate answers.

Nothing here is urgent in the way a failed activation is. It is a compliance question with a technical prompt attached.

If the product name matches your agreement, record the check and stop. If it does not, the next section covers the four ways that happens.

Why it happens

Start with what can be established. Microsoft publishes no description for 0x4004F040 on any support or documentation page. What is documented is the HRESULT layout: the top bit is a severity bit, and when it is clear the result is a success rather than a failure. On this value it is clear. So whatever the notice says, Office activated, and there is no fault to repair on the machine.

Read the text your own machine holds rather than a gloss: cscript ospp.vbs /ddescr:0x4004F040 prints it. That is a two-second check and it is worth doing before anyone spends an afternoon on a compliance question they may not have.

The reason a code like this exists at all is that activation is deliberately not a compliance check. Volume keys are designed to activate broadly so that deployment does not stall, and Microsoft publishes a separate Generic Volume License Key for each edition precisely so that each edition can find its own licence. Nothing in that arrangement stops an administrator deploying Professional Plus with a Professional Plus GVLK on devices the agreement only covers for Standard. The software succeeds; the entitlement is a separate document.

In practice the mismatch has a small number of shapes. A build was deployed with a product ID that does not match what was bought. Devices outside the organisation named on the agreement are carrying the volume key. Or Office has moved into a shared or virtual desktop scenario whose terms differ from ordinary per-device use. The two companion codes, 0xC004F028 and 0xC004F073, have no published descriptions either.

Full reference

Which situation is yours

What the software can and cannot tell you

That table is the whole point of this notice. Everything in the top half is knowable from the machine in a minute. Everything in the bottom half is not knowable from the machine at all, which is why the software raises a prompt rather than an error: it has done what it can and the rest is a document.

Edition, product ID and key all have to agree

Microsoft publishes a distinct Generic Volume License Key for Professional Plus and for Standard in each release, and a distinct product ID for deploying each: ProPlus2024Volume and Standard2024Volume, with the 2021 equivalents for that release. Its own guidance on the product IDs is blunt: if you use the wrong product ID, you cannot activate Office. So a deployment that activated at all tells you the three agreed with each other. What it does not tell you is whether they agree with what you bought.

Doing the check properly, once

1. Export the installed edition and channel from a sample of devices, using /dstatus through your management tooling rather than by walking to desks.
2. Get the licence quantities and products from your volume licensing portal, not from an old purchase order.
3. Compare them by edition, not by count alone. A hundred licences of the wrong edition is not coverage.
4. Note the devices that fall outside the organisation named on the agreement, because those need their own licences whatever the count says.
5. Write down who confirmed it and when, so the same question does not have to be answered from scratch next year.

The two companion codes

0xC004F028 and 0xC004F073 have no published descriptions. Both are failure-severity codes, unlike 0x4004F040, so if you are seeing one of them the machine is not activated and this is the wrong article. Read the vendor’s text with cscript ospp.vbs /ddescr: and work from there.

Can you simply ignore it?

Technically, yes: Office is activated, editing works and no banner appears. Whether that is wise depends on whether the mismatch behind it is real. A notice that reflects an edition or a device genuinely outside your agreement does not go away on its own, and it resurfaces during a licence review, when the conversation is less comfortable and the remedy is priced by someone else. Checking costs an hour.

Every code this article covers

Confirm the fix worked

1. cscript ospp.vbs /dstatus reports a licensed status and names the edition you are licensed for.
2. cscript ospp.vbs /dstatusall shows no second licence you did not expect.
3. The product ID used to deploy matches the licence you hold.
4. The number of activated devices agrees with your purchase records.
5. The check is written down, with who confirmed the entitlement and when.

Questions people ask about this