Windows Service Monitor returns an error about butler

[mountaindude]

Ohh... interesting. Could it be that Qlik changed the name of the engine service in QS 2023-May?
Got to admit that I have not tested Butler with that QS version - will certainly have to do so!

[rumen-vasilev]

Hi Göran,

I checked the names of the services. They have remained the same. I have tried it with any service of the Windows operating system and it works. Is it a problem that Butler is running on a separate Windows computer and not directly on the Sense server?

BR,
Rumen

[mountaindude]

Butler should be able to check service status on a remote server, assuming firewalls allow this.

First, there should be better error handling for this. Throwing an error like that is no good.
Will put that on the todo list.

Then, some questions to narrow things down:

• You are running Butler on a Windows server (server A) and Qlik Sense on another server (server B), correct?
• Can Butler monitor services on server A?
• Can Butler monitor other services (i.e. not QS engine service) on server B?

[rumen-vasilev]

Butler should be able to check service status on a remote server, assuming firewalls allow this.

First, there should be better error handling for this. Throwing an error like that is no good. Will put that on the todo list.

Then, some questions to narrow things down:

• You are running Butler on a Windows server (server A) and Qlik Sense on another server (server B), correct?
  ==> Correct.
• Can Butler monitor services on server A?
  ==> Yes.
• Can Butler monitor other services (i.e. not QS engine service) on server B?
  ==> Yes.

[mountaindude]

Edit: The below is still true to the best of my knowledge, but I also found a small bug that causes remote lookup of service status to fail.
So, your only option with current Butler version is to run Butler on the same server as Sense.
Fixing the bug is easy though, so it should hopefully not be too long until a new version is out.

---

I had a look at this and it's most likely a permissions problem.

It can be tested by running this command on the server where Butler is running:

sc.exe \\10.11.12.13 query state= all

If the response looks like this you got a permissions problem, with the remote/Sense server blocking access to the services on the that server.

C:\temp>sc.exe \\10.11.12.13 query state= all
[SC] OpenSCManager FAILED 5:

Access is denied.


C:\temp>

If you get the same error as above this can be solved in a few different ways:

1. Modify Butler itself so it authenticates with the remote server before trying to get info about its services. This requires some work, but would be a nice and clean solution.
2. Disable the security mechanism preventing Butler's access to the remote server. This works, but lowering security may not be ideal/allowed. Some editing of the registry of the Sense server is needed, examples here. Some old info (but still relevant I believe) from Microsoft here.
3. If the user account running Butler is member of the domain Administrators group, things should work even with today's Butler version. The question then is whether it's ok for the Butler service account to be a domain admin.
4. Run Butler on the same server as Sense itself.

[rumen-vasilev]

Hello Göran,

This issue is not urgent for me. I will wait for the new version.

Thank you very much!

Rumen

[mountaindude]

Version 9.3.1 adds some bug fixes and improvements to Windows service monitoring.
Among other things there is clearer log output when authentication to a remote server (on which Windows services should be monitored) fails.

[rumen-vasilev]

Hi Göran,

I have just installed the new version 9.3.1 and I still have the same issue. Please take a look at the screenshot.

BR,
Rumen

[mountaindude]

Thanks for reporting it, I've noted the same on some servers, while everything works great on other servers.
Not sure yet what's going on, need to find what differs between the different server / what causes the errors.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.