1. 项目概述一次真实的 IIS 站点迁移不是备份还原而是跨服务器“搬家”我做过不下二十次 Windows Server 上的 IIS 站点迁移从 Server 2008 R2 到 Server 2022从物理机到虚拟机再到云主机。很多人一提“IIS 迁移”第一反应是导出配置、复制文件、再导入——这其实是IIS 备份与还原只适用于同版本、同架构、同权限模型的环境复刻。但真实业务场景里90% 的迁移都不是“复制粘贴”旧服务器跑着 .NET Framework 4.6.2新服务器要上 .NET 8旧站用 Classic 模式应用程序池新环境强制要求 Integrated旧服务器用 LocalSystem 权限跑服务新安全策略要求最小权限原则必须切到 ApplicationPoolIdentity甚至数据库连接字符串里的 IP 地址、证书路径、物理路径盘符都得重配。这些细节AppCmd 命令导出的 config.xml 里根本不会告诉你。这次要迁的是一个典型的政企内部系统ASP.NET WebForms SQL Server 2016 自签名 HTTPS 证书 自定义 HTTP 模块。旧环境是 Windows Server 2012 R2 IIS 8.5新环境是 Windows Server 2019 IIS 10。关键词里反复出现的 “iis应用程序池权限设置失败”、“未知错误(0x80005000)”、“执行此操作时出错,文件名:c:\windows\system32\inetsrv\config\administr” 都不是偶然——它们是权限、UAC、配置锁、AD 组策略四重叠加下的典型症状。而 “iis 中没有 .net8” 这个热词恰恰暴露了很多人忽略的根本前提.NET 运行时不是 IIS 的一部分它是独立安装的前置依赖。你不可能靠 AppCmd 把 .NET 8 “迁”过去它必须在目标服务器上手动部署、注册、验证。我把整个过程拆成四个硬核阶段环境对齐 → 配置解耦 → 文件迁移 → 权限与服务缝合。这不是脚本一键执行就能搞定的事而是一场需要逐层剥开 Windows 内核权限模型、IIS 配置体系、.NET 托管管道的实操手术。适合正在面临真实迁移任务的运维工程师、开发负责人或者被老板催着“三天内把老系统搬上新服务器”的技术骨干。如果你只是想学个备份命令这篇内容可能太重但如果你正对着 Event Viewer 里满屏的 0x80005000 错误发呆那接下来每一行都是我踩坑后亲手写的解药。2. 核心思路拆解为什么不能直接用 appcmd add apppool /copy2.1 AppCmd 的本质配置快照而非迁移蓝图AppCmd.exe 是 IIS 7 的命令行管理工具它的add apppool、add site命令看似能“新建”但背后调用的是同一个 COM 接口——Microsoft.Web.Administration。当你执行appcmd add apppool /name:MyAppPool /managedRuntimeVersion:v4.0它实际做的是向applicationHost.config文件写入一段 XML并触发 IIS Manager 的配置验证逻辑。而appcmd list apppool /config导出的只是当前生效的配置快照。问题在于这个快照不包含任何上下文依赖信息。举个最痛的案例旧服务器上应用程序池“MyAppPool”启用了“标识”为“LocalSystem”这是为了兼容一个老旧的 COM 组件。但新服务器启用了 UAC用户账户控制且开启了“管理员批准模式”LocalSystem 账户在 IIS 配置中被显式禁止这是 Windows Server 2016 的默认安全策略。此时你把旧配置导出的 XML 直接appcmd add apppool /in导入会立刻报错未知错误 (0x80005000)。这个错误代码在 MSDN 文档里查不到具体含义但它在 IIS 日志里对应的是CONFIG_E_INVALID_PATH或HRESULT_FROM_WIN32(ERROR_ACCESS_DENIED)。根源不是路径错而是 IIS 配置系统在解析 XML 时发现processModel identityTypeLocalSystem /这一行违反了底层安全策略直接拒绝加载。AppCmd 不会告诉你“因为 UAC 开启LocalSystem 被禁用”它只会甩给你一个晦涩的十六进制码。所以真正的迁移思路必须是逆向工程先用appcmd list apppool /config和appcmd list site /config把旧环境所有配置拉出来然后人工逐行比对新旧服务器的applicationHost.config结构差异。重点看三个 sectionsystem.applicationHost应用池、站点定义、system.webServer模块、处理程序、重写规则、system.web.NET 特定配置。你会发现Server 2012 R2 的applicationHost.config里section nameapplicationPools overrideModeDefaultAllow /而 Server 2019 默认是overrideModeDefaultDeny。这意味着旧配置里允许子站点覆盖应用池设置的location pathMySite块在新环境会被直接忽略——除非你手动把overrideModeDefault改回Allow或者把所有覆盖配置提到全局层级。这就是为什么很多迁移后站点能启动但自定义 HTTP 模块不生效模块注册在location下新 IIS 拒绝加载。2.2 应用程序池权限模型的代际鸿沟热词里高频出现的 “iis应用程序池权限设置失败”核心矛盾在于ApplicationPoolIdentity 的演进。Windows Server 2008 R2 引入了 ApplicationPoolIdentity它是一个虚拟账户格式为IIS AppPool\MyAppPool。但早期版本尤其是 2008/2008 R2对它的 ACL访问控制列表支持不完善。很多老系统直接给IIS AppPool\MyAppPool赋予了Full Control权限到网站根目录这在新系统上是危险且无效的——因为 Server 2012 的 ApplicationPoolIdentity 实际映射为一个 SID安全标识符其 ACL 权限必须通过icacls命令精确授予而不是图形界面里选账户名。更致命的是.NET 运行时版本切换带来的托管管道模式变更。旧站用.NET Framework v4.0Classic模式意味着请求先过 IIS 原生管道再交由 ASP.NET ISAPI 处理新站用.NET 8Integrated模式请求全程由 IIS 的AspNetCoreModuleV2统一调度。这两者对应的web.config里system.web和system.webServer的配置项完全不兼容。比如Classic 模式下httpModules有效Integrated 模式下必须用modulesClassic 模式下compilation debugtrue可以全局开启调试Integrated 模式下必须配合aspNetCore节点的stdoutLogEnabled。AppCmd 导出的配置不会自动转换这些它只会原样复制httpModules结果就是新 IIS 启动时报错“无法识别的配置节 httpModules”。因此迁移不是复制配置而是重建配置契约明确新环境的 .NET 版本、托管管道模式、身份验证方式Windows Auth / Anonymous再反向推导出web.config和applicationHost.config的最小可行配置集。我习惯先在新服务器上用 IIS Manager 创建一个空站点选好 .NET 版本和应用池然后用appcmd list config Default Web Site /config导出干净模板再把旧站的业务逻辑配置如rewrite规则、自定义handlers逐条合并进去。这个过程慢但绝对可控。2.3 站点文件迁移物理路径、权限、符号链接的三重陷阱很多人以为“复制网站文件夹”就完了。错。IIS 站点的物理路径physicalPath在applicationHost.config里是硬编码的比如site nameMySite id2 application path/ virtualDirectory path/ physicalPathD:\WebSites\MyApp / /application /site。如果你把文件从D:\WebSites\MyApp复制到新服务器的E:\Websites\MyApp但没改physicalPathIIS 启动时会报错“HTTP 错误 500.19 - Internal Server Error”详细信息指向config error: Cannot read configuration file. 因为 IIS 在E:\Websites\MyApp下找不到web.config它就认为配置损坏。更隐蔽的是权限继承问题。旧服务器上D:\WebSites\MyApp的 ACL 可能是这样Administrators: Full Control,SYSTEM: Full Control,IIS AppPool\MyAppPool: Modify。但新服务器的磁盘是 NTFS 格式且启用了“替换子容器和对象的所有者”策略。当你用robocopy D:\WebSites\MyApp E:\Websites\MyApp /E /COPYALL /DCOPY:T复制时/COPYALL会复制所有 ACL但IIS AppPool\MyAppPool这个账户在新服务器上并不存在——它是个虚拟账户SID 完全不同。结果就是新应用池身份对E:\Websites\MyApp没有任何权限连读取web.config都失败Event Log 里全是Event ID 1000“应用程序池 MyAppPool 因发生下列错误而停止运行...”。还有一种情况是符号链接Symbolic Link。老系统为了节省空间可能用mklink /D D:\WebSites\SharedLibs \\NAS\Shared\Libs创建了指向网络共享的链接。但新服务器没加入域或防火墙阻止了 SMB 445 端口这个链接就失效。IIS 不会报“链接无效”它会静默地把请求路由到D:\WebSites\SharedLibs的本地空目录导致 DLL 加载失败错误日志里只有模糊的Could not load file or assembly。排查这种问题必须用dir /AL命令列出所有符号链接再用fsutil reparsepoint query D:\WebSites\SharedLibs查看其目标路径是否可达。所以文件迁移必须分三步走第一步用 robocopy 复制文件带/COPYALL第二步用icacls重置目标目录 ACL精确授予新应用池身份权限第三步用dir /AL和fsutil扫描并修复所有符号链接。跳过任何一步都会在启动时卡住。3. 核心细节解析与实操要点从 appcmd 到权限落地的完整链路3.1 AppCmd 配置导出与清洗去掉“有毒”的历史残留AppCmd 导出配置的命令是appcmd list apppool /config apppool.xml和appcmd list site /config site.xml。但直接拿这两个文件去新环境导入99% 会失败。原因有三XML 命名空间冲突、冗余属性、隐藏的依赖项。首先appcmd list apppool /config输出的 XML 默认带xmlnshttp://schemas.microsoft.com/.NetConfiguration/v2.0命名空间。而新 IIS 的applicationHost.config使用的是xmlnshttp://schemas.microsoft.com/IIS/ConfigSchema。如果强行导入IIS 配置系统会因命名空间不匹配而拒绝解析。解决方法是用 PowerShell 清洗 XML。执行以下脚本$xml Get-Content apppool.xml -Raw $xml $xml -replace xmlnshttp://schemas.microsoft.com/.NetConfiguration/v2.0, $xml $xml -replace configuration, configuration xmlnshttp://schemas.microsoft.com/IIS/ConfigSchema $xml | Set-Content apppool_clean.xml -Encoding UTF8其次旧配置里常有autoStarttrue、startModeOnDemand这类属性。在 Server 2012startMode已废弃IIS 会忽略它但某些老模块如 URL Rewrite 2.0会因读取到未知属性而崩溃。必须手动删除所有startMode、queueLength已由内核管理、idleTimeout建议用默认值等过时属性。最后也是最关键的检查processModel节点。旧配置里可能有processModel identityTypeSpecificUser userNameDOMAIN\svc_iis passwordxxx /。密码是明文 Base64 编码的但新 IIS 默认禁用明文密码存储enablePasswordSyncfalse。强行导入会导致应用池无法启动错误日志显示The specified password is invalid.。正确做法是把identityType改为ApplicationPoolIdentity然后在新服务器上用icacls单独授权。提示永远不要在配置文件里存明文密码。IIS 的最佳实践是使用ApplicationPoolIdentity或NetworkService并通过 ACL 授予最小权限。如果必须用域账户应启用 Windows 凭据管理器让 IIS 从凭据存储中安全读取。3.2 应用程序池权限设置icacls 是唯一可靠的工具热词里反复出现的 “请手动为其设置 localsystem 权限未知错误(0x80005000)”根源在于图形界面IIS Manager的权限设置是“假授权”。当你在 IIS Manager 里右键应用池 - 高级设置 - 标识选择LocalSystem它只是修改了applicationHost.config里的processModel identityTypeLocalSystem /。但 LocalSystem 对网站物理路径的 ACL 权限必须由icacls命令显式授予。图形界面不会帮你做这一步它假设你已经手动设置了。正确的权限授予流程如下以新应用池MyAppPool为例确认应用池已创建且处于 Stopped 状态appcmd list apppool MyAppPool appcmd stop apppool MyAppPool获取应用池的 SID安全标识符# PowerShell 获取 SID $sid (Get-WmiObject -Class Win32_Account -Filter NameMyAppPool AND DomainIIS APPPOOL).SID Write-Host AppPool SID: $sid输出类似S-1-3-10-XXXXXX。这是关键因为icacls必须用 SID而不是账户名IIS AppPool\MyAppPool后者在命令行里会被解析为无效路径。用 icacls 授予最小权限icacls E:\Websites\MyApp /grant:r %sid%:(OI)(CI)(RX) /T icacls E:\Websites\MyApp /grant:r %sid%:(M) /T解释(OI)表示“对象继承”(CI)表示“容器继承”(RX)表示“读取和执行”(M)表示“修改”。/T是递归。这里给了“读取执行”和“修改”两组权限足够 ASP.NET 应用运行读取 DLL、写入临时文件、生成编译缓存。绝不授予(F)完全控制这是安全红线。验证权限是否生效icacls E:\Websites\MyApp | findstr S-1-3-10输出应显示S-1-3-10-XXXXXX:(OI)(CI)(RX)和S-1-3-10-XXXXXX:(OI)(CI)(M)。如果没看到说明 SID 获取错误或命令执行失败。注意icacls命令必须以 Administrator 权限运行。普通用户即使属于 Administrators 组也会因 UAC 而失败。务必右键“以管理员身份运行”CMD 或 PowerShell。3.3 .NET 运行时与托管管道iis 中没有 .net8 的真相热词 “iis 中没有 .net8” 是个经典误解。IIS 本身不“包含”任何 .NET 版本它只是一个 Web 服务器负责接收 HTTP 请求并转发给对应的“托管模块”。.NET Framework 是 Windows 的一部分随系统安装而 .NET Core / .NET 5包括 .NET 8是独立运行时必须单独下载安装。迁移 .NET 8 站点必须在新服务器上完成三件事安装 .NET 8 Runtime非 SDK访问 https://dotnet.microsoft.com/download/dotnet/8.0下载Hosting Bundle不是 Runtime 单独包。Hosting Bundle 包含.NET 8 Runtime、.NET 8 ASP.NET Core ModuleANCM、以及 IIS 注册脚本。安装时勾选“Install the .NET 8.x Hosting Bundle”它会自动执行aspnetcore.dll的注册。验证 ANCM 是否注册成功打开C:\Windows\System32\inetsrv\config\applicationHost.config搜索globalModules节点确认存在add nameAspNetCoreModuleV2 image%windir%\System32\inetsrv\aspnetcore.dll /如果没有说明 Hosting Bundle 安装失败或未重启 IIS。执行net stop was /y net start w3svc重启 WASWindows Process Activation Service。配置 web.config 的 节点旧站如果是 .NET Frameworkweb.config里没有aspNetCore。新站必须添加且参数必须精确匹配system.webServer handlers add nameaspNetCore path* verb* modulesAspNetCoreModuleV2 resourceTypeUnspecified / /handlers aspNetCore processPathdotnet arguments.\MyApp.dll stdoutLogEnabledtrue stdoutLogFile.\logs\stdout hostingModelinprocess / /system.webServer关键点processPathdotnet表示使用全局 dotnet CLIhostingModelinprocess表示进程内托管性能更好stdoutLogEnabledtrue是调试必备日志会输出到.\logs\stdout。如果arguments里的 DLL 名称错IIS 会报错HTTP Error 500.30 - ASP.NET Core app failed to start。实操心得.NET 8 的inprocess模式要求 IIS 应用程序池的“.NET CLR 版本”设为“无托管代码”。很多人卡在这里以为要选.NET CLR Version v4.0。错inprocess模式绕过了 CLR直接由 ANCM 调用 .NET 运行时所以必须选“无托管代码”。这是 .NET Core 之后的重大变更。4. 实操过程与核心环节实现从零开始的迁移全流程记录4.1 环境对齐新旧服务器的“体检报告”迁移前必须对新旧服务器做一份完整的“体检报告”避免后续所有问题都归咎于“配置没导好”。我用一个 Excel 表格记录以下 12 项检查项旧服务器 (Win2012 R2)新服务器 (Win2019)是否一致备注OS 版本 Build6.3.960010.0.17763❌Win2012 R2 是 NT 6.3Win2019 是 NT 10.0内核差异大IIS 版本8.510.0❌IIS 10 新增了 HTTP/2、动态压缩等特性.NET Framework 版本4.6.24.8✅4.8 向后兼容 4.6.2无需重装.NET 8 Runtime无8.0.3❌必须安装 Hosting BundleWindows 功能IIS已启用已启用✅但子功能可能不同需逐项核对UAC 状态启用启用✅但默认策略不同影响 LocalSystem防火墙状态关闭启用❌新服务器防火墙默认阻止 80/443需放行磁盘格式NTFSNTFS✅NTFS ACL 是权限基础域成员状态域成员工作组❌影响 Kerberos 认证、域账户权限证书存储位置LocalMachine\MyLocalMachine\My✅但私钥权限需重新设置SQL Server 版本20162019❌连接字符串需更新实例名DNS 解析能力正常正常✅但新服务器可能缺少 hosts 条目这份表格的价值在于它把模糊的“环境不同”变成了可操作的 12 个检查点。比如“域成员状态”不一致意味着旧站用的 Windows AuthenticationKerberos在新环境会失败必须切换为 NTLM 或匿名认证“防火墙状态”不同意味着即使 IIS 启动成功外部也无法访问必须执行New-NetFirewallRule -DisplayName IIS HTTP -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow。4.2 配置解耦手把手拆解 applicationHost.config 的 5 个关键区块applicationHost.config是 IIS 的心脏它位于C:\Windows\System32\inetsrv\config\。迁移的核心就是把旧配置里与业务强相关的部分剥离出来适配新环境。我把它拆成 5 个区块区块 1system.applicationHost—— 应用池与站点骨架这是最易出错的部分。旧配置里可能有applicationPools add nameMyAppPool managedRuntimeVersionv4.0 managedPipelineModeClassic autoStarttrue / /applicationPools sites site nameMySite id2 application path/ applicationPoolMyAppPool virtualDirectory path/ physicalPathD:\WebSites\MyApp / /application bindings binding protocolhttp bindingInformation*:80: / binding protocolhttps bindingInformation*:443:myapp.internal / /bindings /site /sites迁移到新环境必须改managedRuntimeVersionv4.0→managedRuntimeVersionv8.0如果用 .NET 8managedPipelineModeClassic→managedPipelineModeIntegratedphysicalPathD:\WebSites\MyApp→physicalPathE:\Websites\MyAppbindingInformation*:443:myapp.internal→bindingInformation*:443:myapp.newdomain.local域名变了区块 2system.webServer—— 模块、处理程序、重写规则旧站可能有自定义 HTTP 模块modules add nameMyCustomModule typeMyNamespace.MyModule, MyAssembly preConditionintegratedMode / /modules如果preConditionintegratedMode说明它只在 Integrated 模式下加载。迁移到新环境没问题但如果preConditionclassicMode就必须删除或重写模块。区块 3system.web—— .NET Framework 特定配置这是 .NET 8 迁移的雷区。旧站的compilation targetFramework4.6.2 /在 .NET 8 站点里完全无效必须删除。保留的只有customErrors modeRemoteOnly /这类通用配置。区块 4location pathMySite—— 站点级覆盖配置很多老系统把 SSL 设置、IP 限制放在这里location pathMySite system.webServer security access sslFlagsSsl, SslNegotiateCert, SslRequireCert / ipSecurity allowUnlistedfalse add ipAddress10.0.1.0 subnetMask255.255.255.0 allowedtrue / /ipSecurity /security /system.webServer /location迁移到新环境sslFlags必须改为Ssl仅要求 HTTPS因为SslNegotiateCert和SslRequireCert需要客户端证书新环境可能没部署。ipSecurity的allowUnlistedfalse会默认拒绝所有 IP必须确保add项里的 IP 段正确。区块 5configSections—— 第三方模块注册URL Rewrite、ARRApplication Request Routing等模块的注册都在这里。旧配置里可能有sectionGroup namesystem.webServer section namerewrite overrideModeDefaultAllow / /sectionGroup新 IIS 10 默认overrideModeDefaultDeny所以必须把Allow改为Deny或者把 rewrite 规则从location移到全局system.webServer下。4.3 文件迁移robocopy 的 7 个必选参数详解robocopy是 Windows 下最可靠的文件复制工具但参数选错就会丢文件、坏权限、漏时间戳。我固定使用以下 7 个参数robocopy D:\WebSites\MyApp E:\Websites\MyApp /E /COPYALL /DCOPY:T /R:3 /W:5 /LOG:C:\temp\robocopy.log /NP/E复制所有子目录包括空目录。这是必须的因为 IIS 的App_Data、bin目录可能为空但结构必须存在。/COPYALL复制所有文件信息数据、属性、时间戳、ACL、所有者、审计项。这是权限迁移的基础缺一不可。/DCOPY:T复制目录的时间戳创建时间、最后修改时间。很多 ASP.NET 编译依赖文件时间戳时间错乱会导致Compiler Error Message: CS0016。/R:3失败重试 3 次。网络共享或大文件复制时瞬时错误很常见。/W:5每次重试间隔 5 秒。避免对源服务器造成过大压力。/LOG:...输出详细日志到文件。日志里会记录每个文件的复制状态、跳过的文件如被占用、ACL 复制失败项。/NP不显示进度百分比。避免 CMD 窗口刷屏便于事后查日志。执行完后必须检查日志末尾的 Summary------------------------------------------------------------------------------ Total Copied Skipped Mismatch FAILED Extras Dirs 123 123 0 0 0 0 Files 2156 2156 0 0 0 0 Bytes 1.234 g 1.234 g 0 0 0 0如果FAILED不为 0说明有文件复制失败必须根据日志定位原因通常是文件被 IIS 进程锁定。此时应先appcmd stop site MySite停掉旧站点再重试。4.4 权限与服务缝合从启动失败到 200 OK 的 5 分钟诊断法迁移完成后启动站点浏览器打开http://localhost如果看到HTTP Error 500.19别慌。这是 IIS 最友好的错误因为它会告诉你具体哪一行配置错了。按以下 5 分钟流程诊断第 1 分钟看错误详情页500.19 错误页会显示错误代码如0x80070005拒绝访问、0x80070021配置节被锁定、0x80070003路径不存在配置文件路径如\\?\E:\Websites\MyApp\web.config行号与列号如Line 15, Column 22第 2 分钟查 Event Viewer打开“事件查看器” - “Windows 日志” - “系统”筛选来源为IIS-IIS Manager或IIS-APPHOSTSVC。最常见的错误是Event ID 5011应用程序池MyAppPool因发生下列错误而停止运行The data is invalid.—— 这是applicationHost.config里某个属性值非法如idleTimeout设为负数。Event ID 1000Application pool MyAppPool is being automatically disabled due to a series of failures...—— 应用池连续 3 次启动失败被 IIS 自动禁用。必须手动appcmd start apppool MyAppPool并查原因。第 3 分钟验证物理路径与权限执行dir E:\Websites\MyApp\web.config icacls E:\Websites\MyApp | findstr S-1-3-10如果dir报“系统找不到指定的路径”说明physicalPath配置错如果icacls没输出 SID 权限说明 ACL 没授好。第 4 分钟检查 .NET 运行时与 ANCM执行dotnet --list-runtimes dir C:\Windows\System32\inetsrv\aspnetcore.dll如果dotnet --list-runtimes没显示Microsoft.AspNetCore.App 8.0.3说明 Hosting Bundle 没装好如果aspnetcore.dll不存在说明注册失败。第 5 分钟启用 stdout 日志编辑web.config确保aspNetCore stdoutLogEnabledtrue stdoutLogFile.\logs\stdout /。然后访问站点等待 10 秒检查E:\Websites\MyApp\logs\stdout_*.log。日志里会有清晰的启动错误如Could not find file E:\Websites\MyApp\MyApp.dllDLL 名字错或Failed to load dll C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\hostpolicy.dll.NET 运行时损坏。5. 常见问题与排查技巧实录那些年我们踩过的 0x80005000 坑5.1 0x80005000 错误权限、UAC、配置锁的三重奏这个错误代码是 IIS 配置系统的“万能错误”它不指代单一问题而是表示“配置验证失败”。根据我的实战记录它 80% 以上源于以下三种组合错误现象根本原因排查命令解决方案appcmd add apppool /in失败UAC 开启LocalSystem 被策略禁止gpresult /h report.html查看“计算机配置\管理模板\Windows 组件\Internet Explorer\安全性功能\增强的安全配置”改用ApplicationPoolIdentity或在组策略里启用“允许 LocalSystem 作为应用池标识”appcmd set config MySite /section:system.webServer/...失败applicationHost.config的section name... overrideModeDefaultDeny /锁定了该节appcmd list config /section:system.webServer/handlers执行appcmd unlock config /section:system.webServer/handlers解锁或把配置移到全局层级appcmd start apppool MyAppPool失败应用池身份对C:\Windows\Temp没有写入权限icacls C:\Windows\Tempfindstr IIS AppPool实操心得遇到 0x80005000第一反应不是查文档而是打开C:\Windows\System32\inetsrv\config\applicationHost.config找到报错的section看它的overrideModeDefault属性。90% 的时间这就是病灶。5.2 HTTPS 证书迁移从 PFX 到 P12 的无声陷阱很多迁移失败