第3章 部署规划

如果没有事先进行规划便实施部署，那么可能会无意中导致内在的设计问题，从而引发代价高昂的停机事件，并可能使用户认为系统不可靠。此外，如果没有进行正确的规划，那么组织用于制定预算和财务决策的清单最终可能是无效的。

成功实施SMS需要进行详细的规划。非常重要的一点是：我们需要了解规划过程。当正确准备好项目规划后，我们的SMS部署就可能和执行计划一样简单。因此，我们必须对规划阶段分配适当的资源，必须在部署SMS之前全面研究、记录和测试的同时对之前的规划进行概念性验证。正确的规划能够帮助我们确保最大的投资回报，因此我们不应该草率地实施SMS 2003这样的管理解决方案。

定义和实施SMS站点结构可能非常困难，除非我们首先就考虑了SMS客户端的要求并做出适当的规划。新安装的SMS 2003的规划要求与升级现有的SMS 2.0安装的规划要求略有不同。因此，建议在尝试部署SMS站点之前，首先进行适当的规划。

本章讨论了以下几个方面的规划：

Active Directory规划

安全规划

客户端规划

站点层次规划

备份和恢复规划

数据库规划

SMS服务器容量规划

在决定是否部署以及如何部署SMS 2003之前，请参考本书中概述的前期规划步骤。在前期规划阶段，我们将收集有关站点的信息，来帮助我们识别组织的管理需求，决定我们的企业、服务器和网络是否满足SMS 2003安装要求。

3.1 规划考虑

不同于Microsoft Word或Microsoft Excel，这类产品安装后就可以开始使用。SMS 2003包含了大量的服务和组件，是一个很复杂的产品。该产品包含的许多功能和往往要求执行很多前期的操作。

3.1.1 企业组织结构

正如在管理网络前需要对网络结构有一个深入的了解一样。在部署SMS前，我们也要对企业的组织结构进行一个完整的了解。在这部分工作中，我们需要了解企业的地理分布、逻辑结构、现有的服务器和客户端环境等。因此我们应该准备好回答下列这些问题：

打算部署的SMS站点在地理上是如何划分的？

办公室和SMS站点在物理上都处于什么位置？

企业的组织结构是怎样的？

企业的管理结构是怎样的？

目前的Active Directory域和组织单位结构是怎样的？

需要考虑什么长期因素？

毋庸置疑，明确这些问题将有助于我们设计企业内部的SMS层次结构，尤其是对最终的结果产生重大的影响。另外，和网络基础设施类似，我们必须能更好地判断出需要在实施SMS站点之前解决什么问题。

3.1.2 网络拓扑结构

首先，我们需要对网络基础架构有一个了解（网络边界、层次结构以及连通性），我们应该清楚下列问题的答案。

网络结构：企业的网络是否是一个大的局域网，或者是由路由器和远程连结组成的广域网。这些信息将决定站点和站点系统的位置。

网络协议：SMS 2003需要使用IP协议。

子网：是否可以通过子网判断出不同的部门、地区，或者其他组织关系？SMS 2003需要根据IP地址或Active Directory站点边界分配客户端。

网络基础设施：SMS 2003将充分利用良好维护和优化的网络，但如果网络条件不好也将影响到其使用效果。例如，如果计算机统一连接了100 Mbps交换机，但安装了10 Mbps的网卡，那么SMS的处理速度也就只能是10 Mbps；但如果安装了100 Mbps的网卡，SMS的处理速度将达到100 Mbps。另一个例子，如果网络的路由不是很好，从客户端收集的数据可能会需要更长的时间才能发送到SMS站点数据库。

域模型：严格来说，虽然Windows NT/2000域模型通常会受到网络基础架构的影响，而Windows NT/2000域模型将影响到我们对SMS站点层次结构的设计。如果Windows NT/2000域的结构无法满足高效或快速的要求，那么最好在部署SMS之前首先重新考虑调整网络基础架构。

Active Directory：SMS 2003可以利用对活动目录对象的使用，例如可以发现在Active Directory注册的服务器、计算机、用户和组账户对象。

是否具有Active Directory站点：如果有Active Directory站点，到底有多少个站点？我们的规划又该包含多少个SMS站点层次结构才能反映Active Directory站点？

一旦对网络基础架构有了清楚的了解，我们就可以更好地利用网络基础架构的能力，并能扬长避短。另外，在正式实施之前，最好考虑清楚是否要对基础架构进行相关的调整。

3.1.3 服务器环境

在部署之前，我们还必须清楚目前的服务器环境如何，以及这样的环境是否可以支持SMS站点。这时候需要考虑下列问题：

有多少台服务器，分别位于什么位置？

打算使用SMS管理企业中的哪些计算机（例如：桌面计算机，笔记本电脑，移动设备等）？

这些服务器由谁负责管理，分别负责什么内容？

这些管理人员是否需要承担SMS服务器的管理工作？

这些服务器的硬件和操作系统情况如何？分别具有怎样的磁盘空间、CPU速度、操作系统版本？

这些现有的服务器是否需要任何升级？虽然SMS 2003支持Windows NT域架构，不过却只能安装在运行Windows 2000 SP2以上或Windows Server 2003的域环境中。

这些服务器分别被分配了什么角色或起到了什么样的作用，例如DHCP、DNS、IIS、WINS、终端服务、群集，那么企业中的域控制器又是哪个呢？

这些服务器目前的使用情况如何？在今后的三到五年内，它们在资源分配上会有怎样的变化？

是否需要使用系统监视器之类的工具检测服务器的资源使用情况？

如果需要通过SMS 2003的高级安全特性管理移动设备（例如，笔记本电脑）客户端，网络是否运行在Active Directory纯模式下？如果没有，是否可以进行升级？

了解和提供这些关于服务器的数据有助于判断SMS服务器的位置，并且可以判断是否需要在升级或新的设备方面进行投资。

3.1.4 客户端环境

和服务器信息同样重要的还有客户端环境，我们应该明确下列这些问题的答案：

企业中有多少计算机？有多少希望通过SMS管理？

目前谁负责管理这些客户端，具体的管理任务是什么？这些管理人员是否需要负责SMS客户端的管理？

这些计算机上都运行了什么操作系统？Service Pack的安装情况如何？硬件是否可以满足SMS的要求？都安装了哪些主要应用程序？以后是否会有新增的应用程序？

有多少客户端是“可移动”的？例如，笔记本电脑，这些移动客户端如何连接到网络？

3.2 Active Directory规划

和老版本相比，SMS 2003中一个重大的改进在于与Active Directory服务的集成更加紧密。SMS 2003可以充分利用Active Directory的安全、基础架构，配置和发布属性。但是这也意味着我们的Active Directory服务必须处于良好的健康状态下，这些需要在开始部署SMS 2003前就考虑好。

Active Directory站点与SMS的站点有所不同。Active Directory站点在本质上实际就是通过子网定义，连接良好的网络。简单的网络环境可能只有一个唯一的Active Directory站点；而复杂的环境中则可能存在多个Active Directory站点。

SMS 2003可以使用Active Directory站点的名称或子网确定SMS站点的边界。在最理想的情况下，我们可以直接使用Active Directory站点名称，因为这样可以保证管理员在维护Active Directory站点、子网、SMS站点之间的关系时有章可循。客户端可以根据自己的IP子网或Active Directory站点名称分配到不同的SMS站点，SMS 2003站点将根据客户端的IP地址和Active Directory站点信息决定客户端的分配情况。

注意：在很多企业中，Active Directory站点仍然会使用安装时的默认名称，这样的名称完全无法提供足够的信息。如果对于Active Directory架构有任何问题，建议首先向专业人员了解清楚再进行规划。

3.2.1 活动目录健康检查

在部署之前我们需要对企业内部的Active Directory进行健康检查，微软公司为我们提供了一些用于检查Active Directory服务健康程度的小工具：DCDiag、NetDiag，以及ReplMon。这些工具都可以在微软公司网站上免费下载，但在下载时请注意选择正确的版本。

3.2.2 活动目录计算机账户清理

除了Active Directory的健康程度外，经常容易被忽略的是计算机账户的健康程度。很多企业并没有关于禁用或删除无用账户的制度。这种现象很不好，因为这样做很容易导致一些隐藏的安全问题。一旦某些计算机因为某种原因退出了Active Directory，就应该采取适当的措施将该计算机在Active Directory中的所有信息都清理干净。

当然这个操作可以通过多种方式完成。在企业中，有些管理员可能会将要删除的计算机账户禁用，然后移动到一个专门的OU中，并定期删除该OU中的所有内容。而有些管理员可能只禁用计算机账户，但并不将其删除。有些企业则是直接从Active Directory中将不需要的计算机账户删除。

从表面来看，计算机账户的清理工作似乎并不是个严重的问题。然而，如果开始使用SMS 2003，并使用SMS 2003的Active Directory站点发现功能发现客户端，如果不注意这个问题，就会遇到很严重的后果。因为这种发现方法会将失效的计算机账户视为活动的计算机，因此在推送高级客户端之前，建议首先进行清理工作。

3.3 客户端规划

3.3.1 确定客户端类型

对于分层结构中的每个站点，我们应谨慎考虑要部署哪类SMS 2003客户端（高级客户端或者旧客户端）。

部署高级客户端对于管理员来说往往更容易，而且这也是SMS客户端软件未来的发展方向。因此强烈建议把高级客户端视为首选客户端，安装到所有运行Windows 2000或更高版本Windows系统的计算机上，以便利用高级客户端在这些平台上提供增强的安全性和其他收益。

