views:

1582

answers:

6

I am testing an upgrade to SSAS 2008 and verifying existing reports working properly. I am able to get some SSRS reports that are using SSAS as a datasource to run without any issues. They are simple and only have a single dataset. The reports that I am unable to get to work correctly against SSAS 2008 have multiple datasets and have a fitler setup with a data range setup as a parameter. As soon as I setup that filter as a parameter and deploy them the report returns a "The connection either timed out or was lost. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. An existing connection was forcibly closed by the remote host" message.

The funny thing is that the report works fine when I run it locally in BIDS and it works fine once deployed if I point it to a SSAS 2005 server. Once I point it to the SSAS 2008 server it fails. I can get other reports to work fine, but not the ones with this type of a filter setup. I can see that the start and end date parameter MDX statements get run in the trace, but that is it. After those run then we receive the transport connection message.

Another funny thing is that in the production environment the reports are working fine, but that has SSRS 2005 and SSAS 2008. Does this make sense?
What could be causing this? I have tried setting the single transaction level on the datasource too, but that does not seem to make a difference.

+2  A: 

It turns out this is a known issue now at Microsoft. We are at least the fourth customer to log this issue. It is specifically related to Windows Server 2008 and use of Kerberos. It has to deal with the packets and the checksum calculation when using Kerberos. I am working with someone on the Analysis Service support team at Microsoft. They are actively working on this with the Windows team to hopefully resolve this. Until then we need to run one of the components (SSRS 2008 or SSAS 2008) on a Windows 2003 server since we are going to continue to use Kerberos and stay in a distribute environment. This is what I received from MS Support last night:

Thanks for confirming your test with Server 2003 as the middle tier. Unfortunately, based on the symptoms you described so far, it sounds likely this may be an ongoing issue we have been seeing when both client and server in a Kerberos authentication are 2008 or Vista. We are currently investigating that actively with the Windows team, but so far do not have a resolution, if this is the problem. We can work around the issue by using a non-2008 client as you found, or by placing the client and server on the same box, or avoiding Kerberos authentication (which requires clear text authentication in middle tier – basic authentication from the client or else anonymous authentication with specified account supplied in middle tier configuration).

Hopefully this will be resolved in the near future. For now we are planning on running SSRS 2008 on Windows Server 2003.

Windows Server 2008 Kerberos Bug Patch – resolves SSAS connection issues (http://denglishbi.spaces.live.com/blog/cns!CD3E77E793DF6178!1718.entry)
A: 

Just as a follow up in regards to this I did a blog posting about this that you can check out here - Windows Server 2008 Kerberos Bug – Transport Connection Issues with SSAS data

A: 

hi there,

May I know of whether you host your SSAS on one box and the other SSRS on the other box? Based on your reported problem, I highly believe that the port in between this two servers are blocked. If the services are hosted on the same box, you probably have to use "localhost" as an entry.

I personally have not had a chance to try SSAS yet, but I am a regular user of SSRS 2008 service. I host my SSRS 2008 at ASPHostDirectory.com and so far, everything works smoothly. I am able to remotely connect to my reports and I am able to administer my reports online.

I have not experienced the error message like the one that you have currently. However, I did see "similar" error when I tried to FTP lst time. I was able to connect to the FTP server, but the FTP server was unable to display the folders and immediately terminated my session. I then set my FTP connection mode to active and everything started to work. I understand that this resolution might be irrelevant, but what I want to point out is that the problem seems to cause by the firewall, etc.

Thank you.

A: 

Windows Server 2008 Kerberos Bug Patch – resolves SSAS connection issues

I was notified by a colleague that Microsoft had released the patch to fix the AES Kerberos issues that had been discovered earlier this year - Windows Server 2008 Kerberos Bug – Transport Connection Issues with SSAS data. I had not been notified of this yet, but I checked out the blog posting by Dr. John Tunnicliffe SSAS: Microsoft release fix for “Kerberos killing MDX” issue and he provided a link to the downloads

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

There doesn’t appear to be an official knowledge base (KB) link to this specific download, but according to Dr. John this does resolve the issue with the transport errors. I had been told that the KB was going to be 968700, but according to these links it appears that it will be 969083.

So for those of you who have had to put the upgrade to Windows Server 2008 on hold because of this you can now download the patch and continue on with your infrastructure upgrades. Just make sure that you properly test the patch before deploying this into your production environments.

A: 

Thanks very much for documenting this bug so well. However it's very frustrating that MSFT can't get the basics right. Now I have to push for a corporate wide distribution of this fix. :(.

nojetlag
A: 

I got KB969083 and testet it on one machine, much to my surprise (or should I say not much to my surprise) the versions of the DLLs that came with the patch are not matching with the description in the KB and I still have the problem :(

nojetlag