# netnr/kms: a public KMS activation endpoint for Windows and Office

> netnr/kms is a small repository whose README documents a public KMS host at skms.netnr.eu.org, the slmgr command sequence for Windows, and the ospp.vbs sequence for Office. The service is the product; the code is mostly a landing page.

**netnr/kms** — KMS 激活服务，slmgr 命令激活 Windows 系统、Office

- Repository: https://github.com/netnr/kms
- Website: https://kms.netnr.eu.org
- Stars: 3,292 · Forks: 498
- Language: HTML
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/netnr-kms

## What netnr/kms actually provides: a reachable KMS host, not an activation crack

The repository describes itself as a KMS activation service that uses the slmgr command to activate Windows systems and Office. Read the README closely and the shape of the project becomes clear: the deliverable is the hostname skms.netnr.eu.org, which the README says is kept pointed at a working server through a CNAME record. The repository itself is a landing page (index.html, favicon.ico, a _headers file, and a wrangler.jsonc configuration), not a KMS server implementation. Nothing in the README describes a server binary, a port listener, or a daemon that ships with this repository.

That distinction matters for anyone evaluating it. A KMS client talks to a KMS host over TCP port 1688. This project supplies an address for that host. The activation logic running on the other end is not visible in the repository, and the install section points elsewhere: the README cites the Wind4/vlmcsd releases page and recommends the portable build from kkkgo/vlmcsd for people who want to run their own server. So the project is best understood as a maintained DNS name plus documentation, sitting in front of a vlmcsd-style server that someone else wrote.

The intended audience is narrow and practical. It is for people who have volume-licensed Windows or Office installations and need a KMS host that answers on port 1688 without building one. It is not for retail licences, and it is not a licence generator: the README's key table is explicitly the Microsoft KMS client setup key list, which installs the generic key matching an edition so the client will attempt KMS activation.

## The slmgr sequence and what each step changes on the client

The Windows flow is three commands run from an elevated prompt. The README lists them in order: set the KMS server with slmgr -skms skms.netnr.eu.org, install the edition key with slmgr -ipk followed by the matching key, then activate with slmgr -ato.

The order is not arbitrary. slmgr -skms writes the KMS host into the client's configuration; without it the client queries DNS for a _vlmcs SRV record and may find a different server or none at all. slmgr -ipk installs the generic volume key for the edition, which is what makes the product a KMS client rather than a retail or MAK installation. slmgr -ato then triggers the activation attempt against whatever host is configured. Running -ato before -skms means the client tries the default discovery path.

The README's key tables cover a wide range of editions, from Windows 7 Professional and Enterprise through Windows 8.1, Windows 10 and 11 (Professional, Enterprise, Education, and their N and G variants), Windows 10 LTSC 2019 and LTSB 2015 and 2016, and Windows Server from 2008 through 2025, including the half-yearly channel releases and the Azure Edition variants of Server 2022 and 2025. The keys are copied from Microsoft's published KMS client activation key documentation, which the README links to twice. Treat the tables as a convenience index into Microsoft's list, not as an independent source; if an edition is missing, the linked Microsoft page is where the README sends you.

## Installing nothing: using the public host for a first activation

There is no package to install for the hosted service. The README's install section is about self-hosting, and it points at two external release pages rather than shipping anything in this repository. For the hosted path, the first real use is checking that the host is reachable from the machine you intend to activate, then running the three slmgr commands.

The README suggests telnet or tcping against port 1688 as the reachability test. A successful TCP connection is the signal you are looking for; a timeout means the client will fail at the -ato step.

```bash
telnet skms.netnr.eu.org 1688
```

On Windows, open an elevated Command Prompt or PowerShell and run the three steps in order. The key below is the Windows 10/11 Professional key from the README's table; substitute the key for your actual edition.

```bash
slmgr -skms skms.netnr.eu.org
slmgr -ipk W269N-WFGWX-YVC9B-4J6C9-T83GX
slmgr -ato
```

For Office, the README's steps are different because Office uses the OSPP script rather than slmgr. Change into the Office installation directory, register the KMS host, then activate. The README notes that Office16 corresponds to Office 2016, Office15 to 2013, and Office14 to 2010, and that the directory should contain OSPP.VBS.

```bash
cd "C:\Program Files (x86)\Microsoft Office\Office16"
cscript ospp.vbs /sethst:skms.netnr.eu.org
cscript ospp.vbs /act
```

The README specifies the 64-bit default path as C:\Program Files\Microsoft Office\Office16. If neither directory contains OSPP.VBS, the installed Office build is not a volume edition and the script will not be there to run.

## The 180-day renewal window and what happens when a client goes offline

The README's activation notes describe the KMS timing model plainly. Activation is valid for 180 days, a period it calls the activation validity interval. To stay activated, the system must contact a KMS server at least once every 180 days. By default the client retries renewal every 7 days, and each successful renewal restarts the 180-day interval.

