深入剖析 Sharepoint 企业项目管理与 SharePoint

 哪些 SharePoint 技术适合您？为了努力找出答案，您可能已经仔细检查过没有尽头似的类别列表（包括协作和社会性计算、门户、企业搜索、企业内容管理、业务流程和形式、商业智能，以及开发人员平台功能），也可能比较过 Windows SharePoint Services (WSS) 3.0、Microsoft Office Search Server 2008 Express、Microsoft Office Forms Server 2007 和 Microsoft Office SharePoint Server (MOSS) 2007 提供的功能。不过，有项技术您可能从未考虑过，因为 Microsoft 没有将其列在 SharePoint 产品及技术范围内，这就是企业项目管理（Enterprise Project Management，EPM），该技术通过 Microsoft Office Project Server (MOPS) 2007 启用。

但 MOPS 2007 是 SharePoint 技术，它构建在 WSS 3.0 的基础之上，并以与 MOSS 2007 兼容的方式进行扩展。如果您希望通过任务、资源和预算管理（而不是使用 WSS 3.0 和 MOSS 2007 中包含的轻型任务管理功能）的方式提高部门内部以及各部门之间的小组协作效率，MOPS 2007 可以说是正确的选择。通过 MOPS，您可以将小组站点转变成项目工作区、管理部门内部和各部门之间的小组协作，以及为整个组织建立牢固的 EPM 基础。不过，您首先需要战胜部署挑战。

在本专栏中，我将讨论在 Windows Server 2008 环境中通过 SQL Server 2005 SP2 和 WSS 3.0 SP1 来部署 MOPS 2007。首先，我将从系统架构师的角度对 MOPS 体系结构做简短评论，说明各组件如何与 WSS 3.0 集成。了解这一信息后，将更容易进一步讨论典型部署和您可能遇到的集成挑战（例如，应用程序池配置问题、缺少访问权限、队列系统启动错误以及与 SQL Server 2005 Analysis Services 相关的问题）。

为了演示部署和故障排除步骤，我将使用一个基本的测试环境，其中包括服务器场中的两个 WSS 3.0 服务器、一台专用的域控制器以及一台单独运行 SQL Server 的计算机，这个环境类似于一直用于此 SharePoint 专栏的测试环境。您可以在 TechNet 杂志网站上本专栏的附属材料中找到相应的工作表和分步说明。

Project Server 体系结构

MOPS 2007 是最先进、最复杂的 SharePoint 应用程序之一。它充分利用了 WSS 3.0 平台进行集中式管理、站点配置、身份验证和安全性设置。另外，MOPS 2007 还添加了更多组件，例如 25 个通用和专用的 MOPS Web 部件、每个 Project Web Access (PWA) 站点有多达四个 MOPS 数据库的新集合。每个组件都通过一组 21 个公用和内部 MOPS Web 服务进行访问，这些 Web 服务联合构成 Project Server Interface (PSI)，如图 1 所示。您可以在 MSDN 上查找有关 MOPS Web 服务的详细信息。

图 1 SharePoint 与 MOPS 2007 集成（单击图像可查看大图）

MOPS 2007 体系结构依赖于分布在客户端工作站、应用程序服务器和数据库服务器间的各种组件。我会在本专栏中讨论其中最重要的组件，但如果您对所有的技术细节都感兴趣，请阅读 Project 2007 SDK 中的“Project Server 体系结构”文档。

请记住，在阅读 SDK 时，PWA Web 部件和 Microsoft Office Project Professional 2007 并不直接访问 PSI Web 服务。SDK 建议客户端直接呼叫 PSI，但大多数应用程序实际上使用 PSI Forwarder，这是 PWA 站点中的一个组件，提供对 PSI Web 服务的间接访问。只有使用系统级权限运行的基于服务器的组件（如队列服务和事件服务），才直接呼叫 PSI。在故障排除环境中记住这个小细节很重要，这是由多种原因决定的，特别是：

1. PWA 站点定义数据库的上下文（每个 PWA 站点都有独立的草稿、已发布、存档和报告数据库）和用户权限，但不会授权一般用户帐户访问 PSI Web 服务。
2. PSI Forwarder 不支持模拟，但可以使用 PWA 站点的应用程序池帐户代表用户访问 PSI Web 服务。
3. 如果服务器场包含多个应用程序服务器实例，则 PSI 呼叫并不一定需要使用本地 PSI Web 服务。

