请求新增最新版系统Win11 LTSC2024 Win server 2025等系统以及Office LTSC等新版本的密钥

[Nexchard]

系统KMS：https://learn.microsoft.com/en-us/windows-server/get-started/kms-client-activation-keys?tabs=server2025%2Cwindows1110ltsc%2Cversion1803%2Cwindows81
OfficeKMS：laomms/PidKeyTool#39
Office密钥信息来源是另一个项目的issue,可以参考

[ikxin]

感谢反馈，目前正在构思下一个版本的计划，该建议已纳入计划中，请期待

[Nexchard]

感谢回复，此外是否增加安装Office的功能，利用微软的Office部署工具来实现，在友站看到的这项功能希望能引入。还有kms检测功能也希望可以修复。此外监控功能是否有其他实现方式，UptimeRobot不太适合在内网机器上使用。

[ikxin]

该友站一直是我学习的对象，另外安装 Office 的功能我打算放到另一个项目里面去，因为该项目打算作为一个纯粹的 KMS 辅助工具，KMS 检测功能稍后修复。

UptimeRobot 去监控 KMS 确实不合理，它只能检测 1688 端口是否在线，检测不到 KMS 是否在线，所以还在考虑其他监控方式。您说的在内网环境使用，可以详细描述一下吗，想了解一下这个业务场景。

[Nexchard]

场景其实也比较简单，内网用户下载脚本自助激活，KMS检测以及监控一般只有桌面运维的人员会看。目前kms监控是放在夜莺上面的，但是考虑到kms激活服务器本身监控需求简单加上桌面运维人员不会被其他监控消息打扰，将脚本下载检测监控集成在一起是比较合适方便的。附一张检测工具的截图

[ikxin]

如果需要激活的设备处于内网环境，需要用 kms 去激活系统，假设它无法访问外网，那么它只能使用本地或者内网所搭建的 kms 服务器，本项目所依赖的公网 kms 服务器则起不到作用。

目前我的想法是 kms 监控主要用来检测互联网中公开的 kms 服务器可用性如何，不过我倒是觉得可以把整个项目打包成 docker 镜像，以此来部署在内网环境中，同时拥有激活服务器、检测、监控、生成脚本四个模块。

[Nexchard]

kms监控自身应该无需关心kms服务器是公网还是内网，只需监控与服务器二者网络可达即可。目前我们内网的kms服务器，监控以及脚本生成都是分开独立的，而且kms检测是通过第三方工具，如果能集成在一起那就太好了。

[ikxin]

明白你的意思，要实现这个场景还是要私有化部署，整个项目部署到内网环境中去，不然存在于公网的 kms 监控从原理上应该是访问不到内网中的 kms 服务器，自然就监控不到了