机翻搬运，原作者Paul Thurrott

原文：http://www.winsupersite.com/reviews/winserver2k3_gold1.asp

第 1 部分：早期

在最近与 Janet Robbins 和 Mike Otey 一起访问微软雷德蒙德园区期间，我们有机会坐下来与 Windows 历史上最著名的两位人物 Mark Lucovsky 和 David Thompson 交谈。对于那些不熟悉早期 Windows NT（当时简称为 NT）的人来说，Lucovsky 和 Thompson 在这个重要软件项目的开发中都发挥了关键作用。Microsoft 的杰出工程师兼 Windows Server 架构师 Mark Lucovsky 与 NT 架构师 Dave Cutler 一起加入公司的最初一批前数字设备公司 (DEC) 员工。主要以他理解 NT 中数以千计的组件如何协同工作的非凡能力而闻名，Lucovsky 因其技术敏锐度和早期努力将 NT 从基于 OS/2 的系统转变为运行 32 位 Windows 应用程序的系统而广受赞誉。Windows Server 产品组副总裁 David Thompson 于 1990 年加入 Microsoft，并在当年晚些时候加入 NT 团队之前领导了公司 LAN Manager 项目的高级开发组。在那里，汤普森指导了 NT 网络子系统的开发，确保该产品不仅适用于 Microsoft 的产品，还适用于外部世界。

这就是一切的开始。

NT团队抵达微软

“我们在 1988 年 11 月作为一个团队聚集在一起，”Lucovsky 告诉我们，并指出 NT 团队的首要任务是获得开发机器，这些机器是 [当时] 顶级的 25 MHz 386 PC 和 110 MB硬盘驱动器和 13 MB RAM。“它们贵得离谱，”他笑着说。开发的前两周相当平静，NT 团队使用 Microsoft Word 创建原始设计文档。

“最初，我们将 NT 定位到 Intel i860（代号为‘N-Ten）’，这是一款严重落后于计划的 RISC 处理器。因为我们内部没有任何 i860 机器可以测试，我们使用了一个i860 模拟器。这就是我们称它为 NT 的原因，因为它适用于‘N-10’。”

-Mark Lucovsky
杰出工程师
Windows Server 架构师

最后，是时候开始编写一些代码了。“我们在 1988 年 12 月中旬左右检查了第一个代码片段，”Lucovsky 说，“到 1 月，我们在英特尔 i860（代号为“N-Ten”）的模拟器上有了一个非常基本的系统启动。” 事实上，这就是 NT 真正得名的地方，Lucovsky 透露，并补充说，“新技术”这个绰号是在最初的 NT 团队成员罕见的产品营销突飞猛进之后添加的。“最初，我们将 NT 定位到 Intel i860，这是一款 RISC 处理器，它远远落后于计划。因为我们没有任何内部 i860 机器可以测试，所以我们使用了 i860 模拟器。这就是我们称之为 NT 的原因，因为它适用于‘N-10’。”

到 1989 年 4 月，新命名的 NT 团队已经在模拟器上启动并运行了一个基本的内核模式系统。“我们从 DEC 的五个人和一个来自‘外部’（即微软）的人开始，一个叫Steve Wood 的人，”Lucovsky 说. “整个夏天，我们都在一小群人中呆了很长时间。我们想，‘构建操作系统有多难？’ 并计划用 18 个月来构建 NT。但我们忘记了一些重要的东西——用户模式、网络等等。”

到 1989 年底，NT 集团开始壮大。他们增加了一个正式的网络团队，并将安全团队扩大到一个人之外，顺便说一下，这个人以前也曾被文件系统和本地化开发所累。“我们在第一年增加到 50 人左右，”Lucovsky 说。“一年之内，我们终于有了第一个功能性的 i860 原型，所以我们可以使用它们而不是模拟器。我们开始研究上下文切换时间，以了解它的性能如何。几乎立即变得显而易见i860 永远不会成功。所以我们开始研究 MIPS 架构，这是另一种 RISC 设计。

1989 年 12 月，NT 团队决定放弃 i860，转而瞄准 MIPS R3000 芯片。“在两三个月内，我们就可以在 Big Endian 模式下在真实硬件上启动 NT，”Lucovsky 告诉我们，“我们的架构确实得到了回报。我们将 NT 设计为可移植的，我们证明它几乎可以立即运行转移到 MIPS。我们做出改变没有太多的痛苦。”

这时候，NT 团队开始迅速扩张，现在大部分成员都来自微软的行列。一旦创建了一种新的图形制作风格，图形团队就得到了极大的扩展。他们还启动了一个 NT 端口到英特尔 i386，这是当时主流的 PC 处理器，但 Lucovsky 解释了为什么他们最初没有针对 i386 对团队很重要。“我们暂时远离 386，以免陷入架构中，”他说。“我们不想使用不可移植性假设。” 他说，如果他们从第一天起就瞄准英特尔的批量芯片，他们最初会有一个性能更高的系统，但从长远来看，它会伤害 NT。

NT 成为 Windows NT

“到 1990 年春天，我们让 MIPS 版本步履蹒跚，我们认真地开始了 386 版本，”Lucovsky 说。“这是又一次巨大的增长突飞猛进。” 那年五月，微软发布了 Windows 3.0，突然间，全世界都注意到了它。Windows 取得了巨大的成功，并且是基于 PC 的图形计算的明显未来。“我们开始研究 Windows 3.0 并说，'如果我们开发 32 位版本的 Windows 而不是 OS/2 会怎么样？'”Lucovsky 指出，随口抛出了下一个十年计算的关键问题。“四个人——Steve Wood、Scott Ludwig、图形引擎组的一个人和我自己——研究了 16 位 Windows API 并想出了将它们扩展到 32 位需要什么。我们花了一个月的时间半准备 API 集，

新 API（最终命名为 Win32）的主要特征是，虽然它是一个新 API，但它的外观和行为与 16 位 Windows API 一样，让开发人员可以轻松迁移到新系统并移植他们的应用程序。“我们使将 16 位应用程序非常容易地转移到 NT 成为可能，”Lucovsky 说，“这些应用程序可以利用 NT 的独特功能，例如更大的地址空间。我们还添加了新的 API，这些 API 不是在 16 位版本中。我们添加了主要的新功能来完善 API，使其成为一个完整的操作系统 API，但我们使用的是新兴的 Windows 程序员群体所熟悉的风格。”

微软内部的反应是立竿见影的。“他们喜欢它，”他说，“当他们看到它是多么容易时。它基本上是类固醇的 Windows，而不是 OS/2，后者使用完全不同的编程模型。” 然而，使 NT 成为 32 位 Windows 版本而不是 OS/2 产品会引入新问题，但并非所有问题都是技术问题。Microsoft 必须获得 ISV 和 OEM 的批准，当然还要提醒 IBM 这一变化。“我们与 IBM 进行了 ISV 预览，并制作了大约 20 张幻灯片，然后我们说，‘看，这就是我们要做的。’ 起初，他们认为 Win32 是 OS/2 的奇特名称。然后你可以从他们的脸上看到：‘等一下，这不是 OS/2。’”

