将SharePoint功能映射到业务需求
当部署SharePoint时，关于可伸缩性的主要关注是有多少用户会使用该系统。对于部门合作来说，这个数字可能很小。另一方面，对于大型的、公开可访问的门户，这个数字可能会迅速增加。基于用户数量来缩放SharePoint实现是很简单的，但可以作为一个起点。除了用户总数之外，还应该确定以下因素，以便更充分地了解SharePoint服务器上的负载:
用户数量
每个用户每个工作日的页数
工作日数(小时)
所执行的工作类型和Office集成水平
文档存储库的大小
收集这些信息并了解谁将访问SharePoint环境是正确扩展环境的第一步。
使用SharePoint规划容量
在设计SharePoint环境时，最好是简单地开始设计，然后根据需要扩展设计。对于SharePoint，这意味着应该规划单个服务器，并在识别新约束时添加其他服务器。在SharePoint中，单个服务器不应该超过几个通用限制，这些限制应该被理解。这些限制如下:
SharePoint用户数小于2000- SharePoint站点中定义的用户数量不能超过2000，否则会有性能下降的风险。如果需要更多的用户，可以使用Active Directory组成员关系将用户数量扩展到数万。
现场收藏少于50,000件-每个站点集合应该容纳不超过50,000个用户，以获得最佳性能。
下属网站少于2000个-超过2,000个子站点会降低服务器性能。
文档库中单个文件夹中的文档少于10,000个—如果在一个文件夹中存储超过10,000个文档，性能会下降。然而，使用多个文件夹会将这个限制增加到将近200万个文档。
视图中的项目少于2000个-超过这个就会减慢访问速度。
每页少于100个网页部件-加载超过100个网页部件会降低用户浏览网页的速度。
个人文件大小小于50MB-文档越大，对环境的压力就越大。SharePoint默认的“硬限制”是50MB;任何更大的文档都会严重减慢服务器的速度。文档的最大大小是2GB。
理解这些限制是扩展环境的重要部分。如果在设计和实现了SharePoint环境之后，达到了这些限制中的任何一个，那么SharePoint应该进行缩放以匹配。
测量内容增长
除了最初加载到SharePoint的数据量外，了解内容的增长速度对于适当扩展环境至关重要。在SharePoint部署一年后耗尽存储空间并不是一个理想的情况。了解内容的增长速度以及如何控制这种不可避免的增长非常重要。
正确使用SharePoint中的站点配额是控制SharePoint数据库可以增长到的大小的有效方法。在创建站点配额时实现站点配额是推荐的最佳实践方法，在大多数情况下都应该考虑。SharePoint很容易因不必要的数据而膨胀，站点配额有助于本地站点管理员合理使用可用空间。
SharePoint的SQL数据库可以急剧增长，这取决于它的使用程度和包含的内容类型。表3.1说明了各种数据源对SQL数据库的影响。特别需要注意的是搜索和索引内容，它们可以随着现有内容的增长而增长。
表3.1各组件对SQL Server的影响
存储类型 |
大小 |
数据库开销 |
12 mb |
WSS网站开销 |
4 mb |
文档元数据(10个属性) |
12 kb |
搜索内容 |
高达25%的内容大小 |
索引的内容 |
高达50%的内容大小 |
事务日志 |
最初内容上传后，平均占内容大小的2-4% |
在实现SharePoint之后，监控系统以确保它不会为了自己的利益而发展过快是很重要的。除了一些默认的警报和工具，Microsoft Operations Manager (MOM)还专门设计了一个管理包来收集关于SharePoint的信息，包括监控特定组件的增长。
扩展逻辑SharePoint组件
SharePoint成功的关键在于它能够智能地为每个用户提供所需的信息，允许他们快速、容易地访问这些信息。SharePoint通过各种逻辑机制来实现这一点，这些逻辑机制帮助组织内容，以一种将非结构化数据拉到一起并呈现给用户的方式构建内容。例如，文件服务器只是以简单的文件结构将杂乱的文档组合在一起。这些文档的多个版本进一步混淆了这个问题。SharePoint包含将这些文档组织成逻辑文档库的机制，这些文档库可以根据元数据进行分类，这些元数据可以通过最新版本进行搜索和呈现。
除了最明显的逻辑组件外，SharePoint还允许数据集向外扩展，以支持用户组。例如，通过使用不同的站点集合及其自己独特的权限集，SharePoint可以配置为在同一组机器上托管不同的用户组，从而增加灵活性。
扩展站点集合
在SharePoint Team Services和Windows SharePoint Services 2.0成功的基础上，Windows SharePoint Services 3.0中的SharePoint站点允许不同的团队或用户组访问与他们相关的特定信息。例如，可以为公司的每个部门建立站点，以允许他们访问与其组相关的信息。
站点可以向外扩展，以支持每个用户组的各种站点集合。这允许数据在逻辑上分布在SharePoint环境中，允许更大的用户群体分布在SharePoint服务器环境中。每个站点集合可以由在站点结构中指定的唯一所有者管理，如图3.1．这使得SharePoint站点的安全性得以扩展。
使用IIS虚拟服务器和Web应用程序扩展
SharePoint将数据存储在SQL Server 2000/2005数据库中，但通过HTML和ASP提供对数据的访问。净的web服务。用户可以通过Windows Server 2003 Internet信息服务(IIS) 6.0访问这些数据。IIS由各种逻辑结构组成，称为虚拟服务器这些网站是浏览网页内容的入口。每个虚拟服务器可以配置为指向位于web服务器上的各种信息集，或通过SharePoint扩展为唯一的SharePoint web应用程序。
为SharePoint站点设置站点权限。
注意:SharePoint 2007中的web应用程序相当于SharePoint portal Server 2003产品中的门户。Web应用程序在物理上是SharePoint的唯一实例，具有不同的站点集合集和不同的设置。例如，一个组织可以为外部供应商提供一个web应用程序，为内部员工提供另一个单独的web应用程序，以保持数据在物理上分离，并提供不同的身份验证设置。
通过SharePoint使用独特的虚拟服务器和/或web应用程序可以帮助进一步扩展环境的功能，允许使用安全套接字层(SSL)加密或跨不同端口灵活地授予访问SharePoint的权限。此外，部署多个虚拟服务器允许为SharePoint组织使用多个主机头，如sharepoint.companyabc.com、docs.companyabc.com、infoo.companyabc.com、moss.organizationa.com等。
利用和理解SharePoint的集群
SharePoint-Windows Server 2003的操作系统提供了两种集群技术:网络负载均衡(MSCS)。NLB在所有版本的平台上都可用，包括标准版，而MSCS仅在企业和数据中心服务器平台上可用。聚类是在网络上作为单个系统访问和查看的独立服务器节点的分组。当应用程序从集群运行时，最终用户可以连接到单个集群节点来执行他的工作，或者每个请求可以由集群中的多个节点处理。在数据只读的情况下，客户端可以请求数据并从集群中的所有节点接收信息，从而提高整体性能和响应时间。
Windows Server 2003中的集群技术可以帮助扩展SharePoint，允许更多的资源在整个环境中提供帮助。例如，多个网络负载均衡的SharePoint前端服务器可以将流量分配到一组SQL数据库服务器，如图所示图3.2．
支持nlb的前端服务器和集群SQL数据库服务器。
第一个Windows Server 2003集群技术是NLB，它最适合为前端SharePoint web服务器提供容错。NLB通过让集群中的每个服务器单独运行网络服务或应用程序，消除任何单点故障，从而提供容错和负载平衡。
Windows Server 2003提供的第二种集群技术是集群服务，也称为微软集群服务或简称MSCS。群集服务通过一个被调用的进程提供系统容错故障转移．当系统发生故障或无法响应客户端请求时，集群服务将脱机，并从故障服务器转移到另一个可用服务器，在那里它们将联机并开始响应现有的和新的连接和请求。群集服务最适合用于提供文件、打印、企业消息传递和数据库服务器的容错性。
注意:微软不支持在同一台计算机上同时运行MSCS和NLB，因为这两种技术之间可能存在硬件共享冲突。
主动/被动理解集群
主动/被动聚类当集群中的一个节点提供集群服务，而其他可用节点保持在线，但不向最终用户提供服务或应用程序时发生。当主动节点发生故障时，之前在该节点上运行的集群组将故障转移到被动节点，导致该节点在集群中的参与状态从被动状态变为主动状态，开始为客户端请求提供服务。
这种配置通常是通过数据库服务器实现的，这些服务器提供对仅存储在一个位置的数据的访问，这些数据太大，无法在一天中进行复制。主动/被动模式的一个优点是，如果集群中的每个节点都具有类似的硬件规格，则在发生故障转移时不会造成性能损失。这种模式的唯一缺点是，在日常集群操作期间无法利用被动节点的硬件资源。
注意:主动/被动配置是保持集群管理和维护尽可能低的一个很好的选择。例如，被动节点可以测试更新和其他补丁，而不会直接影响生产。然而，在隔离的实验室环境中进行测试还是很重要的，或者至少在几个小时后或预定义的维护窗口期间进行测试。
了解Active/Active集群模式
当应用程序的一个实例在集群的每个节点上运行时，就会发生活动/活动集群。当发生故障时，一个集群节点上可以运行两个或多个应用程序实例。主动/主动模式相对于主动/被动模式的优势在于，每个节点上的物理硬件资源都是同时使用的。这种配置的主要缺点是，如果您以100%的容量运行集群的每个节点，当某个节点故障时，其余的活动节点将承担故障节点的100%负载，这将大大降低性能。因此，在任何时候都要监视服务器资源，并确保每个节点都有足够的资源来接管其他节点的职责，如果其他节点发生故障转移的话。
为SharePoint选择正确的集群技术
为了使这些容错集群技术最有效，管理员必须仔细选择最适合他们特定SharePoint需求的技术和配置。NLB最适合为无状态的SharePoint前端web服务器提供连接。这提供了可伸缩性，它提供的冗余量取决于NLB集中的系统数量。Windows Server 2003集群服务为关键应用程序(如SharePoint的SQL数据库服务器)提供了服务器故障转移功能。
尽管微软不支持使用活检和msc在同一台服务器上,这两种技术的多层应用程序可以利用使用NLB前端应用服务器的负载平衡和使用msc提供故障转移功能的后台SQL数据库包含数据太大复制在白天。
为SharePoint选择Microsoft集群服务
Microsoft群集服务是一种集群技术，通过使用称为故障转移的过程提供系统级容错。MSCS在SharePoint中用于提供对SQL数据库服务器或服务器的访问。调用由集群定义和管理的应用程序和网络服务，以及集群硬件(包括共享磁盘存储和网卡)集群的资源．群集服务监视这些资源以确保正确操作。
当集群资源出现问题时，cluster Service会在资源完全失败之前尝试修复问题。运行失败资源的集群节点首先尝试重新启动同一节点上的资源。如果无法重新启动资源，集群将使资源失效，将集群组脱机，并将其移动到另一个可用节点，然后重新启动资源。
有几个条件可能导致集群组进行故障转移。当集群中的活动节点失去电源或网络连接，或遭受硬件故障时，就会发生故障转移。此外，当一个集群资源在一个活动节点上不能保持可用时，资源的组被移到一个可用节点上，在那里可以启动资源。在大多数情况下，故障转移过程要么被客户端视为服务的短暂中断，要么根本不会造成中断。
为了避免不必要的故障转移，应该在主板BIOS中的每个集群节点、网络接口卡和操作系统控制面板中的power applet中禁用电源管理。允许监视器关闭的电源设置是可以的，但是管理员必须确保磁盘被配置为永远不会进入待机模式。
集群节点可以监视在其本地系统上运行的资源的状态，并可以通过调用的私有网络通信消息跟踪集群中的其他节点心跳．心跳确定节点的状态，并将集群配置更改的更新发送到集群仲裁资源。
仲裁资源包含将集群恢复到工作状态所需的集群配置数据。集群中的每个节点都需要访问仲裁资源;否则，它将无法参与集群。Windows Server 2003提供三种类型的仲裁资源，每种类型适用于每个集群配置模型。
使用MSCS的集群最常用于SharePoint配置，以提供SQL数据库服务器上的服务器冗余。通过在SharePoint SQL数据库服务器上实现MSCS集群，服务器组件本身变得更加冗余，而不是实际的数据库本身，因为它存储在共享存储组件上。
为SharePoint选择网络负载均衡
Windows Server 2003中可用的第二种集群技术是NLB。NLB集群通过在多个服务器上平衡客户端请求来提供高网络性能和可用性。当客户机负载增加时，NLB集群可以很容易地向外扩展，通过向集群中添加更多的节点来维护或提供更好的客户机请求响应时间。
NLB的两个重要特性是不需要专用硬件，并且可以在几分钟内配置和运行一个NLB集群。NLB集群可以增长到32个节点，但如果需要更大的集群场，则应该研究DNS(域名服务器)轮询或第三方解决方案，以满足这一更大的需求。
需要记住的重要一点是，在NLB集群中，每个服务器的配置必须独立地更新。NLB管理员负责确保应用程序配置和数据在每个节点上保持一致。可以使用Microsoft的Application Center等应用程序来管理参与NLB集群的服务器之间的内容和配置数据。
NLB是SharePoint中最常用的一种机制，用于提供对多个SharePoint前端服务器的负载平衡访问。寻求扩大SharePoint前端功能的组织应该考虑在环境中使用该技术。
使用高可用性替代扩展SQL Server
高可用性解决方案掩盖硬件或软件故障的影响，并维护应用程序的可用性，以便将用户感知的停机时间降至最低。如果需要不间断地运行组织的SharePoint数据库，建议实现SharePoint的it专业人员理解SQL Server提供的高可用性替代方案。
关于SharePoint, SQL Server 2005提供了三种高可用性替代方案:日志传送、故障转移集群和数据库镜像。点对点复制是另一种SQL高可用性替代方案;但是，它不适用于SharePoint。它通过基于已建立的事务复制技术的可伸缩性实现负载平衡和提高可用性。下面的章节将描述适用于SharePoint的SQL Server 2005高可用性替代方案。
日志传送
对于从源SQL Server创建数据库冗余副本到另一个目标SQL Server，日志传送是推荐的解决方案，如图3.3．日志传送的正常过程包括从源服务器(主服务器)备份事务日志，复制到另一个目标服务器(辅助服务器)，最后恢复事务日志。以前，日志传送仅在SQL Server 2000的企业版中可用。但是，它现在包含在SQL Server 2005标准版和企业版中。
理解日志传送的概念。
要为SharePoint关键任务数据库提供高可用性，日志传送就足够了，首先，它不昂贵，其次，它相对容易管理。与与硬件集群相关的高得多的成本相比，这是创建冗余数据库的最经济有效的方法。与数据库镜像(仅限于单个目标服务器)不同，在使用日志传送时，可以配置多个辅助服务器以实现冗余。
另一方面，日志传送提供了一种较慢的手动故障转移过程，这不是无缝的。因此，与Windows集群和数据库镜像方法相比，日志传送可能不是为组织提供高可用性的最佳解决方案。所有的SharePoint数据库连接也必须手动更改，以反映新的目标SQL Server的名称。
Windows 2003和SQL Server 2005集群
Windows Server 2003和SQL Server 2005支持无共享集群模型。在无共享集群中，集群的每个节点拥有和管理其本地资源，并提供非共享数据服务。当节点发生故障时，该节点上运行的硬盘和业务将自动切换到集群中幸存的节点上。然而，使用高可用性集群，在任何给定时间，只有一个节点管理一组特定的磁盘和服务。
在Windows 2003 Enterprise或Windows 2003 Datacenter上的SQL 2005可以在单个集群中支持最多8个节点。SQL Server 2005的故障转移集群可以通过两种方式配置:单实例故障转移(Active/Passive)配置或多实例故障转移(Active/Active)配置。
注意:可以使用SQL Server 2005标准版创建双节点集群，这在过去是不可能的。
单实例故障转移配置
在SQL Server单实例故障转移配置中，如图3.4，集群在集群中的所有节点上运行一个SQL Server实例。如果主节点上的主SharePoint SQL Server实例失败，幸存的节点将运行相同的SQL Server实例。在这个配置中，集群中的所有服务器共享一个主数据库以及一组SharePoint数据库，例如配置数据库和内容数据库。
理解单实例故障转移配置。
多实例故障转移配置
在多实例故障转移配置中，如图3.5，每个活动节点都有自己的SQL Server实例。每个SQL Server实例都包含完整服务的单独安装，可以独立地管理、升级和停止。要应用多实例故障转移配置，集群上必须安装至少两个SQL Server实例，并且每个实例都应配置为在某个节点上作为其主服务器运行。
多实例故障转移配置。
出于可扩展性的目的，可以在SQL Server的实例中分离SharePoint数据库。经常相互引用的SharePoint数据库应该放在同一个SQL Server实例上。在实现多实例故障转移配置之前，应该首先评估每个数据库应用程序上的预期负载，然后进行第二次评估，以确定单个节点是否能够在故障转移情况下处理组合负载。如果单个节点不能工作，则应考虑使用两个单实例故障转移模式集群。
注意:SharePoint数据库不会在SQL Server的多个实例之间静态负载均衡。这种设计方案最适合拥有独立数据库的组织，这些数据库可以从同时使用的多个服务器(如多个站点和内容数据库)中受益。
数据库镜像
数据库镜像是SQL Server 2005中引入的一种新的高可用性替代方案。此解决方案通过在热备服务器上实时维护源数据库的最新副本来提高数据库可用性。
数据库镜像由两个必选角色和第三个可选角色组成。第一个强制角色是Principal Server，它包含源数据库，是所有事务的源。次要的强制角色是Mirror Server，它是另一个服务器，主要用于从主体服务器接收事务。见证服务器是第三个可选角色，它在发生故障时检测并启用主体服务器和镜像服务器之间的自动故障转移。
了解数据库镜像。
镜像是在每个数据库的基础上实现的，并且只适用于使用完整恢复模型的数据库。简单和大容量日志恢复模型不支持数据库镜像。SQL Server 2005标准版和企业版支持数据库镜像。
与以前的高可用性替代方案相比，数据库镜像在可用性方面提供了实质性的改进。实现很简单，维护起来也很简单。它类似于日志运输;但是，当数据库镜像会话同步时，它提供了一个热备份服务器，支持快速故障转移，而不会丢失提交事务的数据。此外，与日志传送不同的是，故障转移几乎是无缝的，客户机应用程序可以通过重新连接到镜像服务器来进行恢复，从而产生轻微的中断。
注意:数据库镜像是在SQL Server 2005发布时引入的。但是，该功能在默认情况下没有启用，并且在生产中不被微软支持。SQL Server 2005的Service Pack 1版本现在支持数据库镜像。
选择适当的SQL Server高可用性备选方案
为SharePoint设计后端数据库基础设施的IT专业人员面临着为他们的解决方案选择合适的高可用性技术的困境。如果组织中的服务级别协议需要热备份服务器用于立即故障转移，则在High Availability Configuration模式下进行故障转移集群和数据库镜像是正确的选择。对于管理员和客户端来说，故障转移几乎是无缝的。如果需要热备用服务器(其中需要较便宜的解决方案，但不是立即解决方案)，则使用High Protection或High Performance模式的日志传送和数据库镜像应该足够了。在这种情况下，必须手动进行故障转移，客户端将首先受到影响。最后，影响这些决策的其他因素是成本、硬件和站点邻近性。
跨SharePoint Farm扩展
除了SharePoint的逻辑结构(可以扩展)之外，SharePoint还包括在多个服务器上物理地传播数据和内容的能力。这是自SharePoint的第一个版本以来实现的主要设计变化之一，SharePoint的第一个版本没有很好地扩展到单个服务器之外。SharePoint农场的概念随后允许更大范围的灵活性和可伸缩性的环境，因为服务和数据库可以分布。
定义场服务器组件
SharePoint农场由两个、三个、四个或更多的服务器组成，共享一个共同的配置数据库。场除了为环境提供有限程度的额外冗余之外，还提供跨多台机器的处理和应用程序能力分布。
安装到SharePoint场中的每个SharePoint服务器在该环境中都承担特定的角色集。SharePoint服务器在集群中的角色如下:
Web服务器-这种类型的SharePoint服务器是无状态的，不包含任何数据。它用于为终端用户提供基于网络的服务。作为前端服务器配置的一部分，可以部署多个负载均衡的web服务器，将SharePoint数据的分布向多个用户扩展。
搜索索引服务器-指定的搜索服务器用于对SharePoint中的索引数据进行搜索。
Excel计算服务器Excel计算服务器运行Excel服务所需的计算，为浏览器客户端提供电子表格功能。
数据库服务器-数据库服务器可以运行SQL server 2000或SQL server 2005，其中包含SharePoint数据库。Windows SharePoint服务还可以在SQL的轻版本上存放数据库，称为MSDE在SQL 2000和SQL Server Express在2005年。数据库可以跨多个位置分割，一个场中的多个内容数据库可以跨多个数据库服务器分割。
注意:一台服务器可以执行SharePoint场中列出的多个角色。事实上，在特定的服务器上执行多个角色比为每个任务配置专用服务器更常见。
由于一个组织对SharePoint的需求已经超出了单个服务器的能力范围，因此向farm中添加额外的服务器就成为了一种必要。了解如何设计这些服务器并将其适当地扩展到环境中是关键。
利用SharePoint农场的共享服务
SharePoint的可伸缩性并没有在场级别结束。相反，SharePoint将资源扩展到大型部署的能力是由共享服务的概念支持的。共享服务是跨多个SharePoint农场共享特定功能的能力。例如，可以利用共享服务模型在多个SharePoint农场中扩展搜索功能。虽然不能使用此方法共享单个项目，但可以共享以下项目:
警报
观众
个人Mysites
单点登录服务
业务数据目录
Excel Services
门户使用情况报告
SharePoint服务器搜索和索引
用户配置文件
但是，使用共享服务方法部署SharePoint存在一些限制。使用该模型的局限性如下:
父场和子场服务器必须属于同一个域或受信任域环境。
服务器群不能被防火墙分隔开，而且必须在彼此之间具有实质上的完全网络访问。
SharePoint服务器的版本和语言必须在每个farm的服务器之间相同。
子站点不能与父站点切换角色。
当配置为使用共享服务时，不能从该功能中删除服务器场。此外，必须关闭子服务器群中的一些服务才能使用共享服务。
对于最大的SharePoint部署，共享服务允许超出服务器场本身的一定程度的可伸缩性，允许在多个SharePoint环境之间共享资源。
Microsoft Office SharePoint Server (MOSS) 2007要求为每个farm创建共享服务实例，而不管farm的大小如何。即使是单个服务器实例也必须构建共享服务提供者(SSP)。SSP用于管理农场范围内的特定内容，如果农场未来要扩大，则使用它作为占位符。
证明和部署业务门户
随着提供门户结构的成本下降，创建基于门户的解决方案(而不是在个人pc上购买、安装和维护软件以访问信息)具有业务意义。在每个桌面维护一个web浏览器和一个足够灵活的集中式应用程序结构来为任何一组用户提供访问，这通常更划算，并为实现创新解决方案提供了一种方法，而使用传统方法可能会成本太高。当应用程序或新特性添加到门户时，用户可以立即使用它们，而无需接触每个桌面。通过网络浏览器交付信息和应用程序也减少了IT部门的负担，同时为他们提供必要的控制谁可以访问信息和应用程序。
为门户解决方案利用各种SharePoint组件
商业门户的主干是Microsoft Office SharePoint Server 2007。它提供了创建企业门户的平台，用于集中管理、存储、共享和访问信息。经过适当设计后，门户可用于快速查找相关信息并提供团队协作的方法。用户可以创建他们自己的自定义门户视图来满足他们的需求，并且可以根据个人的角色来定位信息。
团队和工作组协作、文档管理和列表管理都是使用MOSS 2007中的Windows SharePoint Services 3.0引擎完成的。它旨在促进信息共享和文档协作。它的特性使用户和团队能够轻松地一起工作，并使管理人员能够协调内容和活动。当Microsoft Office 2003/2007与Windows SharePoint服务结合使用时，通过提供一个集成的桌面，使用用户熟悉的工具访问服务器协作服务，进一步提高了用户的工作效率。
利用Office 2007/2003技术实现全面门户协作
Microsoft Office 2007和较早的2003版本提供了用户熟悉的界面，是创建和修改文档的主要工具。微软Office 2007/2003的一些元素也可以与SharePoint技术集成，以提供以网络为中心的信息访问功能。
SharePoint 2007环境的最紧密集成可以通过2007版本的Office客户端实现;但是，SharePoint 2007场支持2003客户端。尽管有技术支持，但通常不建议在SharePoint 2007环境中使用旧版本的Office，如Office XP或Office 2000，因为存在主要的功能限制。
使用BizTalk Server 2006管理业务流程
Microsoft BizTalk Server 2006和定制开发的web部件提供了将业务线应用程序集成到MOSS 2007环境中的方法。Microsoft BizTalk Server 2006包含了集成应用程序的工具，而web部分可以开发为与SharePoint的集成。这为最终用户提供了执行业务事务和从业务系统检索信息的能力，而无需离开站点或学习新的应用程序。此外，BizTalk本身集中了对不同数量的企业数据的访问和控制，允许做出更智能的业务决策。
改进与Exchange Server 2007集成的通信和协作
一个有效的SharePoint环境在其设计中包含了协作和交流的概念。例如，文档更改时提醒用户的功能就利用了电子邮件路由。莫斯2007接口的能力与任何SMTP(简单邮件传输协议)服务器传递消息,但是是最有效的,当结合最新的2007版的交换,因为多个新的两个应用程序之间的集成点了,都在几个月内公布。
在Exchange Server 2007中使用SharePoint 2007，或者在较小程度上使用Exchange 2003，可以与Exchange本身的各种组件紧密集成，比如共享日历、直接访问邮箱项目、任务列表和公用文件夹。例如，可以将警报发送到特定的邮箱，以允许多个用户查看它们。部门日历可以在Exchange中设置，并在SharePoint中显示。
利用SharePoint的现有Exchange Server 2007部署极大地扩展了这两个应用程序的覆盖范围，填补了两个产品功能上的空白。这些技术的组合可以创建功能最强大的协作环境。
注意:较小版本的Exchange，如Exchange 2000/2003，可以直接从SharePoint内部支持作为web部件，尽管与Exchange Server 2007版本的Outlook web Access的集成功能不那么丰富。
更多关于Exchange 2007和配置Exchange以配合SharePoint 2007的详细信息，请参见第18章“配置启用电子邮件的内容和Exchange服务器集成”。
用SharePoint特性解决常见的业务问题
MOSS 2007和Windows SharePoint服务3.0旨在解决企业中经常出现的业务需求和问题。本节汇集了本书其他章节中描述的SharePoint特性的信息，来总结一些常见的业务问题，以及如何使用SharePoint特性来解决这些问题。描述这些问题的场景以及可用于解决该特定问题的特定SharePoint技术。
用SharePoint处理文档的冗余重建
在许多组织中，用户通过创建文档或在组织中其他人已经这样做时收集信息来重复工作。这是因为用户不知道信息的存在，或者他们找不到信息，从而导致时间的浪费。
SharePoint解决方案: SharePoint文档库、工作区、元数据信息和列表的全文索引和搜索
Windows SharePoint Services站点的SQL全文索引支持对站点内容进行索引和搜索，以便用户能够快速找到他们需要的文档或信息。
解决无法有效搜索不同类型内容的问题
用户需要信息，而获取信息的唯一方法通常是在多个内容源上执行多个不同类型的搜索，然后手工合并结果。这将导致内容不被搜索的可能性(要么因为它被忽略了，要么只是花费了太多的时间)以及时间的低效使用。
SharePoint解决方案可以被索引和搜索的MOSS 2007内容源
在SharePoint 2007环境中添加经常使用的信息源作为内容源，使用户可以执行一个搜索请求，并将来自许多不同内容源的结果显示在一起。例如，一个单一的SharePoint搜索请求可以跨越其他SharePoint站点、组织外部的网站、文件共享和Microsoft Exchange公共文件夹。这使用户能够轻松地跨多个来源搜索，以找到他们需要的信息。
注意:只有完整的MOSS 2007版本的产品支持搜索和索引来自外部来源的内容。WSS 3.0只支持对WSS站点的本地内容进行索引。
用SharePoint文档库解决低效的文档协作方式
一组人需要在一个项目上进行协作，并生成一组要发送给客户的文档。用户A处理第一个文档，并将其保存为“Doc1”。用户A给用户B发送邮件，告知用户B可以查看该文档。用户B进行更改和添加，并将文档保存为“Doc1 R1”。用户B创建一个邮件列表的关于额外的变化,使和电子邮件用户和用户C用户C回复用户a和用户B关于用户B的邮件修改建议,使自己的变化,将其保存为“Doc1 R2,”和电子邮件用户a和B,让他们知道改变了。用户A也会回复建议的修改，对文档进行“最终”修改，保存为“Doc1 final”，并通过电子邮件将文档发送给客户。
两天后，客户端通过电子邮件返回了客户端希望在文档中看到的更改列表。用户A再次编辑文档，并将其保存为“Doc1 Final R1”。这个过程会一直持续下去，直到突然出现了10个版本的文档和16封关于文档应该包含什么的电子邮件。在这一点上，团队不确定做了什么更改，存储文档的文件夹中混杂着文档的不同版本(占用了很多空间)，没有人知道哪个版本发送给了客户端。
SharePoint解决方案: WSS团队站点，共享文档库，文档版本控制，文档讨论