3

我正在测试升级到 SSAS 2008 并验证现有报告是否正常工作。我能够获得一些使用 SSAS 作为数据源的 SSRS 报告来运行而没有任何问题。它们很简单，只有一个数据集。我无法针对 SSAS 2008 正常工作的报告有多个数据集，并且有一个带有数据范围设置作为参数的 fitler 设置。一旦我将该过滤器设置为参数并部署它们，报告就会返回“连接超时或丢失。无法从传输连接读取数据：现有连接被远程主机强行关闭。现有连接被远程主机强行关闭”消息。

有趣的是，当我在 BIDS 中本地运行报告时，它运行良好，如果我将它指向 SSAS 2005 服务器，它在部署后运行良好。一旦我将它指向 SSAS 2008 服务器，它就会失败。我可以让其他报告正常工作，但不能使用这种类型的过滤器设置。我可以看到开始和结束日期参数 MDX 语句在跟踪中运行，但仅此而已。在这些运行之后，我们会收到传输连接消息。

另一个有趣的事情是，在生产环境中，报告工作正常，但是有 SSRS 2005 和 SSAS 2008。这有意义吗？
这可能是什么原因造成的？我也尝试在数据源上设置单个事务级别，但这似乎没有什么区别。

4

4 回答 4

3

事实证明，这是微软现在的一个已知问题。我们至少是第四个记录此问题的客户。它与 Windows Server 2008 和 Kerberos 的使用特别相关。使用 Kerberos 时，它必须处理数据包和校验和计算。我正在与 Microsoft 分析服务支持团队的某个人合作。他们正在与 Windows 团队积极合作，希望能解决这个问题。在那之前，我们需要在 Windows 2003 服务器上运行其中一个组件（SSRS 2008 或 SSAS 2008），因为我们将继续使用 Kerberos 并保持在分布式环境中。这是我昨晚从 MS Support 收到的：

感谢您确认使用 Server 2003 作为中间层的测试。不幸的是，根据您迄今为止描述的症状，当 Kerberos 身份验证中的客户端和服务器都是 2008 或 Vista 时，这听起来可能是我们一直在看到的一个持续问题。我们目前正在与 Windows 团队积极调查，但到目前为止还没有解决方案，如果这是问题。我们可以通过使用您找到的非 2008 客户端，或者将客户端和服务器放在同一个盒子上，或者避免 Kerberos 身份验证（这需要中间层中的明文身份验证 - 来自客户端的基本身份验证）来解决这个问题使用中间层配置中提供的指定帐户进行匿名身份验证）。

希望这将在不久的将来得到解决。目前，我们计划在 Windows Server 2003 上运行 SSRS 2008。

于 2009-02-11T12:09:20.283 回答
0

作为对此的跟进，我发表了一篇关于此的博客文章，您可以在此处查看 - Windows Server 2008 Kerberos Bug – SSAS 数据的传输连接问题

于 2009-04-03T10:01:18.197 回答
0

我可以知道您是否在一个盒子上托管您的 SSAS，而在另一个盒子上托管另一个 SSRS？根据您报告的问题，我高度相信这两台服务器之间的端口已被阻止。如果服务托管在同一个盒子上，您可能必须使用“localhost”作为条目。

我个人还没有机会尝试 SSAS，但我是 SSRS 2008 服务的常客。我在ASPHostDirectory.com上托管了我的 SSRS 2008，到目前为止，一切都很顺利。我能够远程连接到我的报告，并且能够在线管理我的报告。

我没有遇到像您当前遇到的错误消息。但是，当我第一次尝试 FTP 时，我确实看到了“类似”错误。我能够连接到 FTP 服务器，但 FTP 服务器无法显示文件夹并立即终止了我的会话。然后我将我的 FTP 连接模式设置为活动，一切都开始工作了。我知道这个解决方案可能无关紧要，但我想指出的是问题似乎是由防火墙等引起的。

谢谢你。

于 2009-05-08T01:59:16.337 回答
0

Windows Server 2008 Kerberos Bug Patch – 解决 SSAS 连接问题

一位同事通知我，Microsoft 已发布补丁以修复今年早些时候发现的 AES Kerberos 问题 - Windows Server 2008 Kerberos Bug – SSAS 数据的传输连接问题。我还没有收到这方面的通知，但我查看了 John Tunnicliffe SSAS 博士的博客文章：Microsoft release fix for “Kerberos kill MDX” issue，他提供了下载链接

http://support.microsoft.com/default.aspx/kb/969083

似乎没有指向此特定下载的官方知识库 (KB) 链接，但根据 John 博士的说法，这确实解决了传输错误的问题。有人告诉我 KB 将是 968700，但根据这些链接，它似乎是 969083。

因此，对于那些因此不得不暂停升级到 Windows Server 2008 的用户，您现在可以下载补丁并继续进行基础架构升级。只需确保在将补丁部署到生产环境之前正确测试补丁即可。

于 2009-07-23T11:18:01.903 回答