Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hei all,
I've got two users in my flock that have trouble with QlikView.
So they do have a named cal in the QMC. I can see them under "assigned CALs".
However, they will not receive the licensed edition on their user desktop
Anyone has some handy tips on how I should proceed with these users so that they get the licensed edition? We have plenty of named CAL licenses left so there aren't any limitations on that.
Cheers
Jörgen
Are the users really the same? A text-box with: osuser() in a new created app should show how they are recognized and is this also the user which is used to connect to the QV server?
Another look may go to the users within the qmc if they are enabled or disabled.
Struggles may also occur if the releases of the server and the desktop clients aren't the same. If I remember correctly there were an announcement within the last release notes that the qvp-protocol is outdated.
Besides this there may a lot of network-stuff (load-balancer, proxies, firewalls / group policies, cross-domain accesses, ...) which could prevent a successful access and/or if there were different authentication-methods in use.
Helpful would be to try the access per Access Point which may already exclude various possibilities.
QlikView Desktop only becomes licensed when it successfully connects to the QlikView Server. Even if a CAL is assigned in QMC, the desktop will remain in Personal Edition if that connection fails.
Check the QlikView version
The user’s QlikView Desktop version should match (or be very close to) the server version.
A significant version mismatch can prevent the license handshake.
Are the users really the same? A text-box with: osuser() in a new created app should show how they are recognized and is this also the user which is used to connect to the QV server?
Another look may go to the users within the qmc if they are enabled or disabled.
Struggles may also occur if the releases of the server and the desktop clients aren't the same. If I remember correctly there were an announcement within the last release notes that the qvp-protocol is outdated.
Besides this there may a lot of network-stuff (load-balancer, proxies, firewalls / group policies, cross-domain accesses, ...) which could prevent a successful access and/or if there were different authentication-methods in use.
Helpful would be to try the access per Access Point which may already exclude various possibilities.
Hi @SweJoCa ,
please check this article with possible resolution steps.
OK, so more info is needed I see now 🙂
1. The QlikView Desktop is on the same server as the apps; They access the server through an RDT.
2. They try to open the files through "open in server".
3. They re-start their desktop and still do not have the license - according to the desktop.
4. They are present in the QMC with a named CAL.
I've tried to "un-license" them before, with the quarantine and everything and still can't make it work.
For all other users it's working fine.
They are present in the correct AD-groups, have access to the correct documents, distributions and groups in the QMC.
They can access the app through the accesspoint, but - of course - they have a need to see the script and in-depth properties of the measures (and macros, etc. etc.)
I've actually never seen this before so I'm at loss.
Cheers
Jörgen
Grazie, Daniele.
I've tried most of the relevant steps there.
Even the quarantine for 7 days one... didn't work.
Cheers
Jörgen
Is this the general way for all users? Means opening the apps per "open in server" or may others opening the apps directly per windows explorer or qv start-window?
QlikView Desktop only becomes licensed when it successfully connects to the QlikView Server. Even if a CAL is assigned in QMC, the desktop will remain in Personal Edition if that connection fails.
Check the QlikView version
The user’s QlikView Desktop version should match (or be very close to) the server version.
A significant version mismatch can prevent the license handshake.
Hi - I was convinced they were the same.
They are not the same (which is strange... who does that?) as the DT is 2022 SR2 and the QMC is 2021 SR2
I foresee an upgrade in the future 🙂
I will accept this as the solution for now.
But I find it strange it worked with other users earlier.
Thanks for now 🙂
Cheers
Jörgen
Actually, Marcus - your sentence "Struggles may also occur if the releases of the server and the desktop clients aren't the same. If I remember correctly there were an announcement within the last release notes that the qvp-protocol is outdated."
When I actually took a look at it, the desktop is 2022 SR2, but the server is 2021SR2.
Which is weird, if it is that.
As I write to svg below (or above) - I'll accept that as a solution, but I find it peculiar that it worked for all other 😄
And that I foresee a big update within two months. 🙂
Cheers and thank you for now.
/Jörgen
I'm not sure that an upgrade on all sides will solve the issue. Yes, it will avoid the potentially conflict between different releases but if some users could lease a licence and some not the release is rather not the cause. Especially if the upgrade isn't only an upgrade of Qlik else also used to upgrade the OS and/or the machine / VM it could become hard to trace issues to a certain cause.
Therefore it might be more helpful to compare the user-rights/settings and the environment of the working and not working users closely. It's very likely that there are any differences which may not obvious. For example if the wanted apps contain a section access and these users may have no valid entries within the access table and their access is then denied. AFAIK is it the successful opening of an app which released the licence.
Also might be tried to delete (after a backup) the settings.ini from the users. QlikView creates then a new one with the default settings which would exclude any conflicts in regard to the user-settings.
Another view may go to the RDT. Is there really a single server or may it be a server-cluster. Of course the IT will claim that they were all identically but this mustn't be true. We had in the past such trouble especially with citrix-servers.