Repeated qvstunnel error in IE

[#1]

We are relatively new to Qlikview but have establisehd a Qlikview Server which has been configured to present access to the apps via the inbuilt Qlikview Web Server with authentication based around DMS.

I am getting the following error 4-5 times a day when trying to access one of the hosted applications via my client browser, which is IE8. Then at other tiems it will work fine. Can anyone shed any light as to what this means and how it can be resovled?

qvp://<servername>/<full path to qvw file>
iis_authenticate=F112261AB83C3AFCBFCD4ACBFDF28B154FB&tunneler=http%3A//<serveralias>/scripts/QVSTunnel.dll%3Fhost%3Dlocalhost could not be opened.

We have setup a DNS Cname/Alias to make the url more friendly so this is what is meant by <serveralias> in the above example whereas <servername> means it is actually showing the physical server name in this part of the error.

Any advice greatly received.

Ross

[vgutkovsky]

In QEMC --> System --> QlikView Servers, try setting a Link Machine Name equal to your server alias. If that doesn't work, check out this post, it might be relevant to you: http://community.qlik.com/forums/p/24522/93666.aspx. But in general, you want to avoid tunneling--if you're tunneling that means port 4747 is blocked in some way (either on the client or on the server) and your communications will be slowed down for the protocol to be translated by qvstunnel.dll...

[#3]

Vlad - Thanks very much for the suggestion, sorry it has taken so long to reply but we have a Xmas break so only returned to work yesterday. I have tried the Link Machine name as you suggested, using the server alias, but the problem still exists. I also looked at the other post but am not sure this is relevant as we are not using IIS but the Qlikview Web Server so I dont thik the filters it refers to are relevant.

I am checking firewall rules though on the basis of your reference to 4747. We were led to believe this was only needed for license validation but you are implying it is used for application access in your comment, we thought it was using port 80 only for this. We are not consciously trying to use tunneling hence why we are perplexed with the message being displayed. We do though feel that performance on opening up the initial Qlikview App via IER is not great so I am now wondering if this is also linked to the tunneling aspect.

Will continue to explroe these areas but any other ideas greatly appreciated,

Ross

[Bjorn_Wedbratt]

RossEllard wrote:I am checking firewall rules though on the basis of your reference to 4747. We were led to believe this was only needed for license validation but you are implying it is used for application access in your comment,

Correct. The QVP protocol is utilizing TCP/4747 for communication between Qv Plugin (or Qv Dev) and QVS. If not opened in firewall client will try to fall back to tunnel using the http protocol (default TCP/80).

RossEllard wrote:We do though feel that performance on opening up the initial Qlikview App via IER is not great so I am now wondering if this is also linked to the tunneling aspect.

Yes, tunneling using the http protocol will have an impact on performance. Depending on the infrastructure the impact on experienced performance can be anything from almost nothing to severe. It is therefore not recommended to tunnel if not required due to various network policies.

[#5]

Bjorn,

Based on your comment regarding 4747 being used between plugin and QVSserver we have done some network monitoring on the client to try and confirm what port is being used. This appears to show that despite using the plugin the access to the server apps are using Port 80 and we can also see if talking to the qvstunnel.dll.

Would I be correct in thinking this should not be the case based on your earlier reply and if so is there something we can do to try and force the use of 4747 if for nothing else but to test if the performance does improve?

Many Thanks,

Ross

[Bjorn_Wedbratt · Accepted solution]

Hi Ross,

RossEllard wrote:Would I be correct in thinking this should not be the case based on your earlier reply and if so is there something we can do to try and force the use of 4747 if for nothing else but to test if the performance does improve?

That is correct, this should not be the case. You don't need to force the use of 4747, it is always the prioritized port as I wrote before. Only in two scenarios will it fall back to tunnel over http:

- if the port (4747) is blocked between the client and the server

- if you force tunneling using a setting in config.xml for the web server, <AlwaysTunnel>True</AlwaysTunnel>

The easiest way to check if 4747 really is open the whole way, from client to server, is by running telnet in a Command Prompt on the client and connect to the server using: telnet servername <space> 4747. This will give a clear indication if you can connect or not.

Regards,
Bjorn

[marsman82]

Already solved the problem?

Having the same problem...

There are no problems when I use qvp://<servername>, but when I trie to connect by clicking on IEplugin in the accesspoint I get the tunnel error 9 out of 10 times.

Installed Qlikview 10 in IIS and added the dll file. Also followed the steps in the link above.

Kind regards,

Teun Marsman

[Bjorn_Wedbratt]

Hi Teun,
This doesn't sound like the same issue, but rather that you fail to connect, maybe because the generated qvp-address in AccessPoint is wrong? If you can connect using qvp://<server> as you wrote, port 4747 is open and you shouldn't need to tunnel at all.

It's really hard to say exactly what goes wrong in your case, so I suggest you open a case with Qliktech support and they will assist you to resolve the problem.

Regards,
Bjorn

[marsman82]

Hi Bjorn,

Thanks for the advise.

Regards,
Teun

[#10]

Finally managed to get to the bottom of this problem with the help of Qliktech support.  Our Qlikview server is hosted in a separate AD infrastructure than our users. The problem turned out to be that the user's domain was unabel to resovle the short version of the server name as being used by the IE PlugIn. The fully qualified name had been setup in DNS but it seems the IE Plugin also requires the short, i.e. just the servername, to be resolvable.

Once we set the short server name up as a CNAME in the DNS within the user's AD Infrastructure it all worked, and was noticably quicker as well.

The final evidence was found in the plug in Log files on the client.