使用Exchange Server 2007或更新版本时，禁用邮箱是一个相当常见的操作。 但是，Technet文档没有关于禁用邮箱的副作用的详细信息。 这就是它所说的。
“此任务将从Active Directory中的用户对象中删除所有Exchange属性。根据删除的项目保留策略，Exchange存储将保留该用户对象的邮箱数据。
资料来源： http : //technet.microsoft.com/en-us/library/bb123730(v=exchg.141).aspx
但是，这一切？ 现实世界中的交换邮箱往往是高度相互关联的。 也许老板已经把日历控制权交给了秘书。 也许一组工作人员共享访问一个公共文件夹。 也许一个高级用户被授予了在几个不同地址接收电子邮件的能力。 想到两个明确的问题。
Disable-Mailbox操作可以轻松撤消吗？ 微软的文档似乎表明，禁用邮箱是一个简单的操作。 不幸的是，有几个“陷阱”。
当邮箱被禁用时，它将被重新分类为“已断开连接的邮箱”。 默认情况下，Exchange将保留断开连接的邮箱30天。 这是邮箱所在数据库的属性。 但是，Exchangepipe理员可以更改此值。 如果MailboxRetention的值设置为0，邮箱将被立即删除。 （糟糕） （在technet.com上删除邮箱保留）
编辑：断开未初始化的邮箱也将导致其立即和不可恢复的删除。 未初始化的邮箱是从未通过OWA或Outlook访问的邮箱。 当编写断开连接+重新连接邮箱的脚本时，这会造成困难，因为某些邮箱可能无法重新连接。
禁用和连接邮箱不是瞬时的。 如果您只想禁用邮箱，那很好，但是如果您打算立即重新连接邮箱，则需要注意以下两点。
Get-User来确定更改是否完全传播。） 邮箱断开连接时，配额信息将被丢弃。 如果要保留邮箱配额，则需要在发出命令禁用邮箱之前logging这些值。
同样的事情适用于EmailAddresses列表和邮箱别名。
现在事情开始变得不友善。 对于任何给定的用户，与常规交换邮箱或传统样式的公用文件夹有几种可能的联系。
“ Send-As权限由Active Directory用户对象上的ACL表示，ACL在内部存储为SID值列表。 因此，此权限可以完全在Exchange外部pipe理。
当邮箱被禁用时，它不会影响发送权限。 用户对象的访问控制列表不变，不会丢失任何信息。
如果已断开连接的邮箱重新连接到同一用户，则以前能够以该用户身份发送的任何用户都将重新获得该能力。
如果已断开连接的邮箱已连接到其他用户 ，则没有用户将能够以新用户身份进行发送。 您需要重新应用所需的“代理发送”权限给新用户。
Send on behalf权与Outlook客户端提供的“代表团”的想法密切相关。 通常授予另一个用户的send on behalf权，特别是在委托pipe理日历时。 目前还不清楚Exchange如何在内部存储这些内容，但我确实知道Send on behalf权限连接邮箱对象，而不是用户。
当邮箱被禁用时 ，所有“代表发送”连接都将被丢弃。 这不仅影响被禁用的邮箱，而且如果另一个邮箱已授予代表发送到此邮箱，该链接现在将被删除。
不用说，如果邮箱重新连接到任何用户，“代表发送”权利不会恢复。 邮箱被禁用时，这些信息会立即丢失。 我把这些链接称为“易变”。 这种波动性源于这样一个事实，即代表发送权利是唯一不在SID内部存储的特权。
奖励提示：Exchange将在AD用户对象publicDelegates和publicDelegatesBL上分别填充两个属性，分别包含提供委托权限的委托邮箱和邮箱的可分辨名称。
邮箱文件夹的权限是邮箱之间最常用的链接之一。 文件夹权限作为Outlook“授权”的后半部分非常重要，但它们通常是手动分配的，没有关联的发送代表权限。
尽pipeExchange使用基于用户SID的典型ACL表示文件夹权限，但不能像常规ACL那样操作它们。 Outlook只允许select已启用邮件的用户，同样PowerShell Add-MailboxFolderPermission cmdlet也只允许您为其他用户添加权限（如果他们具有关联的邮箱）。
如果授予用户委托文件夹权限（例如审阅者，编辑器），并且该委托的邮箱稍后被禁用 ，则权限将显示为“NT用户：DOM \ samname”。
如果委托人的邮箱重新连接到同一个用户，他们显然能够利用权限，尽pipe他们现在畸形的外观。
但是，如果委托人的邮箱连接到不同的用户 ，则该新用户将不会inheritance原始委派，因为他们没有匹配的SID。 尽pipe它看起来像授予邮箱的文件夹权限，但确实授予AD安全主体。
完全访问权限只能由Exchangepipe理员分配。 与Send-As权限类似，它们被授予AD用户对象，并基于SID在内部存储。 但与Send-As权限不同，事实certificate，完全访问权限实际上是作为Exchange邮箱对象的一部分存储的。
如果邮箱断开连接 ，具有完全访问权限的用户列表将保留在邮箱对象中。
如果已断开连接的邮箱重新连接 ，则无论连接的是哪个用户，以前具有完全访问权限的用户都将重新获得对该邮箱执行完全访问权限的权限。
奖励提示：有一个称为AutoMapping的完全访问权限的可选function。 如果在启用了AutoMapping的情况下授予完全访问权限，Exchange将填充接收FullAccess权限的用户的msExchDelegateListBL属性。 这样可以很容易地看到FullAccess有什么function，但并不总是启用，所以您不能依赖它来获得完整的答案。
公用文件夹的“ Send-As权限与常规邮箱的工作方式大致相同。 “但公用文件夹不与用户对象关联！” 你喊。 实际上，Exchange不会为您制作的每个公用文件夹在Active Directory中创build秘密对象。
（您可以使用ADSI Edit在安装Exchange服务器的林中打开根域的默认命名上下文，然后查找“CN = Microsoft Exchange System Objects”。在此容器中，您将find每个公用文件夹的对象，每个对象都有一个包含“ Send-As权限的ACL。）
为公共文件夹“发送代表”的想法有点奇怪，因为从Outlook的“委派”的概念根本不适用于公共文件夹。 但它在那里，但是。
公共文件夹上发送代理权限的区别因素是，它们永远不会填充已授予发送权限的用户对象的“publicDelegatesBL”属性。
在这一点上，我不清楚在公共文件夹上发送代表权是否也是不稳定的。 如果有人知道这一点，请随时编辑这个答案！ （TODO / FIXME）
公用文件夹上的权限不同于邮箱的权限。 因为他们链接到一个邮箱，他们是易变的。
如果邮箱断开连接 ，那么该邮箱将失去所有已授予的公用文件夹权限。 （TODO / FIXME还是遵循NT USER格式？）
如果您有一个AD用户帐户在两个单独的域中，并且您希望将邮箱从一个域中的用户移到另一个域中的用户，则您将面临一场艰苦的战斗。
不幸的是，Exchange不容易跟踪权限和授权如何被应用。 如果您需要将邮箱从一个AD用户移动到同一个林中的另一个用户，并且希望完全保留这些权限，则需要自己发现并恢复这些权限。
即使在中等规模的森林中，这也是一项非常昂贵的操作，所以如果您经常移动邮箱，那么在所有邮箱中进行一次大的枚举以收集所有当前链接的列表是值得的。 然后，当您要将邮箱分配给不同的AD用户帐户时，您确切地知道哪些其他邮箱需要更新权限。