SharePoint 集成

现在，让我们深入讨论一下 MOPS 与 SharePoint 的实际集成。从 SharePoint 管理员的角度来看，MOPS 是共享的 Web 应用程序，作为服务器场服务在 SharePoint 3.0 管理中心进行管理。这对于熟悉 MOSS 2007 中的共享服务提供程序 (SSP) 的管理员来说，就相当简单了。

不过，如果您是 WSS 3.0 管理员，而且刚刚接触 SSP 管理，您应该参考一下附属材料中提供的“部署 Project Server 2007”工作表，以便了解创建和配置 SharePoint 场的共享服务和 PWA 站点的分步说明。安装和配置 MOPS 之后，您便可以在 IIS 管理器中分析系统实施。如图 2 所示，在 MOPS 应用程序服务器上会显示共享服务、SSP 管理和站点集合的各自的网站。

图 2 通过 PWA 和 PSI Forwarder 访问 Project Server 2007（单击图像可查看大图）

客户端通过 PWA 站点中的 _vti_bin/PSI 虚拟目录访问 PSI Web 服务。不过，PSI Web 服务并不在此虚拟目录中。_vti_bin/PSI 虚拟目录对应以下物理路径：%COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\ISAPI\PSI。您会发现此目录包含 web.config 文件，该文件在 <http Handlers> 部分指定对 *.asmx 文件（即基于 ASP.NET 的 Web 服务）的所有 HTTP 请求都应该传送到自定义 HTTP 处理程序，并通过 Micro soft.Office.Project.Server.PSIForwarder HandlerFactory 实例化。

该自定义 HTTP 处理程序是 PSI Forwarder。PSI Forwarder 建立对实际 PSI Web 服务的新 HTTP 连接，转发客户端的 HTTP 请求，然后将结果返回到客户端。

借助 HTTP，PSI Web 服务可通过共享服务 Web 应用程序（位于 Office Server Web 服务站点中）的 PSI 虚拟目录供 PSI Forwarder 使用。此虚拟目录将默认映射到物理路径 %PROGRAMFILES %\Microsoft Office Servers\12.0\WebServices\Shared\PSI，您可以在此处找到 MOPS 2007 *.asmx 文件。

稍后，我将详细介绍 Office Server Web 服务站点。现在，从图 2 获得的最重要的信息是，PSI Forwarder 使用 PWA 站点的 Web 应用程序池帐户标识（而不是当前访问 PWA 站点的用户）与 PSI Web 服务通信。

服务器场部署

在服务器场部署过程中，PSI Forwarder 的另一个重要作用是采用不同的 Web 前端服务器和应用程序服务器来提高系统可伸缩性和可用性。MOPS 前端服务器是 WSS 3.0 服务器，不能承载 PSI Web 服务或其他 MOPS 服务（例如，队列服务和事件服务），但可为客户端提供对 PWA 站点（包括 PSI Forwarder）的访问权限，如图 3 所示。

图 3 中小型 MOPS 2007 服务器场（单击图像可查看大图）

另一方面，应用程序服务器是装有一套完整的 MOPS 组件和服务的 WSS 3.0 服务器。应用程序服务器可以承载 PWA 站点，但通常只为前端服务器提供后端服务，并且不运行 WSS Web 应用程序服务。您可以在 MOPS 安装期间选择服务器角色。

图 3 说明了中小型服务器场的配置。根据您的组织的需求，您可以添加其他的前端服务器以增强可伸缩性，还可以添加其他应用程序服务器来提高可用性。您没必要为 MOPS 应用程序服务器配置负载平衡群集，这是因为如果服务器场中存在多个 MOPS 应用程序服务器，PSI Forwarder 会自动对 PSI 请求进行负载平衡。有关 MOPS 部署选项的详细信息，请参阅Office Project Server 2007 部署指南。

欢迎使用 IIS 7

理论到此为止！现在我们来解决您在部署 MOPS 2007 的过程中可能遇到的一些实际问题。我最喜欢的一个问题与 PWA 站点的主机命名的站点集合有关。在这种情况下，在 Project Web Access Site 页面上选择“将 Project Web Access 路径用作主机标头”复选框，随后输入完整的 PWA URL（例如，pwa），您就可以顺利部署 MOPS、配置 SSP 以及在主机标头模式中配置 PWA 站点。然后，当所有资源都配置成功后，您尝试打开站点，看到的却是标准的 IIS 7“欢迎使用”屏幕，而不是 PWA 屏幕。