The practical consequence is that a machine which never reaches the network for more than 180 days will fall out of activation, and the README says so directly. That is a real constraint for laptops that spend months offsite, for test VMs kept on an isolated segment, and for machines behind egress rules that block port 1688. The public host at skms.netnr.eu.org is only useful to clients that can reach it, and the README does not describe an offline or air-gapped path.

There is a second constraint that follows from the design. The README states that the hostname is maintained through a CNAME pointing at a valid service. That means the address you configure is stable while the underlying server may not be. If the CNAME is repointed or the target goes down, existing clients keep the hostname but stop renewing, and you find out at the next 7-day retry or, worse, when the 180-day window closes. The README offers no status page, no uptime commitment, and no notification mechanism. Reachability testing is something you do yourself, which is why the telnet and tcping lines are in the documentation at all.

## Where netnr/kms is the wrong choice, and what to run instead

The clearest case against the hosted service is any environment where activation must not depend on a third party's DNS record. If you are activating a fleet, a lab, or anything with a compliance obligation, the dependency on an external CNAME is a single point of failure you do not control. The README's own install section acknowledges this by pointing at vlmcsd: Wind4/vlmcsd for a build from source, and kkkgo/vlmcsd for a portable version the README recommends. Running vlmcsd on your own host replaces the external dependency with an internal one, at the cost of operating a server and keeping it reachable on port 1688 from every client.

A second alternative worth naming is the KMS host built into Windows Server itself. Microsoft's KMS client setup key documentation, which this README links, is written for exactly that scenario: a Windows Server acting as the KMS host for a domain. The difference in approach is governance rather than protocol. Both speak KMS on port 1688 and both issue 180-day activations. The server-based route gives you control over who can activate, logging, and a host inside your own network; the public host gives you a working endpoint in seconds with no infrastructure.

There is also a licensing boundary that the README does not resolve. KMS activation is a mechanism for volume-licensed products. The README supplies keys, but it does not supply licences, and it does not discuss what entitlements a user needs before pointing a machine at any KMS host. That question is outside the repository's scope, and the README does not attempt to answer it.

## Maintenance, licence, and the cost of depending on this repository

The repository is licensed MIT, which covers the code and documentation in the repository itself. It does not extend to the KMS service the hostname points at, and it does not cover the vlmcsd projects the README links to, which carry their own licences. Anyone reusing the README's key tables should note that those tables are reproduced from Microsoft's documentation, and Microsoft's terms govern that content.

The last push to the repository was on 2026-03-28, roughly six months before this writing. That is recent enough that the repository is not abandoned, but the README shows no release history: the releases query returned nothing, and the README does not describe a versioning scheme, a changelog, or an upgrade procedure. For a project whose main artifact is a documentation page and a DNS record, that is not necessarily a problem, but it does mean there is no upgrade path to plan for and no rollback procedure to follow if a change breaks your activation flow. The README is silent on rollback.

The operational cost sits with the user. You need to test reachability before deployment, monitor whether machines are renewing, and have a fallback (typically your own vlmcsd host) if the public endpoint stops answering. None of that is expensive, but none of it is provided by the repository either.

## Conclusion

netnr/kms is for administrators who already hold volume licensing rights for Windows or Office and want a reachable KMS host without standing up vlmcsd themselves; it is the wrong tool for machines that cannot reach the internet every 180 days, and for anyone who needs a documented SLA. Before pointing production machines at it, run telnet skms.netnr.eu.org 1688 or tcping skms.netnr.eu.org 1688 from the network in question, and confirm the hostname still resolves through its CNAME. The README lists no release history and no rollback procedure, so treat a failed activation as something you diagnose with slmgr /dlv rather than something the project will undo for you.

## FAQ

### How long does KMS activation with netnr/kms last?

The README states that KMS activation is valid for 180 days, a period it calls the activation validity interval. The client attempts renewal every 7 days by default, and each successful renewal restarts the 180-day window.

### How do I activate Microsoft products through KMS with netnr/kms?

For Windows, run slmgr -skms skms.netnr.eu.org, then slmgr -ipk with the key matching your edition, then slmgr -ato, all from an elevated prompt. For Office, change into the Office installation directory and run cscript ospp.vbs /sethst:skms.netnr.eu.org followed by cscript ospp.vbs /act.

### Can netnr/kms activate Microsoft Office?

The README documents Office activation for volume editions using the OSPP script, with cscript ospp.vbs /sethst and cscript ospp.vbs /act from the Office installation directory. It notes that the directory should contain OSPP.VBS, which is present in volume builds.

### Is KMS activation legal?

The README does not address licensing or legality. It supplies Microsoft's KMS client setup keys, which install the generic volume key for an edition, but it does not discuss what entitlements a user needs before pointing a machine at a KMS host.

## Sources

- [Issues](https://github.com/netnr/kms/issues)
- [License: MIT](https://github.com/netnr/kms/blob/main/LICENSE)
- [netnr/kms on GitHub](https://github.com/netnr/kms)
- [Project website](https://kms.netnr.eu.org)
- [README](https://github.com/netnr/kms/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/netnr-kms