为了帮助我们确定需要部署哪类客户端，我们应仔细查看这两种客户端之间的区别。虽然这两种客户端在特性上几乎一样，但还是有细微的差别。

当选择部署哪类客户端时的其他考虑事项包括：

对于在SMS中部署和支持两种不同的客户端的准备情况，以及是否有必要只部署一种类型的客户端。

企业对于移动式计算机支持的需求如何。如果需要提供在SMS站点之间进行漫游的功能，那么就只能使用高级客户端。

SMS客户端部署的准备情况如何。如果拥有客户端系统模板镜像，或类似的计算机操作系统部署机制，那么应计划更新参考镜像以包括高级客户端。同样，如果要从不同站点的Windows共享文件夹中部署系统镜像，则需要计划利用适合的SMS客户端软件更新这些共享文件夹。

客户端是否满足高级客户端的安装的最低要求？只有在客户端运行受支持的操作系统，并且管理点经过正确的设置，而且已经满足SMS安全性要求后才能迁移到高级客户端。

3.3.2 客户端发现规划

在经过上述操作后，还需要考虑要为SMS站点启用哪些客户端代理和客户端代理设置。客户端代理设置通常是针对具体站点的，适用于站点内的所有客户端。通过了解需要给哪些客户端应用哪些客户端代理，以及客户端代理设置，可以帮助我们决定可能需要部署的SMS站点的数量。

这时候可以使用部署规划工具中的客户端代理设置规划表，帮助我们确认需要为SMS站点中的客户端启用哪些客户端代理和客户端代理设置。如果在站点中有一组客户端需要单独的设置，则可以把它们指定到不同的站点或部署站点中，以便专门管理这些客户端。客户端代理设置规划表可以帮助我们确定客户端是否需要单独进行设置。

3.3.3 自动发现资源

SMS中会自动生成一些发现任务，不过我们不能对其进行调整。这些自动生成的任务包括：

SMS站点系统发现

检测信号发现

SMS在硬件清单期间执行的发现

SMS站点系统和站点服务器会被自动发现。站点系统发现功能会提供有关站点系统的发现数据，如果启用和配置了客户端推送安装方法并在服务器上安装SMS客户端，该功能还可以将站点系统作为SMS客户端进行安装。因为这种发现方法是完全自动的，所以我们不能对其进行配置，也不能将其禁用，甚至无法在SMS管理控制台中看到它。

注意：SMS的恢复站点系统是一个基于Web站点的应用程序而不是站点系统，因此不能通过站点系统发现功能进行发现。我们必须使用其他发现方法来发现SMS系统还原Web站点的计算机。

检测信号发现则是用于刷新SMS站点数据库中的SMS客户端计算机发现数据的一种方法。如果启用该功能，则发现数据会根据我们定义的时间计划进行刷新；如果禁用该功能，则只有当其他发现方法被调用，或按计划运行发现功能的时候，发现数据才会被刷新。检测信号发现对于维护客户端（通常不受其他发现方法的影响，如用户很少登录的服务器）上的当前发现数据非常有用，默认情况下检测信号发现功能是起用的。

重要须知：我们可以对检测信号发现设置计划，从而客户端会定期在某个特定时间报告其发现的数据。但应避免在大型站点，或同时在多个站点上进行此项设置，否则可能会产生大量待处理的累积DDR。当检测信号发现在所有客户端上同时运行时，网络和SMS服务器可能会承担巨大负载。

此外，如果SMS硬件或软件清单在接到有关计算机的DDR之前将该计算机的详细信息上传到SMS站点数据库中，SMS会使用清单中包括的详细信息为该计算机自动创建DDR记录。因为这种发现方法是全自动的，我们不能对其进行配置和禁用，也无法在SMS管理控制台中看到它。

3.3.4 发现域用户和组

如果希望发现在域中的域用户账户和用户组，则应计划启用Windows用户账户发现和Windows用户组发现方法。通过发现的这些信息，我们可以将域用户和用户组添加到SMS集合中。

另外我们还可以把Windows用户账户发现与Windows NT域或混合模式的Active Directory域一起使用。然而，Active Directory用户发现功能可以从Active Directory域返回更多信息，而且当我们把这些域切换到本地模式时，还可以继续与这些域一起使用。因此我们只需要把Windows用户账户发现方法与Windows NT 4.0域一起使用。

SMS必须能访问我们为Windows用户账户发现或Windows用户组发现方法指定的域。这将取决于SMS运行的安全模式，我们可以使用SMS服务账户或SMS站点服务器的计算机账户来指定这些域。

Windows用户组发现方法对于为软件分发创建的基于用户组的集合非常有用。例如，如果希望根据用户组分发软件，那么我们就可以使用这种发现方法确定哪些组在域中。比如我们的Active Directory中有一个“架构师”用户组，我们就可以发现该组，然后把这些员工需要的软件播发给包含该组的集合。

重要须知：为了发现域中的Windows用户账户或组资源，我们必须为SMS提供访问每个指定站点的管理权限和许可。通过向目标域授予SMS服务账户（如果站点处于标准安全模式）或站点服务器计算机账户（如果站点处于高级安全模式）管理权限和许可，就可以实现这一目的。

不同的SMS站点可以在相同域或不同域中发现用户账户。如果要求用户资源来自站点和其子站点的域中，则只应该在子站点上启用Windows用户账户发现。子站点会将发现数据自动转发到父站点，从而两个站点都可以发现相同的用户。

另外我们还可以制订一个计划，规定SMS每隔多长时间轮询一次用户账户或用户组发现。每次SMS轮询用户账户或用户组发现时，账户的发现数据都会被刷新。因此请根据实际需要决定希望每隔多长时间这些发现方法将对各个域轮询一次，并为每个域中的所有用户账户生成新的DDR记录。随着账户在域中的添加和删除，用户和用户组账户列表可能逐渐变得不准确，所以我们应该制订一个良好的计划，以使列表尽可能保持最新。

3.3.5 发现可IP寻址的资源

如果希望找到网络上所有可IP寻址的设备，那么就可以使用网络发现方法。通过使用网络发现方法搜索特定子网、域、SNMP设备和Windows NT或Windows 2000 DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）服务器，就可以找到所需的资源。网络发现方法还可以使用SNMP发现由路由器，并进行资源验证操作。我们可以为此功能指定SNMP列表和跃点数。

SMS站点服务器必须在DHCP服务器上拥有用户级安全访问权限，只有这样才能从这些服务器上检索数据库信息。另外SMS服务账户必须在与DHCP服务器相同的域中拥有域用户凭据。

我们可以使用网络发现方法收集资源发现数据，从而可以使用SMS客户端推送安装。根据我们希望提供的所发现的资源信息量，以及我们希望网络发现运行的时间，在启用网络发现方法之前，请首先规划需要如何配置网络发现选项。

对于需要的发现类型，我们可以从下列三个详细级别中选择：

拓扑结构

拓扑结构和客户端

拓扑结构和客户端以及客户端操作系统

注意：如果选择“拓扑结构和客户端以及客户端操作系统”详细信息，如果发现的资源运行了Windows 98或Windows Millennium Edition操作系统，则只有当计算机被配置为启用共享资源时，网络发现方法才可以发现这样的客户端操作系统。

网络发现会根据我们在SMS管理控制台中定义的计划运行，我们必须在准备为整个企业网络使用网络发现时确定网络发现功能的运行计划，并配置其范围。在启用网络发现时一定要非常小心，使用网络发现功能会大量增加网络上的通信流量，因此我们应该合理安排网络发现的运行计划，使其不会干扰网络的正常使用。如果计划在低速网络连接上运行网络发现，那么在配置网络发现选项时，我们需要充分考虑网络速度和可用带宽情况。

3.3.6 发现Active Directory对象

Active Directory发现方法会轮询最接近的Active Directory域控制器，以发现Active Directory计算机、用户、用户组和容器。如果要使用Active Directory发现方法，那么Active Directory可以是混合模式或本地模式，同时我们还需要指定希望轮询的容器，例如特定域、站点、组织单位或用户组。另外，还需要定义轮询时间计划。

当SMS启用了Active Directory发现方法后，SMS会根据轮询周期向Active Directory进行查询，从Active Directory获取的SMS资源可能无法在所有时间都能反映当前的Active Directory资源，因为自从上一次轮询后，Active Directory中的对象可能已经被重新添加、删除或修改过。

SMS必须能够有权限访问我们为Active Directory系统发现、Active Directory用户发现或Active Directory系统组发现功能指定的容器，我们可以使用SMS服务账户或站点服务器计算机账户来指定容器，这主要取决于SMS所运行的安全模式。当这些发现方法在域中（不包括站点服务器所在的域）使用SMS服务账户或站点服务器计算机账户时，账户必须拥有在这些域上的域用户凭据，同时账户必须至少是这些域上的用户组或本地用户组的成员。

3.3.7 Active Directory用户发现

通过使用Active Directory用户发现方法，我们可以发现：

用户名

唯一的用户名（包括域名）

Active Directory域

Active Directory容器名

用户组（不包括空组）

我们只能在主站点上运行Active Directory用户发现，如果需要在只有辅助站点的域中发现用户或组，则可以配置辅助站点的父主站点来发现这些域。

通过使用Active Directory用户发现方法可以发现我们希望分类到SMS集合中的账户。例如，如果希望将软件分发给用户集合，就可以使用这个发现方法确定哪些用户在Active Directory域中。如果网络中包含我们希望向其分发特定软件包的用户，那么我们就可以发现这些用户账户，并创建一个包含这些账户的集合，随后我们可以将软件包只播发给该集合，从而只有适合的用户才会安装。