如果默认网站未经过 SharePoint 扩展，而且 PWA URL 也没有其他网站具有适当的站点约定，就会发生这种情况。如果没有明确的站点约定，IIS 就会将 pwa 请求与非扩展的默认网站关联，因此，您看到的是“欢迎使用”屏幕。您可能希望 SharePoint 3.0 管理中心将必要的约定添加到您选择承载 PWA 站点的 SharePoint Web 应用程序，但情况并非如此。

若要解决此问题，您必须按附随的“故障排除 IIS 和 PWA”工作表说明的那样，使用 SharePoint 扩展默认网站，然后使用此站点集合来配置 PWA 站点。或者，您可以将 IIS 管理器中缺少的站点约定手动添加到为 PWA 选择的 Web 应用程序。别忘了在宿主 PWA 站点的所有 WSS 服务器上执行此步骤。

会话数据库权限

如果您决定扩展默认网站，请确保使用应用程序池的域帐户 — 请参阅“规划系统管理和服务帐户 (Office SharePoint Server)”，否则，在配置 PWA 站点后，您将碰到与权限有关的问题，这些问题通常会在不提供 SharePoint 错误消息的情况下显现出来，如图 4 中的出现的问题。

图 4 访问 SSP 数据库时出错（单击图像可查看大图）

若要查找更有用的信息，您应查看位于 %COMMONPROGRAMFILES %\ Microsoft Shared\Web Server Exten sions \12\LOGS 目录中的跟踪日志。如果您的服务器场包含多个负载平衡的 Web 前端服务器，这可能是项繁琐的任务。

出于进行故障排除的考虑，更改 PWA 主机名称的 DNS 记录然后将其暂时指向一部前端服务器，是个不错的办法。如此一来，您就知道是哪个服务器处理客户端请求，从而只需检查一个服务器的跟踪日志文件即可。

在记事本中打开最近的日志文件，并搜索“无法打开数据库”的条目。如果找到此条目，就可以知道您要处理数据库权限的问题。例如，图 4 中的跟踪日志说明帐户 LITWARE\WSS02$ 不具有对数据库 SharedServices1_DB 的访问权限。这很清楚地表示 PWA 站点是使用网络服务标识运行的。

LITWARE\WSS02$ 是 Web 前端服务器的计算机帐户，而 SharedServices1_DB 是共享服务提供程序数据库。除了其他用途，此 Web 前端服务器使用此数据库来在 ASPStateTempSessions 表中维持 ASP.NET 会话阶段状态数据，但是 LITWARE\WSS02$ 并不具备对该数据库的访问权限。

要特别注意的是，您必须将共享服务提供程序数据库包含在每周的数据库维护活动中，以确保稳定的系统性能。例如，您应该使用 SQL 命令 TRUNCATE TABLE ASPStateTempSessions，将过期的会话阶段状态数据从 ASPStateTempSessions 表中删除，如“ 将 Project Server 2007 部署到服务器场环境”中所述。

与网络服务相关的配置问题很容易令人困惑，所以我将仔细讨论一番。域帐户（例如 LITWARE\SspConfig Admin）适用于服务器场中的应用程序池，这是因为它们在所有计算机上完全一样。而网络服务帐户 (NT AUTHORITY\ NETWORK SERVICE) 在每台计算机上都不一样。在名为 wss02.litware.com 的前端服务器上，NT AUTHORITY\NETWORK SERVICE 帐户会转换成 LITWARE\WSS02$。但在名为 sql01.litware.com 的服务器上，NT AUTHORITY\ NETWORK SERVICE 帐户则是指 LITWARE\SQL01$。问题就出在这里。

如果在 SQL Server Management Studio 中检查 SharedServices1_DB 的 SQL Server 权限，您可以看到 NT AUTHORITY\NETWORK SERVICE 帐户具有 db_owner 权限，并尝试授权使用网络服务帐户的应用程序池访问共享服务提供程序数据库。但请记住，这只在单一服务器的安装环境中奏效。

