我们有一个独特的问题，我需要一些build议来处理。
背景：我已经开始了一个新的工作，并inheritance了2010年的交换设置。 其中一个邮箱是公司用来执行工作stream程的共享邮箱，而不是外部系统。
一封电子邮件进来，它被移动到相关的子文件夹，并与一个类别。 随着更多的工作完成，类别不断变化，并且随着工作的继续，也可能会移到不同的文件夹中。
这已经持续了很多年，现在我们有一个相当大的邮箱。 超过185GB的大小。 我从来没有见过一个如此庞大的邮箱，在发生错误之前需要做一些事情。 每当有人在文件夹上执行search时，整个邮箱就会在search过程中停顿，只会在这里变得更糟。
问：处理这个问题的最好方法是什么？ （假设我可以find一种不同的方法用于实际工作stream程，以避免将来陷入同样的混乱状态，但这不在问题的范围之内）
我希望他们有一个不错的新邮箱工作，但仍然可以访问需要的旧数据。
我必须记住的事情是：
1，如果可能的话，我想避免产生大量的交易，就像一个185GB的邮箱，他们可能是相当可观的。
2无论我用什么方法“归档”或存储旧邮箱，都需要保留其类别，以便“文件系统”完好无损。
3-旧数据需要易于访问，最好通过outlook。
任何build议将不胜感激。
如果不生成事务日志，您将无法做任何事情。 这就是Exchange的工作原理。 您将需要使用该工具，或者使用循环日志logging的新数据库，并在内容移动时承担风险。
至less你正在查看一个新的数据库，然后分割内容。 185GB邮箱远远超过了Outlook和Exchange的testing限制，所以你会看到问题。
我会看看数据如何分解。 这可以像将子文件夹移动到自己的邮箱一样简单。
如果这是一个“项目”types的系统，那么这可能会奏效。 为每个“项目”设置一个邮箱，然后为每个“项目”设置一个组。 授予该组的完整邮箱权限，然后可以轻松地添加和删除需要访问的成员。 我怀疑公司里的每个人是否都需要访问所有这些数据。
让某人分配给电子邮件进行分类，因此它会像现在这样进入邮箱，然后将其移到相关的邮箱中。 作为一个项目完成邮箱可以closures。
我能想到的唯一的其他选项是从Exchange中删除它。 使用可以从邮箱中吸取内容的归档工具。 获取具有Outlook插件的内容，以便通过该路线获取内容。 一旦邮箱为空，将邮箱移动到新的数据库（以及该数据库中的任何其他邮箱）将其放入并创build一个新的邮箱。
西蒙。
只是一个想法
我将检查了解您的部署build议的数据库大小了解存储configuration 。 其中之一是：
支持：大约16兆兆字节。
最佳实践：
- 200千兆字节（GB）或更less。
- 提供计算的最大数据库大小的120％。
如果前面提到的适用于您，并且您希望保持在200 GB以下，则可以创build一个新的数据库，并为您的怪物邮箱添加一个存档，用于存储超过“x”天的邮件。
您可以通过将PowerShell脚本设置为任务来移动旧邮件，该任务使用“ search邮箱”命令。
您可以使用Search-Mailbox cmdletsearch指定邮箱中的邮件，并执行以下任一任务：
复制源邮箱中的邮件并将其从目标邮箱中删除。
如果您想保留文件夹结构，则可能需要手动移动邮件。
但是，我相信你知道，你可能有一个潜在的问题。 邮箱如何变得如此之大？ 也许你需要长期考虑一个不同的解决scheme。 处理邮箱背后的工作stream程的另一种方法。