Users keep getting logged out

[byron_fox]

Hi

We have a user in a different country that keeps getting logged out of the model. The model is about 400MB uncompressed and has section access. His session seems to last a few minutes and then gets reset, wherein he has to put in his section access details again. We have enough RAM 128GB on the server. He has a named Cal. Our server version is 12.30.2. The server is running through IIS not QVWS

Looking at the Events Log file, I get the below

The timeouts are all set a lot longer than 5 minutes and we don't have this issue with other models.

Please assist with any ideas

Regards

Byron

[Josh_Berg_Support]

Byron,

Your title mentions "users" but your description mentions a specific user, is this issue affecting multiple users or just one?  If the issue affects one specific user, please provide us more detail about what the user is doing before they get logged out of their session, are they actively working and selecting values in the QVW or is the session idle?  Since you're using IIS instead of QVWS, have there been any changes on your IIS config before this issue started?  I'd recommend taking a look at an article we have related to timeouts for Qlikview, the bottom of the article mentions timeout values for IIS, please review them and compare them to your setup.  

Thanks,
Josh

Qlik Support

[Brett_Bleess]

Byron, need to know which client this user is using?  If they are using IE Plugin, there are a lot more things in play, but if they are using Ajax Client, then it is a bit more simple.  My hunch is the user may be using IE Plugin client, and it will do a direct TCP port connection over 4747, which can cause issues with some intelligent network devices in that we use a proprietary protocol for these connections, QVP, and from past experience, these 5 minute timeouts generally match these intelligent device timeouts for unknown protocol idle timeouts.  

If it is Ajax Client, the best way to try to sort things is likely going to be to use Fiddler to trace the client/server connection to try to see if that will give us a clue as to where things are getting disconnected.  The only other thing that comes to mind here is whether this user by chance gets to the IIS via a Network Load Balancing device, as if so, that could be where things are configured differently as well.  Sorry I do not have anything more definitive, but hopefully this will help you move things forward if you have not figured it out yet.

Regards,
Brett

[byron_fox]

Hi

We don't have any users using IE plugin - they are all using Ajax. We have run traceroutes before and while it is slower, there don't seem to be any breaks. The client also travels around the country (US) quite a lot, so he has had the issue on various networks. I have also seen the same error "System: DetermineAccess: Failed to access the following document" on various documents - can you provide more info on what could possibly cause that error?

Thanks

Byron

[byron_fox]

Hi Josh

We have one user that complains the most, but checking the logs, I can see that the "System: DetermineAccess: Failed to access the following document" does affect other users too, just not to the same extent. These users are all making selections when it cuts out - not idling. Our timeout times are set very high until we can resolve this issue. 

We haven't changed anything on IIS for quite a few months (so the last change predated this issue by a long time). Thank you, I will go through the article and see if we are missing anything on our side.

Appreciate the help!

Byron

[Brett_Bleess]

Byron, I think you are looking for something in the Auth side of things given I realized I could blow up that image you attached, and I could then see there is no ID being returned in these instances, which means the web server is having issues getting the credentials.  How are things configured in the QVWS resource Authentication and the QVS Security tab settings, you using NTLM and NTFS?  If so, then the IIS instance can run all Anonymous except for the Authenticate.aspx page, that one needs to be locked down to only Windows Auth in that case, as that is the page that captures the user info.  If you use an SSO process of some sort, then everything in IIS should be anonymous as far as our directories go.  If you can provide some further details, or a larger log snippet, I might be able to find something else here.  

Regards,
Brett