我在位于加州的terminal服务器场中使用Outlook 2010 。 纽约市的Exchange服务器。 在美好的一天，延迟是50ms到80ms。 潜伏期有时达到120ms。
提供良好的用户体验的唯一方法是使用caching模式（因此是问题）。 请不要在terminal服务器上给我讲关于OST的事情，它会发生，而且必须发生。 我可以做的事情并不多，但要让它工作。
题
我应该如何configuration有关其他terminal服务器场的OST？ 他们应该都指向一个共享的文件服务器？
首先 – 你不想（也不可能）将OST文件redirect到networking共享。 他们应该始终为客户提供服务。
我已经完成了我的部分研究，事实certificateOST的远程桌面服务是不会发生的事情。 我可以猜测为什么你想要它（即时search），但它根本不值得的成本。
另外 – 如果您运行一个远程桌面服务器，用户可以将负载平衡到不同的服务器上，您将得到以下潜在的情况：
100个用户 – 5GB邮箱 – 5个远程桌面服务器= 2.5TB磁盘空间JUST用于在远程桌面服务器上存储OST文件。 每次用户login到远程桌面服务器时添加增加的I / O，并启动Exchange同步。
你真的想要这个成本吗？
有一种方法：使用Microsoft Outlook 2010 GPO，您可以将OST文件redirect到其他位置。 我遇到的唯一的事情，它不是100％的工作。 某些用户的OST文件仍然存储在c：\ users中。 这最终导致c：-drive空间不足。
虽然我与其他人一起推荐在terminal服务器上使用Outlook中的caching模式，但是如果您必须使用它，则可以在TS服务器场中执行此操作（用户可以login到任意一个服务器）将使用文件夹redirect将Application Data文件夹（这是ost文件的默认path）redirect到networking共享，以便用户使用相同的ost文件，而不pipe它们login到哪个terminal服务器。
您还可以通过将相应的Office模板添加到适用于该用户的GPO，以便在用户login到TS并修改GPO设置中的位置时，修改ost文件的默认位置。
AppData文件夹不会跟随漫游configuration文件吗？ 在这种情况下，为什么不把configuration文件放在可以容纳这个负载和空间的存储上。
Justy的意见，但你应该稍后，build议纽约市民，这种configuration不能很好地工作，并加强他们的交stream方面，以适应每个邮箱的大小要求，所以你可以在TS农场时运行在线模式。