The MID Server 'url' parameter cannot be updated from the instance, potentially causing outages after Instance Rename or Worker node implementation - Known Error

The MID Server 'url' parameter cannot be updated from the instance, potentially causing outages after Instance Rename or Worker node implementation Description The MID Server 'url' parameter is read only in the instance. It cannot be updated from the instance/servicenow side, and must be manually updated by editing the config.xml file and restarting the MID Server, for each MID Server.

The reason that is a problem is that there are 2 instance automations that will change the instance URL: - Instance Rename, where the URL of the instance is changed. - Worker Node migration, where an additional different URL is provided for integrations such as MID Servers, to separate them from the UI Nodes that end users will be using for their browser requests. See KB0815860 MID Servers and Worker Nodes

And also other reasons a customer may want to update the URL: - To use a interception firewall/proxy/forwarder/dns alias URL instead of the instance URL - To use a Custom URL https://docs.servicenow.com/bundle/xanadu-platform-security/page/integrate/authentication/concept/custom-url.html

The MID Servers will all need manually reconfiguring on the host servers, which could be in the hundreds, and might not be directly accessible by the customer.

For Instance Rename, if a customer is not aware of the need to reconfigure all MID Servers, then there will be a total MID Server outage after 2 days when the old URL is turned off. For Worker Node migration, if any MID Servers remain pointing the the reduced pool of UI nodes API_INT semaphores after the migration, this could cause MID Server connection/performance issues and problems for User requests.

If you attempt to change the url parameter for a mid server in the instance UI, you receive the warning "You are attempting to add or modify a read-only parameter -- not allowed" because the MID Server code doesn't support updating that in its config.xml and restarting on the new URL. If the MID Server platform supported reconfiguring the URL from the instance, then this could also be automated as part of the rename/worker node workflow, without the need for any manual steps by the customer. In theory the MID Server platform could be enhanced to allow that, update its config.xml file, then trigger a restart , but the current design does not support that.

Steps to Reproduce

Provision an instance Install a mid server for it Request an instance rename via datacenter Wait 2 days for the old URL to be turned off MID Server will go down

Provision an instance Install a mid server for it Request a worker node migration MID Servers will now be using the UI Nodes, and likely cause performance problems for the end users and/or app node, which in turn will impact the MID Server related jobs/connections/performance Workaround This is expected behavior and by design in all currently supported releases.

MID Servers will continue to need manually reconfiguring as part of any URL change, for any reason. That will need doing within 2 days of an instance rename, or immediately after a Worker Node migration.

For each MID Server: Log into the host that the MID Server is installed on, and navigate to the Home directory. (the hostname and home folder can be seen in a list of MID Servers in the instance.) Open config.xml in a text editor. If on Windows, use a an editor that understands UNIX line feeds e.g. Wordpad, not Notepad. Find the line with the 'url' parameter this value to provide the URL of your organization's ServiceNow instance. --> instancename >.service-now.com/"/> Edit the value to change it to the new URL. Be careful not to loose the "/> bit on the end of the line while doing that. e.g. instancename >worker.service-now.com/"/> Save the file Restart the MID Server, either: Click the 'Restart MID' related link on the MID Server's form in the instance. or Restart the MID Server Service directly, either running stop.bat and start.bat from a command line, or from the Services Control Panel. Related Problem: PRB1248643