我已经向管理层提出了非常详细的建议，无论是全新的本地扩建还是迁移到 0365。我只是在等待决定，然后是购买/许可，实施仍需要一些时间。
我们是在同样旧的 Dell Poweredge 服务器上运行本地 Exchange 2007 的 SMB。它的 Win 2008 R2，8 GB 内存，并有 2 个 E5405 @ 2.00Ghz。一切都用完了这个盒子。
在过去的一年里，事情变得越来越糟糕。我只在这里大约一年，并试图与一些超级关键服务器所采取的不良做法作斗争。几个月前，我以为我们会继续使用 2016 年的本地或 0365 解决方案，但我们仍然在这里思考。
我们有大约 154 个邮箱，可能有 105-115 个活跃用户。
我有 4 个活动数据存储/数据库和 1 个公用文件夹数据库。它们是 264GB、223GB、109GB、20GB 和 12GB。我不认为我们甚至可以拥有超过 250GB 的存储空间，所以一定有人在某个时候捏造了这个限制。根据该服务器的运行方式，我认为其中任何一个超过 100GB 都不合适。
因此，很多人都在抱怨 Outlook 2013 中的暂停和滞后。使用 Salesforce for Outlook 插件的人的情况要差大约 1,000 倍。几个月来，我一直在从 SFO 插件方面进行故障排除，由于在我们的邮件服务器上进行叉车升级没有任何进展，我现在更多地从 Exchange 端查看它。我很确定这台服务器上的 Exchange 2007 是我所有问题的根本原因。
谁能帮我确认一下？此外，拆分这些数据存储的最佳方法是什么？100GB 是正确的目标吗？我应该去50GB吗？我们能否在服务器上拥有更多具有我们所拥有的规格的商店并实际看到任何形式的性能提升？或者这是一个白日梦？还有什么能给我带来暂时的解脱？更多的内存值得吗？
此外......我还想知道是否有人可以证实我的怀疑，即这个 Exchange 服务器如此臃肿导致了很多问题。
我们不在缓存交换模式下运行 Outlook。我们运行的其他一些实用程序会导致缓存模式出现问题（我们有一个在 SCO-UNIX 上运行的古老 ERP 系统，并且我们使用了一个小应用程序，它允许人们从 ERP“打印”到 PDF 文件，该文件被丢弃作为通过 MAPI 的电子邮件附件。）对于该过程，我可能有一个替代选项，但它不是一个“更好”的解决方案，只是一个对 Outlook 没有太多要求的辅助解决方案。我需要解释一下杀死 Outlook 和 Salesforce 插件的部分原因是我们没有在缓存交换模式下运行。
我们的人似乎也非常痴迷于创建文件夹。大量文件夹。一切的文件夹。对于客户，然后按客户发生的事件进行细分，然后按订单进行细分……这太疯狂了。
因此，任何建议将不胜感激。当我们慢慢地获得新的和更好的东西时，我能做些什么来改善这种情况？
这里的答案是在其中投入 32GB 的 RAM。仍在等待完成我们的 0365 迁移，但至少一切正常！