放弃 OS/2 for Windows 的决定永远破坏了两家公司之间的关系。“但我们得到了行政批准，并启动了移植，”Lucovsky 说。“因此，我们没有为 NT 开发 OS/2 子系统，而是选择了 Win32。” 他说，在那一刻，产品变成了 Windows NT。

“我们的核心架构是如此坚固，以至于我们能够将 NT 从 1990 年的 386-25 发展到今天的嵌入式设备、64 路、64 位多处理器机器和价值 1000 美元的横向扩展服务器刀片。”

-David Thompson
副总裁
Windows Server 产品组

NT 的模块化架构也在这一变化中得到了回报。“由于我们的微内核架构，内核与 POSIX 和 Win32 等应用程序环境分离，我们不必更改内核或开始新的编程工作，”Lucovsky 告诉我们。“调度程序的核心内容无需更改。我们在两周内启动并运行了 C 命令行应用程序。那是 1990 年 9 月。”

Thompson 详细阐述了 NT 基金会的重要性。“我们的核心架构非常坚固，以至于我们能够将 NT 从 1990 年的 386-25 发展到今天的嵌入式设备、64 路、64 位多处理器机器和价值 1000 美元的横向扩展服务器刀片。我们已经能够在其上提供一整套服务。”

1990 年 9 月，确实是 Windows NT 的转折点。并非巧合的是，之前领导微软 LANMAN for OS/2 3.1 高级开发团队的 Dave Thompson 也加入了 NT 团队，这并非巧合。“我们改变了方向，”汤普森告诉我们，“团队从 28 人增加到大约 300 人。我们有了第一个真正的产品计划。”

RTM及以后

Windows NT 的第一个版本 Windows NT 3.1 于 1993 年 7 月发布，其名称与当时的 16 位 Windows 产品的版本号相匹配。该 NT 版本具有桌面和服务器版本以及域形式的分布式安全性。从那时起，NT 团队致力于一系列版本的发布，所有版本都是在相同的底层代码基础上开发的。

下一个版本 Windows NT 3.5 代号为 Daytona，于 1994 年 9 月发布。“Daytona 是一个非常有价值的项目，”Thompson 说。“我们专注于尺寸和性能问题，以及‘完成’许多 3.1 的首次发布功能。Daytona 还进行了重大的功能改进和增强。” Daytona 的原始主题是尺寸、性能、压缩和 Netware 兼容性。其中两个目标是当时的标志性目标：DoubleSpace 式压缩是 1990 年代初期的热门话题，因为磁盘空间非常宝贵，而 Netware 是当时占主导地位的网络操作系统。“我们最终放弃了压缩，”Thompson 说，“但 Netware 端口具有战略意义。Novell 对 NT 桌面持矛盾态度——他们没有” 不知道他们是否想建立一个客户。我们提供了帮助，但他们一直在胡闹……好吧。我们自己做了。它只是把他们吹走了。我们的是更好的 Netware 客户端，客户使用我们的多年，甚至在他们最终使用了一个之后也是如此。该客户端支持 NT 桌面，因为 Netware 是市场上流行的服务器。否则我们将无法销售 NT 台式机。”

NT 时间线

1988 年 10 月 31 日：David Cutler 到达 Microsoft
1988 年 11 月：NT 项目开始工作 1993 年
7 月 27 日：Windows NT 3.1 发布 1994 年
9 月 21 日：Windows NT 3.5 发布 1995 年 5
月 30 日：Windows NT 3.51 发布 1996
年 7 月 31 日： Windows NT 4.0 发布
2000 年 2 月 17 日：Windows 2000 发布
2001 年 10 月 25 日：Windows XP 发布 2003 年
4 月 24 日：Windows Server 2003 发布

Daytona 还受益于新的编译器技术，它使 Microsoft 能够压缩代码大小，并在比原始版本低端的系统上启用逼真的 NT 桌面。“结果是可衡量的，”汤普森说。

Windows NT 3.51 被称为 Power PC 版本，因为它是围绕 NT 的 Power PC 版本设计的，它最初应该在 3.5 版中发布。(up注：存在PowerPC版本的NT3.5)但 IBM 不断推迟 PowerPC 芯片的发布，需要单独的 NT 版本。“NT 3.51 是一个非常没有回报的版本，”汤普森说，并将其与 Daytona 进行了对比。“Daytona 完成后，我们基本上坐了 9 个月来修复错误，等待 IBM 完成 Power PC 硬件。但正因为如此，NT 3.51 是一个可靠的版本，我们的客户喜欢它。” NT 3.51 最终于 1995 年 5 月发货。

恰好，下一个 NT 版本，Windows NT 4.0，被称为Shell Update Release(SUR)，这是另一个具有挑战性的任务，将再次证明 NT 模块体系结构的好处。“我们想构建一个具有 Win95 UI但使用 NT 技术的桌面，”Lucovsky 告诉我们。“我们最终移动了 Win32 GUI 组件并将它们作为进程内驱动程序托管。性能是一个副作用。我们在使用该 API 并在不同进程中运行它时遇到了问题。因此将代码移动到与运行时相同的上下文中“解决了很多问题。我们不必为 GDI 和 USER 进行死锁检测。这是一项重要的工作，但它解决了很多令人头疼的问题。” NT 4.0，该产品的分水岭版本，于 1996 年 7 月发布。

无处不在的 Windows

在下一个版本中，Windows NT 将失去 NT 名称并简单地成为 Windows。Thompson 说这个决定来自营销团队。“Windows [9x] 营销团队的一个人转向 NT 营销，他说我们应该在所有地方使用 Windows。起初我们都对名称更改感到不舒服，因为 NT 享有良好的声誉。但由于 Windows 的可靠性推动2000 年，人们开始谈论 Windows 2000 比‘那些旧的 NT 东西’好多少，即使它是相同的体系结构。所以它的发生实际上有点偶然。” 顺便说一句，Windows 2000 没有代号，“因为 Jim Allchin 不喜欢代号，”Thompson 说。

自 Windows 2000 完成以来，Windows 团队做出的最大决定是将客户端和服务器版本与 Whistler 产品分开，即 Windows XP 和 Windows Server 2003。稳固，而不是现在，”汤普森告诉我们。“桌面软件必须与 [PC 制造商] 销售周期同步发货。服务器没有假期高峰。” 

 

第二部分：开发 Windows

NT 系列操作系统（从 Windows NT 发展到 Windows 2000、XP，以及现在的 Windows Server 2003）的一个要素多年来一直保持不变，尽管细节发生了巨大变化，那就是构建过程. 在 Microsoft 内部的某个深处，几乎每天，至少有一个 Windows 产品被编译或构建为可由开发人员或开发团队进行内部测试的可执行代码。对于 Windows Server 2003，这个过程在微软庞大的雷德蒙园区的 26 号楼中完成，在几位工程师的注视下，成排的 PC 和 CD 复制机几乎在不停地运转。

“Windows 团队中有 5000 名开发人员为 Windows Server 2003 生成了超过 5000 万行代码。这是一项艰巨的任务，是有史以来最大的软件工程任务。没有其他软件项目像这样。”

