cscript slmgr.vbs /ipk <New-Office365-KMS-Key> cscript slmgr.vbs /dli cscript slmgr.vbs /ato The first two commands worked. The third—activation against Microsoft's servers—failed. "Error: 0xC004F074. No KMS key found."
Six months ago, Alex had migrated the company from Office 2016 (perpetual, KMS-friendly) to Microsoft 365 Apps for enterprise (subscription-based, designed for cloud activation). He'd assumed the old KMS server would just handle the new clients. It did not.
cd "C:\Program Files\Microsoft Office\Office16" cscript ospp.vbs /dstatus cscript ospp.vbs /remhost cscript ospp.vbs /sethost:kms.contoso.com cscript ospp.vbs /act Office 365 Kms Activation
(his laptop). Then 4/25 . Then 12/25 . Other users, still online, were automatically reactivating as their Office clients performed their next background check-in.
slmgr /dli showed the old Office 2016 KMS host key. Fine. But the new Office 365 clients were looking for a different KMS host key—one tied to Microsoft's subscription activation. cscript slmgr
But Dave had retired to a fishing boat in Florida, and Alex had inherited the server like a ticking time bomb.
cscript slmgr.vbs /dli cscript slmgr.vbs /dli all Finally, he forced a test on his own laptop. He opened an elevated Command Prompt on his Windows machine, navigated to Office's installation folder: No KMS key found
Alex knew the problem instantly. His predecessor, Dave, had set up a host for Microsoft Office years ago. Every 180 days, company computers would quietly check in with this internal server to reactivate. No internet needed. No Microsoft accounts. It was elegant—when it worked.
It was 5 PM on a Friday.