Active Directory用户发现方法执行的轮询会产生较大的网络流量，不过该方法产生流量要小于Active Directory系统发现。因此我们可以安排计划，将发现时间放到网络空闲的时段，以免影响正常的网络使用。

另外，虽然SMS会根据轮询周期向Active Directory进行查询，但从Active Directory获取的所有SMS资源并不一定能够反映所有时间内的Active Directory资源。因为在最后一次轮询后，Active Directory中的资源可能已经被添加、删除或修改过。

3.3.8 Active Directory系统发现

通过使用Active Directory系统发现方法，我们可以发现：

计算机名称

Active Directory容器名称

IP地址

特定的Active Directory站点

在这里可以不使用Active Directory系统发现方法发现客户端操作系统，因为我们可以使用其他发现方法（例如网络发现）完成此项任务。

Active Directory系统发现方法执行的轮询可能产生较大的网络流量（每台客户端计算机大约5 KB），因此请通过计划将发现时间安排到网络空闲时间。

此外，因为SMS将通过轮询计划向Active Directory进行查询但不接收Active Directory变更报告信息，因此从Active Directory获取的SMS可能并不能反映最新的Active Directory资源。因为从上一次轮询到现在，Active Directory中的计算机可能已经被添加、删除或修改过。

注意：在只有一个Active Directory站点的Active Directory森林中，SMS中的Active Directory系统发现方法将无法从域控制器上获得子网信息。这是因为操作系统中存在了一个限制，不过Windows Server 2003不存在这个问题，只有Windows 2000才存在。在Windows 2000的这种环境下，要想获得子网信息，我们必须创建另一个Active Directory站点，并为其指定子网。

3.3.9 Active Directory系统组发现

Active Directory系统组发现方法是其他发现方法的增强，通过使用Active Directory系统组发现方法，我们可以发现：

组织单元

全局组

通用组

嵌套组

非安全组

我们可以只在主站点上运行Active Directory系统组发现，并通过轮询周期向Active Directory进行查询，来了解在其数据库中的所有系统资源，甚至包括在子站点（以及辅助站点）中发现的资源。因为Active Directory系统组发现方法不直接涉及计算机，因此客户端计算机不必打开就可以被发现。

Active Directory系统组发现方法执行的轮询可能产生较大的网络流量，因此我们应该将发现时间安排到网络空闲时。

3.3.10 使用脚本进行发现

我们还可以使用脚本在网络登录期间发现客户端。使用脚本发现对于希望完全控制发现过程的SMS管理员非常有用。如果在我们的SMS测试环境中包括各种各样的计算机，但我们不希望发现太多计算机，也不希望把大部分时间都浪费在发现计算机上，那么就可以使用脚本发现。

脚本发现也适用于当我们有特殊报告需求的情况下。例如，我们可以为计算机租赁协议创建DDR，然后生成报告，其中就可以为租赁细节提供SMS收集的详细的计算机信息。

3.3.11 网络发现

我们可以通过逐步启动和配置网络发现方法选项的方式控制网络发现方法发现资源的速度。例如，如果将网络发现配置为搜索特定IP子网以发现资源，就可以通过每次运行网络发现时只向配置中添加一个子网的方式控制发现。随后还需要监视对每个子网的网络发现后对网络的影响，如果负载没有过量，则可以更快地添加其他子网。通过类似的控制方式，每次只添加一个子网，可以有效避免网络负载过大。

如果想让网络发现在特定时间运行（包括使网络发现以特定时间间隔运行的循环模式），我们可以制订多个计划。新的计划和计划变更一旦被写入到SMS站点控制文件，就会立刻生效。当我们在主站点服务器上运行网络发现时，在写入站点控制文件后会有一个大约1分钟的短暂延迟。如果是从父站点为子站点配置网络发现，延迟时间可能会更长，这是因为对子站点控制文件的更新取决于对子站点地址的站点间通信计划。

如果向站点控制文件写入数据时已经过了轮询的时间，那么第一次网络发现操作并不会立刻开始，而是会等到下一个轮询时间。例如，如果将网络发现设置为每周一下午5:00运行，但是这个计划直到周一下午5:01才被写入站点控制文件，那么网络发现会到下个周一的下午5:00才开始运行。为了尽快启动网络发现，我们应在预定的启动时间之前留出充足的时间，以便将计划写入站点控制文件中。

3.3.12 检测信号发现

鉴于检测信号发现与客户端刷新周期的交互，我们无法准确控制创建检测信号发现DDR记录的时间。然而我们可以控制在特定时间内（如一周或一个月）创建这些内容的频率。

对于所列出的其他发现方法，我们还可以控制它们运行的时间或日期。通过把这些方法设置为在网络空闲时间执行，我们可以确保这些方法不会对服务器或网络带宽产生太大影响。

重要须知：如果将发现方法计划改为以较高频率运行，发现方法可能会立即运行。例如，如果发现方法最初被设置为按周运行，而我们将其改成按天运行，那么这个方法可能会在我们做出改变之后立即运行，即便其被配置为在午夜运行。这是因为从上次发现方法运行到此时，时间已经超过了一天。

3.3.13 控制客户端发现和客户端安装

当我们在大型SMS站点环境中自动安装SMS客户端时，很多计算机会在短时间（如一个小时或两个小时）内同时尝试安装客户端。这种情况下，我们的网络和SMS站点系统都将承受巨大的负载，导致对网络使用和客户端计算机产生不利影响。为此，我们应该小心控制在大型站点上进行的SMS客户端的安装。

注意：当启用SMS软件或硬件清单后，默认情况下会在安装客户端当天的午夜调用清单。SMS会默认安排这些计算机在7天后处理另一个清单。通过将客户端安装的时间交叉安排在一个较长的时间段内，我们将可以充分利用网络带宽，因为收集和报告有关后继清单编制日期的清单信息的各客户端也将被安排交叉进行。

要想评估SMS客户端部署是否会对站点产生不利影响，可以将潜在客户端的数量乘以SMS客户端软件的大小（以MB为单位），然后将结果除以安装客户端所用的时间（以秒为单位）。假定客户端安装请求在这段时间内平均分布，我们可以将结果数字与网络中最慢的连接速度作比较。如果结果显示网络流量太多，例如已经超过了25%，那么我们就必须限制客户端的安装。

控制客户端部署可以通过运用多种方法实现。这些方法使客户端的发现或安装过程每次只能安装有限数量的客户端。例如，我们可能不想使用登录脚本在短时间内发现或安装太多客户端，如果有许多用户都在运行登录脚本，这一点就更为重要。

发现方法可以自动寻找SMS资源。如果企业中有许多资源，而我们配置的发现方法不当，SMS可能会同时发现太多资源，这可能对整个网络，以及和某些SMS组件服务器产生巨大的工作负载。为了避免这种情况，我们必须控制发现方法。

3.3.14 客户端部署规划

我们可以使用SMS 2003的内置的推送安装的方法部署SMS客户端，或者使用其他方法发来部署SMS客户端。例如，某些企业可能会使用软件分发方法，而某些则可能会在计算机镜像上安装SMS客户端（这适用于为在生产环境中使用作好准备的计算机）。使用哪种方法取决于我们的环境所特有的许多因素。

SMS客户端的不同安装方法包括：

在SMS管理控制台中使用推送安装方法安装SMS客户端。

利用以下方法之一在客户端启动程序文件：

● 登录脚本。

● 手动运行程序文件。

● Windows组策略。

● SMS软件分发或其他软件分发机制。

● 在计算机镜像上安装高级客户端。

3.3.15 推送安装

SMS 2003提供了对于使用客户端推送安装方法从SMS站点服务器远程安装SMS高级客户端的支持。客户端推送安装（或“客户端推送安装向导”）必须与一种SMS发现方法配合使用，因为它要求在安装SMS客户端软件之前先发现客户端。

客户端推送安装对于在具有以下特点的计算机上安装高级客户端或旧客户端软件是非常有用的：

已经被SMS发现，但没有安装SMS客户端软件的计算机。

用户锁定了其Windows会话并且很少登录网络的计算机。

使用没有运行登录脚本，或在该计算机上没有管理权限的用户账户进行登录。

用户可能长期不登录的服务器。

3.3.16 登录脚本或Windows策略安装

登录脚本可以启动客户端的安装操作。如果在用户登录到计算机时已经有登录脚本在运行，那么发现计算机并安装SMS客户端的最简单的方法是修改登录脚本，以包含SMS客户端的安装。我们可以使用登录脚本启动式客户端安装程序（Capinst.exe），并将程序文件（Capinst.exe）复制到共享文件夹中。

如果登录脚本需要在整个企业或多个业务部门范围内共享，我们需要考虑把这些变化添加到脚本中。因为可能会有其他SMS站点的管理员要求登录脚本实现不同的客户端安装方式，但为了避免混淆，我们应以协调方式规划和执行这项任务。

3.3.17 手工安装

客户端的手动安装方法有两种：

旧客户端安装程序（Smsman.exe）

高级客户端安装程序（Ccmsetup.exe）

手动安装客户端方法会使用CAP安装旧客户端。为用户或管理员配置一个策略，可以让他们在计算机上启动手动客户端安装。当我们不想使用自动安装客户端方法时，就可以使用这种方法。例如，如果我们正在测试环境中测试SMS，我们可以从硬盘、共享文件夹、网页、电子邮件或闪存盘上等多种方式来运行Smsman.exe。手动安装客户端也可以采用静默方式运行，我们还可以用它发现客户端计算机但不安装客户端。

