Skip to main content

QlikView Administration

Discussion Board for collaboration on QlikView Management.

Skip the ticket, Chat with Qlik Support instead for instant assistance.
Showing results for 
Search instead for 
Did you mean: 
Partner - Creator
Partner - Creator

Error on using QvsTunnel IE Plug-in


Here is my problem,

I have a Qlikview server 10 that works through IIS 7

The HTTP Tunnel works, I ran a test with "http://localhost/scripts/qvtunnel.dll?test and it's ok

So i blocked the port 4747 to validate the fact that the tunneling works,

I still have the error message

"Failed to reach server: IP-...........

Switching to HTTP runneling

Connected to server OK, security settings denies access"

The same issue happens whether using Plug-in IE or Qlikview Desktop

Thanks for your help,


54 Replies
Not applicable

Hi Bill,

I am using QVWS and I have added the FQDN to the link machine name field and still get the identical message in the above post. I struggled to find an email address to send you a screen cap but the message I get is the same as listed previously.

Any advice?


Not applicable

Upgrading the user to IE8 (from IE6) resolved the issue for us

Not applicable

Hi Bill,

One of our client is facing the same problem, I made Tunnelling="True" and even changed the URL path but still that problem is coming.

Their current server Configuration is :

System : Microsoft windows server 2003 R2

Computer : IBM XSERIES_36, Intel(R), Xeon(R)

Please check the attached Screen Shot for the Error.





Can you try http://<servername>/scripts/qvstunnel.dll?testtunnel and replace <servername> with the name of your server. Let me know what you get.

Bill - Principal Technical Support Engineer at Qlik
To help users find verified answers, please don't forget to use the "Accept as Solution" button on any posts that helped you resolve your problem or question.
Not applicable

Hi Bill,

Thanks for your reply.

I think in my attached Image which I sent you, that “;http/ “should not come,

Basically it should take, “qvp://” and currently it is taking, “qvp://;http/Cleartrip_DSS_v2.0.qvw


Please check the attached Doc. For Config file in which I have highlighted modified points.

I think I did some mistake in that but not sure about it. It would be a great help for me if you tell why this is happening.



Partner - Creator III
Partner - Creator III


what if we work with QVS 11?

i have the same issue and changed the name of the linkmachine in the QMC, but wanted to know, is if i need to install the QvTunnel

i do not see the QvTunnel file in my QV installation.

If we upgrade to QVS 11.2, shall we install all the components? Our users get the error message, that that the connection was not possible throught the qvp. Sometimes it works ( i need to restart the QVS) and some times it fails.



PD if i change any document or install new components in the QVS, shall i do a backup of the server documents?

Not applicable

Yes - we have been seeing issues with tunnelling on 11.2 SR2 with a clustered QVS.  QT Support have indicated that tunnelling is not supported with IIS and a clustered QVS, although there is no mention of this anywhere in the documentation which is really helpful.  It seems to work intermittently for us - I believe this is due to the IIS application only being able to speak to a single QVS node - so if the client happens to request a document that is local to the IIS node they landed on, it works, otherwise they get an error message.  We don't specifically need to use tunnelling, so the real question for us is why clients are tunnelling, which is what I am trying to get to the bottom of now, but just posting this information in case it is useful for someone.  Interestingly, our IE Plugin clients are only attempting to tunnel when more than one cluster node is added to the cluster - otherwise everything seems to work fine - clients communicate via TCP 4747 and don't attempt to tunnel.

Not applicable

Just in case this saves some other poor tortured soul...

Our issue turned out to be some sort of inconsistency with the TicketData.pgo files in the cluster.  They reside in N+1 locations (where N = number of QVS cluster nodes).  For some strange reason they appear to have gotten into an inconsistent or corrupt state in our environment, which meant that they weren't all being updated correctly (the timestamps across all files should broadly be in line - the file in our QVS cluster root was timestamped at the time the servers were last started up and not being updated).  This was causing clients to try and tunnel, which in our environment was failing due to the fact that this is not possible with IIS and a multi node QVS cluster. 

  1. The resolution was to shut down the QVS service on all nodes (this is mandatory - doesn't work if you do not do this step).
  2. Delete all TicketData.pgo files (one from the cluster QVS root, and one from each of the nodes)
  3. Start the QVS service on all nodes.

I hope this saves someone a weeks of head scratching and investigation.




Just want to clarify a couple of things on point 2 above, as there have been some customers that were unsure of things here.  You can confirm your QVS Root Folder path by going to the QMC\System\Setup\QlikView Servers\QVS resource\Folders tab and check the Root path there.  The default path for the 'nodes' is going to be C:\ProgramData\QlikTech\QlikViewServer.

Hopefully this will help someone from not being able to get back up and running on their own.  There are also some Articles in the Portals that cover this as well, so be sure to check there too if you are still a bit confused on what to do.  The two most pertinent are 000002589 and 000003857.



To help users find verified answers, please do not forget to use the "Accept as Solution" button on any post(s) that helped you resolve your problem or question.
I now work a compressed schedule, Tuesday, Wednesday and Thursday, so those will be the days I will reply to any follow-up posts.
Not applicable

Hi Bill B.

I would gratefull if you could have a look at our post here:

I have done what is described in: Installing Tunneling on 2008 server with IIS.docx - but that didn't solve the problem.

Any suggestion to what the problem could be?