Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
asa_runstrom
Contributor III
Contributor III

Failed to retrieve CAL configuration

Hi

I am installing publisher on one server och server on one server but doesn’t get it work.

 

In the publisher it looks like this under Status->Service

 

When I open System->Licenses->Qlikview Server I get this error message.

 

When I put the license and controll I get the lef. It is on a testlicense I use and it is valid.

 

When I open access point in access point server I get this

 

The accounts that run the services are members in the administration group and qlikview administration groups.

It is November 2017 SR4 I install. Before I installed this version there were an older installation running that worked.

 

Any suggestion what the problem can be? How do I check my CAL configuration?

 

I used the setupprograms Remove program because I missed it only removed November 2017 SR4. Can it be some old files from the older version?

 

1 Solution

Accepted Solutions
Martin_van_Staden
Contributor
Contributor

Thanks, this sorted out my problem.

I did not create a new account.  I used my existing AD account.  Just re-entered the login details as follows:

instead of using DOMAIN\User

I re-entered the login details as follows:  user@domain.  Restarted all services and all working.

View solution in original post

7 Replies
Miguel_Angel_Baeyens

When I had that issue it was due to a corrupt CalData.pgo.


However, before removing any file, make sure that the dates on your LEFs are current, and also review that the services are running with the expected account in the Windows services console services.msc.

If all the above is as expected, I would contact Qlik Support.

asa_runstrom
Contributor III
Contributor III
Author

How do I know the file is corrupt? When I open them in notepad there is characters and letters but nothing you can read.

I found two in both server which one was 4 years old.

Miguel_Angel_Baeyens

.Pgo, .(T)Shared and .Meta files are not readable with notepad like applications. If you can, you can try and stop all services, move those PGO files to another location and restart the services.

Depending on your license type this can be a bit of a hassle, you might have to reassign all licenses. If you have set the QMC to dynamically assign, there shouldn't be any difference.

I still think contacting Qlik Support would be better, they can check that your license is in order, so it is your LEF file, and give you advice on what to test and how to fix it.

StefanBackstrand
Partner - Specialist
Partner - Specialist

Did you have the services on separate servers already before upgrading, or are you scaling out as part of the upgrade?

Check that the "URL" to the QVS is correct in the settings, so that the QMC isn't trying to configure a QVS that doesn't exist. It's under QMC > System > Setup > QlikView Servers. Click the QVS node and make sure the URL is correct, like qvp://theqvsserver/.

richard_simpson
Partner - Contributor III
Partner - Contributor III

Have you resolved this?

Just wanted to check because I've just upgraded to November 2018 and had the same issue.

I resolved it by stopping the services, creating a new QlikView windows account on the server, which I added to the administrators group and the QV Administrators group, and then setting each service (all five) to logon using that new account.

I then restarted the services and the QV server started to work!

I hope you have solved your issue, but if not... give it a go.

Good luck

arish_delon
Creator
Creator

Adding Service Accounts into the QlikView Administrator group, Rebooting the Server.

Start QlikView Services with Service Accounts.

Apply QlikView Server License and all should be good.

Otherwise check the license expiry date and regenerate the LEF file.

Martin_van_Staden
Contributor
Contributor

Thanks, this sorted out my problem.

I did not create a new account.  I used my existing AD account.  Just re-entered the login details as follows:

instead of using DOMAIN\User

I re-entered the login details as follows:  user@domain.  Restarted all services and all working.