高级客户端则可以通过使用高级客户端安装程序（Ccmsetup.exe）进行手动安装。高级客户端安装程序对于没有足够长时间连接网络，来下载高级客户端安装文件的计算机是很有用的。如果计算机能够在一个会话中下载程序文件（Ccmsetup.exe），那么该计算机就可以在多个网络会话中下载其余所需的高级客户端安装程序文件。

3.3.18 计算机镜像安装

在准备企业使用的计算机镜像时，我们还可以把高级客户端直接安装到模板计算机上。通常，计算机的准备工作是由IT部门提供的，通过安装SMS高级客户端，但不对其分配指定SMS站点代码，高级客户端就可以被正确安装到客户端计算机的镜像中。这样当使用镜像部署新的计算机后，初次使用的时候可以将其添加到SMS站点中。

SMS高级客户端会为客户端计算机自动配置SMS GUID，防止客户端计算机上的GUID重复。

3.4 站点层次规划

在我们规划SMS站点层次时，根据广域网（WAN）的配置情况，我们可能会发现自己拥有很多类似的站点。例如，我们可能拥有：

很多主站点，含有大约10个子站点。

很多辅助站点，含有大约25个客户端。

很多站点，含有大量桌面支持工作人员。

1．客户端管理需求

在设计SMS分层结构时，必须考虑客户端管理需求。因为我们要使用SMS管理客户端计算机，SMS客户端可以与以下SMS服务器进行交互：

客户端访问点

管理点

分发点

服务器定位点

我们必须建立用于站点与高级客户端通信的管理点，以及用于站点与旧客户端通信的客户端访问点。另外我们还可以在分层结构设计中包含一个服务器定位点，来帮助客户端发现客户端访问点。如果Active Directory尚未启用，请考虑使用服务器定位点确定对高级客户端指定的站点代码。只在主站点中安装服务器定位点，需要使分发点在我们的站点中可用，才可以存储分发给客户端的软件包。

建议在本地设置可用的站点服务器、客户端访问点（只适用于旧客户端），以及在有分发点的位置上部署客户端。SMS要求所有在客户端访问点、分发点和站点服务器之间交互的程序必须拥有快速和稳定的连接，因此我们需要在没有本地站点服务器的站点内部署少量SMS客户端的时候必须了解相关的性能问题。

2．给SMS站点指定客户端数量

站点可管理的最大客户端数量受很多不同因素的影响。这些因素包括SMS站点服务器硬件配置、站点服务器负载情况，以及所启用的SMS功能数量和类型。另外在客户端执行的SMS任务的轮询间隔（例如，清单和软件分发，以及配置SMS收集的清单数量）也都会影响SMS站点服务器支持的客户端数量。

3．常规客户端活动周期

大多数客户端活动取决于我们启用的SMS组件和设置运行这些组件的时间间隔。因此，SMS对客户端活动造成的影响会有很大不同。

在设计站点时，请考虑以下与特性相关的客户端活动周期：

检测信号发现

硬件和软件清单

轮询新播发（软件分发）

运行播发（软件分发）

状态报告、配置验证以及客户端软件更新

3.4.1 站点通信

1．SMS站点内部通信

该方式不支持SMS站点服务器与其站点系统之间进行跨森林的通信，以及SMS站点服务器与SMS站点数据库服务器之间的通信。因此我们需要规划好站点的分层结构设计，使所有SMS站点服务器（包括SMS站点数据库服务器）、所有站点系统和SMS客户端在同一森林中。

2．站点对站点通信

站点对站点通信在跨森林方面有一些限制。一个森林中的子主站点可以连接到另一个森林中的父站点，但子辅助站点不能连接到另一个森林中的父站点。数据可以从下向上（从子站点向其父站点）在分层结构中传送。为了实现站点间通信，发送站点的SMS地址必须能够访问接收地址，反之亦然。如果有一个或多个森林运行Windows 2000 Active Directory混合模式，或Windows Server 2003 Active Directory正在使用中间域功能，则我们必须将用户账户限定为地址来实现站点间通信。

3.4.2 SMS站点命名

建议规划一套以逻辑站点代码的命名规则。利用统一的命名规则，管理员可以使用站点代码来定位分层结构中的父子关系。这对于支持和恢复操作也非常有用。同时需要注意，不要在多个站点中使用同一SMS站点代码。

注意：SMS站点代码创建后不可更改。在部署SMS分层结构之前，一定要仔细规划站点代码和站点名称。在设计SMS分层结构时，一定要遵循企业的命名规则策略，同时应当尽量避免在站点代码名称中使用扩展字符。

如果正在使用Active Directory，我们还必须确保Active Directory站点名称只使用有效字符。Active Directory命名规则要求Active Directory站点名称是合法的域名系统（DNS）名称。否则SMS将无法识别这些Active Directory站点。在站点名称中，只能使用标准字符A～Z、a～z、0～9和连字符（-）。

注意：请不要使用在SMS站点代码中使用非法的MS-DOS目录名作为SMS的站点代码，例如AUX、PRN、NUL或CON。虽然这样做在SMS站点安装过程中可能不会遇到问题，但如果使用这样的SMS站点代码作为节点名，后续操作将会遇到很多问题。

3.4.3 站点服务器的位置和类型

规划工作的另外一个重要部分是规划我们的中心站点、主站点，以及辅助站点。为了做到这一点，我们需要了解父子站点间的关系，以及每个站点将包含的客户端数量，甚至还有站点间的通信方式。通过确定主站点和辅助站点的位置，我们就可以规划出良好的分层结构。

在规划站点时，需要考虑每个站点与我们的项目范围和目标的相符程度，同时考虑将在分层结构中如何连接它们。针对可用硬件资源，仔细平衡使用的模式，这些对于分层结构的成功规划至关重要。在安装SMS站点前，我们还必须决定SMS提供程序（SMS提供程序）SMS提供程序和SQL Server的安装位置。

1．管理范围和父子站点之间的关系

这种情况下，分层结构中的上级站点会存储分层结构下级站点的相关信息。拥有合理权限的上级站点管理员可以管理他们站点中的所有计算机，以及所有分层结构中的下级站点。这样做可以确保每个级别的管理员都可以合理地管理分层结构中的下级站点。如果可能的话，在规划站点基础架构时，可以考虑将每个站点设计成为向最需要管理此站点的父主站点报告，这对于完全依赖它们的父站点管理的辅助站点尤为重要。虽然这种方式可能无法每次都使用，但却是一个重要的规划思路。

2．确定主站点和辅助站点

在这种情况下，需要考虑规划我们的主站点位置，并确定分层结构是否需要辅助站点。请谨记，辅助站点需要向上报告到主站点，而且不需要安装SQL Server。同时在高级安全模式下运行的SMS站点不能向在标准安全模式下运行的SMS站点报告。SMS管理员可使用SMS管理控制台远程管理辅助站点，辅助站点可以安装在局域网（LAN）和远程位置，例如没有IT工作人员的远程办公地点。

SMS站点内的所有站点系统都应当保持良好的连接。建议的规划思路是，尽量将SMS站点设计到广域网（WAN）链路的末端，因为对于站点间通信来说，SMS可提供带宽安排、调节和数据压缩。这种站点可能比主站点需要更少资源的辅助站点。

3．确定每个父站点包含的子站点数量

在我们规划如何划分SMS分层结构中的子站点时，请考虑如下因素：

通过对子站点进行有效划分优化我们的管理计划。

考虑站点间的通信对设计有何影响。

检查我们的计划中的性能缺陷和超额成本。

4．辅助站点共享服务器

辅助站点服务器不需要和主站点使用相同的资源，因为辅助站点并不运行SQL Server。因此，小型和简易站点的辅助站点服务器可能会与位于其客户端附近的服务器共享。如果想要使用这样的配置，我们需要测试这些应用对辅助站点服务器的影响，以及SMS可能对其他应用产生的影响。

注意：请不要在不了解SMS与群集服务互操作性的情况下就在运行Windows群集服务的计算机上安装SMS站点服务器。要了解更多信息，请参阅SMS相关的白皮书http://www.microsoft.com/smserver。

5．中心站点

是否拥有向中心站点报告的客户端，以及是否使用中心站点服务器做其他用途，取决于企业的规模和复杂程度。客户端可以有选择地向中心站点以下的子站点报告。因为分层结构上层的所有状态和客户端数据都向上传送到中心站点，因此添加大量客户端到此站点将降低中心站点服务器和客户端的性能。如果我们计划将中心站点服务器用于其他用途，例如SMS报表服务，请考虑不要让客户端直接向中心站点报告客户端信息。

分配到中心站点服务器的任务类型以及客户端是否直接向其报告的一个决定性因素是：该服务器的硬件功能和容量。如果确实向中心站点分配了任务，该服务器应当足够强大，来同时支持本地处理和全公司范围的处理。

在设计完站点，并确定站点的报告结构后，我们可连接这些站点，构成一个向上游中心站点服务器报告的独立分层结构。建议从分层结构最低层开始计划添加到高级站点的低级站点，一直沿着分层结构向上，不断添加到更高级的站点。我们可利用这样的结构确定中心站点最符合逻辑的位置。

6．平面与深层分层结构

分层结构的构建会受到多种内在和外在因素的影响。根据企业的业务需求和物理布局，我们的分层结构设计将最终类似于一个平面或深层分层结构。

注意：建议设计一个平面程度更高的分层结构，这样的分层结构更容易配置、管理和支持。分层结构中的层次越少，SMS就需要越少的时间来将软件部署到低级站点，并能够快速地向分层结构顶部返回状态报告。

7．限制站点故障影响

