Has anyone had any success in setting up QVS on one box with the web front-end (QVWS and/or IIS) on a separate box? Here's what we're trying to do:
Has anyone managed to pull off a similar configuration? I'm particularly interested in the answers to the following:
Any help would be greatly appreciated.
There is some more information on this in the new QVS 9 SR1 Reference manual under chapter 17 - Functional Architecture. Page 196 contains settings for running the webserver on another machine than the QVS.
I've set this up a number if times with QlikView Server 8.5 and earlier and I don't think it's changed for 9.
The following steps should help:
From the machine you have installed QVS on:
1) Copy the folder 'C:\Program Files\QlikView\Server\QvClients' to your web server, I would recommend copying this to 'C:\Inetpub\wwwroot'.
2) Copy the file 'C:\Program Files\QlikView\Server\QvsComRemote.dll' to your web server, say to 'C:\QlikViewServerComponents\'.
Now on the target web server (you shouldn't need to run any QlikView installers on this):
3) In IIS. create a virtual directory in your web site named QvAjaxZfc which points to 'C:\Inetpub\wwwroot\QvClients\QvAjaxZfc'.
4) In IIS, create a virtual directory in your web site named QvClients which points to 'C:\Inetpub\wwwroot\QvClients'.
5) At the command line run 'regsvr32 c:\QlikViewComponents\QvsComRemote.dll'.
6) Edit 'C:\Inetpub\wwwroot\QvClients\settings.js' in notepad by uncommenting the line:
// var QvsHost = "qvs.site.com";'
and replacing the variable with that of you QlikView server machin name or ipaddress.
You should now be able to browse to:
Where localhost is the name or ipaddress of your webserver - this is the backend which talks to QlikView Server.
This may be *an* answer, but not the one I was hoping for. We have this running under 8.5. We set it up by installing the QV 8.5's IIS components on our web server. The end result was similar to what you describe, although there wasn't as much manual movement of files.
I was hoping to get it working so we wouldn't have to publish our AJAX files to the IIS web server. I believe this is only possible when using the QVWebServer. In the end, if we get this working, we'll probably need both the QVWS and IIS. QVWS for the qlikview pages and IIS to handle our special authentication needs.
Still looking for ideas...
QV9 supports getting the AJAX files directly from the QlikView server *if* you are using the QVWebServer. You don't have to publish the web pages like you did in older versions.
Or so we're told.
I have that working on a stand-alone box that's running QVS and QVWS. I no longer have to publish the AJAX pages every time I make a change to them.
Now I need to split these functions apart so that QVS is running on a different box than QVWS. I also need IIS running on the same box as QVWS so I can implement my authentication stuff.
I have done a configuration for that. What i have done is..
- Install QVS on both server
- On IIS server machine, edit the file "QVClients\setting.js" to point to QlikView Server (change the vars QvsHost). Vars QvsPort is optional. Dont forget to remove the comment tags.
- On QV Server machine, edit the file "HttpServer\config.xml". Change QvsHost to point to QV Server. And also change QvsTunnel to match ur environment.
- IIS Server machine - do not run QV Server (QV Management Console)
- QV Server machine - run QV Server (QV Management Console)
That's what i have done and I'm able to access all the qvw file from our intranet but...we can't accessed from outside intranet. If I'm access from internet all the document list is appeared but cant open the QVW it's gave an error something like this "iis_authenticated .... . .. cant open file". All of my qvw file and ajax is located on QV server machine.
What i have done is quite same with Chris Brain but i didn't do the step number 5. Maybe Chris can explain what is the purpose on this step.
Do people on your intranet have connectivity to your QV Server machine? If so, it might explain why it works from the intranet but not from outside.
Can you get to the QlikView AccessPoint page on your IIS Server machine?
When people are on your intranet, what is the URL that they use to open the document?
Are you using AJAX/ZFC or IE Client to deploy it? Are you using NTFS or DMS authorization?
Can you get to the
Yes, people in intranet can connect to QVServer, I try to run telnet command to that IP from internet but failed to connect.
Yes i can get to qlikview accesspoint from intranet and also from internet (from internet can't get the document list)
The URL to access is "bi.mydomain.com/qlikview"
I'm using IE client. It should be the same method if you using AJAX/ZFC to deploy.
I'm using NTFS authorization
Btw, my problem is people from the outside/internet can't get access to the document because this IP address is on out intranet. Is this the source of my problem? How to solve this?
When people connect to the Accesspoint page from outside, do they authenticate? On the accesspoint page, in the upper right, it says "Logged in as: " somebody. If you have a particular user who connects from both inside and outside, is the "Logged in as:" name the same in both cases? I would think that even without connectivity to the QVS, Accesspoint should provide the same document list regardless of where the user comes from.
I'm not completely sure about this, as we only use AJAX/ZFC, but you need to have some sort of connectivity from the outside to your QV Server when using the IE plug-in. You could poke a hole in your firewall so that traffic over port 4747 can get from the outside to your QVS. Or, you could implement tunnelling so that people connect to your web server, and then it tunnels requests to your QVS. By default, I think it will try to use port 4747, but I think it can also use port 80 if things are configured correctly.
There's more information about this in section 17.2 of the Server/Publisher Reference Manual.
I finally got our set-up running by installing the QlikView Web Server service on *both* our IIS Web Server and our QVS. I'm not completely sure if this is necessary, but things started working for us when we configured it this way, so I didn't spend a lot of time trying to figure out the details.
Please post back to the list if you get things working.