Not able to assign a document CAL

[Jagveer]

Hi,

I am trying to assign a user a document CAL on QMC. I've been doing this for past 3 years with no issues. But today, when I am assigning a new user in Document CALs, it appears in the list and the "Document CALs assigned to Users" increase. But, the moment, i hit apply the number goes back to the previous value, even though the name of the user stays in the assigned users list and the user doesn't see anything on the access point.

[Brett_Bleess]

Recheck the path, you are in ProgramData.... 🙂  It is in Program Files...

Regards,
Brett

[Jagveer]

I checked there because i couldn't find any folder named Managementservices in program files.

i have attached the screenshot for reference.

[Brett_Bleess]

Ok, so I am guessing things may not all be on the same server in this case, go to the QMC\System\About the first entry in the list there is going to be the QMS, see what server that is running on, that is where you should find the file...  Hopefully this makes sense.

Cheers,
Brett

[Jagveer]

Hi Brett,

everything is on the same server. it occured to me as well and i checked in QMC. it is the same machine.

[Brett_Bleess]

Ok, so the only thing left is you likely installed to a different directory when you ran the installer, hopefully you know where that would be, as the only other way I know to find it is to look at the following Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\QlikviewManagementService

Check the ImagePath string value there, that should confirm where things were installed and hopefully you can find the exe.config there.

Cheers,
Brett

[Jagveer]

Hi Brett,

you were right, the installation path was different. However, even after changing the MaxReceivedMessageSize value to double like you said, the issue still remains. i have attached the screenshot from the log, from which it seems everything is perfect. However, on the server the issue persists as before.

[Brett_Bleess]

Jagveer, ok, so you have confirmed worst case scenario here, thanks for the log snippet, that shows the QVS is doing things, the issue is it cannot update the CalData.pgo, and the only strange thing at this point is we are not getting any message in the log telling us as much.  Can you check on all your CalData.pgo files to see if all the timestamps are relatively in sync, or if one of them may be way off?  You are not getting any error when you are setting things up as well, which would indicate the read of the file is fine, it is the update/write that is having issues, so the best bet is to confirm the timestamps on all the copies of the CalData.pgo files, there will be one in the Root path of the QVS Folders tab settings in the QMC, and then each QVS node will have a local copy in C:\ProgramData\QlikTech\QlikViewServer as well.  Best I have to try to keep moving forward here.

Regards,
Brett

[Jagveer]

Hi Brett,

By timestamp for the file if you mean their last modified timestamp then they are in sync. Both at the root path and at the C:\ProgramData\QlikTech\QlikViewServer as well.

[Brett_Bleess]

Hmmmm, that is quite puzzling to say the least, as if they are updating, it begs the question of why we cannot write the new Doc CAL out.  The only thing of which I can think at this point would be to put the QVS into Debug log level, you have to go into the QVS Settings.ini and change the Verbosity setting there to 900 to get that, and then restart the service to have it kick in, you will then start seeing Debug messages in the logs, if you can do that at some point and then try things again, we can see if that tells us anything.  The only other thing of which I can think is some other utility running on the server that is monitoring those files and rolling back the change on us for some reason.  

Regards,
Brett

[Brett_Bleess]

There is one other thing we could do to confirm the pgo contents, there is a setting we can add to the QVS Settings.ini:

PgoAsXmlAslo=1

Setting PgoAsXmlAlso setting

You do not really want to leave this running all the time, as it creates quite a bit of overhead in that every time there is an update to the .pgo, the .xml has to also be updated, but this would allow us to look at the matching .xml file and confirm contents....

If you see the entry you have entered in there, then I think that would confirm we have a corrupt file...

Regards,
Brett