在确定最适合企业的分层结构设计时，需要考虑限制可能出现的站点故障的需求程度。在深层分层结构中，如果一个拥有数量相对较多的低级站点的站点服务器出现故障，那么其负面影响就更大，因为数量相对较多的客户端将被从失效站点的父站点断开。然而，在平面分层结构中，站点和SMS客户端更加分散，如果平层分层结构中的一个站点服务器失效，只有极少数客户端会受到影响。

3.4.4 站点系统角色

我们可以将系统所有角色指定给主站点服务器，或在其他服务器之间分配这些角色。在规划分层结构的站点系统角色分配时，请谨记，有些角色是在安装期间分配的，而其他角色是通过SMS管理控制台指派的。

注意：在部署后能否对站点做出更改，因为有些站点系统角色在安装后可以被转移，但有些则不能转移。

1．站点服务器和站点系统重定位

如果在部署SMS后，企业的需求出乎意料地变化或者增大，我们可能会发现原来的分层结构设计的性能降低到了无法忍受的程度。如果出现这种情况，我们就必须重新规划。这时候可以通过将站点系统的角色转移和分配给额外的计算机的方式来提高站点性能。

另外还需要注意企业与数据库服务器相关的策略。例如，如果有一个独立部门管理企业中所有运行SQL Server的计算机，那么该策略就可能要求SMS提供程序不准安装在运行SQL Server的远程计算机上。或者该策略可能不允许在SMS站点服务器上安装SMS。在规划的时候，这些内容都要充分考虑到。

如果可能的话，请为SMS 2003准备专用的SQL Server数据库。总之，建议不要与其他SQL Server应用程序共享SMS站点数据库，因为这样做将降低SMS的性能。这个建议主要适用于托管了大量SMS客户端的企业，以及占用大量处理器时间的其他SQL Server应用程序。在与其他SQL Server应用程序共享SMS站点数据库的时候，请遵守企业IT部门的相关策略。

如果安装SMS站点，并使用属于其他SMS站点的SMS数据库，那么这两个站点都将无法正常工作。无论SMS站点的版本如何，都不能与其他SMS站点共享SMS站点数据库。然而，两个站点可使用同一台运行SQL Server的计算机上的不同SQL实例，前提是它们拥有各自独立的SMS站点数据库，并且运行SQL Server的计算机不是SMS站点服务器。

2．SQL Server数据库复制

如果预计我们的服务器定位点或管理点与SMS站点数据库服务器之间将出现大量网络流量，请考虑实施一个额外的数据库，作为SQL Server数据库的复制。为了提高SMS站点数据库服务器的性能，管理点使用的高级客户端策略表可以被复制到另一台运行SQL Server的独立计算机上。在这种情况下，SQL Server数据库复制功能会自动保持已复制的高级客户端策略数据库与SMS站点数据库保持同步。

SQL Server数据库复制功能支持管理点和服务器定位点，可以查询它们需要的SMS数据，并支持客户端的请求，而不会给SMS站点数据库服务器造成额外负载。这个任务可以在一台或多台运行未托管SMS站点数据库的SQL Server的计算机间运行，从而提高SQL Server的资源性能。复制过程完全由SQL Server发布和签署服务进行处理，不需要人为干预。

3．SMS管理控制台

SMS管理控制台可从SMS安装光盘中安装到任何运行Windows 2000 Professional SP2或更高版本操作系统的计算机中，但必须将适当的权限分配给运行该控制台和管理SMS站点的用户。

因为SMS管理控制台是基于Microsoft管理控制台（MMC）的一个管理单元，因此我们可以针对不同的SMS用户定制提供不同访问级别的SMS管理控制台。

4．客户端访问点

在每个SMS站点上，至少需要规划一个客户端访问点。就算SMS站点只包含高级客户端，没有旧客户端，我们也必须保留至少一个客户端访问点，因为有些SMS站点服务器组件必须使用客户端访问点。

如果SMS站点包含大量旧客户端，需要保证拥有足够的客户端访问点以支持这些客户端。需要考虑将客户端访问点角色分配到一个或多个站点系统中，而不要分配到站点服务器，以减少站点服务器负载。在确定所需的客户端访问点数量时，请考虑客户端访问点上的负载，以及在客户端访问点之间是否需要容错功能。

我们的目标是将部署的客户端访问点数量减少到最小，但同时仍保证客户端访问点能够有效满足旧客户端的需求。这将确保这些客户端不会遇到任何不可接受的服务降级，例如无法及时收到播发。因为SMS站点服务器需要连续执行复制，而且必须通过每个客户端访问点循环进行，如果拥有太多的客户端访问点，那么这个过程将需要很长时间。这是一个重要的注意事项，因为所有旧客户端文件都会被复制到各个客户端访问点中。

在更改SMS站点配置时，所有旧客户端都将在它们下一次轮询间隔时联系客户端访问点，并根据这些变更对客户端访问点客户端进行更新。例如，SMS服务堆栈，默认的轮询间隔是25 小时，虽然客户端访问点可能并不总是承受大量负载，确保在分层结构规划好后拥有足够的容量来执行这些操作。这个问题特别适用于管理了大量客户端的站点，一定要谨记，客户端访问点也需要从客户端接收数据，包括清单和状态消息。

SMS站点服务器会被自动安装为客户端访问点。如果需要指定一个主站点只执行SMS服务器行为，那么我们可以在此站点上创建另外一个客户端访问点，然后将该客户端访问点转移给另一台服务器。这样可以确保主站点专门执行站点服务器相关任务，同时这些服务器不会受客户端请求的影响。这个方法特别适合管理了成千上万客户端的大型站点。

5．分发点

分发点的负载会因为播发的数据包数量和大小不同而有所不同。我们可以按大小排列企业内所有文件服务器的方式确定分发点必要的容量。

站点所需的分发点数量取决于要访问数据包以进行软件发布的客户端的数量，同时还可能取决于客户端的位置。因此我们最好能指定一个与一组客户端计算机距离很近的分发点。分发的软件越多，部署的软件数据包越大，需要的分发点数量就越多。

注意：分发点会在不限制网络带宽的情况下从站点服务器接收数据包和数据包更新，我们可以在远程办公室安装辅助站点，保证客户端尽量从本地网络访问数据包。

6．启用BITS的分发点

当客户端在各个位置间漫游时，安装了高级客户端的计算机将会查找附近是否有包含所需软件内容的分发点。虽然高级客户端依然可以被指定使用最初的站点，不过当高级客户端需要接收播发的软件包时，还可以从本地分发点获取，可以不需要访问最初指定的站点。在选择远程服务器作为分发点时可以充分利用这一特性。

为了防止高级客户端过渡占用网络带宽，我们还可以启用分发点上为高级客户端提供的BITS服务。这项服务通过充分利用客户端剩余带宽的方式实现了高效的文件传输机制，同时该服务还提供了软件包的断点续传功能，这样所需文件可以多次发送到客户端。

在站点服务器上规划客户端访问点和分发点的时候，必须选择拥有相同的高速和可靠连接的服务器，虽然这些站点系统可以跨广域网（WAN）运行，但可能因为需要进行大量跨广域网的通信而影响性能。

注意：BITS服务要求管理点上安装有IIS服务，同时该功能需要单独启用。

7．受保护的分发点

受保护的分发点被设计用于防止网络连接与分发点之间产生多余网络流量。SMS管理员可以通过受保护的分发点来限制高级客户端，客户端必须位于某些漫游边界或站点边界内，这些边界外的所有客户端都无法从此分发点下载或运行软件包。受保护的分发点内的高级客户端会优先选择此这个受保护的分发点，不需要与边界外的分发点通信。但旧客户端无法使用该功能。

为了限制对减速或不可靠的网络连接上分发点的访问，我们可以将这样的站点设置为受保护的分发点。这样将只有少数SMS客户端和分发点可以通过WAN连接到主站点的远程位置。

8．管理点

虽然高级客户端只被指定到主站点，但是管理点在主站点和辅助站点上都可以安装。辅助站点的管理点被称为“代理管理点”。如果漫游边界已经启用，这样的管理点可以被安装并用于实现高级客户端漫游。代理管理点通过使用辅助站点漫游边界内的漫游客户端，可以提高带宽使用效率。

多个管理点：通常，含有高级客户端的SMS站点只能使用默认管理点。然而在一个站点内还可以实施多个管理点，以满足网络负载平衡或备份需求。

在含有大量高级客户端的站点上，网络负载平衡可以包含两个或多个管理点，这样可以平衡从客户端流向管理点的网络流量。并且还可以站点中拥有一个额外的管理点，以避免默认管理点失效，达到管理点备份的功能。在这样的环境下，管理员可以指定备份管理点作为默认管理点。但是需要注意，辅助管理点无法提供自动故障转移功能，这样的站点在被指定为默认管理点之前会闲置。

注意：网络负载平衡服务是Windows 2000 Advanced Server中的一种功能，可以用于构建服务器集群。服务器集群是一组通过共同协作来提供某种服务的计算机，典型的安装涉及使用一块网络适配器来管理计算机，并使用另一块网络适配器为客户端提供服务。同时第二块网络适配器还拥有独立的虚拟IP地址。集群中的其他计算机共享相同的虚拟IP地址作为网络适配器，为SMS客户端提供服务。

辅助站点管理点：指位于辅助站点和通过WAN连接，向父主站点管理点报告的高级客户端，这种管理点可以影响辅助站点和其父主站点之间的WAN连接的可用带宽。当客户端状态和硬件或软件清单数据被发送到父主站点时，会产生大量网络流量，因为高级客户端只能被指定给主站点，因此高级客户端策略请求产生的网络流量可能会减少这两个站点之间的可用带宽。

