18 Replies Latest reply: May 10, 2016 12:27 PM by Steve Lord RSS

    While using nprinting, named QV license not always recognized

    Steve Lord

      Hi community, We have an interesting issue while using nprinting where sometimes when it goes to open the qlikview it gives that error prompt about 'since you are using a personal edition of qlikview...somethingsomething...recover this document.  <Proceed> <Abort>'

       

      I push abort thinking I just need to go pull my named license down again with the open in server feature, but then nprinting pops open the qlikview document and exports the tables despite the error message about me not being the creator of the document.

       

      1> This happens some days, and some days it does not happen.

      2> Another user and I are working with this same NPrinting file and related qlikviews, under our own sessions in a remote desktop environment, but not at the same time.

      3> We are using a powershell to open nprinting, select the nsq, and select the job and the job opens the qlikview

      (The powershell is a big one designed to move lots of files from various places to where the qlikviews need them, then tells nprinting to run the qlikviews.)

       

      Any ideas on why the error message about us using a personal edition sometimes appears when using the nprinting job, and how it can open the qlikview document and proceed without issue when all we do is hit abort?  We'd like to solve this, because having to hit abort is not something we can write into the powershell I don't think, so it disrupts automation efforts.

        • Re: While using nprinting, named QV license not always recognized
          Herbert Zangarini

          Hi Steve

           

          I think is better in your case to contact Qlik support or buy a Personal Qlikview Desktop licence(Local Licence),then there is no need to "Open in server" anymore.

            • Re: While using nprinting, named QV license not always recognized
              Steve Lord

              My team has the named licenses for ourselves ( the ~$1300 ones that say you can open any document).

               

              I think, sometimes the check for the license is happening just after the attempt to open, and the attempt to open is throwing the message about it not being a document I created.  Then when I push abort, it checks and sees my license (for some reason), and opens the document for me.   I can go several days without seeing this issue, then have it plague me all day on one day, then disappear again the next day.

               

              But yeah, contact qlik support sounds like a way to go.  Let someone operate my computer remotely and see if they can get us around it themselves.

               

              Edit: and if the license you mention is different from the named cal or document cal, I'd consider it.  'open in server' was just an action I tried to clear the error message, and it did not produce the desired result.  I can open these documents directly all day long.  Just the issue occurs sporadically when I run a powershell that tells nprinting to run a job that opens the qlikview and wonder if something slips loose or moves too fast in that sequence of events.

            • Re: While using nprinting, named QV license not always recognized
              Colin Albert

              Is the NPrinting service running under its own dedicated service account (not the QlikView service account)?

              Has a QlikView named (full) cal been allocated to the NPrinting Service account?

                • Re: While using nprinting, named QV license not always recognized
                  Steve Lord

                  yes, we created a service account nprintserv and gave a named cal to it

                  qvserv has its own service account

                   

                  However, when I'm logged onto the server as myself and use a powershell to trigger an nprinting designer job to open the qlikview...  I'd guess everything is looking at my own account.

                   

                  (We've actually set aside nprinting server 16 because Qlik couldn't make it quit checking whether I was an administrator, and corporate was unwilling to make me an administrator.  Powershell is turning out to fill a more robust need anyway, and nprinting designer was getting the job done.  Qlikview management console never needed me to be an administrator.  Ironic I had to make qlikviews without ntname source control or sheet conditions for nprinting, and Qlik can't make nprinting server stop checking whether I'm an admin on the server.  We're pausing on nprinting server 17 because we've heard of issues there too.)

                • Re: While using nprinting, named QV license not always recognized
                  Bill Markham

                  I had that issue.  Solved by changing to a Local User Licence.


                    • Re: While using nprinting, named QV license not always recognized
                      Steve Lord

                      Thanks, marking helpful for now and will circle back with correct if/when I can get it corrected.

                       

                      I did go into the qv desktop edition's license update window and notice the lef data that it does have is outdated and does not match the lef data we have in the qlikview server.  It's the same license key at the top, but the user and document license counts are old as is the control number at the bottom.  I'm sure that's a problem.  I tried replacing the old lef with the current lef data and hitting the button to contact license enabler server.  (Okay button is grayed out.)  It starts processing that request then says it can't contact the server - check my internet connection or call qlik support.

                       

                      So I will do these things next:

                      1> Ask our network administrator to push the button and see if our network connection is the problem.

                      2> If he can get through, see if he can get the current LEF data to 'stick' in the QV Desktop application. (I put it in, but it all disappears and the old lef data is there when I close/reopen the application.)

                      3> If the issue doesn't come back after we synch the lef data in the personal edition to the lef data in the management console, I might call that the solution.

                       

                      4> If the issue does come back, or the enabler server remains elusive, we'll contact Qlik and see if they can spot us a local user license.

                      (The old LEF data stuck in the qv desktop application shows 5 user cals, but currently we have 21 user cals.  I'm wondering now if the qv desktop application in the server environment can see how many user cals are in use and stumbles when it sees 5 or more of us active...)

                        • Re: While using nprinting, named QV license not always recognized
                          Colin Albert

                          A desktop licence will not show any user Cal's. User Cal's are part of a server licence.

                          Can you logon to the server using the nprinting service account and launch QlikView desktop. Then check that the setting for the QlikView licence lease are pointing at the QlikView server. It may be worth trying the loopback address 127.0.0.1

                            • Re: While using nprinting, named QV license not always recognized
                              Colin Albert

                              That should read - logon using the account that is running the power shell session that launches nprinting and check the licence lease server settings.

                                • Re: While using nprinting, named QV license not always recognized
                                  Steve Lord

                                  Hi Colin, on the qv management console system->licenses->general the checkbox for allow license lease is checked.  Please let me know if there is something like this for me to view in the desktop application; it wasn't apparent to me.

                                   

                                  my own user id is on the list of people with named licenses, as is the nprinting service account, but I am logged in as myself when I encounter this issue.

                                   

                                  Both the qv management console, and the qv desktop edition in this server environment have lef data present on their respective license tabs.   But the personal edition's lef data is outdated.  QV management console server shows 21 named cals allocated and in use, but personal edition has 5 named cals showing in its lef screen.

                                    • Re: While using nprinting, named QV license not always recognized
                                      Colin Albert

                                      From the QlikView desktop, you can use "Open in Server" to update the licence lease and remove the personal edition restrictions.

                                        • Re: While using nprinting, named QV license not always recognized
                                          Steve Lord

                                          Thanks for your help Colin, but I've tried that on days I was getting the error and it wasn't enough to clear the error.  And the error itself was sort of fake because when I hit the abort button, nprinting would still proceed to open the qlikview and run it without issues.  Bill and Steve above and below seem to have worked out solutions to get around it, though still no clue why the issue would happen only on one out of five days.  (OSusercheck was good to help me confirm who qlikview thought was accessing it.  It will likely be nprintserv once we have that account's task scheduler running things.)

                                           

                                          Steve's idea about the double-click file name sometimes being an issue might be something and the batch file might solve that (or whatever the actual issue is - seems to me that would happen all the time or none of the time but not some of the time).

                                          Bill's idea about getting a local user license onto the qlikview seems like it would work by sweeping away the issue of lef discrepancies.  Since the number of named cals in use can exceed 5 some of the time and not all of the time, that discrepancy between the qvmc and qv desktop edition lef files might fit the pattern.

                                           

                                          I'd like to get the lef data in the qv desktop edition updated first just because it is fundamentally wrong and outdated.  Then try steve and bill's ideas if fixing the old lef data doesn't solve it.

                              • Re: While using nprinting, named QV license not always recognized
                                Steve Dark

                                The issue you are seeing can sometimes manifest itself with a leased licence if you double click on a .qvw file to open it, rather than opening QlikView first and then opening the .qvw file.  NPrinting is just falling foul of this little QV glitch.

                                 

                                The recommendation is, as bill.markham has mentioned above, to buy a Desktop licence to use with NPrinting.  This is the only foolproof way of ensuring that you don't get drop outs of this kind.

                                 

                                If that is not practical I have seen this worked around by running a batch file from Windows Task scheduler to open QlikView from the command line with a reload and exit switch, with a small app with very little load script.

                                 

                                The batch file would need something like:

                                 

                                @echo off

                                "c:\Program Files\QlikView\qv.exe" /r "c:\qlikviewdocuments\reloadme.qvw"

                                 

                                As also mentioned above, by colin_albert , you will need to ensure that the batch file runs in the same user context as NPrinting, and that is of course a user that has a Named CAL.  Watch out also for the fact you can only lease a licence to two machines.

                                 

                                Good luck!

                                Steve

                                  • Re: While using nprinting, named QV license not always recognized
                                    Steve Lord

                                    Thanks Steve Bill and Colin for all the ideas and things to check and test.  If updating the lef data in the qv desktop edition, to match the lef data in the qvmc, doesn't solve it likely the batch file or local user license approach will.  I'll come back with correct answer credit for whatever does the job.  (Our network administrator is looking at why qv desktop couldn't contact the license enabler server now.)  Thanks again!

                                     

                                    edit, support info from the qv desktop edition for reference:

                                    Client Build Number           11.20.12904.0409
                                    Server Build Number         
                                    QlikTech Product              QlikView 64-bit Edition (x64)
                                    License Key                   [Leased license]
                                    PE Recoveries Remaining       4
                                    CPU Target                    x64

                                     

                                     

                                    I will look at that license key row the next time the error prompts start, but glad to see it's not eating up recoveries.