-Mark Lucovsky
杰出工程师
Windows Server 架构师

NT 的细节——对不起，Windows——自 1980 年代末该项目首次启动以来，开发已经发生了巨大变化。“回到早期，我们从 6 个人开始，”微软杰出工程师和 Windows Server 架构师 Mark Lucovsky 告诉我。“现在 Windows 团队有 5000 名成员，外加另外 5000 名合作伙伴，为 Windows Server 2003 生成了超过 5000 万行代码。让所有这些人朝着同一个方向前进，编写代码，是一项艰巨的任务。构建他们的工作成果，将其编译并链接到可执行文件和构成 Windows CD 的其他组件是一个 12 到 13 小时的过程，每周每天都要完成。这是有史以来最大的软件工程任务。

  “当我们转动曲柄时，我们就编译了整个东西，”他说。“我们还必须能够在任何时间点重现系统。所以开发人员签入代码，我们按下一个按钮，然后系统就出来了。我们应该能够在未来三年重现那个[构建] ，使用我们当时使用的各种工具、编译器和脚本。”

微软 Windows Server 产品组副总裁 David Thompson 详细阐述了这一过程。“这里的关键是我们多年来建立了这个系统，在三个方面推进它，”他说。“首先是产品本身。其次是我们设计产品的方式。第三是我们与越来越广泛的客户互动的方式。产品演变非常简单。我们现在使用的源代码控制系统是新的，因为我们确实通过 Windows 2000 扩大了以前版本的规模。Mark [Lucovsky] 亲自领导新系统的开发并在 2000 年后推出。我们从一些获得的技术开始。我们现在确实有一个分阶段构建 [for the第一次]。但每天 [staged builds] 都会汇总到总构建中。

随意吃吧：微软提供狗粮

Lucovsky 回忆起早期的事情，当时第一个 NT 原型是在他的办公室里建造的，只有一个人监督这个过程。当新构建准备就绪时，那个人会简单地向 NT 团队发送一封电子邮件，然后大约 50 个人会“吃他们自己的狗粮”，在他们自己的系统上测试构建并运行压力测试。Lucovsky 说：“我以前只是在大楼里走来走去，写下我们发现的问题。” “这就是 NT 3.51 之前的情况。现在我们有 7 个构建实验室。Dave [Thompson] 为他监督的 1200 人拥有自己的 [构建实验室]。主要构建实验室推出了官方构建，其中有数千人每天都有人。通知是自动的，并使用整个校园的骨干服务器分多个阶段发送出去。这一切都是自动化的。

“最初，我们有一天中的特定时间 [up to which time] 我们可以签入代码，然后我们就停止了，”Thompson 说。“在那之后，我们启动了新系统并构建了新系统。最终，我们将团队扩大到 85 人，并将流程序列化以实现更多控制。[NT 架构师] Dave Cutler——我们都为他工作——负责构建实验室一个星期左右，他要求人在实验室的白板上亲自写下他们的签到要求。他把它压在一个模具里。我也在里面坐了一会儿。有一天我接受了85个签到，到那时我们拥有的最多。现在我们每天可以接收 1000 多个。这是一个完全不同的规模。甚至白板都是电子的——实际上是基于网络的——现在。”

“有一天，我在 NT 上接受了 85 次 [代码] 签到，这是我们当时最多的一次。现在我们每天接受超过 1000 次。这是一个完全不同的规模。甚至白板都是电子的——Web基于，实际上——现在。”

-David Thompson
副总裁
Windows Server 产品组

“没有其他像这样的软件项目，”Lucovsky 说，“但是 [多年来] 保持不变的一件事是构建 [Windows] 需要多长时间。无论是哪一代产品，都需要 12 个小时编译和链接系统。” 即使这些年来处理能力有所提高，Windows 也已发展到与之相匹配，并且开发过程变得更加复杂，因此 Microsoft 将更多的代码分析作为日常构建的一部分。“构建实验室中的 CPU 会持续 12 个小时，”他说。“自 Windows 2000 以来，我们已经调整了该过程。现在，我们将源 [代码] 树分解为独立的源树，并使用新的构建环境。这是一个多机环境，可以让我们更快地转动曲柄。

汤普森告诉我，对他们的代码进行内部测试一直是 NT 团队的一项关键要求，也是微软文化的一个组成部分。“这是我们一直在做的事情之一，可以追溯到最早的时候，”他说。“实际上，我们今天只是在开玩笑，谈论我们的电子邮件程序。当我们第一次在桌面 [PCs] 上运行 NT 时，我们的电子邮件程序不会运行，因为它是 DOS 应用程序，而且我们没有DOS 兼容模式仍然有效。所以我将我们的内部电子邮件应用程序 WizMail 移植到了 Win32，这样我们就可以只使用 NT 系统了。”

“当你被迫自己使用系统时，你会看到错误和性能问题，”汤普森补充道。“然后你会去找问题的负责人，并要求他们解决问题。” Thompson 加入 NT 团队时的主要职责之一是将文件服务器交付给 NT，以便它可以用作源代码服务器。这需要一点信心，特别是因为 NT 当时正在使用 NTFS 文件系统的原型版本。“网络组非常重视这件事，”他说，“并确保它已准备好进行内部部署。一旦推出，我们就不会退缩。显然，如果文件服务器出现故障，那将是一场灾难。所以它对我们来说是一个重要的时刻，克服了困难。”

后来，随着 Windows NT 4.0 开发的结束，Thompson 的团队开始研究 Active Directory (AD)，这是 Microsoft 的第一个目录服务，它于 1996 年在专业开发人员大会 (PDC) 上公开亮相。“在 AD 之前，我们有 NT 域用于我们的基础设施，”他说，“而且转向 AD 更加复杂。我们很早就部署了 AD，首先是与我们的团队，然后是更广泛的 Windows 组。然后我们在 1999 年 4 月在雷德蒙德园区AD 上投入使用。”

Thompson 说，微软通过周密的计划，分阶段向公司的其他部门推出了 AD。去年，校园采用了 Windows Server 2003 的多林 AD 拓扑。“对于所有基础架构服务器，我们总是在内部进行完整的部署，然后将其推送给 JDP（联合开发合作伙伴），后者在 250 多个使用场景中对其进行测试和部署。我们收到错误报告、功能反馈、以及真正证明产品的复杂场景测试。”

去年夏天，Windows Server 2003 在候选版本 1 (RC1) 阶段达到了 99.995% 的可用性，当 RC2 于 2002 年 11 月推出时，Microsoft.com 网站已完全部署在 WinServer 2K3 上。“内部和密切客户的大量使用是关键”Thompson 告诉我，“我们对现在的产品有了更成熟的看法 [与早期相比]。我们不仅在盒子里运送比特，而且还在运送范围广泛的补充工具，产品、服务和文档。” Thompson 解释说，在 Outlook 11、Exchange Server 2003（“Titanium”）和 Windows Server 2003 上工作的团队都更加紧密地合作，以实现满足客户需求的完整端到端方案。过去，这些产品往往是比较独立开发的。

