I'm a sysadmin at a large factory where production-floor computers run Windows IoT Enterprise LTSC. We're upgrading roughly 80 offline clients from Windows 10 2016 LTSB to 21H2 LTSC so they can continue receiving security updates for years. Some machines are older hardware that was originally sold with Windows 7, so replacing them all isn't practical yet.
Because these clients cannot reach Microsoft's activation servers, I currently activate each one manually with slmgr.exe and SLUI 4. The offline activation website requires entering the long installation ID, solving a CAPTCHA, signing in with a Microsoft account, and completing two-factor authentication. The session is not reliably remembered, and I have to restart the process for every machine. Each activation takes around two to five minutes, even though I've already automated the repetitive command entry with a small Python script and QR codes.
A local activation server has apparently been prohibited in our production VLANs by security and central IT, and our normal process is to purchase manufacturer-preactivated devices. The clients are domain joined, but our Active Directory environment is centrally managed and we only control a subordinate OU. I'm also looking into whether VAMT or another centrally managed activation method is available.
Is there a supported way to make this process faster, such as activating through Active Directory, VAMT, a centrally managed KMS/MAK arrangement, or another offline workflow? I'd prefer not to automate or bypass Microsoft's website authentication in a way that could violate licensing or security policy.
4 Answers
The first thing to investigate is a properly approved KMS or Active Directory-based activation service. A KMS host can activate eligible clients on the internal network, while Active Directory-based activation can handle domain-joined machines if your organization’s licensing and domain permissions support it. Since your domain is centrally managed, the domain owner or central IT team would need to publish the keys and configure the relevant activation objects. This would eliminate the manual website workflow without bypassing Microsoft’s controls.
I would avoid reverse-engineering the activation website or trying to reuse its API calls. Even if the session behavior makes it seem possible, that could create licensing, security, and account-compliance problems. The supported approaches—KMS, Active Directory-based activation, VAMT with approved MAKs, or manufacturer-provided activation—are worth escalating before attempting automation against Microsoft’s service.
VAMT may help if your organization has the required volume licensing, MAK keys, and permissions. It can inventory activation status and coordinate activation for multiple machines, but it isn’t a replacement for the licensing infrastructure itself. If KMS and local activation servers are prohibited, VAMT might still be useful for managing approved MAK activations, although central IT would probably need to provide the keys and approve the process.
That matches my understanding. I’ll check whether we have suitable MAK licensing and whether VAMT is permitted in our environment.
If a local activation server is forbidden in the production VLAN, the practical solution is probably an exception or service from central IT rather than a client-side workaround. They may already operate KMS or Active Directory-based activation for other corporate devices. You could document the manual effort—around 80 machines at several minutes each—and request a temporary, centrally managed activation path or have central IT activate the clients in a controlled staging network.
That sounds promising. I’ll ask the domain owner whether our OU and licensing setup can use Active Directory-based activation, and I’ll also raise KMS with the central team.