在辅助站点上安装代理管理点，可显著降低在此站点的漫游边界或站点边界，高级客户端对可用网络带宽的影响。高级客户端可以发送清单数据、软件测量数据和状态数据到代理管理点，代理管理点使用此站点的发送器功能将数据传输到父主站点。通过使用发送器带宽控制功能，我们可以限定数据发送到主站点的时间。同时代理管理也可以存储一些高级客户端策略信息，这样高级客户端就可以从代理管理点，而不是从主站点管理点获得此高级客户端策略信息。

如果在本地有大量的客户端资源，那么我们需要在辅助站点上规划一个独立管理点。

针对管理点的SQL Server数据库复制：如果高级客户端的数量显著增加，我们可以将SMS站点数据库中的表复制到另一个不同的SQL Server实例中，而不是SMS站点数据库使用的SQL Server中。这样做可以降低主站点的SQL Server数据库负载。因为管理点在服务高级客户端请求时，会查询一个不同的SQL Server实例，而已复制的表可以存放在拥有管理点的计算机，或运行SQL Server且没有包含其他SMS站点系统角色的计算机上。

在规划的时候，我们可以使用以下这些标准配置：

一个独立管理点，直接访问站点服务器的SQL Server数据库。这适合支持少量高级客户端的情形。

一个拥有其自己复制的SQL Server数据库的独立管理点。此配置可降低站点服务器SQL Server数据库的负载，并支持管理点在没有SQL Server数据库时继续操作。

使用网络负载平衡，并访问独立复制的SQL Server数据库的多个管理点。这适合需要支持大量高级客户端的企业环境，隔离站点服务器数据库和拥有动态故障转移功能的网络负载平衡可提供高可用性。

在网络负载平衡服务器后端的多个管理点，每个管理点都拥有其各自本地复制的SQL Server。这适合需要支持大量高级客户端的企业环境。同时可以安装本地SQL Server和网络负载平衡服务，提供最高的吞吐量和可用性。

9．服务器定位点

在出现以下任何情况时，我们可以在SMS分层结构中规划服务器定位点：

使用登录脚本初始化的客户端安装程序部署旧客户端或高级客户端。

想要把高级客户端自动指定给未针对SMS扩展Active Directory架构的站点。

服务器定位点也需要一定的规划。与管理点不同，只有主站点支持服务器定位点，而辅助站点不支持，同时管理点可以同时适用于高级客户端和旧客户端。站点包含的服务器定位点数量取决于此站点的客户端数量，通常SMS分层结构只需要一个服务器定位点。

我们通常可以将服务器定位点安装在中心站点上。如果服务器定位点对中心SMS站点数据库造成了大量负载，那么也可以在此站点使用复制的SQL Server数据库。如果客户端的请求过多，并在服务器定位点上造成过多的负载，则可以在中心站点设置多个服务器定位点。

旧客户端只能在登录时访问服务器定位点，并且产生最小限度的网络流量，从客户端上传大约1 KB数据，同时向客户端下载大约1 KB数据。因为高级客户端只在其最初登录进行自动站点分配时访问服务器定位点一次，因此其对带宽只有很小的影响。

与管理点一样，服务器定位点也需要预先安装IIS。

注意：有些SQL Server版本支持管理点和服务器定位点数据库复制功能，SQL Server支持复制到第三方不同数据库；然而SMS 2003不支持这样的功能。

10．报告点

报告点只与本地SMS站点数据库通信。报告点服务器需要IIS，我们只能在主站点服务器上实施报告点，在辅助站点上无法安装。报告点的分布取决于想要报告的数据。例如，在中心站点的高级报告点可以报告分层结构中所有层面产生的数据，但发送到分层结构低级站点的状态除外。

拥有大量报告用户和额外扩展需求的大型企业可以考虑使用多个报告点。借助多个报告点，我们可以为想要访问报告的不同用户提供不同报告点访问URL。然而如果大量使用报告和报告查询，特别是拥有大量运行相同报告查询的用户，请注意这可能导致降低SMS站点数据库服务器性能。

3.4.5 站点边界和漫游边界规则

因为SMS站点的边界是由IP子网或Active Directory站点名称定义的，所以大部分SMS站点都会被映射到我们的物理网络拓扑中。

规划站点边界可以帮助我们决定在每个站点要包含哪些资源和子网。每个SMS客户端都会被指定给一个独立的SMS站点，旧客户端必须存在于已定义的站点边界内。如果不能满足这些条件，旧客户端软件可能会从客户端计算机中删除。然而，高级客户端可以根据站点代码被明确指定到某一站点。这种分配方式不受站点边界限制，SMS 2003不支持多站点客户端指定。

1．超网（Supernetting）

无类域间路由（CIDR）使用一个单独的IP地址指定多个唯一的IP地址。CIDR也叫做“超网”。SMS站点边界不支持以超网连接的IP子网。为了利用SMS中所有子网组合技术（例如，超网等），我们必须使用Active Directory站点名称作为站点边界，而不能使用IP子网。

站点边界包含的子网应当与可靠的链路连接，以便站点内的所有资源都与其他所有站点资源拥有快速连接。通常，如果两个子网被一个慢速连接分开，请不要将它们包含在相同的站点内，而是在每个物理位置上创建一个独立的SMS站点。如果此物理位置含有许多用户、含有具有不同需求的众多用户，或者含有多个管理计算机的团队，我们就可以将一个独立物理位置分成多个SMS站点。

计算机必须属于SMS站点边界内中的某个域。

因为站点边界通常反映了企业的布局，所以在考虑设立站点边界位置时，可以使用在前期规划阶段创建的网络图表。通过图表可以确定每个局域网（LAN）和WAN中包含的用户数量和类型，可以根据连接速度估算如何将现有子网站构建到独立的站点中。同时还需要考虑站点中域的位置，因为我们可以通过域启用资源发现功能，这是一个使用很少考虑就能找到所有计算机的可靠途径。

如果客户端位于站点边界，或位于指定的站点漫游边界内，那么该计算机就可以访问本地可用软件包文件。或者，该客户端会以类似远程连接的方式访问内容（也就是使用下载和运行软件安装的方式，而不是使用网络方式运行）。

2．站点范围的设置

在规划站点边界时，请考虑为客户端代理、组件、发现方式、安装方式，以及其他功能配置的站点设置是否适用于所有我们指定到此站点的客户端。

注意：在某些情况下，我们可能希望某一站点内的一些客户端含有与此站点内其他客户端不同的配置。例如，我们可能希望远程工具代理只在台式计算机上要求用户权限，而在服务器上不要求。借助Active Directory组策略或注册更改，站点中服务器的用户权限设置可以被覆盖。

3．高级客户端漫游边界

计划漫游边界在站点设计中是一个重要步骤，因为我们限定的漫游边界将指定软件分发到高级客户端的方式。

SMS站点边界决定了SMS站点可以管理哪些资源。漫游边界支持SMS软件分发到高级客户端的功能。出于此原因，我们需要在高级客户端需要访问公开程序的SMS站点上定义漫游边界。漫游边界也用于高级客户端站点指定和配置受保护的分发点。

如果客户端漫游到未定义漫游边界的位置，那么该客户端将还原到其指定的站点管理点和分发点。在这种情况下，这个客户端会视分发点为远程分发点。

另外需要注意，应该尽量避免创建重叠的漫游边界。如果高级客户端位于多个站点的漫游边界内，那么此客户端将无法与正确的站点通信。

注意：在Active Directory环境中，每个SMS站点服务器都需要在Active Directory中公布其漫游边界列表。为使用高级客户端的全部优势，我们必须在站点中部署Active Directory，并且已经针对SMS扩展了Active Directory架构。这样高级客户端才能进行全局漫游。在没有Active Directory扩展的情况下，SMS客户端只能进行局部漫游。

在规划站点和分层结构设计时，必须了解漫游边界与站点边界的区别：

站点边界由IP子网或Active Directory站点名称组成，并且定义该站点管理哪些资源。

漫游边界适用于高级客户端访问，可为其提供公开软件包的分发点。

漫游边界与SMS站点边界类似，因为它们都可以由IP子网和Active Directory站点定义。

然而，我们也可以使用IP地址范围定义漫游边界。这对于通过远程访问或虚拟专用网连接网络的SMS客户端有所裨益。

站点边界默认包含在站点漫游边界内。

注意：在确定站点边界时，需要考虑客户端将使用的客户端访问点、分发点、管理点，以及服务器定位点所对应的位置。确保固定客户端可使用快速和可靠链路访问这些站点系统。

SMS站点限定范围和客户端漫游站点边界定义了我们的网络逻辑区域，其中客户端系统可能由SMS 2003管理。如果客户端在这些限定范围之外存在，它也许会被发现，但不受SMS 2003的管理和支配的。SMS限定范围是由IP子网和Active Directory站点定义的限定范围，在设置SMS客户端和SMS站点限定范围时，请注意下列问题：

应该由Active Directory站点边界定义SMS站点。这意味着客户端应该是Windows 2000或更新版操作系统，以便有效利用SMS站点边界。

如果有任何低速子网，例如无线，拨号或者VPN，应该由他们自己的子网和站点进行定义。

保证所有局部站点边界都被包括作为本地漫游边界。

如果IP地址或Active Directory站点名称在被定义的SMS站点范围内，那么旧客户端也会被包含到SMS站点中。

Active Directory站点不应该造成SMS站点限定范围重叠，这可以保证客户端只被分配到一个SMS站点。