有人为你服务吗？产品维护一览

“多年来，服务肯定已经成熟，”Lucovsky 补充道。“我们做了很多工作来确定每种产品的服务包、修补程序、[产品] 开发分支、测试版和 JDP 客户的正确组合。” （有关开发分支的更多信息可以在下一节中找到。）

“我们确实延长了我们为产品提供服务的时间，”汤普森说，因为当微软推出服务器产品时，客户可能会使用它长达十年。所谓的批量或主流服务持续七年，但随着时间的推移，该公司不断改进其提供更新和修复的方式。首先，Microsoft 必须确保将错误修复应用于所有适用的开发分支。“我们在快速解决安全漏洞方面的工作意味着我们现在会尽可能积极地发布热修复程序，”Thompson 指出。“同样，过去 [服务包] 是灵活的，这是我们可以提供功能和修复的一种方式。但客户明确表示他们只需要 [服务包中的错误修复]。这导致了一个有趣的问题不过，问题是：究竟是什么，是一个错误？缺少的功能是错误吗？客户自己往往有不同的看法。但是 [Windows] NT 4 SP3 是 [服务包中的主要新功能] 的终结。

主干服务的一个副作用是 Microsoft 必须为其最新操作系统的每个排列维护测试环境。这意味着 Windows 2000 的最终版本或“黄金”版本是一个分支，Windows 2000 SP1 是另一个分支，Windows 2000 SP2 是另一个分支，依此类推。“并且测试对于提供服务包也很重要。在我们的 IT 组织中，我们维护一个 [单独的] Windows 2000 基础结构，这样我们就可以对 Windows 2000 系统进行实时部署并在生产环境中对其进行测试，”Thompson 说。“这是一笔很大的开支，但值得。”

Hot-fixes 被视为窄版本，应该只修复一个特定的问题而不影响系统的其他部分。汤普森说，客户通常只应在受到修复所解决问题的影响时才应用热修复。但是，安全修复完全是另一个问题。“我们希望我们所有的客户都安装安全修复程序，”他说，“所以我们对它们非常小心，并进行正确的测试。它们是通用部署版本 (GDR)，就像服务包一样。”

树干、树木和树枝

如前所述，各种 Windows 版本需要一系列产品开发代码分支，随着时间的推移，每个不同的 Windows 产品都从主要开发“主干”中“分支”出来。因此，每个 Windows 版本都建立在上一个版本的基础上，并且至少有两个不同的版本——Windows Server 2003 和 Longhorn，在撰写本文时——正在同时开发中。因为WinServer 2K3是从XP中分离出来的，服务器产品基本上是建立在XP之上的。Longhorn 是几年后将接替 XP 的客户端版本，它实际上是在服务器分支代码库的基础上构建的，而不是您可能期望的 XP。

“这样做的机制令人头脑麻木，”Lucovsky 告诉我。“我们有一个当前 Windows 版本的主要代码分支，该分支成为热修复和下一个服务包的源代码库。一旦我们吐出一个服务包，它就成为一个分支，现在我们有两个分支必须测试热修复和服务包。我们不能告诉客户先安装，比如说，SP1，然后再做这个热修复。每个 [Windows] 版本都会这样，所以有些有 2 或 3 个服务包、许多修补程序和许多安全修复程序。其中每一个都是 5000 万行代码的托管集合。这是一个相当大的会计问题。”

此外，对于活跃开发中的每个主要分支，微软还有大约 16 个团队级分支，以允许团队级独立/并行，同时在一个共同的主线分支上工作。每个团队维护一个完整的构建实验室环境，该环境构建一个完整的版本，包括团队的最新更改，并定期将他们经过测试的更改集成回关联的主分支，以便其他人可以看到他们经过测试的工作。

开战：在作战室中对错误进行分类

在向 RTM 的疯狂冲刺期间，该项目的核心是作战室，作战团队每天开会 2 到 3 次，每周开会 5 天——现在 Windows Server 处于开发的最后几天，每周开会 6 天。汤普森告诉我们：“作战小组每天都会检查报告和指标，以查看项目的进展情况，”他的解释很低调，但几乎没有让我们为作战室的恐怖做好准备。“现在一切都是自动化的，但那时候我们进来并传递纸质报告，向我们展示我们的表现。房间里可能有 15 到 20 人。现在情况大不相同了。”

确实是。

对于 Windows Server 2003，作战室由 Todd Wanke 管理，我们最终发现他是一个非常讨人喜欢的人。然而，在长达一个小时的作战室会议中，Wanke 以铁腕统治，到处征求可信赖的副手的建议，但毫无耐心地向前推进流程出席会议。

这是它的工作原理。每天早上 9 点 30 分，来自各个 Windows Server 2003 功能团队的代表都会开会，对错误进行分类。他们进入 26 号楼的 3243 号会议室——其外部标志被写着“争论诊所”的手写字条遮住了。房间中央有一张大会议桌，但大多数与会者必须站着，屋子里总是挤满了人。在我们参加 War Team 会议的那天——第一次允许任何局外人查看 Windows Server 的内部密室，并且在整个 NT 和 Windows 的整个开发过程中也是第二次——团队在大约 50 个错误中取得了进展，其中大部分是简单的品牌问题，尽管我同意不讨论当天讨论的任何错误的细节。

每个错误都记录在一个令人难以置信的错误跟踪系统中，每个错误都伴随着一系列令人眼花缭乱的信息，包括错误是如何发现的、哪些客户（如果有的话）受到了影响，以及迄今为止为消除该问题所做的努力的完整历史记录。Wanke 迅速解决了这些错误，召集了特定功能团队的成员来解释修复的进展情况。如果 IIS 中存在一个或多个错误，例如，IIS 团队的代表需要在场，不仅要解释错误的优点，还要解释客户是否受到影响，修复可能如何影响系统的其他部分，以及多久会修好。在开发过程的后期，错误通常会传递或“踢”到下一个 Windows 版本——Longhorn——如果它们还不够严重的话。

作战室的气氛令人生畏，我大部分时间都呆在房间里，一言不发，几乎畏缩不前，祈祷万克不要把注意力转向我或我的团队。激烈的争论和咒骂在作战室中是常有的事，而对你的错误没有控制的惩罚是来自其他团队成员的迅速而残酷的嘲笑。最恶毒的待遇自然是留给那些愚蠢到可以取消作战室会议的人。在我参加的那天，一个特性小组将其四个错误提交给了 Longhorn，因为它们没有出现在作战室中。当有人争辩说应该再给他们一天时间时，Wanke 只是说，“F#$% 他们。如果有那么重要，他们早就在这里了。它在 Longhorn。下一个漏洞。”

“如果人们不在[作战室]，我就会进入他们。我就是踢屁股的人。”

-Todd Wanke
产品经理
Windows Server 发布管理

