MID Server for multiple sub production instances

[hadyndickson]

What is the best practises / pitfalls / workarounds for deploying mid servers and using them with multiple instances?

Currently I have 3 sub prod instances (dev,test,stag) and 1 production isntance.

I have 2 Mid Servers (Dev, Prod) Prod is linked to production instance an reporting UP status. Dev is linked to dev instance and reporting UP.

From the test instance I cannot seem to communicate with the dev MID server. It reports being DOWN.

Interestingly there is a "url" configuration parameter specified in the mid server record on the test instance which points to the dev instance and cannot be changed.

Can a mid server ONLY be bound to 1 instance?

[doug_schulze]

Thats correct Hadyn, a single midserver application can only "work for" a single instance. While multiple MIDServer applications can run on the same host..

[Hadyn · Accepted solution]

Thanks Doug, I found this in the docs too: Install multiple MID Servers on a single system

For anyone reading this, I ended up Installing multiple separate MID server service instances on the one windows host, all working out of different folders on c:\.

Each MID server service instance can only be configured to talk to one servicenow instance.

Be sure to match your MID server version / patch level to your target instance.

I use the same user record in servicenow across all instances to authenticate. (After clone things will continue to work, although I guess you could have multiple user records across all instances for each mid server instance)

If you are tempted to copy/paste the agent folder per install, be sure to remove the <parameter name="mid_sys_id" value="123456789123456789123456789"/> from config.xml in each new install. A new mid server (ecc_agent) record is created on the target instance during initial installation. Interestingly if you remove the record from the target instance it will be recreated with the same sys_id eventually. This makes sense if you clone from prod and don't have that mid server record already. I guess it's possible to point each mid server service instance to the same mid server record sys_id in the target instance via the mid_sys_id value in the config.xml as above. Then You would only have one mid server record in servicenow but it would communicate to the correct MID server service instance per unique servicenow instance (haven't tried this).

Also check out .\agent\conf\wrapper-override.conf for the default service names.

I ran installer.bat as administrator each time. Also I had to restart between installs else I got a null pointer exception during install.

[doug_schulze]

Couldn't have described the process better!   Great work..

One thing to contribute around your thoughts about the sysID... was to have the midservers all have the same name, name in regards to how the instance knows the application..This will help streamline use as well for when in dev i can set something up to use 'middisco1' on the development servicenow instance and have that same named midserver on prod, really seamless when moving update sets...

Check out the midserver best practices documentation and I talk a bit about what you are doing here... But again, you describe it much more succinctly

[hadyndickson]

If anyone is reading this, I did end up configuring each mid server windows service to point to the same mid server record sys_id in the target instance via the mid_sys_id value in the config.xml as above. Now I have 1 unique mid server record shared across all my servicenow instances but it communicates to the correct MID server windows service.

So in summary: I have 2 Mid server Windows Hosts, each running 4 Mid server windows services (one for each instance of servicenow, dev, test, stag, prod). In each instance of servicenow (dev,test, stag, prod), I see both of my 2 Mid servers.

After patching or upgrading an instance, my mid servers continue to function.