I should add that we are intentionally NOT specifying either `--User`
or `--ServiceUser` when installing the service via prunsrv x64.
On Sat, 31 Aug 2019 at 00:18, Adam Retter wrote:
>
> After just updating from prunsrv x64 1.1.0 to 1.2.0, we are finding
> that prunsrv will no longer start our se
After just updating from prunsrv x64 1.1.0 to 1.2.0, we are finding
that prunsrv will no longer start our service under the "local service
account".
It is very strange, as if I launch a cmd.exe as the Administrator
User, and run `prunsrv //TS/FusionDB-Server` then it starts up
correctly on the con
Known issue with 32-bit processes.
You can track progress here:
https://issues.apache.org/jira/browse/DAEMON-401
Mark
On 30/08/2019 15:57, David Gutknecht wrote:
> Hello everybody,
>
> I tried to update the prunsrv.exe (1.0.15) installed on my server
> (Windows 2012) to the latest version (1.2
Thank you for the response. A conditional definitely works, as does a
specific namespaced function, e.g. ${val:orError(my.field)} -- if I cannot
persuade our template authors of either of these approaches, I will look at
working towards building a case and a PR around TemplateInterpreter.
On Fri,
I don't see any current way to throw an exception on null evaluation through
configuration.
A case can be made to add this as a feature (a hook checking eval result
before doPrint in TemplateInterpreter).
And about making this use case, you can't workaround using a conditional
(${user3.firstName?:e
Hello everybody,
I tried to update the prunsrv.exe (1.0.15) installed on my server
(Windows 2012) to the latest version (1.2.0)
I simply replaced the exe with the newest version.
After replacing it I was no more able to start the service.
Windows deliver the message "1067: the process has unexp