简介Py-KMS是一款基于Python的开源KMS服务实现用于在内网或离线下模拟微软KMS激活机制批量激活Windows与Office产品适合需统一管理授权的中小企业、IT运维人员及开发测试者。此版本源自ThunderEX维护的持续更新分支兼顾跨平台与稳定性命令行操作方式也更利于脚本化自动化管理。压缩包内共32个文件以27个Python源码文件为主涵盖KMS请求处理、RPC通信、UUID生成及加密模块另附KmsDataBase.xml密钥数据库、README说明文档与Dockerfile容器配置方便查阅部署。资源整体仅98KB轻量易用已有481人学习下载。通过这份最新版代码读者可直接搭建本地KMS激活环境深入理解KMS协议与激活流程并借助Docker实现容器化部署适合快速内网应用与二次开发学习。 做了这么多年系统运维和公司IT架构每年最头疼的事情之一就是批量环境的激活授权问题。特别是手上有几十台服务器、几百个终端要统一部署的时候一个个对着电话激活或者桌面操作根本不现实。这时候KMS这套批量激活机制就派上用场了。py-kms作为一个用Python实现的开源KMS服务端是我这几年测试环境里用得最多的工具之一而它更新到新版本之后我觉得有挺多细节值得拿出来单独聊聊。这篇文章不是教你怎么钻空子而是从技术实现和合规测试的角度讲清楚KMS是什么、py-kms新版改了什么、怎么快速搭一套服务端用于学习和验证。如果你是企业IT管理员、SCCM/终端管理工程师或者单纯是对Windows激活协议好奇的开发者这篇内容应该正好对得上你的胃口。1. KMS激活机制与py-kms的定位1.1 KMS协议到底在做什么KMS全称是Key Management Service翻译过来就是密钥管理服务。它是微软针对批量授权场景推出的一套激活机制。和普通零售密钥不同KMS走的是“客户端-服务器”模式企业内网里部署一台KMS服务器局域网里的Windows和Office客户端定期去这台服务器上完成激活和续期。KMS激活里面有几个关键点理解它们你才能明白py-kms为什么能如此轻量地替代微软的KMS角色。首先是DNS发现机制域内的客户端通过查询特定的SRV记录定位到KMS服务器比如_VLMCS_._TCP.contoso.com。其次是最低计数要求KMS客户端在请求激活时服务器会检查当前环境中是否有足够多的客户端已经联系过它这个阈值通常是25台不满足阈值的话客户端拿不到激活许可。最后是续期机制KMS激活默认有效期是180天期间客户端会每7天尝试续期一次保证授权状态不掉。py-kms就是对这一整套协议的服务端实现。它用Python复刻了微软KMS服务器的核心逻辑包括对VLKV2密钥的处理、CMCF数据的管理、客户端请求的响应等。在网络里把它跑起来之后从功能上看它和一台真正的KMS服务器几乎没有区别。1.2 为什么开源社区选择py-kms微软官方想要部署KMS你需要专门的KMS Host Key并且要经过完整的授权申请流程。这个流程本身没有错但对于实验室模拟、协议研究、以及做集成测试的场景来说太重了。py-kms的价值在于它把整个KMS服务端逻辑压缩成了一个几百KB的Python程序跑在任意一台Linux机器或者容器里就能工作。我这里说得直白一点如果你有正当的企业软件资产授权在测试环境里用py-kms来模拟KMS服务器、验证客户端的激活行为和批量部署脚本是完全没有问题的它甚至能帮你省掉申请临时KMS主机的等待时间。这也是我推荐大家从技术角度研究它的原因。新版本的py-kms还有一个让我很满意的点就是它对现代激活环境的兼容性变好了。以前老版本偶尔碰到Office新版客户端会报错新版本在协议响应细节上做了不少修正跑起来明显更稳。2. 新版本带来的关键变化2.1 支持更多的产品版本微软这些年一直在更新Windows Server和Office的发布节奏对应的KMS激活协议也一直在小步迭代。py-kms如果停留在旧版本很容易出现客户端请求能收到、但激活码校验失败的情况。最新版的py-kms把新出的Windows Server 2025、Windows 11 24H2等版本的相关CID和密钥处理逻辑都补上了Office LTSC 2024的支持也比之前完善很多。我自己实测下来把新版本容器拉起来之后用Windows Server 2025的测试客户端去请求激活日志里能正常看到“Activation successful”这样的响应整个过程没有任何版本不匹配的报错。这里也提醒一下如果你还在用两三年之前的老版本py-kms遇到新版本Windows激活不了是正常的不是配置错了纯粹是产品版本支持列表没跟上。升级到最新版基本能解决这类问题。2.2 数据库文件与日志系统的改进KMS服务端在运行过程中需要记录客户端的请求信息比如Client Machine IDCMID、请求时间、续期状态等。旧版py-kms是用文本数据库文件来做的虽然能用但久了之后文件会越来越大查询效率也会下降。新版在数据库管理上做了调整对数据文件的读写逻辑进行了优化同时增加了更详细的日志输出选项。你可以通过命令行参数自由控制日志打印的级别从完全静默到输出每条客户端请求的详细内容都可以配置。这在实际排查问题的时候特别有用比如你可以先开启完整日志观察客户端第一次请求KMS时到底是在协议协商阶段出错还是在密钥校验阶段失败。2.3 运行环境要求新版py-kms对运行环境的要求有一个明显变化就是不再老惦记着Python 2了全套代码基于Python 3。官方文档里建议使用Python 3.7以上的版本我自己一般直接上Python 3.10或者3.11跑起来没遇到兼容性问题。如果你完全不想在自己的机器上装Python环境那也没关系项目官方提供了Docker镜像这已经是我在服务器上部署py-kms的首选方式。容器化的好处就是干净不污染宿主机环境升级也简单拉一个新镜像重新启动就行。3. 基于Docker的部署实践3.1 准备目录与docker-compose配置我建议用docker-compose方式部署py-kms这样参数修改和容器重建都方便。在目标服务器上先建一个工作目录比如/data/py-kms然后创建一个docker-compose.yml文件。配置里最核心的几个部分是这样的version: 3.8 services: pykms: image: pykmsorg/py-kms:latest container_name: pykms restart: unless-stopped ports: - 1688:1688 command: [-p, 1688, -s, HWID-SERVER-ID-EXAMPLE, -l, 0, -t, verbose, -e, UTC] volumes: - ./data:/data端口1688是KMS协议的默认通信端口客户端默认就是往这个端口发请求的所以这里必须映射出来。如果你服务器上已经占用了1688记着换一个宿主端口然后客户端那边对应的DNS记录也要改。volumes: - ./data:/data数据目录挂载出来是为了持久化数据库文件。KMS客户端每7天会来续期一次如果容器重启后数据库清零会导致客户端重新走完整激活流程虽然没有实质影响但能让日志干净一点我还是会挂载数据目录。3.2 启动与验证服务端配置好compose文件后在目录下执行docker compose up -d服务启动后先看日志确认状态docker logs -f pykms正常情况下你会看到类似这样的日志输出表示py-kms已经成功绑定到1688端口并且开始等待客户端的连接请求。说明服务端的骨架搭好了。接着在客户端机器上我们通常还需要把DNS SRV记录加到域里让客户端能自动找到这台KMS服务器。这个步骤需要DNS管理员权限配置内容是在_VLMCS._TCP区域下新建一个SRV记录指向你的KMS服务器主机名和端口。如果没法改DNS也可以用注册表方式手动指定KMS服务器地址HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform把KeyManagementServiceName改成你的服务器IP或主机名把KeyManagementServicePort改成1688。这是Windows激活排障里最常用的手段之一我遇到客户端找不到KMS服务器的案例一半以上都是SRV记录没生效直接用注册表指定IP最省事。3.3 确认激活结果在Windows客户端上完成上述配置后以管理员身份打开命令提示符执行最直观的验证命令slmgr /ato这个命令是手动触发激活的意思正常情况下会弹出弹窗提示“激活成功”。如果想看更详细的状态信息比如当前KMS服务器地址、剩余的续期次数、下次续期时间等可以用slmgr /dlv这个命令输出的信息量很大建议激活前先在客户端上跑一遍确认KMS服务器地址已经正确指向你的py-kms容器再执行/ato。我自己在排障时基本就是靠这两个命令定位问题简单快速不需要看任何图形界面。4. 配置参数解析与常见问题排查4.1 常用命令行参数说明py-kms的命令行参数不算多但有一些会直接影响激活行为下面是我实际使用中比较关注的几个参数作用我的推荐值备注-p监听端口1688防火墙和DNS记录必须一致-sKMS服务器IDHWID随机生成即可客户端会用它做标识建议固定-l日志级别0-40为静默4为全量调试输出-t日志时间戳格式verbose排障时能确认请求时间-e时区设置UTC避免日志和本地时间对不上-cCMID数据库文件路径/data/clients.db挂载持久化卷时有用-d数据文件路径/data/data.json保存KMS数据状态特别注意-s这个参数它指定的HWID会出现在客户端的slmgr /dlv输出里。如果你有多套环境最好为每套环境分配不同的ID方便从客户端侧确认它到底连的是哪台KMS服务器。我之前就因为两套环境用了同一个ID导致排障时搞不清楚客户端到底激活在哪台服务器上白折腾了半天。4.2 客户端连着KMS但激活失败这是我遇到过最多的一个问题现象是客户端能Ping通KMS服务器防火墙也放行了1688但执行slmgr /ato就是激活失败报错代码通常会在弹窗里直接显示。首先要确认的第一件事情是客户端安装的版本对应的KMS客户端密钥是否已经安装。Windows企业版、教育版默认是KMS客户端而专业版默认不是需要手动安装KMS客户端密钥。在管理员命令行里执行slmgr /ipk 对应的KMS客户端密钥然后再执行slmgr /ato问题大概率就解决了。这个坑一半以上的人都会踩因为很多人根本没意识到专业版默认不具备KMS激活资格。还有一种情况是时间不准造成的。KMS激活对客户端与服务器之间的时间偏差极其敏感默认偏差超过一定范围激活请求会直接被拒绝。容器默认使用UTC时区如果你宿主机的时区是东八区但没设置好客户端和服务器之间会出现整8小时的偏差。这时候客户端报错的内容往往是时间戳相关的问题。把容器时区设置成和客户端一致的或者统一改成UTC问题就能解决。4.3 防火墙和容器网络问题Docker部署下如果映射端口改了比如宿主用了11688但客户端配置的端口还是1688那客户端请求会直接被拒绝。这时候从客户端侧用slmgr /skms host:port重新指定服务器和端口问题就能解决。另一个容易被忽略的地方是服务器防火墙。很多云服务器默认安全组只放行80和4431688通常不在白名单里部署完py-kms后记得在安全组里加一条入站规则允许TCP 1688端口。不然即使容器端口映射是对的外部请求也根本到不了容器。5. 从运维角度的几个实际体会最近一次帮一个测试团队搭环境他们要做Windows Server 2025的批量部署演练需要在测试网里临时起一套激活服务。申请正式的KMS Host Key流程比较长我就直接拉了一个py-kms最新版容器配合DNS SRV记录做了全套的激活验证。整个环境从拉镜像到客户端批量激活成功加起来不到半天时间效率提升非常明显。这套东西虽然用起来顺手但必须强调一点py-kms只能用在你确实拥有微软批量许可合规授权的测试和验证环境中。它不是一个可以绕过商业授权的合法工具。从技术学习角度它可以帮你深入理解KMS协议交互的每一个环节但从实际部署角度如果你的组织有正式授权诉求请走微软正规授权渠道。至于我自己现阶段已经习惯把py-kms的新版镜像放到内部测试专用的容器仓库里每次发布新版本都会拉下来在隔离网络里跑一轮基础验证再决定要不要让测试团队使用。最后再分享一个小技巧如果你要多台KMS服务端做高可用实验记得把数据目录用共享存储挂载到不同节点上这样客户端不管连到哪台服务器看到的CMID记录都是完整的不会出现一边能激活一边被拒的情况。本文还有配套的精品资源点击获取