我注意到许多第三方SharePoint应用程序需要将Office安装在服务器上才能运行，例如PDF转换器。
对我来说，这似乎是一个可怕的想法。 开销，更新要求，重新启动和占用空间都结合起来，这是一个坏主意。 我的假设是错的吗？
当供应商或供应商希望我在服务器上安装客户端/大型应用程序时，会降低我对其技术知识和/或经验的看法。 我不喜欢它，但我习惯了。
有时候，我能够在购买之前领先一步，了解这些小小的惊喜。 这是由我来决定的，我们将会遇到麻烦，因为一家公司不明白为什么租用的networking打印机应该有更好的卷跟踪方法，而不是安装在服务器上的bug。
这绝对是一个糟糕的主意，但是除非你能够根据这种要求的不专业性和不合理性与另一个供应商合作，否则没有什么可以让人失眠的。
作为一个供应商谁提供了一个stream行的PDF格式转换为SharePoint需要办事处安装在服务器上的某些格式我想增加我的2美分。
过去当我负责一家大型金融机构的变更控制时，如果任何一个供应商需要在办公室里安装办公室，我就会提起我的眉毛。 哦，我是如何爱我的象牙塔？讽刺并没有完全丢失在我身上。
事实是，有时我们需要考虑业务需求，如果在转换使用最新和最好的办公室格式的文档时业务需要完美的保真度，那么您无法逃避在服务器上安装Office的路线。
现在很多人都试图做到这一点，并且没有做到这一点，甚至有的时候甚至雇用专门的人来重新启动挂起的服务器。 问题是，如果你知道自己在做什么，并处理所有的问题，那么实际上就可以在服务器上成功可靠地使用Office，并且可以很好地扩展。
我不想把这个问题变成一个精细的销售点，但是我们有数百个（高知名度）客户，而且我还没有听到有客户发生崩溃，中断或与我们的软件有关的任何停机时间的情况。
如果您不知道自己在做什么，只需在SharePoint应用程序中直接编写一些COM自动化代码，那么您肯定会遇到问题，但是如果您的工作做得很好，则可以在单独的进程中运行所有内容，卸载到非SharePoint服务器，那么从技术angular度来看，在服务器上运行Office是没有问题的。
与Office交互的程序通常使用服务器不支持的COM / Interop接口：
Microsoft目前不推荐并不支持从任何无人参与的非交互式客户端应用程序或组件（包括ASP，ASP.NET，DCOM和NT服务）自动化Microsoft Office应用程序，因为Office可能会出现不稳定的行为和/或在此环境中运行Office时发生死锁。
我可以确认某些操作确实会使进程死锁（在打印机驱动程序中打印一个Word文档，这会打开“提示”，这让我很头痛）。
然而 ，有些应用程序只需要办公室，因为它带有一些组件，而且它们确实可以运行得非常好。
但正如所说：如果操作系统和办公产品的制造商说不支持，我倾向于相信他们。
我同意这是一个令人不寒而栗的想法，但内容pipe理系统针对Office文档协作是非常标准的做法。
我也在Linux上用OpenOffice和Plonefind了这种做法。
现在，当我们以实用的眼光看待这个问题的时候，在许多情况下，用例可能是共享服务器而不是实时的关键资源，而且公司偶尔也会重启。 特别是在SME环境中，用户相对较less，因此生成的负载不会使服务器瘫痪。 在这种情况下，这是实现人们想要的自动化的实用方法。
你绝对正确，这是一个坏主意。 但是…在一天结束的时候，这就是我们作为系统pipe理员所做的事情，但事实并非如此。 我们必须平衡对生产服务器进行更改的成本与不进行更改的成本。
如果企业必须在Sharepoint安装上具有某种function，并且这是获得它的唯一方法，那么您还能做些什么呢？ 明确安装的风险和成本，以及修补资源的潜在停机时间等，看看它如何堆积起来。
有一件事情可能是合理的，就是准确地找出需要什么办公室组件，然后对这些组件进行最低限度的安装。 将办公室磁盘重新装入服务器之间有一个很大的区别，只是做一个“点和stream口水”的快速安装，并说：“只需要，例如，加上foobaz插件的话，这就是我要安装”
其他人关于在服务器上安装软件的要点是我认同的。 我会认为服务器应该用于服务和被用于他们的指定angular色。
如果您不想安装完整的办公套件，则可以使用小型软件包来查看文档，powerpoint等。 看看Powerpoint Viewer或Word Viewer 。
服务器上的Office的另一个原因是当它是瘦客户端的terminal服务器:-)