In the nprinting webengine log file, I find this message (several times):
2016-03-01 01:22:18,423  ERROR Qlik.NPrinting.WebEngine.Engine - proxy: 2016/03/01 01:22:18 server.go:1934: http: TLS handshake error from 10.32.9.43:57546: tls: no cipher suite supported by both client and server
Can anyone help?
The two accounts you're talking are :
1. Service account with which qlikview server services run, and
2. Service account with which nprinting services run.
Does these two accounts need to be different ? In my case, I'm having different account each for qlikview services and nprinting services, but still getting the same error. Again the document I'm creating connection upon is a huge in size (~1.5 GB).
Can you please help me to understand whether I got it correct way ? Or if not, can you please throw some more light on the solution that you have suggested.
Many thanks in advance.
Hello Hardik, yes the two service accounts need to be different. That resolved our issue but it sounds like you already have 2 separate services running. What errors appear in the log file?
Also, check/try the following:
1) Make sure your .qvw does not have section access
2) Make sure your connection to the .qvw is not to a mapped drive on the server
3) Restart the services using these steps:
1-delete the connection to your .qvew
2-stop the services in the following order:
-QlikView NPrinting Scheduler
-Qlikview NPrinting Web Engine
-Qlikview NPrinting Engine
-Qlikview NPrinting Repo Service
3-restart the services, one at a time in the reverse order as above, starting with the rabitt MQ
4- create a new connection, with a new name and generate
Coincidentally, our engine is offline this morning and the rabbitt MQ service won't restart...so anyone reading this that knows how to jumpstart rabitt MQ, please advise.
Sorry for the delayed response and Many thanks for your valuable suggestions. However, I had tried almost all of what you have mentioned here.
Ultimately, creating a new connection and regenerating meta data helps in such cases, I would prefer to call it as a workaround only.