- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 10-26-2020 03:00 PM
Summary
I have not found any documented Best Practice for managing MID Server Selection either in the Communities or in the ServiceNow documentation - so MID Server selection is a bit of a dark art. However, this area became a little clearer as a result of a recent SN Support Case (CS4905528) - so I though I would share my learnings with the community.
3. Best Practice
At most companies, MID Servers are split according to SN Environment. Here at my Company, we have 4 main environments (DEV, TEST, UAT and PROD) each of which have their own set of MID Servers. These MID Servers are also sometimes cross connected. Overall, each SN Environment has 40 to 50 MID Servers attached. This number is probably too many, however I heard from SN Support that this number of MID Server is not unusual; some company have hundreds of MID Servers. So managing MID Servers is probably a challenge for all SN Customers. Additionally, MID Servers are split up according to three types of usage (or Application) such as (a) Discovery; (b) Event Management; and (c) Integrations such as the TechStore (SCCM) or IIQ.
It is important that each Workflow and Activity uses the correct MID Server, otherwise the Workflow may fail. For example: many Workflows use Powershell and many of the MID Servers may be mistakenly configured with the Powershell Capability - however the server may not be configured properly for Powershell; a common error is that Set-ExecutionPolicy is set to restricted meaning that the Powershell script may fail to run. Also, some protocols such as JDBC require that the MID Server Service is configured to logon with a Service Account with JDBC Access to the Target Server. There are two options to solve these type of issues:
- Option1: Central Management. Have one central team manage MID Server Capabilities and ensure that if a MID Server is assigned a capability - and the MID Server can truly service that capability.
- Option2: Distributed Management. Allow each team to continue to manage their own MID Servers and allow them to create custom capabilities as required. See below.
Here at my Company, our Global team are not currently performing central manage of all MID Servers - but are allowing countries such as NZ to perform Distributed Management. Option 2 is probably the only realistic option for larger companies.
Currently, best practice for my Company has evolved into the following:
- Allow distributed management of MID Servers by separate teams in each country.
- Use Custom Capabilities (see the pdf attached).
- Prevent the use of the All Capability (see the pdf attached).
FOR FURTHER DETAILS, PLEASE SEE THE ATTACHED PDF.
- 1,610 Views