长达一个小时的会议结束后，我们坐下来与私下里几乎完全变了一个人的万科交谈。“托德，你召开了一场卑鄙的会议，”我们坐下时我告诉他。Wanke 的背景包括曾在 NCR、America Honda 任职，以及作为美国政府承包商的一项未指明且听起来神秘的安全相关任务，他在 Microsoft 工作了将近八年。在加入 Windows 团队之前，Wanke 是 Microsoft.com 网站的原始架构师之一，在整个 Microsoft 建立互联网信仰之前，他在公司担任了三四年的“互联网人”。在我们的会面中，Wanke 解释了他是如何找到新工作的，他现在在微软做什么，以及 War Team 是如何运作的。

“我的工作是管理与运送 Windows 相关的日常运营，”他说。“我负责 8000 到 10,000 名开发人员、项目经理和测试人员，我必须确保他们每天都在做正确的事情。”

他说，War Team 由 Windows 团队中非常广泛的人员组成，他们都负责项目的不同领域。他们是负责 TCP-IP 和其他低级技术等事情的测试主管、一些开发人员、每天进行构建的人员、进行构建验证测试的人员等等。“项目的每个领域都有代表，”他告诉我们。“[Windows Server 团队] 的日常行军命令来自 War Team，也来自我发出的广泛邮件。这些电子邮件几乎都是微软机密，甚至更高，非常机密的电子邮件，只发送给一小群人。”

正如我们所见，作战室是一个非常结构化的事件，每天在同一时间发生，持续整整一个小时。团队成员每天查看同一个错误系统，并且经常检查相同的错误，直到它们被修复。“如果你不在那里，那就不好了，”他说。“微软人对产品有强烈的主人翁意识，他们希望确保正确的事情发生。但如果没有人，我就会投入其中。我就是踢屁股的人。”

除了上午的作战室会议外，Windows Server 团队还在下午 2 点到 3 点召开下午会议，如果需要，下午 5 点到 6 点再召开一次会议。每日构建通常在 4:30 开始，但可以延迟到 6 点，因此最后一次会议让团队有机会审查将添加到当天构建中的任何最终错误修复。“结构非常重要，”他说，“我们需要随时了解构建的位置。我们会查看构建的质量、各种压力水平，以及所有在一夜之间运行的东西，任何我们认为需要跟进。我们会得到详细的报告，并审查项目中的所有内容。”

除了主作战团队之外，每个功能团队都有自己的作战室，因此每天可能会召开多达 50 场这样的会议，每次都讨论系统的一个特定组件。这些其他的作战室会议每天早上 8 点召开。当 bug 修复通过本地 War Team 流程时，它会在 Wanke 的会议上介绍。“除非他们准备好修复，否则他们不能进入作战室，”Wanke 说。“他们必须准备好修理。” 因为没有一个人做决定，所以有一个检查和平衡系统，每个错误修复在被引入构建之前通过该系统。

构建 Windows 的复杂性是惊人的。“为了简化事情，假设 Windows 包含 100,000 个文件，”他说。“通常，有七个源代码仓库，每个都包含所有源代码的精确副本，但在这一点上，我们只剩下一个。每个开发组都有自己的仓库，因此当开发人员编写修复程序时，他可以将其编译到软件仓库中进行测试。如果构建在本地使用他的修复编译，他们可以在那里测试它，然后将其签入主构建实验室的主软件仓库中。”

当然，并非每次构建都成功。有时，Windows Server 会遇到 Microsoft 所说的“在地板上构建”，当修复程序破坏系统的其他部分时，导致构建无法使用。“这太残酷了，”万克告诉我们。“大约一年前的某个时候，我们有 7 天没有构建出来。我们不得不向公司的产品组主管发送电子邮件来解释这个问题，”然后公司进入了私有版本Defcon-5。“所有的危险信号都上升了，”他说。“在开发人员中根深蒂固的是不要破坏构建。他们进行修复，进行伙伴构建，然后将其签入。但他们不能回家。我们已经在凌晨 3 点发出呼叫，当时构建是坏了，找到坏掉它的开发商，然后让他立即投入工作并立即修复它。开发人员每天 24 小时待命。肯定有一个升级过程。损坏的构建被认为是严重的 1 级问题。”

随着 Windows Server 2003 开发周期的结束，错误数量急剧下降，过程每天都变得越来越简单。然后微软宣布更名。“我们只能接受那个糟糕的决定，”他告诉我们。“他们应该在六个月前就做到了。那时候，我们都认为这是正确的做法。但在这个后期阶段——他们请来了 [CEO] 史蒂夫·鲍尔默，与所有战队队员讨论我们为什么做到了改变。” Wanke 说，团队能够修复系统中所有品牌图形、文本和注册表项的速度证明了公司修复错误的动态过程。问题是需要进行几千处更改，而这通常需要在产品的错误跟踪系统中添加几千条新条目。“ 我出去挑选了团队中最好的三位开发人员，然后说，“去解决它吧。” 一位开发人员修复了 7,000 多个对 [Windows] .NET Server 的引用。就这么说吧，有我信任的人，也有我不信任的人。我告诉这些人，‘别告诉我你在做什么。去做就对了。'”

进入最后阶段

据 Wanke 说，在我们参加 War Room 的那天，也就是 2003 年 1 月 21 日，Windows Server 2003 的错误率达到了“绝对历史最低点”。“我们本周将关闭该项目，”他说。“做好了，我们要发货了。” 那天，WinServer 2K3 只有几个活跃的错误，其中至少四分之一到三分之一的错误是简单的品牌问题。“假设有大约 150 个悬而未决的问题需要解决，”Wanke 告诉我们。“其中，我们将修复大约 100 个。所有错误的严重程度都从 1 到 3，此外它们还获得了优先级评级。我们还有 [一些] 严重程度为 1 的错误需要修复，而这些都必须是为我们准备好发货。”

万科表示，服务器团队已经修复了所有已知的安全漏洞。“我们对安全感到非常高兴，”他说。“看到我们[在安全方面]所处的位置很有趣。我个人对其中的工作、修复和思考过程印象深刻。我们都认为它非常安全。[Trustworthy Computing] 安全推动 [last年]对我们来说是一个重要的里程碑，因为它，一切都会变得更容易。对开发人员来说更容易，因为他们现在都有相同的心态和目标，关于最佳实践的相同教育。过去有不同的方法论不同的群体。安全推动统一了它。现在每个人都更容易沟通并看到最终目标。”

随着Windows Server 2003开发的完成，开发团队将进入一个过渡期。首先，产品将进入托管状态，构建过程将被冻结。然后将该构建部署在园区周围，包括 Microsoft 的企业基础设施。“这是最终版本，”Wanke 指出。“然后我们坐了一段时间，在此期间没有对产品进行核心修复。” 他说，托管版本也将分发给测试人员和 JDP 成员。”

如果在托管期间确实出现任何问题，战争团队将根据具体情况决定是否修复错误。如果需要内核修复，将创建一个新版本，并重置托管。“对核心组件的更改可能会延迟 RTM，”Wanke 告诉我们。“我们在要求客户之前运行它，并且必须在签署之前运行它几天。这是一个漫长的过程。” 在 Windows Server 2003 上工作的每个功能团队都必须在不重新启动的情况下运行托管构建 21 天，然后该构建才能被宣布为黄金大师并发布到制造商。

