我已经向管理层提出了非常详细的提案，无论是全新的内部部署还是迁移到 0365。我只是在等待决定，然后购买/许可和实施仍需要一些时间。
我们是一家 SMB，在同样老旧的 Dell Poweredge 服务器上运行本地 Exchange 2007。它运行 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 吗？我们能否在服务器上拥有更多存储，并且真正看到任何性能提升？或者这只是一个白日梦？还有什么可以让我暂时松一口气？更多 RAM 值得吗？
此外... 我还想知道是否有人可以证实我的怀疑，即这个 Exchange 服务器过于臃肿会导致很多后续问题。
我们不会在缓存交换模式下运行 Outlook。我们运行的其他一些实用程序导致了缓存模式的问题（我们有一个在 SCO-UNIX 上运行的古老 ERP 系统，我们使用的一个小应用程序允许人们从 ERP“打印”到 PDF 文件，该文件通过 MAPI 以电子邮件附件的形式发送。）我可能有一个替代选项来完成该过程，但它不是一个“更好”的解决方案，只是一个不会对 Outlook 提出太多要求的附带解决方案。我需要解释一下，导致 Outlook 和 Salesforce 插件崩溃的部分原因是我们没有在缓存交换模式下运行。
我们的员工似乎也对创建文件夹非常痴迷。大量的文件夹。文件夹里放着所有东西。先是客户文件夹，然后按客户发生的事件细分，再按订单细分……这太疯狂了。
因此，任何建议都将不胜感激。在我们慢慢地获得新的、更好的东西的同时，我能做些什么来改善这种情况呢？
答案1
答案是将 32GB RAM 放入其中。仍在等待完成我们的 0365 迁移，但至少一切都正常了！