QlikView automation no more working in new server

[Edo_Sax]

Hello,

I developed a VB.NET application currently working on a Windows Server 2008 R2 architecture. QV version is 11.2 SR5. The application reads data from a QV document and fills a Microsoft Excel template following a set of rules based on a configuration file. The application runs on a scheduled basis, using the Windows Task Scheduler, which runs the application in a non-interactive way.

The customer needs to update the OS to Windows Server 2016, so the whole system has been migrated and reconfigured. The application works correctly if launch it in an interactive fashion, but if I try to schedule it, no output is generated. So, reading the logfile the application outputs, I can see that the QlikView application is correctly instanced, but when the OpenApp method is called to open the QlikView document, the application waits indefinitely, with no errors or other feedback.

The DCOM configuration has been set (the user launching the application has full grants); there are not folder access or document access issues; there are no section access or other issues regarding the specific document, because I also tried to open an empty QVW but the result was the same...

Any ideas? Are there known issues about QV 11.2 automation under Windows Server 2016? My last attempt was to upgrade to QV 11.2 SR19, because I read that Windows Server 2016 support is granted only from SR18, but I had no benefits from this.

Thanks to everyone in advance.

Edoardo

[marcus_sommer]

The windows-task is running but nothing happens? No open/reload of the application or no export to excel? How is the task triggered - per internal schedule, per external call (any batch) and/or manually? How is the user granted - within the task or in any other way, for example with a RUNAS batch? Is this user logged in at the time of executing?

- Marcus

[Edo_Sax]

Hello Marcus and thank you for your interest.

My application starts by creating a Qlikview.Application instance and then calling .OpenApp with the QVW path. A logfile is written and a .writeline call is set both before and after the completion of the OpenApp method.

If I launch the application in interactive mode (from a cmd window), the Document opens and the entire process works to the end. I also configured a scheduled task (that I can launch manually anyway) to launch the application without the user logged. The user who executes the command in the scheduled task is the same I use for the successful test in interactive mode; it is a machine administrator and has full grants in QlikView DCOM configuration; in DCOM config is also the user who must execute the application.

The configuration is IDENTICAL to the one used in the old system, where the entire procedure works regardless of being activated by interactive launch in a cmd window or by task scheduler (no matter if the task is triggered in a timely fashion or manually).

[marcus_sommer]

If an user isn't logged in windows will take the "default" user for many (all ?) handles/processes because the granted user from the task has indeed the access rights to start this process and to access the files but everything which needs a logged in user will fail. I couldn't exactly say which things needs to be done / configured to get it running but I think your issue is related to the above mentioned matter (I struggled many years ago on the same and since then my user is always logged in).

- Marcus

[Brett_Bleess]

Edoardo, generally, Server 2016 comes with a lot more security features enabled by default than did Server 2008, so my hunch would be this is an OS security related problem.  I would verify whether Windows Defender has been deactivated on the new server or not, as if that is running, that is very likely what is causing the issues.  Defender is fully enabled by default in Server 2016, you have to disable it and its features manually.  That would be my best hunch from past experience.

Regards,
Brett

[Vikas]

Hi Edoardo,

We are facing same issue , please suggest any solution or workaround .

Thanks,

Vikas