您可以明确地授与 LITWARE\WSS02$ 及其他所有 WSS 服务器帐户（可能是 LITWARE\WSS01$ 等）SharedServices1_DB 的 db_owner 权限，但改用应用程序池的域帐户更妥当，因为这样一来，所有前端服务器都将使用 SharePoint 已授与其必要数据库权限的相同标识。

共享服务权限

如果您的 PWA 站点的应用程序池因某种原因使用网络服务帐户，您还会碰到与 SSP 相关的权限问题。还记得我曾提到在 PWA 站点应用程序池帐户的上下文中，PSI Forwarder 可能代表用户访问 PSI Web 服务吗？如果此帐户不具备访问 Office Server Web 服务站点的权限，您会再次收到常见的 SharePoint 错误消息。这次，前端服务器上的跟踪日志会指出“请求失败，HTTP 状态 401: 未经授权”，如图 5 所示。

图 5 请求失败，HTTP 状态 401: 未经授权（单击图像可查看大图）

请记住，此错误并不是指 PWA 中的用户权限。在 PWA 站点中授与的 SharePoint 权限确定了哪些用户可以访问该站点的 _vti_bin/PSI 虚拟子目录，但这些用户并不会获得对共享服务 Web 应用程序或该应用程序服务器上的 PSI Web 服务的访问权限。

即使您是 PWA 站点集合管理员，如果 PWA 站点的应用程序池帐户不具备对 PSI Web 服务的访问权限，MOPS 也依然会失败。如果您忽略对服务器场中的应用程序池使用域帐户的建议，而改用网络服务帐户，情况更是如此。

若要验证应用程序服务器上的 SSP 访问权限，可在 Office Server Web 服务站点的根目录中（默认为 %PROGRAMFILES%\ Microsoft Office Servers\12.0\Web Services\Root）查看 web.config 文件。您可能会注意到 <authorization> 部分中的 NT AUTHORITY\NETWORK SERVICE 条目，它应该用于授权使用网络服务帐户的应用程序池。但是，此条目还是无法完成该任务，因为它只参考本地计算机，而本地计算机并不是前端服务器。

最佳策略是更改应用程序池配置，并使用域帐户。但若坚持使用网络服务帐户，您必须明确授权前端服务器帐户。

请勿直接编辑应用程序服务器上的 web.config 文件，否则 SharePoint 会覆盖您的更改。请改用 SharePoint 3.0 管理中心来授与缺少的权限，如“测试共享服务提供程序访问权限”工作表所述。另外，还需验证配置，方法是使用简单的 ASP.NET 应用程序来建立与 PSI Web 服务的直接 HTTP 连接，例如 SSPCheck（包含于附属材料中）。请确保您在 PWA 站点的应用程序池下运行 ASP.NET 测试应用程序，以获取可靠的结果。

Windows 防火墙

到目前为止，打开 PWA 应该不成问题 — 当然啦，除非您尝试通过 Web 前端服务器访问 PWA，而 MOPS 应用程序服务器上的 Windows 防火墙阻止了 TCP 端口 56737 和 56738。这些是分配给 Office Server Web 服务站点用于 HTTP 和 HTTPS 通信的默认端口。

当创建 Office Server Web 服务站点时，SharePoint 并不会在 MOPS 应用程序服务器上自动打开这些端口。如果您在应用程序服务器上启动了 Windows 防火墙，则必须手动创建防火墙规则，以允许这些端口的数据传输，使前端服务器能够访问 PSI Web 服务。如果防火墙阻止了这些端口，您会收到图 6 中显示的错误消息，同时前端服务器上的跟踪日志将指出“连接的主机未能响应”。

图 6 Project Web Access 无法连接到 Project Server（单击图像可查看大图）

MOPS 服务和服务帐户

解决了前端/后端通信问题后，您就应该能够访问 Project Web Access 了。可喜可贺！现在是时候把重点放在更困难的特定于 MOPS 的问题上了。深吸一口气，然后打开您的 MOPS 应用程序服务器上的应用程序事件日志，如果您看到成千上万条错误消息指出“无法启动队列系统”（如图 7 所示），千万别惊讶。您还可能注意到 MOPS 服务导致 CPU 使用率几乎为 100%。

图 7 无法启动队列系统（单击图像可查看大图）

