迁移至Windows Server 2019后Data Protection密钥未持久化问题

• Windows Server 2012及更早版本的IIS存在默认逻辑兼容：即使应用池配置中Load User Profile显示为未勾选状态，运行.NET相关应用时底层仍会隐式加载应用池标识对应的用户配置文件，ASP.NET Core Data Protection 可以正常访问用户级注册表（HKCU）、用户目录下的默认持久化路径完成密钥存储，不会触发报错。
• 从Windows Server 2016开始（含Windows Server 2019），微软修正了这一隐式兼容逻辑，严格按照应用池的显式配置执行：未手动将Load User Profile设为True时，工作进程启动不会加载对应用户配置文件，Data Protection既无法访问HKCU注册表完成密钥加密，也无权限写入本地持久化路径，只能降级使用内存临时密钥存储，就会触发对应的三类报错。

这个配置是IIS的标准功能项，不属于非常规修改，绝大多数场景下无严重负面影响：

• 开启后仅会在应用池首次启动时加载对应用户的配置文件，带来毫秒级启动延迟，单池额外占用几十MB级别的内存，在现代服务器配置下完全可以忽略，不影响服务正常运行。
• 开启后Data Protection会自动遵循默认安全逻辑：将密钥持久化存储在用户配置文件的专属目录，通过Windows系统自带的DPAPI完成密钥加密，不需要额外修改业务代码配置。

仅在极端场景下需要注意潜在问题：

• 如果应用池使用自定义的低权限服务账号运行，首次开启配置前需要确保该账号在本地有完整的用户配置文件（至少完成过一次本地登录、或通过命令预创建配置文件），否则会出现配置文件加载失败的问题。
• 如果单台服务器部署了上百个使用独立账号运行的应用池，累计加载的用户配置文件会占用一定量的内存、系统句柄资源，这类场景更推荐直接为Data Protection配置集中化的共享密钥存储，降低单节点资源开销。

内容的提问来源于stack exchange，提问作者Michel van Engelen