Service Control on one server support for OTAP

How to solve the following:
We have 4 seperate OTAP environments with each their own (identical in case of structure) SQL database.
ServiceControl manager is setup on a different machine.
When I configured to run SenviceControl on the O (of OTAP) It generates tables and uses the error and audit queues as entry for the endpoints.
Those error and audit table (queues) exist on every environment.

Now I created the ServiceControl for the O environment, I want to create the ServiceCOntrol Instance for the T (and A and P) the same way. Only difference: Database connection string.
Here is the problem, I cannot create an ServiceControl Instance next to the O with the same name because the Windows Service Name and SQL tablenames are identical and I am not allowed to have multiple Windows Services (which is also generated by the ServiceControl creation) with the same name.

Anyone have a solution for this deployment issue?

Am I right in saying that you want to have 4 instances of ServiceControl running on 4 separate machines (one for each in OTAP), but you also want each of those 4 instances to have the same name?

Or do you want each of those 4 instances running on the same machine, but consuming messages from different queues?

If it’s the latter and you want all 4 instances running on one machine, wouldn’t it be better to have a different name for each instance so that you can tell which environment it is for?

It is possible to create an instance with a different name, but have it consume messages from a queue of a different name using the InternalQueueName setting. This would allow you to create 4 instances named ServiceControl.Ontwikkeling but have it consume messages from the ServiceControl queue.

This also sounds like something that should be an environment variable, since it’s describing the environment that the instance is consuming messages from (but this requires each instance to be on a separate machine).

A word of caution though: Your P environment is at risk of being affected by everything else happening in your OTA environments. I strongly recommend against doing this and keeping your P (at least) separate.

Thank you William. I think the InternalQueueName could help me.
But how do I use it or how do I set it before I I am going to create a serviceinstance from the Service Control management tool.

Thnx in advance
Robert

The process would be:

  1. Create a new instance of ServiceControl using SCMU (called ServiceControl.Ontwikkeling with a connection string pointing to your ontwikkeling environment)
  2. Use SCMU to stop the instance from running
  3. Add a new appsetting key <add key="ServiceControl/InternalQueueName" value="ServiceControl" /> to the servicecontrol.exe.config file
  4. Open a command prompt and navigate to location of the ServiceControl.exe file
  5. Run ServiceControl.exe --setup
  6. Start ServiceControl again via the SCMU.

At this point, you will see in SCMU that you have an instance of ServiceControl called ServiceControl.Ontwikkeling connected to your ontwikkeling environment database, but consuming messages from a queue within that database called ServiceControl

You can repeat the process for the other environments too.

Many thnx This is what I need!

Hey William,

It seems not to be working . I created a service with the name nServiceBus_O.
Then I added the config with the line of:

<add key="ServiceControl/InternalQueueName" value="Particular.OTKeten" />

I have run the servicecontrol.exe --setup and of course stopped the service first.

But in the eventviewer I keep getting the error:
Microsoft.Data.SqlClient.SqlException (0x80131904): Invalid object name ‘OGRJ01OTKETENMESSAGEBUS.dbo.Particular.nServiceBus_O’.

So it keeps looking for the table with the name of the service.
The internalQueueName setting should overwrite this?

Any thoughts are welcome.

EDIT:
In the log directory there was a file Particular.nServiceBus_O-configuration.txt that has the following section:

“Receiving”: {
“LocalAddress”: “Particular.nServiceBus_O@[dbo]@[OGRJ01OTKETENMESSAGEBUS]”,
“InstanceSpecificQueue”: null,
“LogicalAddress”: {
“Qualifier”: null,
“EndpointInstance”: {
“Endpoint”: “Particular.nServiceBus_O”,
“Discriminator”: null,
“Properties”: {
“Schema”: “dbo”,
“Catalog”: “OGRJ01OTKETENMESSAGEBUS”
}
}
},
“PurgeOnStartup”: false,
“QueueNameBase”: “Particular.nServiceBus_O”,
“TransactionMode”: “SendsAtomicWithReceive”,

Looks like something went wrong.
How can I correct this.?

It looks like it’s not reading the setting at all, which would only happen if this is not a error instance.

Is this perhaps an auditing or monitoring instance you are setting up?

I double checked it but it’s really an ServiceControl instance… I looked at the code (of github) of teh servicecontrol and can’t figure out why he is ignoring the setting.
The setting works when creting the queue’s, but not when the service control is running and it is going to consume the queue.
Perhaps that clarifies it a bit

I think it’s probably best to escalate to a support case then so that we can get on a call and look closer at what’s happening. Can you log a ticket through one of our support options here: Support options • Particular Software

Looks like we have a bug. The internal queue name is not applied all the way through the stack with SqlTransport.

Until we get that bug fixed, a workaround involves a tweak to the above steps:

  1. Create a new instance of ServiceControl using SCMU (called ServiceControl.Ontwikkeling with a connection string pointing to your ontwikkeling environment)
  2. Use SCMU to stop the instance from running
  3. Add a new appsetting key to the servicecontrol.exe.config file
  4. Open a command prompt and navigate to location of the ServiceControl.exe file
  5. Run ServiceControl.exe --setup
  6. Change the windows service to specify the parameter as a command line arg
    • Run (in an elevated cmd prompt): sc config Particular.nServiceBus_O binPath= "C:\Program Files (x86)\Particular Software\Particular.nServiceBus_O\ServiceControl.exe --serviceName=Particular.OTKeten"
  7. Start ServiceControl again via the SCMU.

Hi William,

I am still having some issues which I can’t solve. I don’t even get to your work around for the Internal Name issue.

I am now struggling with the problem that my login account must have rights on the database in the service control instance even when I run the service under another account.

Case:

On server A there is the sql database . Only an active directory service account has access to it

On server B I want to run the monitoring.

The problem is, when you setup the service control instance in SCMU it uses your credentials from how you are logged in on Server B.

First I installed the service control instance on B to a local sql server where my login account has rights to.

Then I changed the User account to the service that has the rights on the sql on server A. Didn’t change the connection string

That all works.

But now I want to redirect the connection string to the sql database on server A. And that doesn’t work. ServiceControl.exe –setup crashes if I try it by command line.

If I use SCMU it stops stops and won’t save my new settings because my login account has no rights on the sql server on Server A.

I have no control over server A and I will never get the rights there because it’s a production database but I would love to monitor the events. The administrator has run a script on the db so the tables with the correct names etc are there. So there is no need for the SCMU to generates tables.

How get I get passed this issue?

Greets

Robert

What is the error?

Could you instead:

  1. Open a Powershell using the credentials of the service account
  2. Add the instance via powershell or run with --setup