队列系统是 MOPS 应用程序基础结构的主干，用于 MOPS 数据库的插入和更新请求，以便处理、运行清理和维护任务，它还可以更新用于数据分析任务的报表数据库。这在“Microsoft Office Project Server 2007 队列系统”一文中有详细介绍。根据本文，此队列系统依靠 Windows 服务，在程序集 Microsoft.Office.Project.Server.Queuing.exe 中实现，并且在 SharePoint 配置管理和计时器服务帐户的标识下运行，以访问服务器场的配置数据库。

启动时，Windows 服务将检索配置数据库的所有 SSP 的列表，包括相应的 SSP 管理员帐户及其加密密码，然后在相应的 SSP 管理员帐户的上下文中，针对与 PWA 站点相关的每个 SSP 启动额外的 Microsoft.Office.Project.Server.Queuing.exe 进程。换句话说，Microsoft.Office.Project.Server.Queuing.exe 在不同的帐户下启用自身的多个实例，因此，在 MOPS 应用程序服务器上运行的 Microsoft.Office.Project.Server.Queuing.exe 进程总数等于 SSP 的数量与一之和。

额外的进程实例是队列工作进程。每个单独的队列工作进程都将从与它相关联的 SSP 确定自己的一组 PWA 站点、为每个 PWA 站点启动不同的轮询线程，以及开始处理排队等候在相应 PWA 站点数据库的任务。这正是队列系统的工作方式，您可以在 Windows 任务管理器中就此进行验证。

在服务器场的 MOPS 应用程序服务器上，若有一个 SSP 与 PWA 站点相关联，则会出现两个 Microsoft.Office.Project.Server.Queuing.exe 进程 — 一个以配置管理帐户的身份运行，另一个则以 SSP 管理员帐户的身份运行。在我的测试环境中，这些帐户是 WssConfigAdmin 和 SspConfig Admin，如图 8 所示。

图 8 进程间通讯因访问被拒绝而失败（单击图像可查看大图）

为什么无法启动队列系统？应用程序事件日志中的错误条目提供的信息不足，但是，如果您在 SharePoint 3.0 管理中心中的“操作”选项卡上的“诊断日志记录”下，暂时将最低级别事件设置为所有类别的跟踪日志报告，即可获得更多详细信息。

图 8 显示了最终的跟踪日志，如果您仔细查看，会看到 ProjectQueueService（整体 Window 服务）启动了 QueueExecService（队列工作进程），但 QueueExecService 进程因访问被拒绝而失败。因为 QueueExecService 失败，ProjectQueueService 便尝试重新启动它，但是又因相同的原因再次失败，所以它继续耗用 CPU 周期，以上千个错误填充事件并跟踪日志，像个无尽的循环。

可惜的是，即使是最详尽的跟踪日志也不会揭示访问被拒错误的特定原因。但是别泄气，通过排除，您就可以迅速地找出根本原因。

如果您在 SharePoint 3.0 管理中心中更改 SSP 管理员帐户，并且指定配置管理帐户 (WssConfigAdmin)，队列系统便会启动。反过来做也奏效，只要将 SSP 管理员帐户 (SspConfigAdmin) 保持不变，然后将它用作 Windows 服务的服务帐户，队列系统也会启动。

随后，配置管理帐户和 SSP 管理员帐户就都具备了所有必要的权限，队列系统只在 Project QueueService 和 QueueExecService 使用不同的帐户时才不会启动。

这很清楚地指出了要在本地计算机上彼此交互的不同进程之间存在权限问题。毕竟，ProjectQueueService 和 QueueExecService 进程都必须彼此监控，才能确保服务行为的一致性（注意图 8 的跟踪日志中的 ProcessWatcher 条目）。例如，当您关闭 ProjectQueueService Windows 服务时，所有 QueueExecService 工作进程也必须随之关闭。

之所以会产生错误，是因为尝试访问在不同的安全性上下文中运行的进程。访问另一个安全性上下文中的进程需要提升的权限。即使服务帐户可能具有这些权限，但 Windows Server 2008 仍会拒绝访问，这是因为系统会默认启用用户帐户控制 (UAC)，而这会导致进程以标准权限运行。

只要您禁用 UAC，ProjectQueueService 和 QueueExecService 进程便可以使用提升的权限运行，而且队列系统也将启动。是使用配置管理帐户作为所有 SSP 的管理员帐户，进而以相同的帐户来运行所有队列进程，还是通过禁用 UAC 来减弱 MOPS 应用程序服务器上的安全性，都由您选择。

