安装 Server 2008 R2 SP1 时出错

安装 Server 2008 R2 SP1 时出错

我最近通过以下方式将我的 Server 2008 R2 Standard VM 升级到了 Server 2008 R2 Enterprise:

Dism /online /Set-Edition:ServerEnterprise /ProductKey:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

如此处所述:从 Windows Server Standard 就地升级到 Enterprise 或 Datacenter

一切进展顺利,但现在当我想要安装 SP1 时,我在 CBS.log 中收到以下错误:

2011-02-23 11:58:30, Info                  CBS    SPI: Starting SPInstall version 6.1.7601.17514

2011-02-23 11:58:31, Error                 CBS    SPI: (CheckForPendingFlag:90)Failed to open component hive at C:\Windows\System32\config\components er=0x0

2011-02-23 11:58:31, Error                 CBS    SPI: (CSystem::Initialize:317)Failed to GetProductInfo GLE=0x0

2011-02-23 11:58:31, Error                 CBS    SPI: (wmain:939)Failed to initialize system hr=0x80004005

2011-02-23 11:58:32, Info                  CBS    SPI: SPInstall terminating, return code 0x80004005

2011-02-23 11:58:32, Error                 CBS    SPI: (SPIRegQueryStringValue:700)Failed to query registry value: MiscString2 er=0x2

2011-02-23 11:58:32, Error                 CBS    SPI: (CSystem::GetMachineName:395)Failed to query machine name from RAC hr=0x80070002

2011-02-23 11:58:32, Error                 CBS    SPI: (CCrimsonLogger::Unregister:50)Crimson logger not registered hr=0x8000ffff

不幸的是,似乎没有任何资源介绍如何修复组件配置单元(它存在并且具有与成功启动安装的计算机相同的权限)。独立安装程序和 Windows 更新安装程序都会发生这种情况。

更新 切换回 KMS 密钥允许我安装 SP1。RDP 是否能正常工作还有待观察(这是此过程中出现的另一个问题)

答案1

我昨晚想出了一个解决方法。我发现这与我原来的 MAK 密钥及其重复使用有关。

原始虚拟机是具有 MSDN MAK 密钥(适用于标准版和企业版)的 Server 2008 R2 虚拟机

我使用“489J6-VHDMP-X63PK-3K798-CPX3Y”企业版 KMS 密钥进行了 DISM 升级(来自这篇文章)http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/0c68ffd9-ed83-4437-aa79-2f7decc75c0f

DISM 升级后,我切换回了原来的 MAK 密钥(并成功激活)。这种情况的第二个表现是远程桌面在任何使用 MAK 密钥的机器上都不再起作用。然后我做了一些额外的研究,发现其他人在使用 DISM 升级时也遇到了同样的问题(http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/6debc586-0977-4731-b418-ca1edb34fe8b)。我凭直觉切换回 KMS 密钥,然后能够安装 SP1(并重新启用远程桌面)。然后,我尝试使用另一个 MSDN 帐户的 Std/Enterprise 许可证,成功激活,并保持远程桌面启用。我还测试了切换回原始 MAK 密钥,这也有效。然后,我将其余 VM 切换到新的 MSDN 密钥,这也成功了,无需重新引入 KMS 密钥。

我能说的是,在标准 -> 企业 DISM 升级路径的每一端使用相同的密钥一定有一些独特之处。

相关内容