- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-21-2025 10:22 PM
Hi All,
Good morning.
Hope you are doing well.
Is it possible to choose MID server dynamically based on region through a PowerShell script? I need to run SSH command against multiple servers based on different regions, and in an ideal scenarios it is not recommended to use same MID server for each server as servers are located in different regions.
Please assist.
Best Regards,
Naveen
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-22-2025 06:51 AM
Hi @_navin9898 ,
1. Understanding the challenge
* ServiceNow usually chooses the MID Server automatically, based on:
* Capabilities
* IP ranges
* Affinity settings
* For PowerShell or SSH steps (like in Orchestration or custom scripts), you can:
* Let the system auto-select
* OR manually force it through MID Server selection logic
Since servers are in different regions, it's best not to use the same MID Server across all, to avoid latency or firewall issues.
Solution: How to do it (best practices)
2. Use capabilities & IP ranges
* Tag each MID Server with capability like:
* region:EMEA
* region:APAC
* region:AMERICAS
* Assign IP ranges (subnets) for each region to each MID.
* When Discovery or Orchestration runs, it auto-picks the MID Server with matching capability for the target server.
Benefit: No code, built-in ServiceNow method.
3.Use MID Server selection script / business rule
If you must control selection dynamically from a script:
* In Orchestration, you can:
* Create a PowerShell Activity or SSH Activity
* Set its MID Server field dynamically.
* You can write a Script Include or Flow Action that:
* Looks up the target CI or its region
* Finds a MID Server in that region (ecc_agent table)
* Updates the orchestration step to use that MID.
4 Use PowerShell script itself to route
* Less recommended: write PowerShell that connects to different jump servers/MID servers.
* But better: use Orchestration and ServiceNow’s MID selection to do this, as it’s more manageable.
5 Use Connection & Credential Alias
* Define different Connection & Credential Aliases mapped to different MID Servers.
* In your orchestration flow, dynamically select which alias to use, based on region.
Recommendation (best practice):
* Tag your MID Servers properly with region capabilities.
* Configure Discovery or Orchestration to auto-select MID by capability.
* Use IP ranges as fallback.
* For rare exceptions: write a script that looks up ecc_agent and sets activity.mid_server.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
ServiceNow Community MVP 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-22-2025 05:59 AM
Hello @_navin9898,
Please refer to the below link:
https://www.servicenow.com/docs/bundle/washingtondc-it-operations-management/page/product/discovery/...
If this is helpful, please hit the thumbs up button and accept the correct solution by referring to this solution in future it will be helpful to them.
Thanks & Regards,
Abbas Shaik
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-22-2025 06:51 AM
Hi @_navin9898 ,
1. Understanding the challenge
* ServiceNow usually chooses the MID Server automatically, based on:
* Capabilities
* IP ranges
* Affinity settings
* For PowerShell or SSH steps (like in Orchestration or custom scripts), you can:
* Let the system auto-select
* OR manually force it through MID Server selection logic
Since servers are in different regions, it's best not to use the same MID Server across all, to avoid latency or firewall issues.
Solution: How to do it (best practices)
2. Use capabilities & IP ranges
* Tag each MID Server with capability like:
* region:EMEA
* region:APAC
* region:AMERICAS
* Assign IP ranges (subnets) for each region to each MID.
* When Discovery or Orchestration runs, it auto-picks the MID Server with matching capability for the target server.
Benefit: No code, built-in ServiceNow method.
3.Use MID Server selection script / business rule
If you must control selection dynamically from a script:
* In Orchestration, you can:
* Create a PowerShell Activity or SSH Activity
* Set its MID Server field dynamically.
* You can write a Script Include or Flow Action that:
* Looks up the target CI or its region
* Finds a MID Server in that region (ecc_agent table)
* Updates the orchestration step to use that MID.
4 Use PowerShell script itself to route
* Less recommended: write PowerShell that connects to different jump servers/MID servers.
* But better: use Orchestration and ServiceNow’s MID selection to do this, as it’s more manageable.
5 Use Connection & Credential Alias
* Define different Connection & Credential Aliases mapped to different MID Servers.
* In your orchestration flow, dynamically select which alias to use, based on region.
Recommendation (best practice):
* Tag your MID Servers properly with region capabilities.
* Configure Discovery or Orchestration to auto-select MID by capability.
* Use IP ranges as fallback.
* For rare exceptions: write a script that looks up ecc_agent and sets activity.mid_server.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
ServiceNow Community MVP 2025