但万科并不担心具体的时间安排，经过多年的努力，结果终于成定局。他的团队现在正在准备它的 RTM 派对——如果天气允许，就在校园外的众多足球场之一；如果不是在车库里——Wanke 还有其他与 RTM 相关的问题，他必须解决，包括发射场。“我正在与发射团队合作预订场地，”他说。“他们需要 95% 的置信日期。” 他们还与 OEM 商谈以确保系统已准备好发布，与 ISV 商谈，与标志和海报的营销人员商谈，等等。“而且我必须确保 8000 名应得船舶奖的人获得一艘，”他补充说。

最终，所有这些奉献将产生微软有史以来最安全、最可靠的操作系统，万科对这个项目的贡献怎么强调都不为过。“在一年半的时间里，我基本上没有错过任何一支战队，出于个人原因给予或花费一天左右的时间，”他说，“每天，每周六天，在计划结束时。我们让人们在星期六带他们的孩子来，这是一个家庭日。星期六不允许说脏话。但你仍然必须在那里，我们仍然必须建造。”

那么 Wanke 会在未来的 Windows 版本上运行 War Team 吗？

“不可能，”他笑着说。“决不。”

第三部分：测试 Windows

随着三年前 Windows 2000 开发的结束，Microsoft 正在进行另一种转变：公司的开发重点从提供技术转移到提供满足实际客户需求的解决方案。这听起来像是一个显而易见的策略，但考虑一下后果：过去，Microsoft 会确定其产品的每个修订版中包含哪些功能，在分配的时间内尽可能多地提供这些功能，然后移动任何丢弃的功能进入下一个版本。通常，公司会将客户反馈吹捧为每个产品版本中包含的功能的主要灵感之一，但客户反馈只是公司考虑的众多标准之一，当然不是主要标准。

必须考虑过去十年的竞争格局和微软瞄准的市场，才能理解为什么会出现这种情况。在其历史的大部分时间里，微软都是火热的暴发户，争夺市场份额并偏执地认为下一件大事会出现，从而将公司甩在后面。对于 1990 年代的许多核心市场——桌面操作系统、办公生产力软件和基于工作组的企业计算——微软主要关注低成本、简单性和功能，因为它试图超越 IBM 等竞争对手， Lotus、Novell、WordPerfect Corporation、Borland、Apple 等。客户研究基本上等于“越多越好”：当时的想法是大多数用户会比较功能的项目符号列表并选择最能满足他们需求的软件。

  快进十年，计算行业发生了翻天覆地的变化。在确保其在桌面操作系统和办公生产力市场的主导地位之后，微软不得不做出两项关键改变。首先，它必须想办法在其成熟产品已经占据主导地位的那些市场中推动销售。其次，该公司必须进入新市场以推动增长。其中一些新市场包括手持计算和其他非 PC 设备、视频游戏、消费电子产品，当然还有高端企业计算市场。1996 年发布的 Windows NT 4.0 见证了一些可伸缩性的进步，但直到 Windows 2000 微软才为传统上由高端 UNIX 机器服务的市场开发了一款可靠的产品。在 Windows Server 2003 中，

然而，高端企业市场运行的规则与桌面市场甚至中小型企业不同，两者通常都需要尽快获得尖端功能。在更成熟、发展更慢的企业市场中，稳定性和可靠性的价值远高于任何其他标准，而且这些操作通常使用相同的软件数十年，而不是两三年。到 1990 年代后期，微软在这个市场上几乎没有经验。它导致公司全面做出巨大改变。例如，Microsoft 两次延长了 Windows NT 4.0 的支持生命周期，仅仅是因为其客户使用该技术的时间比公司最初预期的要长得多。对于 Windows 2000，更明显的是 Windows Server 2003，Microsoft 了解客户可能会在未来几年内运行该软件。它的客户当然希望该软件易于部署、管理和更新，但他们也希望它能够正常工作，并且永远正常工作。

开发能正常工作的简单软件已经够困难了，但当涉及到像 Windows Server 2003 这样复杂的软件时，它有超过 5000 万行代码、几个不同的产品版本，以及数量未知的未来更新、安全修复、热修复和服务包，传统的软件测试方法是不够的。微软很早就意识到它不能发布这个产品，等待不可避免的问题出现，然后在以后修复它们，许多客户像往常一样等待 Service Pack 1 (SP1) 版本开始部署计划。不，Windows Server 2003 会有所不同，Release Candidate 2 (RC2) 构建被认为是“最终”版本，而产品的正式发布 (RTM) 或“黄金”版本将于 2003 年 4 月 24 日到期，相当于以前开发方法下的 SP1 版本。客户应该对推出候选版本充满信心，知道 RTM 版本会更好，并在几个月后跟进。

Windows Server 2003 需要在真实环境中进行测试，并在现场部署，并且在最终版本公开可用之前，部署的数量要比过去多得多。但这需要微软与其客户之间有一定程度的信任，而且对于这家软件巨头来说，还需要一个远远超出其过去采用的标准压力测试的软件测试基础设施。这个新的测试基础设施以及新的 Microsoft 的关键组成部分之一是公司的企业工程中心 (EEC)。

Microsoft EEC 中的实际测试

Microsoft 企业工程中心 (EEC) 本身是两年测试的结果，于 2002 年 4 月 Windows Server 2003 测试版期间开放。EEC 是微软 Windows 集成场景测试产品部门经理 George Santino 的创意，他想为长期产品测试建立更好的标准。它位于微软雷德蒙德园区，旨在让公司的客户在实验室环境中复制他们的特定环境，并了解各种微软软件升级、迁移和部署如何使用该公司的真实数据和系统执行。EEC 向客户免费提供。

“我们需要在产品推出时进行部署，而不是在 SP1 之后，而不是在 QFE 之后。”

-George Santino
产品部门经理，Windows 集成场景测试

“我们建造这个设施是为了让我们能够在产品仍在开发中时与客户互动，”当我们走过欧洲经济共同体的大量服务器时，桑蒂诺告诉我。“我们希望直接与将部署它们的客户一起测试产品，并了解他们的网络拓扑和他们试图解决的问题。这有助于 Microsoft 为这些客户提供在发货时更适合企业使用的产品，并且它使我们能够直接与客户互动。” 微软通过确保其产品在实际场景中工作而从 EEC 中获益，而在过去，这些场景在实际发布之前没有经过全面测试。客户可以从与负责相关产品的产品团队的一对一互动中获益。

在许多情况下，在 EEC 的积极体验将导致客户以预发布形式部署 Microsoft 解决方案。“像 jetBlue 这样的客户在参观了 EEC 后立即离开并立即在生产中部署了 Windows Server 2003 和 Titanium [Exchange 2003] Beta 2，”Santino 告诉我。“他们来到这里，会见了人，测试了他们的环境，并看到它可以工作，并且更具可扩展性。我们能够在他们离开之前为他们解决问题。”

过去，这些客户中的许多人可能之前一直等到最终产品发布，或者更常见的是，等到第一个服务包发布。“我们需要在产品上市时进行部署，”Santino 说，“不是在 SP1 之后，也不是在 QFE 之后。”