当高级客户端在SMS站点内从一个IP子网或Active Directory站点移动到另一个IP子网或Active Directory站点后，就表示该客户端漫游了。只有SMS 2003高级客户端可以在进行漫游的同时保持连接的有效性。当配置SMS站点限定范围时，我们有机会配置漫游边界。被配置的可以是本地漫游边界，或远程漫游边界。通过定义漫游边界的种类，我们能控制高级客户端如何运行。

即使高级客户端可以从一个站点漫游到另一个，同时其站点分配也将产生对应的变化。客户端计算上安装了SMS客户端以后，它会根据SMS站点的站点边界自动分配站点。漫游边界可以由IP子网，IP地址，或者活动目录站点名称。

4．漫游的客户端和管理点

高级客户端可以与管理点配合，但是也会被分配默认的管理点。所有信息，例如库存数据，总是会被发送给管理点（除非配置了代理管理点，并且代理管理点对该SMS站点是可用的）。这种机制被称为分配的管理点。

驻留管理点是SMS高级客户端当前SMS站点的默认管理点。当客户端漫游后，它将使用驻留管理点作为其被分配的管理点，根据客户端当前漫游的限定范围进行调整。如果我们配置了辅助站点，另外的管理点还可以被配置和分配到该辅助站点。

代理管理点可以为在其漫游边界和被分配到其父项主站点的高级客户端提供服务。在进行漫游时，高级客户端将发送自己的数据包来源地点请求对其驻留的管理点。然而，如果代理管理点不存在，信息将转发到代理管理点或到被分配的管理点。高级客户端与管理点之间除了高级客户端策略其他所有信息全部是压缩传输的。在进行漫游时，高级客户端会尝试通过Active Directory找出驻留的管理点。随后Active Directory会提供客户端分配的管理点漫游情况下的软件分发。

高级客户端只被指定给主站点，而不是辅助站点。当高级客户端需要访问一个已发布的程序时，将使用Active Directory定位其驻留管理点。如果客户端仍在其指定站点中，那么其指定管理点将作为驻留管理点。客户端向驻留管理点发送软件包源位置请求。驻留管理点决定哪些分发点对于客户端是可用的。另外，其还能确定分发点是在本地漫游边界之中，还是在与客户端所在漫游边界相关的站点的远程漫游边界中。这个位置可以帮助确定高级客户端如何访问该站点上的分发点。

另一个决定高级客户端如何访问漫游边界中分发点上的公开程序的因素是：如何配置程序通告。当高级客户端接收到程序通告，并且客户端可以使用本地分发点（即客户端位于本地漫游边界中）时，高级客户端可以执行以下操作之一：

直接从分发点上运行软件包

先下载软件包，再运行

当高级客户端接收到程序通告，并且客户端不能使用本地分发点（即客户端在远程漫游边界中）时，高级客户端可以执行以下操作之一：

不运行

先从远程分发点下载，再运行

直接从远程分发点运行

如果SMS软件包在与客户端所在漫游边界相关的站点中是不可用的，客户端将返回到其指定站点，以便向其指定管理点发送软件包源位置请求。管理点随后提供可用分发点的位置。如果软件包源文件在本地可用，但是不可访问，那么客户端不会返回其指定站点。这一功能可保护WAN不会在分发点出现故障时遇到异常流量。如果软件包可用，并且播发被配置为先下载后运行，则客户端在运行软件包之前先将其完全下载。

本地漫游边界：其中高级客户端能够使用本地站点上的分发点，软件包可以通过良好连接的链路供该客户端使用。发送到高级客户端的通告指定高级客户端是否从本地可用的分发点下载软件包源文件，然后再运行该程序。

远程漫游边界：其中高级客户端不能使用本地站点分发点。发送到高级客户端的播发指定客户端从远程分发点下载软件程序而后再运行该程序；从远程分发点上直接运行软件包；还是什么都不做，等待分发点变成本地可用。远程漫游边界中的分发点被视为不能由客户端在本地使用。换句话说，该分发点是远程分发点。如果把远程漫游边界配置为包括未与SMS站点建立良好连接的网段，那么在物理距离上分发点对于高级客户端来说，可真称得上是远程了。

客户端可以漫游到附近的站点，并仍然位于该站点的远程漫游边界之中。在此情况下，客户端把该站点的分发点视为远程分发点。尽管客户端正在使用物理位置最接近的分发点，但是不会把其视为可在本地使用的分发点。

如果以下情况之一属实，则创建远程漫游边界：

希望高级客户端在位于该边界内时下载并执行软件包。

不希望高级客户端在位于该边界内时下载并执行软件包。

在本地漫游边界中，如果客户端与分发点建立了良好的连接，但是在该分发点上未启用BITS，则使用服务器消息块（SMB）直接下载SMS软件包。如果分发点启用了BITS，则客户端以节流方式下载程序，检查并且重启来自动从网络通信错误中进行恢复。BITS比SMB更高效，即使是在网络连接可靠和快速的环境中（如采用10 Mbps或速度更快的局域网）。

如果高级客户端不在任何漫游边界之中，将返回其指定站点，以支持高级客户端策略和所有其他站点通信。在此情况下，客户端仍然能够访问软件包文件，但是从远程分发点接收这些文件，并使用BITS来高效地下载软件包。或者，如果站点的分发点被认为与客户端位置相距遥远，但是不能定位启用BITS的分发点，则软件包文件可以使用SMB下载。

5．局部漫游和全局漫游

如果Active Directory是不可用的，或者如果支持SMS的Active Directory架构未经扩展，那么高级客户端只能漫游到其指定站点的低级站点，这称为“局部漫游”。在局部漫游中，高级客户端可以漫游到较低级的站点，同时仍然从分发点接收软件包。

当向高级客户端发送播发时，客户端从其指定管理点接收与公开的软件包位置有关的信息。或者，如果客户端已经漫游到辅助站点，并且代理管理点可用，则客户端将从代理管理点接收有关公开软件包的位置的信息。客户端随后使用其指定站点的低级站点之一的分发点。其使用哪个分发点取决于客户端在哪个漫游边界中，以及公开的软件包在分发点上是否可用。

全局漫游允许高级客户端漫游到更高级站点、同级站点以及SMS分层结构中其他分支的站点，同时仍然从分发点接收软件包。全局漫游需要Active Directory和SMS Active Directory架构扩展。全局漫游不能跨Active Directory森林进行。

3.5 SMS服务器容量规划

硬件及系统平台规则

SMS 2003对于硬件和平台具有下列要求：

确认所有硬件设备都包含在Windows 2000或Windows Server 2003硬件兼容性列表（HCL）中，虽然有时候，Windows也可以安装在没有被包含在HCL的硬件设备上，不过如果在这样的服务器上安装微软的BackOffice产品，那么可能会遇到一些问题，例如蓝屏死机，这样就得不偿失了。

安装SMS 2003的服务器平台必须是基于x86架构的。Alpha系统无法支持SMS 2003，同时SMS 2003要求计算机的处理器至少应该是奔腾级别，主频不低于500MHz。处理器的性能越强大，就可以获得越好的SMS性能。通常建议至少使用双处理器系统。

SMS 2003需要至少256MB内存，同时还需要给SQL Server至少分配16MB内存。在只有64MB内存的服务器上运行SMS 2003并不是好主意，同时因为内存很便宜，因此我们需要尽可能安装多的内存，并在每次升级内存后都对不同情况下的负载进行测试。

SMS 2003必须安装在Windows 2000或Windows Server 2003文件系统（NTFS）的分区上，同时SMS 2003需要使用NTFS文件系统的权限控制功能确保对SMS目录和共享的访问控制。SMS 2003站点服务器或站点系统可以是Windows NT 4.0域、Windows 2000域或Windows Server 2003域的成员服务器，或者也可以是Windows 2000域或Windows Server 2003域控制器。

SMS 2003需要在NTFS分区上至少有2GB可用空间，同时需要注意，实际需要的磁盘空间数量主要取决于站点服务器将要负责的系统角色、需要被管理的客户端和资源的数量，以及数据包、程序和播发的数量。例如，如果站点服务器只是负责中型企业独立站点的服务器定位点，以及CAP的用途，那么2 GB可用空间就足够了。然而如果站点服务器还需要负责大型企业里管理点、报告点，以及分发点的工作，那么为了存储所需的数据文件，我们可能需要提供更多可用磁盘空间。

SMS站点服务器所需的硬件配置在很大程度上取决于我们需要的SMS特性。随着业务的增加和业务的变化，SMS站点服务器的硬件要求也会出现相应变化。对于最初的SMS部署，我们必须确定最初的、可以用于进行试验项目的硬件要求。要估算出每个SMS站点服务器的硬件要求，请考虑下列情形：

计划安装的客户端数量，以及预期的站点上拥有的SMS对象数量。

已安装的SMS组件的负载情况。

最重要的是，我们需要尽可能地用较低成本实现最高容错能力的SMS站点服务器硬件。同时需要确定主站点服务器和辅助站点服务器的负载情况，以及所有其他被指定了SMS角色的服务器的负载。在确定了站点组件服务器的负载后，可以根据这些信息确定最初的硬件要求。

本节中的建议是基于许多因素的，如客户端的数量和希望通过SMS处理的对象的数量、规模和频率不确定，那么对于硬件的要求也会有很大的变化。我们应该考虑到所有这些因素，并根据环境中现有的情形谨慎决定。这个过程中需要考虑的重要因素包括：

集合的数量及其刷新间隔。

软件分发的频率和规模。

软件计数。

使用的发现方法。

硬件和软件清单收集频率。

硬件和软件清单规模。

报告。

软件更新管理。

