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