第一轮 EEC 测试涉及近 50 家客户，他们都测试了 Windows Server 2003 升级、迁移和部署。客户通常会在欧洲经济共同体逗留两周——尽管澳大利亚税务局会待近六周——而微软最多可以同时在欧洲经济共同体接待五名客户。更重要的是，由于 EEC 与会者的意见，Windows Server 2003 出现了一些问题和 650 处设计更改。并且已经有一些回头客，例如英特尔、西门子、雪佛龙-德士古和美国大陆航空公司。

带上顾客

实际上，EEC 目前包括三个企业客户实验室（第四个正在建设中，第五个正在计划中）和一个称为控制中心的大型服务器机房，其中配备了几乎所有可以想象到的硬件。三个实验室分别摆满了IBM、HP 和Dell设备，用于主持终端用户测试。“我们让客户来测试他们的实际环境，”桑蒂诺告诉我。“我们配置测试环境的方式与客户配置真实环境的方式完全相同。它使用他们使用的相同软件，完全相同的硬件，一切。这是他们的整体环境。这有助于我们发现有趣的错误，我们可以得到开发人员关注环境，更多地了解我们的客户正在做什么。”

一个明显的问题涉及客户如何参与 EEC。Santino 告诉我，客户通过多种渠道来到 EEC。“我们在现场的客户团队带来了客户，MCS [Microsoft 咨询服务] 人员也是如此，许多客户来是因为他们参与了 JDP [联合部署计划]。我们也有一些来自我们的硬件合作伙伴和其他原始设备制造商。一旦我们收到通知，我们希望提前 3-4 周通知我们参与并获取有关如何构建环境和安装所有软件的信息。但我们只在几天通知后就完成了。如果必须的话，我们可以匆匆忙忙地在几周内完成它。”

在 EEC 进行的测试并不局限于针对客户环境运行的单个 Microsoft 产品。公司提前询问客户他们想测试哪些软件产品，包括他们自己的专有解决方案，以及竞争对手的软件和硬件。“我们这里有几乎所有可以想象到的服务器，”Santino 笑着说。“如果它在他们的环境中，它需要工作。另一件让客户感到惊讶的事情是他们认为我们不会测试那些[非微软]的东西。但事实并非如此。如果你使用的是[IBM] DB/2 ，好吧。我们将测试他们在业务中使用的内容。”

此外，还会询问客户他们想在 Microsoft 与谁会面。“我们还有一位项目经理，当他们在这里时，他基本上和他们住在一起，”桑蒂诺说。“我们发现了不同的错误，因为我们正在使用仍在开发中的产品。但我们可以让开发人员在这里处理该代码，让他找出客户在做什么以及为什么。然后他可以回去并在客户离开 EEC 之前获得修复。”

当客户在 EEC 时，Microsoft 收集信息并为每个客户编写业务模型，记录他们如何赚钱，以及他们的问题是什么，以及他们的问题所在。“我们问，‘你用 SQL Server 做了什么？Exchange？请告诉我们更多信息，’”Santino 指出。在许多情况下，答案令人惊讶，并且 Microsoft 发现其客户以其从未想象过的方式使用其产品。

客户走后

客户离开后，Microsoft 会保留他们环境的图像，但会减去任何真实世界的数据。“我们保留它，向各个产品团队发送电子邮件并告诉他们，‘我们有这个环境，你想来测试一下吗？’ 测试团队过去只测试通用环境，但现在他们可以看到他们的产品如何对现实世界的情况做出反应。这是一个了不起的机会。” 随着时间的推移，当产品团队开发各种产品时，他们可以浏览环境档案并选择他们想要测试的环境。“我们可以在几天内重新构建它并让他们对其进行测试，”桑蒂诺说。

“在 EEC 之前，我们在如何测试涉及更多产品的更大范围内受到限制，”Santino 告诉我。“这些东西如何相互作用真是太神奇了。我们测试过的大多数环境都是异构的。例如，Chevron-Texaco 很有趣，因为它们融合了两个完全不同的环境。但 Barnes & Nobles 几乎是纯粹的 Microsoft，没有冲突。”

客户对 EEC 的反应

为帮助客户了解 EEC 的工作原理，Microsoft 会定期参观该设施。“客户从 [校园内] 的行政简报中心过来，说，‘我们听说了微软如何倾听客户的意见。证明给我看。’ 好吧，这就是它发生的地方。这就是 Microsoft 与客户合作的地方。他们可以来这里，参观，参观硬件，以及实际客户进行测试。最终，EEC 帮助使产品企业准备就绪，当然，但它也使他们的企业可信。”

“当然，EEC 有助于使产品为企业做好准备，但它也使它们成为企业可信的。”

-George Santino
产品部门经理，Windows 集成场景测试

那么反应如何呢？“客户说这是有益的，”桑蒂诺说。“他们说，‘你们真的很关心，你们正在解决问题，我可以亲眼看到。’ 他们告诉我们他们的想法，并根据他们的反馈实时看到变化。最重要的是，不涉及成本。我们不是营销或销售。这是关于运送客户实际可以购买的更高质量的产品使用。最终，EEC 会产生销售，当然。但我们希望让他们进入那里 - 免费 - 我们希望他们帮助我们了解他们如何使用我们的东西。我们需要真实的数据来强调产品，不是模拟。它必须是真实的。客户知道，如果他们要部署它，他们需要现在而不是以后才能确定它是否有效。”

桑蒂诺说，许多参与 EEC 的客户如果可以的话会住在那里。“他们看到了来到这里进行测试以及与开发人员和项目负责人会面的价值。面对面的时间对他们来说非常宝贵。”

事实上，与我交谈过的使用过该设施的客户都对他们在 EEC 逗留期间获得的帮助和专业知识的质量和深度印象深刻。他们都说他们将来会回来测试其他产品。其中一位客户，肯塔基州教育部，有一个特别有趣的故事要讲。

肯塔基州教育部前往雷德蒙德

肯塔基州教育部 (KDE) 在全州超过 175 个学区维护着 1,400 所学校，这是一个为超过 600,000 名学生以及 125,000 名教育工作者、工作人员和其他雇员提供服务的大规模分布式计算环境。以前，KDE 环境由 4400 多台服务器组成，大多数运行 Windows NT 4.0，分布在近 400 个独立和自治的 NT 域中。显然，这种基础结构在向 Active Directory (AD) 发展时提出了一个巨大的问题，Active Directory (AD) 是随着 Windows 2000 首次亮相的更现代的目录服务基础结构。将这种环境发展为更加集中和易于管理的环境的任务落在了 Tim Cornett 的肩上， KDE 的 Active Directory 架构师和 KDE 的 Exchange 架构师 John Logan。

“每个地区至少有一个 NT 域，但大多数有两个，”Cornett 告诉我。“我们必须将这大约 400 个域合并为一个 Active Directory 林中的 178 个域，并在 2003 年底之前建立整个林结构。” 当我在 2003 年 2 月与 Cornett 和 Logan 交谈时，他们刚刚完成了第一个试点项目。“第一个试点是在教育部，”Cornett 说。“我们从 NT 4 迁移到 Windows Server 2003 RC2。” 6 个学区在 4 月进行了试点，其余 170 个学区将在 2003 年 5 月至 11 月期间迁移。

