Does service-now have a maintenance mode?

[michaelgrice]

Does anyone know if SNC has a maintenance mode? Basically we want a way to stop users from logging in during a big update or upgrade for a certain period of time. Is there a specific or best-practice way that this can be done?

Thanks.

[Mark Stanger]

No, but you can customize the login installation exit to only allow login to certain roles.

http://www.servicenowguru.com/system-definition/custom-login-validation-installation-exits/

[geoffcox]

I developed some scripts for managing a "maintenance window", during which most users are locked out. It involved adding the following true/false fields to the sys_user object: "Special Tester" (u_special_tester) and "Restore User" (u_restore_user).

The lockout script goes through all active users except those with "Special Tester" set to true, and locks them out while also setting the "Restore User" flag. It also replaces the "User name or password invalid" string with the message "Service-Now is currently locked down for maintenance, and logins are disabled".

The restore script goes through all users with the "Restore User" flag set, and removes the lockout. It then restores the normal invalid login message.

This is all controlled from a form on a new maintenance window table that has only one record. This record includes two checkbox controls: "Lock Out Users" (u_lockout_users) and "Restore Users" (u_restore_users). These could have been UI actions, but for various other reasons I have kept them as true/false checkboxes. It also has one additional true/false field: "In Lockout"

Here is the business rule that runs on the maintenance window table:

doMaintWindow();

function doMaintWindow() {
   if (current.u_restore_users) {
      if (current.u_in_lockout) {
         do_restore_locked_out_accounts();
         current.u_in_lockout = false;
         gs.addInfoMessage('Users restored.');
         var message = new GlideRecord('sys_ui_message');
         message.addQuery('key','login_invalid');
         message.query();
         while (message.next()) {
            message.message = "User name or password invalid.";
            message.update();
         }
      }
      current.u_lock_out_users = false;
      current.u_restore_users = false;
      return;
   }
   if (current.u_lock_out_users) {
      if (!current.u_in_lockout) {
         do_lock_out_non_admin_accounts();
         current.u_in_lockout = true;
         gs.addInfoMessage('Users locked out.');
         var message = new GlideRecord('sys_ui_message');
         message.addQuery('key','login_invalid');
         message.query();
         while (message.next()) {
            message.message = "<h2>Service-Now is currently locked down for maintenance, and logins are disabled.</h2>"
            message.update();
         }
      }
      current.u_lock_out_users = false;
      return;
   }
}

function do_restore_locked_out_accounts() {
   gs.log('LOCK: Starting do_restore_locked_out_accounts');
   var user = new GlideRecord('sys_user');
   user.addQuery('u_special_tester',false);
   user.query();
   while (user.next()) {
      if (user.u_restore_user) {
         gs.log('LOCK: Restoring ' + user.name);
         user.locked_out = false;
      }
      user.update();
   }
   gs.log('LOCK: Ending do_restore_locked_out_accounts');
}

function do_lock_out_non_admin_accounts() {
   gs.log('LOCK: Starting do_lock_out_non_admin_accounts');
   var user = new GlideRecord('sys_user');
   user.addQuery('u_special_tester',false);
   user.query();
   while (user.next()) {
      if (user.locked_out) {
         gs.log('LOCK: ' + user.name + ' already locked out. Will not restore.');
         user.u_restore_user = false;
      }
      else {
         gs.log('LOCK: Locking out ' + user.name);
         user.locked_out = true;
         user.u_restore_user = true;
      }
      user.update();
   }
   gs.log('LOCK: Ending do_lock_out_non_admin_accounts');
}

[geek1]

This is definitely a creative solution for this problem and it WOULD work, however I'd have to go with Mark's response as it completely simplifies this process and doesn't require changing the value of fields whenever you need a maintenance window (there's also far less chance for error when writing to the table).

Both solutions would definitely work though.

[geoffcox]

I agree, the role based solution is probably more robust, although one error in the login script and you could find yourself locked out!

I confess that when I wrote the script I wasn't familiar with the login script stuff. I did it in February of 2010, I see this role-based solution was published in October. 🙂

My solution is a small part of a bigger script that also manages a maintenance window banner that appears in place of the normal banner message, is posted a day in advance, and includes a countdown to when the maintenance window begins. During the maintenance, the banner includes a countdown to when the maintenance is scheduled to end.