1. Server 1 in Intranet with QVWS, DSC, QVS, QMC. Accesspoint launches, document launch no issues
2. Server 2 in Internet with IIS and DSC. Unable to access the app using direct link to the app i.e. opendoc.htm with parameters
Using QlikView and IIS.docx document, the SSL certificate is bound to the 4750 and 4730 ports on IIS server. QMC Settings under Web Server for IIS server is point to custom FormLogin.htm for SSO which in turn points to Authenticate.aspx that has been modified to use HttpAuthentication
IIS, QvAjaxZfc folder has only Windows Authentication enabled with https: etc. In addition to usual QlikViewAppPool and services under same Service Account.
I launch the app via IIS server, I get a popup for authentication where I enter credentials and then get a 'No Connection' error.
In IIS the Windows Auth provider is showing NTLM as first preference as well. Don't know what I am missing here.
It almost seems like the IIS server does not know that the QVS is sitting on Intranet server and therefore unable to route to that server. IIS, and Events log do not register any events or errors.
I found this when I was about to open a ticket with Qlik Support. It seems like your ticketdata.gpo file could be corrupt/broken. I ran through the steps below and haven't encountered that error yet. Hopefully it fixed the issue.
Users may experience intermittent issues opening documents using the Ajax client from the AccessPoint page, resulting in a "No Connection" message/dialog.
This article outlines steps to take in a clustered QlikView Server environment experiencing the above symptom, which could be a result of corrupt TicketData.pgo or .meta file.
The TicketData.pgo or .meta file has become corrupted or out of sync, and a new version needs to be created.
There is nothing in the file that will cause a loss of anything by recreating new versions. You may also notice in the QlikView Server Event logs that one server is creating a ticket and the other server is attempting to consume it but the ticket cannot be found. The reason is the 'shared' TicketData.pgo file is not updating correctly so the clustered servers will not have access to all tickets generated, or the .meta file may contain old server references which may prevent the application from opening properly.
Follow the steps below to confirm TicketData.pgo file is working properly:
1. Go to C:\Documents and Settings\All Users\Application Data\QlikTech\QlikViewServer (Server 2003) or C:\ProgramData\QlikTech\QlikViewServer (Server 2008) and confirm the TicketData.pgo file timestamp is updating with each user login.
2. Go to the location of your QVServer Root Folder path as specified in the Management Console under System\Setup\QlikView Servers\QVS resource\Folders tab (default is C:\Documents and Settings\All Users\Application Data\QlikTech\Documents [Server 2003] or C:\ProgramData\QlikTech\Documents [Server 2008]). Verify the copy of TicketData.pgo is also updating with each user login or use NotePad to open the .meta file associated with the qvw file in question and look for old server names that are no longer part of the environment.
3. If either of the above TicketData.pgo files is not updating (check timestamp), stop the QVS services on each server running in the clustered configuration, or if you have old server names in the .meta file, simply rename the .meta file(s) in question and allow new ones to be created. Be sure to reset any document preloading on specific cluster nodes etc.
4. Remove all copies of the TicketData.pgo files.
5. Restart the QVS services.
6. Verify all copies of TicketData.pgo are now updating as expected or that a new .meta file has been created.