在架构上，KDE 环境将由一个具有 178 个域的 AD 林组成。将有一个根域，一个用于 KDE 员工的域，以及一个用于该州 176 个学区的每个域。这种结构将为 Cornett 和他的同事提供中央管理，而当前的、分散的、基于 NT 4 的解决方案使他们无法集中管理。

为什么是EEC？

最初，KDE 致力于自行将其基础结构升级到 Windows 2000。但经过 18 个月的评估和测试后，Cornett 意识到他们需要一些帮助。该部门联系了 Microsoft 咨询服务 (MCS) 以询问架构指导，并从 Microsoft 的企业服务组聘请了一名全职技术客户经理。最终，KDE 加入了 Windows Server 2003 快速采用计划 (RAP)，这使他们能够在产品开发过程的早期开始使用该产品。

“微软让我们有机会来到欧洲经济共同体来测试我们的环境，”Cornett 告诉我。“由于我们的规模，不可能坐在这里，将一些服务器放在一起并说它有效。所以我们前往雷德蒙德。一切都提前准备好了。他们使用 NT 4 在 VMware 会话中预先构建了 178 个不同的域，大约在40 台不同的服务器。当我们到达时，他们帮助我们构建了新的林根并完成了升级过程。”

“根本没有兼容性问题，”Cornett 告诉我，“一切都运行得非常好。他们在 Windows 2000 上使用 VMWare GSX Server。我们偶尔会遇到硬件故障，但总体来说一切都运行得非常顺利。那里的人很棒。” 在 EEC 期间，KDE 与 Microsoft 的各个产品组进行了多次会面。这一经验促使 Logan 将 KDE 的 Exchange 基础架构迁移到 Titanium，并且他们很可能很快就会回到 EEC 以帮助促进这一变化。“我们的 Exchange 布局类似于我们的 NT 布局，因为它复杂且分散，”Logan 说。“我们也想看看大大折叠我们的 Exchange 拓扑。Exchange 团队非常有兴趣与我们讨论这个问题。我们”

服务，服务，服务

Cornett 和 Logan 对 EEC 和 Windows Server 2003 留下了深刻的印象。“只要 Windows Server 出现故障，20 分钟内就会有来自整个园区的产品团队成员出现并开始深入研究代码，”科内特说。“非常紧张。我们在那里待了 5 天，非常漫长，尽管他们已经提供了两周。但那是在圣诞节前夕。我们每天在那里待 16-18 小时，但他们愿意 24 小时和我们在一起-7 如果我们想要的话。他们非常出色。你可以支配的资源似乎是无限的。这令人印象深刻。”

“我们唯一的遗憾，”Cornett 说，“是在我们到达实验室之前，我们对实验室的了解不够。我们本可以准备得更好。我们有一个计划，但我们认为他们可能只有几台机器，我们光是准备好就得花好几天时间。但当我们去的时候，机器的数量和质量远远超出了我们的预期。到第一天结束时，我们的计划已经在周三了。我们可以如果我们在出发前就知道有哪些资源可用，我们就能取得更大的成就。” 事实上，EEC 的访问给人留下了深刻的印象，Cornett 补充说，它帮助转变了参观校园的 UNIX 人群中的一些反微软情绪。“我们带了一些反微软的人，或者极度怀疑的人——大多数是 Solaris 的人。

Cornett 说，当他们第一次到达 EEC 时，最担心的是 Microsoft 没有足够的磁盘空间来复制他们的环境，该环境有一个巨大的全局目录 (GC)。“他们问我们需要多少空间，所以我们计算了一下，结果大约是 1 太字节 (TB)，”Cornett 告诉我。“第一天，我们于周二凌晨 1:00 离开 EEC，并于当天早上 8:30 回到实验室。他们已经将光纤连接到我们的房间，并让我们可以访问带有两个 500 的 SAN GB 驱动器。我们有需要，很快就解决了。他们说，“我们整晚都在这里，但我们为你找到了。” 没有任何问题或投诉。”

“在教育领域，我们一直运行到死为止。我们希望 Windows Server 2003 的使用寿命更长，而无需进行重大升级。”

-肯塔基州教育部的Tim Cornett Active Directory 架构师

在 KDE 离开 EEC 之前，Microsoft 备份了他们的环境，以便他们可以将其重新联机并在部门在生产推出时遇到任何问题时对其进行测试。当然，如果需要，Microsoft 的各种产品组可以来到 EEC 并在复杂的 KDE 环境中测试他们的产品。“现在他们有了一个和我们一样大的模拟环境，当然，减去了所有的名字和其他真实世界的数据，”Cornett 告诉我。“但他们可以用它来测试，所以这对双方都有好处。”

与此同时，回到肯塔基州

现在 Cornett、Logan 和其他 KDE 团队成员都回到了肯塔基州，真正的工作可以开始了。在 Windows Server 2003 出现之前，该部门运行的所有设备从配备 64 MB RAM 的老式 Pentium 75 服务器到配备 4 GB RAM 的四核至强服务器；都在运行 Windows NT 4.0。随着升级到 Windows Server 2003，所有学区的服务器都将是具有双处理器能力的 Dell PowerEdge 2600 机器。在试点期间，每台服务器都将以单处理器模式运行，以衡量处理器利用率；如果超过 40%，它们将升级到双处理器。由于 Windows NT 4.0 已经使用了 6 年——它于 1997 年在肯塔基州实施——Cornett 希望从 Windows Server 2003 中获得类似的使用量。他说。“

关于 Exchange 迁移，Logan 告诉我总体目标与 KDE 对 Windows Server 2003 所做的类似：简化管理。“我们希望将我们的 184 个 Exchange 站点合并为一个路由组，或者几个路由组，”他说。“借助 Titanium、Outlook [2003] 和 Outlook Web Access (OWA)，我们将能够进行大量的集中托管。我们有一个基础设施可以在必要时托管所有学区。这将有助于我们更容易做备份、执行病毒防护等。我们真的想集中服务。”

Logan 的宏伟计划是将目前分散在全州的 320 台 Exchange 5.5 服务器减少到仅 20 台 Exchange Titanium 服务器。然而，这个计划的唯一问题是政治上的，而不是技术上的。一些较大的学区可能不希望集中管理他们的 Exchange 服务器。但对于较小的地区，通常只有一名技术人员负责管理、备份和保护 Exchange，集中管理将非常受欢迎。还涉及少量的总体成本节约。

人们可能想知道，在这个困难的经济时代，一个资金匮乏的教育机构如何负担得起所有这些升级。洛根说这完全取决于大小。“首先，每个学区获得 100% 的匹配资金，每个学生每年最多 20 美元，所以州政府匹配，每年为每个学生提供总计 40 美元的支出，外加任何当地资金。这是提供合同的强大购买力用于硬件和软件以使其成本尽可能低。我们获得了一些非常好的折扣。

原文最后更新于2003年4月