MID Server for multiple sub production instances

hadyndickson · ‎03-13-2017

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?

Hadyn · ‎03-14-2017

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.

View solution in original post

Jim Coyne · ‎04-13-2021

So I guess, as @doug.schulze alluded to, using the same Name and sys_ids for the MID Servers makes things easier when setting up Data Sources, etc... that use a MID Server and then moving those changes over in Update Sets. Right now we specify the MID Server in the dev instance but that, of course, does not match one in our other instances. By using the same identifiers, moving changes over to another instance would then match, making it easy to move those changes over, instead of having to reset the proper MID Server each time.

@doug.schulze, I've tried finding the best practices you mentioned, but cannot. Could you possibly provide a link?

alan_lowrance · ‎01-23-2020

Looks like with New York they want only one midserver service running on a server? After NY Patch 4 Hotfix our instance tried updating the midservers to match version and failed after the first one. We had a Prod, Test, and Dev service all running on the discovery midserver and only the Prod one got updated and the rest are offline and failed the update but I wonder if that is in where it downloads the update to (cause looks like each tried to download to %appdata% and if the version already existed there is that where it fails?

John Vo1 · ‎02-12-2020

Alan,

Do you have a link to this? My infrastructure guy wanted to put prod and dev on 1 VM. From what I'm reading it's recommended that it needs to be on it's on VM.

Thanks,

John

Greg Brubaker · ‎05-11-2020

Any luck with this? We're likely to enter a hi ticket for similar in NY.

One may want to consider: https://community.servicenow.com/community?id=community_article&sys_id=95e015eedb514c18d82ffb2439961...

doug_schulze · ‎04-13-2021

Here you go