Hello Deepanshu,
Yes it is completely possible to connect a single MID Server to multiple instances. And it doesn't take much to do it. I regularly connect any new MID Server to a few of our instances.
I'll assume you already have a MID Server connected to Prod. In that case, RDC into the windows box MID Server. From there, you can launch your "services.msc" to look at the running services. For example, I've just logged into one of our MIDs that is running for five different MID Server agent services, each connecting do a different instance.
If you have one for Prod (like mine, called "ServiceNow MID Server"), then you simply need to copy and re-launch new services on this MID Server.
First, locate your directory containing the agent service files, I think the default is "C:\servicenow_mid" but yours may vary. It will contain a sub-directory called "agent" - you'll simply copy this directory and paste it in the same parent directory, then simply rename the copy for the instance it should be related to. Here is an example of my directory tree:
Once you've copied the directory, you'll need to edit a couple of files inside it.
For ease of understanding, I'll simply refer to the new directory as "agent" in order to help you locate the files you'll need to adjust.
Second, inside the agent directory, there is a config.xml file that will need to be edited.
(agent\config.xml)
About twenty lines down (or so, depends on your configuration), you'll see a parameter like this:
<parameter name="url" value="https://production_instance.service-now.com/"/>
I put production_instance in there as a place holder. This needs to be replaced with the sub-production environment URL you are targeting. Our production instance uses a unique name that does not match the actual URL of our production environment, but all of our sub-production environments replace this URL value with the actual sub-production environment URL that we use to access that instance (https://companydev.service-now.com)
Next, just a few more lines down, you will have the service account that is used to access the MID
<parameter name="mid.instance.username" value="s-service_account"/>
<parameter name="mid.instance.password" secure="true" value="your_password"/>
Put in your service account name and password which will be used for this agent. If you see an encrypted password in the value field, jus replace it with your string password and make sure secure="true" so it will be encrypted again with the new environment. If you don't do this, it won't work, the encryption will be tied to the instance.
Next, just a few more lines down, you'll see this guy:
<parameter name="name" value="name_of_server_in_instance"/>
You probably have a naming schema you use to designate your MID Servers, or how they appear in your MID Server list in ServiceNow, so name it accordingly. In our environments, we keep the names between environments identical to keep things simple, so I wouldn't touch this, but you could change things up if you wanted to (not recommended).
Next, at the very end of the config.xml file, there may be a number of other parameters that will be tied to the original agent service config.xml file and the instance it served (probably production). You'll simply want to delete these. For example, here is what I see at the end of mine, and I would simply delete these lines.
<parameter name="keypairs.mid_id" value="52cf0313da02346022f9f9f31fdd4300"/>
<parameter name="mid_sys_id" value="2564e07adb8e012937aff27b996190f"/>
<parameter name="mid.cloud.provider" value="none"/>
Third, you need to delete any files referencing a keystore. The location can vary depending on your installation. You can either find the files in agent\keystore or agent\security. Either way, once you find them, delete them, when we launch this new agent, it will generate new ones.
Fourth, you need to edit the wrapper-override file found here: agent\conf\wrapper-override.conf
In it you will find two lines that will need to be modified, the wrapper.name and the wrapper.displayname
Here is what it probably looks like from the Production installation:
################################################################################
# Windows Service
################################################################################
# The following properties must be unique per MID installed on the same system.
#
# REQUIRED: Name token of the service
wrapper.name=snc_mid
# REQUIRED: Display name of the service
wrapper.displayname=ServiceNow MID Server
So simply change those two lines to match your naming schema:
wrapper.name=snc_mid_dev
wrapper.displayname=ServiceNow MID Server - DEV
This determines what appears in your list of services (the first image above) and it will need to be different than the original or one will always be shutting off (a bad thing).
Once all of these steps are complete, go to your new agent directory and launch the batch file start.bat.
Almost immediately, you will see the new service show up on the MID Server, and after a few minutes you'll see a new MID Server show up in your target environment.
Note: Because a new MID Server record is created in the target environment, if you reference the MID Server in a developer environment while creating awesome stuff, it will be pointing to a specific sys_id that will not exist in Production. In each environment, the same MID Server record will have a separate sys_id. So when your new software finally reaches Production, you may have to update a record or two in Production to ensure you are pointing to the Production MID Server.
Hope this helps.
Andrew Colson