Analysis Services 集成

如果您按照“将 SQL Server 2005 Analysis Services 与 Project Server 2007 多维数据集生成服务配合使用的要求”（发表日期为 2007-04-05）中的说明操作，可能会碰到 SQL Server 2005 Analysis Services 问题，就让我们就此为本专栏下结语。如果您按照说明中的方法，通过创建 SQL Server 2005 数据库来创建 Analysis Services 存储库，当尝试在 PWA 中生成多维数据集时，最后可能会收到图 9 中所示的错误。

图 9 由于不正确的 Analysis Services 配置而产生多维数据集生成错误（单击图像可查看大图）

重点是，MOPS 2007 是针对 SQL Server 2000 Analysis Services 而设计的。SQL Server 2005 Analysis Services 需要其他配置步骤才能实现向后兼容性。SQL Server 2000 版本将关于多维数据集生成的存储库信息存储在 Microsoft Jet 数据库中，虽然您可以迁移 Jet 数据库以与 SQL Server 2005 搭配使用，但在全新的 MOPS 部署中没必要这么做。

我刚刚提到的 TechNet 文章介绍了如何配置 SQL Server 2005 来模拟 Jet 数据库的功能（无论 Jet 数据库是否真的存在）。但该文却没有提到，无论是将 Analysis Services 配置为使用 Jet 数据库（旧方法），还是使用预先配置的 SQL Server 2005 数据库（首选方法），MOPS 仍会在数据库服务器上检查 .dso 文件共享中的存储库锁定信息。

除非此文件共享确实存在，并且 SSP 管理员帐户对此文件共享具备完全控制访问权，否则，多维数据集生成将失败，并显示图 9 所示的权限错误。为了使 SQL Server 2005 Analysis Services 与 MOPS 多维数据集生成服务正常运行，请遵循“配置多维数据”集随附工作表中所述的步骤。

结论

MOPS 2007 并不容易部署，它的体系结构复杂，而且成功部署涉及到许多步骤，其中包括从正确规划服务器场配置、在应用程序服务器和 Web 前端服务器上安装二元文件和运行 SharePoint 产品和技术配置向导，到在 SharePoint 3.0 管理中心内配置应用程序池、共享服务、SSP 管理站点和 PWA 站点，最后到在 SQL Server Management Studio 中安装 Analysis Services 等。

使部署更具挑战性的是 Windows Server 2008 干扰安全性功能，例如 Windows 防火墙和 UAC、SharePoint 管理工具中的漏洞，以及 MOPS 部署文档的疏漏。您不能单靠 SharePoint 3.0 管理中心来警告您应用程序池是否在服务器场中使用网络服务帐户、是否自动应用所有必要的配置更改（例如 IIS 站点绑定和 Windows 防火墙规则），或是检查已配置的 PWA 站点的操作状态。

另外，也别期望一切都有现成的可用。请确保您充分了解 MOPS 体系结构和依赖项，遵守产品建议，并且通过创建测试项目计划和资源，彻底验证 MOPS 配置和功能，以确保部署成功。

尽管有这些挑战，MOPS 仍然继承了作为企业平台的 SharePoint 的强大功能。借助 SharePoint 和 Web 服务技术，MOPS 使得客户端工作站上不再需要进行直接的数据库连接。通过队列系统，MOPS 提高了高峰期的持续性（所有项目经理都希望在星期一早上更新他们的项目，原因无法解释清楚），而通过其他 MOSS 技术，将 MOPS 与更多行业应用程序集成也是可行的。

自过去为 Project Server 2003 开发业务解决方案以来，我发现，与以往的可伸缩性问题、以前因缓慢的网络连接而产生的 ODBC 连接问题，以及构建包含许多 JOIN 语句（多到我必须使用 Excel 跟踪记录所有子查询）的数据库查询比起来，MOPS 2007 部署挑战简直是小巫见大巫。MOPS 2007 是 EPM 解决方案中的重要里程碑，值得花功夫去部署。

Pav Cherny 是一位 IT 专家兼撰稿人，专门研究 Microsoft 协作与统一通信技术。其著述包括白皮书、产品手册和书籍，这些著述主要讨论 IT 运营和系统管理。同时，Pav 是 Biblioso Corporation 的总裁，该公司主要经营托管文档和本地化服务。

原文 | 来源：微软TechNet中文站