那些使用Exchange的机构很快就觉得他们不仅仅满足于使用Exchange来为每个用户提供一个邮箱，有时他们希望能够创建一个邮箱，不是为一个特定的用户，而是为一个机构，一个商业部门，或者是一种职能。我把这种邮箱称为资源邮箱（Resource Mailbox）。比如说，许多公司经常需要创建以support@和help@开头的邮件地址，这样便于顾客记忆，从而直接发送技术相关的问题到这些地址。另外还有一些机构会创建一个邮箱，这个邮箱把收到的邮件转发到外面的多个收件人。但是根据我们的经验，在这些情况当中，真正的邮箱不一定总是最合适和有效的。这时候我们应该考虑是否需要另外的邮箱或者干脆使用其它的方法。在这里，让我们来看看何时该使用不同类型的Exchange资源以及如何使用这些资源。
Exchange资源
当一些人从商业角度提出需要Exchange的资源时。我们一般会认为他需要的是一个邮箱。比如说，一个经理希望建立一个日历，这样的话，他的下属就可以在这个日历上注明他们哪天在公司，哪天外出。通过查看这个日历，经理就可以知道哪天办公室人手紧缺，从而提前调配人手以确保所有的工作都可以被完成。这个经理之所以提出他需要一个额外的邮箱的原因是他已经熟悉了他自己邮箱中的日历功能。尽管为这个经理创建一个邮箱能够满足他的需要，但是一个更可行的方案是使用公用文件夹上的日历功能。
除了邮箱之外，Exchange提供了其它两种资源：公用文件夹和邮件分发列表（distribution lists，简称DLs）。您可以为所有类型的Exchange资源（邮箱、公用文件夹以及邮件分发列表）创建email地址，赋予另一个邮箱对于这个地址send-as的权限。为Exchange资源创建email地址意味着这个资源可以接收从Internet用户或非Exchange（但是使用SMTP）用户发来的邮件。Send-as权限允许一个Exchange邮箱模仿另一个资源发送邮件。这样做的优点就在于收件人所看到的这封邮件的发件人是这个资源而非真正的发送这封邮件的人，他拥有对于资源send-as的权限。如果收件人回复这封邮件，那么回复邮件将被直接发往这个资源。
举个例子，对于特定公用文件夹“Outage Notifications” 我具备send-as的权限。这样的话，当我写一封邮件的时候，我就可以在发件人一栏中填写“Outage Notifications”。当收件人看到这封邮件的时候，收件人将是Outage Notifications，而不是我。同样的，点击发件人打开属性，显示的也是这个公用文件夹的属性而不是我的。如果收件人回复这封邮件，回复邮件将被直接发往这个公用文件夹。
换种说法，我们也可以有一个名为“Outage Notifications”的邮件分发列表，我具备这个DL的send-as的权限。当我写邮件的时候，我还是填写“Outage Notifications”作为发件人。在我发出这封邮件之后，收件人也不会看到我的名字，显示的只有这个DL的名字。您可能觉得使用DL来发信有点奇怪，但是许多内部的收件人并不能发辫出这封邮件是出自一个DL，除非他双击打开发件人的属性页。同样的，因为外部的收件人只能看见发件人的名字和SMTP地址，他们也不会知道发件人是一个DL。使用DL作为发件人的优点在于用户可以直接回复邮件给存在于这个DL中的一个或多个成员。当发送邮件时，Exchange不会使用或者显示任何关于这个DL成员列表的信息；Exchange只会使用这个DL的名字和地址。但是当一封回复邮件发往这个DL时，它的成员列表就会被展开，其中的每个成员都会收到这封回信。
您应该使用哪种资源
现在的问题是，哪种资源更适合您的环境？要回答这个问题，我们需要知道更多问题的答案。根据我以往的经验，很多情况下，用户都不会要求用到邮箱中的高级功能（像规则，委派），但是却会涉及到一些基本功能，像仅发邮件，仅收邮件，同时收发邮件，增加一个日历文件夹，或者是增加一个可安排的资源。那么我们要问的第一个问题就是“为什么您需要一个邮箱？”我们得到的答案可能非常的冗长，复杂。但是我们总可以剥离掉表面的描述，把答案归类为两种：用户需要一个邮箱资源来收发邮件，或者用户需要某种类型的日历功能。当您知道了您需要处理的是这样一种需求时，您就可以问几个更加深入的问题来决定最适合的资源类型以及如何来配置它。
邮箱资源
让我们回到前面的那个outage-notifications的例子。对于简单以outage-notifications的名义发送邮件，使用任意三种类型的资源都是可行的。但是在邮件发送出去之后的行为会和所使用资源的类型有密切的联系，比如说如果您希望收到回信，您应该使用何种类型的资源。要决定哪种资源最适合您的需求，我们还可以问这么几个问题：收件人会回复这封邮件吗？谁将阅读发往这个地址的邮件？如果需要，谁将回复发往这个地址的邮件？您是否需要存储这些通信的副本？我们可以通过对于这些问题的回答来判断最合适的类型。
收件人会回复这封邮件吗？总是有一些人会回复这封邮件的——即使您在邮件的标题中注明“不要回复”。我把这种邮件称为垃圾邮件，这是因为没有一个人会去读这种邮件，我们也不会去浪费系统空间来存储这种邮件。如果您使用的资源是一个邮箱，并且没有打开Mailbox Manager（邮箱管理器），这就需要有人周期性的来清除这些垃圾邮件了。如果您使用的资源是一个公用文件夹，您可以为它设定一个时间限制，Exchange将会自动删除那些超过一定时间的邮件。但是我最喜欢使用的资源还是DL，在里面不包括任何的成员，这样就可以很好的防止垃圾回复邮件了。比如说，您创建一个DL名为不要回复（Do Not Reply），它的email地址是do-not-reply@YourDomain.com。当我们使用这个DL作为发件人时，外部的收件人不能分辨出它的发件人是DL，而内部用户只有通过打开发件人的属性页才能了解它是一个DL。一旦收件人回复这封邮件，它将被发往这个DL，Exchange的路由引擎将会自动放弃这封邮件因为它检测到这个DL不包含任何成员。
谁将阅读发往这个地址的邮件？如果需要，谁将回复发往这个地址的邮件？无论您所创建的这个地址是否希望被用来接收邮件,当您使用这个地址发送邮件之后，收件人可能会直接回复这封邮件，也可能发送一封新的邮件到这个地址，您事先需要知道谁应当阅读这些邮件，以及他们如何在他们的工作中使用这些邮件。同样的，每一种资源类型都可以接收邮件，但是它们也都有各自独一无二的特点。
虽然邮箱可以让您赋予多个用户访问的权限，但是一旦使用邮箱，您需要知道一个隐藏的假设条件就是只有一个人会阅读这封邮件。这样的话，当这封邮件的状态变为已读时，就没有必要去考虑是否其他人将会去读这封邮件了。相比较而言，使用共用文件夹就默认多个用户将会阅读这封邮件，它为每个用户提供跟踪这封邮件阅读状态的功能。而邮件分发列表DLs仅仅将邮件传递到它的成员的邮箱中，并且不提供状态跟踪的功能。它提供了一种非常简便的方式来把邮件发送到那些希望阅读到这些信息的用户的邮箱中，又不需要他们执行任何其它的操作。同时DLs还为管理员提供了一种非常简单和灵活的方式来向成员列表中添加新的希望接收到这些邮件的成员。
考虑一下这些差别会为您的使用带来怎样的影响。举个例子，如果您希望所有发往这个地址的邮件都被阅读并且被回复，邮箱可能是最好的选择，这是因为通过查看邮件的阅读状态我们可以判断这个邮箱的主人是否阅读过这些邮件。这就减少了多个人会阅读并切回复同一封邮件的机率。如果您需要确保所有的用户都阅读过这些邮件，公用文件夹将是您最好的选择，比如说您希望所有员工都被通知到关于安全缺口和潜在威胁的知识。考虑到公用文件夹提供基于每用户（per-user）的邮件阅读状态的跟踪，如果您希望检查是否所有用户都已经阅读这些发往这个地址的邮件，公用文件夹将是最合适的选择。
您是否需要存储这些通信的副本？一般来说,如果您希望跟踪并且保存这些通信，您就需要从技术上找到解决方案，并且在商业流程上制定规则来配合技术的实施。举个例子，如果您使用的是邮箱，并且授予一个用户直接访问这个邮箱的权利，这个用户所发送的任何邮件都将会被保存在这个邮箱的“已发送邮件”文件夹中。但是如果您授予其他用户的是对于这个邮箱资源的send-as的权限，那么所有以这个地址名义发送的邮件都将会被存储在真实发件人邮箱的“已发送邮件”文件夹中。同样的，如果使用的是公用文件夹，用户以它的名义发送的邮件也将被存储用户自己的“已发送邮件”文件夹中。这使得我们很难去追踪谁曾经回复过这封邮件，因为它们可能散布在许多不同的位置。这样同时也增加了不同的人回复这封邮件的可能性，它们有可能不一致或者是有矛盾。
唯一可以确保这些通信被保存在一个集中的位置的方法就是让用户手工去存储邮件的副本。比如说，在发送完一封邮件之后，用户需要把这封邮件从自己邮箱的“已发送邮件”文件夹复制到资源邮箱的“已发送邮件”文件夹。或者，您可以让用户Cc或者是Bcc这封邮件到公用文件夹或资源邮箱中。
可安排的资源 (日历功能)
从某种程度上来说，日历资源总是比邮箱资源要简单，这是因为Exchange服务器仅仅提供了两种日历功能：邮箱中的日历文件夹，或者是公用文件夹中的日历文件夹。当有人需要日历功能的时候，问问这些问题：您是否会在会议请求中邀请这个日历资源？是否需要委派人来监视所接收的邀请？这个日历是否需要使用规则，是否需要自动回复邮件？用户是否需要直接在这个日历中更新内容？
如果您不需要高级功能来检查资源是否在同一时段被重复定用，也不需要任何形式的规则或者委派人参与，公用文件夹中的日历就是最好的选择了。同样的，如果这个日历依赖用户手工检查资源的有效性以及是否在同一时段被重复定用，公用文件夹中的日历也是非常理想的。我本人也倾向于使用公用文件夹中的日历功能，因为这样您就可以中央控制和管理可安排的资源。另外我还发现，对于一种日历资源来说伴随着会议邀请一起发送的附件会浪费很多的存储空间。通过使用公用文件夹中的日历功能，我们可以非常简单的删除超过一定时间的内容。
但是如果您需要一些高级的功能，像用户可以直接预订资源，使用委派人和规则，追踪会议被邀请人同意或者拒绝的状态，基于邮箱的日历功能将会更加适合您。还有一种情况是，如果您有一些应用程序需要使用这个日历的忙闲信息。这样情况下我们也需要使用邮箱中的日历功能。
其它因素
不论最终您选择了哪一种资源类型，您还需要考虑一些其它的因素，以便评估选择这种资源对于Exchange整体系统的影响。试着回答下面这些问题，这些资源需要多少存储空间？存储在这些资源中的内容需要保存多长时间？谁将管理这些资源，并负责“清理”老的项目以保持存储空间在规定的大小之内？这个资源预计要使用多长时间？如果缺少严格并且正确的管理，这些资源也会成为系统安全性上的漏洞，管理上的负担。一旦它们不再使用，您应当及时予以删除。
在许多情况下，当那些负责某项资源的员工离开公司或者调职到其它部门之后，这些资源的管理任务都不会有意识的被转移给新的负责人。这样就造成了资源无人管理，其中的邮件囤积的情况。另外用户经常会要求创建一个测试帐号，但是在使用完成后却没有被删除。考虑到很多帐号（包括测试帐号）都会被加到DLs中以方便他们接收群发的邮件，这就造成了那些没有被删除的测试帐号的邮箱中的邮件日积月累。要避免这种问题的发生，您需要在日常账户管理的流程中加入一些标准的操作，以便周期性的检查和评估是否每项资源还需要继续被使用。
一种使资源帐号管理变得简单的方式是在活动目录中为每个资源帐号指定所有人（如图1所示）。正如我们在图2中所看到的，所有人也会出现在Outlook地址簿中。我强烈建议使用某种方式来标识这些资源帐号，这样您就可以很容易辨识出这些资源以方便的检查。比如说，您可以把这些资源帐号放置在一个特定的组织单元（organizational unit，OU）中，也可以为这些帐号添加一个描述性的扩展属性。我个人比较喜欢使用后者，这是因为这样我就可以使用LDAP来查询或者使用csvde.exe来导出所有人属性，扩展属性，或者其它可选的属性到一个文本文件中。这使我能够非常方便的检查和评估一个资源帐号的信息。
图1：在Exchange资源帐号的活动目录属性中显示了所有人信息
图2：在Outlook地址簿查看特定资源的所有人
最后，如果用户需要使用第三方的软件来发送邮件或者访问资源邮箱，您还需要了解为了让这个软件运行所需要满足的要求。如果这个程序使用的是MAPI，POP或IMAP，您就只能使用邮箱资源了。如果这个应用程序仅仅用来写邮件（像生成一个Active Server Page——ASP的网页），它可能只是用了SMTP来生成和发送邮件。这样的话，它就没有特殊的需求，任何类型的资源都可以让它运行。
要简化决策的过程来选择最合适类型的资源，您可以使用图3所示的流程图来作为向导。这张图表尽管不是涵盖了所有情况，但是却可以为您的决策提供一个很好的起点。
图3：邮箱资源决策流程图
了解商业流程，了解解决方案
取决于相关的商业流程，是否需要同时访问，邮件存储和邮件回复的需求，您可以使用很多方式来部署资源帐号。没有一种方式是可以满足所有情况的，这是因为每一种方式都有自己的要求。选择和使用一个正确的解决方案的关键是经常去了解商业流程需要资源帐号的原因。一旦您真正了解了整个商业流程，在掌握了每种资源的特点和限制之后，您就可以把选择的资源更好的整合到您的邮件系统中去。