How to setup remote ServiceControl instances on another server

We are trying to set up ServicePulse/ServiceControl on our DEV environment. We have a dedicated server where ServicePulse and the primary ServiceControl are installed.

We have self made adapters sending messages via MSMQ, they are installed on different Windows Core servers. The idea is to install ServiceControl on those Core servers and connect them as remotes to the primary ServiceControl.

I tried this set up with 1 remote to start with. My problem is that I can’t get it running.
In ServicePulse I get the error:
The remote at: ‘…’ did not respond within the allotted time of ‘00:’

Is it possible to get it working in this set up?

Hi @hobut

Thanks for reaching out to us; I am sorry you are having issues setting up ServiceControl.
Are you trying to install remote audit instances in the Windows Core servers and connect those instances to the primary ServiceControl instance?
Have a read of this documentation, and see if it solves your issue.


Hi John,
Yes, I am trying to install a remote instance on a Windows Core server and connect the instance to the primary ServiceControl instance on another server.

Configuration is like in the documentation you’ve sent. Key and value for ServiceControl/RemoteInstances are added in the configuration file of the primary instance. Of course in my case the uri is not localhost but the host name of the server with the remote instance. The error I get is: “The remote at: ‘…’ did not respond within the allotted time of ‘00:00:10’. It will be temporarily disabled”

It might be a permission issue? I tried to make the remote uri accessible by “netsh http add urlacl url=… user=…”, without success.

Ensure that the full name matches. Lets say your machine name is daffyduck but you access it via than you need to enter that whole fully qualified domain name.

An alternative is to use * instead which is a wildcard match.

Do you get a JSON response when you open the url in the browser from the remote machine?

Hi @hobut

As @ramonsmits mentions, when you have configured your Audit Instances, you need to ensure they are configured to be accessible from a remote client on specific addresses.
You have a few options, you can use either a * or a +.

or to be safer, be more explicit, for example, fully qualified DNS or IP or machine name

Top-level wildcard bindings (http://*:80/ and http://+:80 ) should not be used. Top-level wildcard bindings create app security vulnerabilities. This applies to both strong and weak wildcards. Use explicit host names or IP addresses rather than wildcards. Subdomain wildcard binding (for example, * ) isn’t a security risk if you control the entire parent domain (as opposed to *.com , which is vulnerable). For more information, see RFC 9110: Section 7.2: Host and :authority.

Source: HTTP.sys web server implementation in ASP.NET Core | Microsoft Learn

So, to be clear, this needs to be done in the Audit instances.

I hope this helps.

Thanks for the help! In ServiceInsights it works great now.

In ServicePulse it works when I connect to the remote server. When I connect to the url of the primary ServiceControl (localhost) the failed messages and monitoring stay empty. Strange, because they both work with ServiceInsights.

Any suggestions?


Can you please check your remote instance configuration in the primary ServiceControl instance to ensure that the setting ServiceControl/RemoteInstances is pointing to the updated audit addresses as per this documentation?


Hi @hobut

Do you see any error on the Connections Configuration screen of ServicePulse, when you press Test?

Hi @John_Simons
Thanks for your reply. I’ve checked that, no errors. It is successfully connected.

Hi @hobut

Let’s figure out this step by step.
So that I understand your setup better, can you please tell me if this is true:

  • One ServiceControl primary
  • Many ServiceControl Audits
  • One ServiceControl Monitoring
  • All the above running on separate machines

Hi @John_Simons

My setup is like this:
On server A:

  • 2 primary ServiceControl instances, 1 for transport MSMQ, 1 for transport Azure Service Bus
  • 1 ServiceControl audit instance, just for Azure Service Bus
  • 2 ServiceControl monitoring instances, 1 for transport MSMQ, 1 for transport Azure Service Bus
  • for the MSMQ instances we added the key “ServiceControl/RemoteInstances” in the config file with the instance on server B as value

This server will be used for monitoring, ServicePulse and ServiceInsight are installed here. We will try to install ServicePulse on 2 ports, so we can use 1 port for MSMQ and 1 for Service Bus.

On server B:

  • 1 remote ServiceControl instance for transport MSMQ
  • 1 remote ServiceControl monitoring instance for transport MSMQ

On Server A ServiceInsight is working correctly when connected to the primary ServiceControl instance for MSMQ (via localhost and port). Also when connected to other instances.

On server A ServicePulse does not work when connected to the primary ServiceControl instances for MSMQ via localhost. The connection is successful but there are no failed messages. When connected to the remote ServiceControl instances for MSMQ on server B it works fine.

Hi @hobut

I understand now the confusion.
So this is not very clear in the documentation about remote instances, but if you look at the diagram in that documentation page you will notice that there are 2 separate ServicePulse instances and a single ServiceInsight.
So in other words, ServiceInsight supports gathering both errors and audits from multiple instances via configuring remote instances, but ServicePulse does not.

My next question is whether you need ServerB instances at all?
My understanding, from your original question is that you want to setup ServiceControl and ServicePulse in your DEV environment, so assuming that you install:

  1. a single ServiceControl primary instance ingesting messages from Error queue
  2. a single monitoring instance
  3. and a single audit instance, ingesting messages from Audit queue

You then configure all your DEV endpoints:

  • to send audits to the Audit queue mentioned above,
  • to send errors to the Error queue mentioned above,
  • and finally to send metrics to the metrics instance mentioned above.

Would that work?


Just for completeness: If you want a single ServicePulse instance for everything you can look at the approach mentioned here

Hi John,
Thanks for your reply. It makes it more clear to me how the connection to ServicePulse works.

We are starting this on our DEV environment, when we have a setup that satisfies us, we will deploy it to TAP.
In our setup we have a lot of “server B like” servers, where software runs sending MSMQ messages.

Do I understand it well that you are proposing that we run ServicePulse from our server B’s?
The thing is that they are all windows core servers, they are not configured to run websites.

Hi @hobut,

Regarding ServicePulse, I would install it on the same server as the ServiceControl primary instance.
I hope this makes sense.