我有一个带有 COM 对象的旧式 ASP 网站，它在 Windows Server 2008 上的 IIS 7.0 下运行。这通常很有效，但最近我遇到了一个相当奇怪的问题，我无法找到解决方案。
有一个页面调用自定义的 COM 对象（VB6 代码，是的，我知道），该对象调用第三方图形渲染 COM 对象。经过测试，我们发现此代码在 Windows 2003 和 IIS 6.0 下运行良好，但在 Windows Server 2008 和 IIS 7.0 下则不行。问题是第三方渲染引擎没有使用正确的（自定义安装的）真字体，似乎使用了默认字体。
当 ASP 页面中的代码在管理员帐户下作为 VBScript 文件运行时，渲染确实使用了正确的字体。因此，您可能认为这是一个权限问题。但是，当我在网站和 IIS 应用程序池正在运行的同一帐户下运行 VBScript 时，也会使用正确的字体。因此，只有当代码在 IIS 7.0 下运行时，它才会使用正确的字体进行渲染。如果它从与 IIS 正在使用的同一帐户下的 CMD 框运行，它会正确呈现。
IIS 使用的帐户是自定义创建的帐户（不是网络服务），权限很少，但足以运行。该网站已使用第三方 COM 对象运行多年。这是第一次出现这样的问题。
我认为字体的权限可能是一个问题，尽管这不能解释为什么它可以在 IIS 之外工作。为了确保它不是问题的一部分，我授予了 Everyone 组对特定字体的读取权限。但这并没有解决问题。
考虑到以上所有因素，我认为我的问题归结为 IIS 做了哪些不同的事情，这可能导致代码无法使用正确的字体。我知道 IIS 7.x 在启动应用程序池之前会自动将应用程序池帐户放入 IIS_IUSRS 组。但我已经手动将帐户添加到该组，因此当我从该帐户下的 CMD 框运行 VBScript 时，该帐户也是 IIS_IUSRS 组的一部分。所以这应该是一样的。
我不知道该如何解决这个问题。欢迎提供任何想法、提示或建议。
答案1
几周前我已经设法解决了这个问题，并且将回答我自己的问题以供将来参考，刚刚收到一位遇到类似问题的超级用户的电子邮件。
这个问题似乎只出现在 Windows Server 2008 上，可能是因为这个版本的 Windows 中有一个错误。该字体是从一家小型字体制作公司购买的未知自定义字体。我们已经请求了该字体的新版本，并尝试将其加载到几个字体编辑器中并重新保存，但无济于事。
最终，一个名为CR8 Software Solutions 的 Type Light设法修复了这个问题。在此编辑器中加载字体并再次保存，修复了 Windows Server 2008 上的问题。从那时起，我们就可以像使用任何其他字体一样使用该字体。
答案2
我知道你找到了解决方案，但我遇到了与你非常相似的问题（通过计划任务运行应用程序会使用默认字体，但在本地运行时会找到我安装的自定义字体），所以我找到了不同的解决方案；在 Server 2008 上，存在一个问题，即非交互式用户安装后不会立即注册自定义字体，而普通用户（即在实际登录到机器的用户上运行时）会立即注册字体。
对我而言有效的解决方案是简单地重启安装了字体的机器，然后字体就会在非交互式帐户下开始工作，因为当计算机打开时，它会正确注册。看来字体安装有一个错误，它直到重启后才能为非交互式用户正确注册字体。