可用的网络容量。

共享SMS服务器硬件的其他应用程序。

SMS站点中的客户端数量。

通过服务等级协议的用户群体和可以接受的性能。

预算限制。

对于在小型SMS站点：

处理器、内存和磁盘资源通常都不是大问题，因为很容易跟踪和维护。

对于在中型SMS站点：

内存必须与客户端数量成比例增长。

磁盘I/O成为潜在的性能瓶颈；考虑RAID配置。

计算机容量要求与软件包分发和清单收集频率成比例增长；考虑部署双处理器服务器。

对于在大型SMS站点：

内存必须与客户端数量成比例增长。

磁盘I/O成为可能的性能瓶颈；考虑采用RAID配置（如RAID 1+0）和分隔硬件卷和通道，以支持增长的性能要求。

处理器容量要求与软件包分发和清单收集的频率成比例增长；考虑采用多处理器服务器。

在阅读完这些章节后，确定仅用于生产目的的硬件要求。对于测试环境，这些数字可能需要根据测试环境的实际情况进行相应的调整。

考虑使用SCSI RAID磁盘控制器：基于硬件的SCSI RAID控制器可以提供冗余，来应对磁盘故障事件。此外，还可以改善系统性能。许多SCSI控制器提供了读/写高速缓存，能够在负载增加时极大地减少CPU使用率。SCSI RAID控制器还加快了在多个磁盘上的读/写操作速度，缩短了磁盘存取时间。

以下是针对站点服务器的SCSI实施规划范例：

通道1——4卷RAID5阵列，存储SMS站点数据库。

通道1——2卷RAID1阵列，存储Windows系统文件、SQL Server主数据库和系统的虚拟内存分页文件。

通道2——6卷RAID5阵列，支持SMS。

通道2——2卷RAID1阵列，存储SMS SQL Server事务处理日志（禁用写高速缓存）。

取决于配置因素的数量，中型主站点（1000～5000个客户端）和大型主站点（20000～50000个客户端）可能认为磁盘输入/输出（I/O）是瓶颈。为此，可考虑将硬件卷和通道相互隔离，利用SCSI RAID控制器进行控制。

建议使用高端SCSI控制器和磁盘为大量客户端提供服务，以及使用许多SMS特性的SMS站点服务器。然而，预算限制可能会妨碍这种方案的可行性，SMS也可以使用IDE或者SATA磁盘。IDE磁盘子系统不提供容错功能，但是很便宜。

通常，如果是在大中型组织中，在构建SMS站点系统硬件时，还应考虑以下技巧：

将SMS站点服务器和SMS站点数据库置于不同通道上（如果正在使用SCSI硬件）。

无论SMS站点还是SMS站点数据库，都不能与其他应用程序共享磁盘。

将SQL Server事物处理日志配置为在不同磁盘上，而不是在SMS站点数据库所在的磁盘上运行。

3.6 数据库规划

1．确定SMS站点数据库服务器要求

SMS 2003依赖于SQL Server作为其数据库引擎。SQL Server的数据库设备配置和SMS 2003的硬件资源需求是关联的，并且硬件之间彼此存在依赖关系。建议在SMS站点服务器上安装SMS站点数据库，SMS 2003的性能与SQL Server的性能直接相关。我们必须确保为这两种应用程序提供足够的硬件资源。为此，我们需要清楚地了解这两种应用程序如何配合工作。

2．SQL Server应远程安装还是本地安装

当SQL Server专门用于SMS 2003时，SMS 2003的性能最出色。如果SMS站点数据库安装在担任SMS站点服务器角色的相同计算机上时（如果该服务器的规模足够支持这两种应用程序），还可以显著提高SMS的性能。在站点服务器计算机上运行SQL Server可以减少网络负载。如果还使用SQL Server支持企业中的其他应用程序，我们必须决定是否使用远程安装的SQL Server来支持这些应用程序。这里的技巧是在SMS站点服务器上运行SMS站点数据库。如果我们正在使用SQL Server支持企业内的其他应用程序，那么在不是站点服务器的计算机上运行SQL Server可以提升站点性能。

磁盘的读写能力是决定在哪里部署运行SQL Server的计算机的最重要因素。将数据设备和日志设备安装在不同的物理硬盘或RAID阵列上可以改善SQL Server的磁盘性能，并间接提高SMS的性能。

3．每天、每周和每月有多少数据写入SMS站点数据库

我们可以通过审查向站点报告的客户端数量和总体使用模式（例如，状态消息、硬件和软件清单记录和DDR向SMS站点数据库的流动），确定写到SMS站点数据库中的数据量。SMS写入到SMS站点数据库中的数据总量可以极大地优化SQL Server性能所需要的硬件。通常，如果每月只有一次将大量数据写入SMS站点数据库的操作，我们只需要较少的处理器能力和磁盘空间来运行SQL Server。同样，如果只有在一天中的特定时间内需要将大量数据写入SMS站点数据库，那么就不需要太多SQL Server处理能力，运行SQL Server的服务器需要较低的处理能力和较少的磁盘空间即可满足要求。

SQL Server可以将内存用于高速缓存。如果可以提供更多内存，那么将可以更高效地运行。将SQL Server内存限制为允许的最大容量，可以减少页错误并改善系统性能。欲了解有关调试SQL Server内存高速缓存的更多信息，请参阅SQL Server相关文档。

在确定SQL Server和SMS组件服务器的硬件要求时，需要考虑的另一个问题是，可能在SMS站点数据库中累积的数据总量。如果我们在搭建测试环境之前对网络有准确和完整的了解，即可开始估计可能积累的数据量，以及存储该数据量所需要的数据库的规模。

重要须知：如果将发现方法轮询计划周期缩短，发现方法可能会立即运行。例如，如果发现方法最初被设置为按周运行，而我们将其改成按天运行，它可能会在我们做出配置变更之后立即运行，即便其被配置为在午夜运行。这是因为从上次发现方法运行到现在配置为止，时间已经超过一天。

注意：如果这些设置变更，相应的值也必须进行调整。例如，如果默认的SMS_def.mof经过修改以包括被报告的额外清单项目，该值可能显著增加。

当我们规划完数据库的规模后，可以使用本章前面所推荐的公式和系统监视器计数器来制定完整的SMS站点数据库服务器的规模和容量规划计划。

SMS 2003要求操作数据库的容量不小于50 MB，事务日志数据库不小于20 MB。然而这个要求只是用于支持小型（不超过1000 台）客户端环境的最小要求。不过我们也可以在更小空间的数据库中成功安装SMS 2003，尤其是演示或者测试用途中。微软建议在数据库中为每个客户端准备大概220 KB的空间，而事务日志数据库的空间应该至少是数据库空间的20%。另外在实际部署的时候，还有一些用于判断数据库大小的因素，包括：收集的软硬件清单的内容，数据包、程序和播发的数量，以及集合的大小和数量，被发现的资源的类型和数量，最后还需要考虑需要维护的查询和状态消息的数量。

Systems Management Server 2003的概念、规划和部署向导提供了下列公式来计算大致需要的数据库空间大小：

50MB+(x×220KB)（其中“x”是站点中客户端的数量）

该公式基于以下站点设置之上：

每周硬件清单，默认为SMS_def.mof。

每日软件清单。

在90天后删除过期的发现记录。

在90天后删除过期的清单历史记录。

在7天后删除过期的状态消息。

每周软件计数的汇总情况。

该公式还允许每周、每个客户端产生20 个状态消息。这个公式主要基于每周进行软硬件清单汇总、发现和清单信息使用默认时间间隔（90天），以及每周每台客户端报告20条状态消息的典型情况下。如果在包含1000台客户端的环境中使用该公式，可以得到下列结果：

50MB+(1000×220KB)=270MB

这里需要注意的是，数据库空间的实际大小还会受制于我们对软硬件清单、汇总的默认设置进行的修改，以及实际生成的状态消息的数量。如果给数据库设置了较小的空间限制并不划算，因为我们可能会需要经常调整这一限制。

最后，不要忘了考虑站点层次结构。如果有子站点，这些站点也会报告自己的清单、发现记录、状态消息，以及站点配置信息传送给父站点。在父站点的SMS数据库中，我们还必须为这些信息预留足够的空间。更不用说中心站点的数据库空间设置了，因为中心站点需要将层次结构内所有下级服务器报告的信息都保存起来。

3.7 安全规划

有关SMS站点安全性的内容我们会在本书第17章，“SMS安全性”中介绍，毫无疑问，在规划和记录实施过程的时候，我们需要回答很多和安全有关的问题。这些问题包括：

目前使用的，影响SMS站点、服务器以及客户端部署的安全策略有哪些？创建了哪些安全组？

谁是管理员？他需要执行哪些与管理有关的任务

对于用户和计算机，都强制使用了哪些组策略和客户端锁定级别？

用户对于自己的桌面具有的权限范围也可能会影响到SMS系统很多方面的安全性，例如客户端以及部署软件的安装等，这些会在本书的其他章节中介绍。另外，我们可能还需要解决管理任务的委派问题，以便决定给每个用户分配怎样的权限。

3.8 备份和恢复规划

在SMS 2003分层结构部署的早期阶段，是考虑备份和还原要求，制订还原计划，将备份和还原准备工作结合到SMS部署计划中的最佳时机。

站点还原是一个复杂的过程，建议预先规划和准备。这将为我们带来以下收益：

最大限度地降低了站点故障的风险。

最大限度地降低了站点故障的影响（如果发生的话）。

我们可以简化还原程序，缩短还原过程的时间，最大限度地减少在发生故障时的数据丢失情况。