Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi all, we suddenly have an issue where Access Point is showing "No Server." After some debugging, it appears that the QMS doesn't start properly when pointed at the existing Documents folder. If we point it at a fresh folder or the default that comes with the app, the server comes up fine and Access Point no longer errors. However, we obviously need the content in the existing Documents folder.
Any ideas what might have caused this? How can we preserve the existing Documents?
You mean the mounted folders are not accessible anymore unless the default one or new added ones? If it's the case it hints for a temporary issue (restarting the entire environment) or changes and/or a corruption to the QV server settings (hopefully there are backups) or there were any adjustments to the security/access settings within the environment.
Hi @BruceLabbate ,
Off-Duty is typically a situation where you have two servers running the Qlik Management service (QMS) under the same license.
Please inspect your network to determine if this is the case. Shutdown one of the QMS services that's causing the Off-duty issue.
The problem you are facing with "No Server" could be a conflict between the two servers.
Let's try to fix that first, then come back to the "No server" situation, OK? I may go away after you fix the initial problem.
Live and Breathe Qlik & AWS.
Follow me on my LinkedIn | Know IPC Global at ipc-global.com
Definitely not two servers running. We only have one in the entire enterprise. Plus if I change the document folder location it comes up fine, which wouldn't happen if it was a licensing issue. It's only when pointed at the folder with all of our work in it that it fails to start.
Basically, we have all our work in C:\Qlik\Documents. If the QMS is pointed at that, it won't start. If I change it to something else with default or sample docs (C:\ProgramData\QlikTech\SourceDocuments, for example) it works fine. I've checked permissions and security, but everything seems ok. It's almost like that folder is corrupted. We didn't change anything in the settings before the issue started occurring.
I see we're getting errors in the event log as well:
SE_LOG: CQvXmlInterfaceRequestHandler - Catch: errId(36). Ino(-1). Fno(90)
I get it now.
What happens if you move the default/root folder to a folder that makes AccessPoint functional, then move the files from one folder to the other?
Are you able to see the documents on AccessPoint?
Did you have a chance to reboot the server? In case a file is locked, it will reclaim it.
Live and Breathe Qlik & AWS.
Follow me on my LinkedIn | Know IPC Global at ipc-global.com
We're going to try exactly what you recommend, setting the folder to a location that gets the server up and running, then moving the files. Seems like the best option. A reboot didn't fix the issue.
Also, could you double-check if all Antivirus the exceptions are in place?
Here's a reference: QlikView Folders and files to exclude from antivir... - Qlik Community - 1713060
Live and Breathe Qlik & AWS.
Follow me on my LinkedIn | Know IPC Global at ipc-global.com
Your checks proved that the general functionality is working and that the cause is most likely on the outside of Qlik.
Theoretically there could be a setting-corruption - preventing the access to previously added mounted folders but it's rather unlikely especially without touching the settings whereby depending on the kind of authentication + authorization a corruption of the *.pgo and/or *.meta files may cause strange effects. Therefore such possibility shouldn't be discard too early.
More likely is therefore any security-stuff like hinted from @hugo_andrade which should be traceable in logs of these tools. Beside the impact from external antivirus/firewall tools you may investigate to internal security rules like group policies - their working may not be easy visible and it may not have an instant effect (some local set admin-configuration are overwritten from the domain-admins by the next group-update every n hours, some by the next server-restart and some remain valid - you could never know because usually they keep their rules confidentially and if anything isn't stable you could write a ticket ...).