Advanced ServiceNow Configuration - Maintenance Mode

Automatically Scheduling a Maintenance Mode from a Change Request

With the introduction of the Inbound Maintenance feature comes the opportunity to fully automate certain aspects of the maintenance mode workflow. Change requests are a good example of a workflow that can be automated in your ServiceNow environment as they will normally have the requester, the configuration item, a short description, and a schedule that can all be used to build up a maintenance schedule. By default, the ‘Cookdown Maintenance Mode Add-on’ does not ship with any logic to automatically create Maintenance mode entries from Change Requests as each organization will have its own checks, balances, and processes around change control that we would not wish to interrupt. However, you can find a guide below on how you might approach this in practice.

Please only attempt this if you know what you are doing. You may accidentally prevent access to change requests, modify the UI, or interrupt other automation for the whole company, and more. Proceed with caution.

Via Business Rule

Business Rules are server-side scripts that can be executed whenever records/tables are created, modified, etc. They are typically a fast method of introducing automation being very quick and efficient in their execution, but, they are also incredibly flexible utilizing Javascript to implement almost any required behavior you can imagine.

Prerequisites

To begin with, you will need to set up a cross-scope privilege to allow your script to work between the change and maintenance tables.

  1. From the 'Settings' cog, select Developer, and then set the application to be Cookdown SCOM Connector Maintenance Mode Add-on'

  2. Search for and select 'Application Cross-Scope Access' from the ServiceNow menu

  3. From the Cross scope privileges table select 'New'

    1. Set the Target Scope to 'Global'

    2. Set the Target Name to 'GlideRecord.insert' (note this is case sensitive)

    3. Set the Target Type to 'Scriptable'

    4. Set the Operation to 'Execute API'

    5. Set the Status to 'Allowed'

  4. Verify that all of the settings are correct and then press Submit

Modifying the Change UI

If you wish to make this an optional component or add some checks and balances to the process you may wish to implement a simple control onto the Change UI. This is a very simple example, you can of course marry up any logic to your internal processes.

  1. Select any open change from the change table

  2. From the hamburger menu (☰) select ‘Configure' followed by 'Form Design’

  3. In the first two-column menu add a new ‘True/False' field type by dragging this from the 'Field Types’ menu

  4. Select the 'Edit' cog on the field

    1. Change the Label to ‘SCOM Maintenance Mode’

    2. Change the Name to u_scom_maintenance_mode

  5. When happy save the changes to the form

(Optionally) Define When the Control Is Shown

You may have scenarios where you do or do not want this UI control shown. In this case, you would likely want to implement a ‘UI Policy' or a ‘Client Script’ to show the control when appropriate. A 'UI Policy’ is the easier of the two to implement, however, this does provide fewer customization options.

  1. From the Servicenow menu search for 'UI Policies'

  2. From the ‘UI Policies’ table select 'New'

    1. Set the Table to 'Change Request'

    2. Set the Short Description to something appropriate like 'Show SCOM Maintenance mode on CI'

    3. Set the Order as appropriate (the default is 100)

    4. From ‘When to Apply' select 'Add Filter Condition’

    5. Set the filter to [Configuration Item][is not empty]

  3. When you are happy submit the UI policy

  4. Re-open the UI policy you have just created

  5. Under ‘UI Policy Actions' select 'New’

    1. Set the ‘Field name’ to 'SCOM Maintenance Mode' (or whatever you labeled it)

    2. Set 'Visible' to True

    3. Set 'Read only' to False

  6. When you are happy, submit the form

Showing a client script is outside the scope of this article as the logic and configuration would be specific to individual organizations. However, you might want to consider showing the field only when a valid configuration item is selected. For example ‘Maintenance Mode’ requires the CI to be a server CI with an FQDN present so checking for these conditions would be worthwhile. Similarly, you may wish to only allow this to be applied to certain pre-approved CIs in your organization so you could have your script check if the CI is a member of a certain group before showing the control. You can find ServiceNows documentation on Client Scripts here.

Implementing the Business Rule

Once you have the pre-requisites in place you should be in a position to implement your Business Rule.

  1. Search for and select 'Business Rules' from the ServiceNow menu

  2. From the Business Rules table select 'New'

    1. Set the ‘Name’ as appropriate (e.g. 'Create Maintenance from Changes')

    2. Set the ‘Table’ to ‘Change Request’

    3. Select the 'Advanced' option

  3. From 'When to run'

    1. Select 'Insert'

    2. From 'Filter Conditions' set [SCOM Maintenance Mode] [Is] [true]

  4. From 'Advanced' enter your script

    1. See our example below for inspiration

  5. When you are happy with your Business Rule submit the record.

Example Business Rule Script

(function executeRule(current, previous /*null when async*/) {

	var maintRecord = new GlideRecord('x_oklt_cookdown_mm_maintenance_mode_entries');
	maintRecord.initialize();
	maintRecord.comment = "Created from " + current.number + " (" + current.short_description + ")";
	maintRecord.computers = current.cmdb_ci;
	maintRecord.related_task = current.getUniqueValue();
	maintRecord.start_on = current.start_date;
	maintRecord.end_on = current.end_date;
	maintRecord.requested_by = current.requested_by;
	if(current.getValue('type') == "normal")
		{
			maintRecord.planned = true;
		}
	
	maintRecord.insert();
})(current, previous);

Back to top

(Video) Schedule SCOM Maintenance Mode from ServiceNow

Search