There are multiple procedures for this, and it depends on the kinds of user, and the privileges they should have.
NetID-based Yale affiliate users
The vast majority of ServiceNow users are Yale affiliates with netid-based login credentials. The settings for these kind of users come from multiple data imports. The main user information import is IST-User, which gets netid and related user fields. There are also two LDAP (Active Directory) imports that come from Yale Central Auth. The Yale-User LDAP import includes phone number information and related fields. The Yale-Group LDAP import contains mappings between netids and ServiceNow Assignment Groups (and Groups that serve no purpose except to assign roles).
These users almost never require maintenance, except when something goes wrong with the IST-User import. Find out more about that at: User import issues in ServiceNow
Fake user accounts to handle inbound email
We made a decision in late-2012 or early-2013 to allow inbound email from non-Yale people. We ended up handling this by allowing inbound mail to create new fake user accounts. The netid field is set to the email address from which ServiceNow received the email address.
These are the second most-common kind of accounts.
These accounts follow patterns like:
One nice feature is we can control inbound spam from specific users by then toggling their user account to non-Active.
Local Service accounts
There are a small handful of user accounts in ServiceNow for various integrations with external systems or services.
These account names correspond to the naming convention: s_
Some examples include:
s_unixsys, used by Unix Systems with scripts that post Incidents into ServiceNow using the API
s_windows, used by Windows group with scripts that post Incidents into ServiceNow using the API
s_sn_drupal, used by web group to integrate between ServiceNow and Yale ITS website
s_nagios, used by Operations to poll certain ServiceNow production services automatically and dynamically contact Production Support team of anomalies
s_update_source, used by ServiceNow for passing update sets between DEV and other SN instances
These accounts almost never require maintenance. Various accounts require certain rights; the most tricky one is the SOAP role (and associated roles with the name soap in them) if the account requires access to the API.
Local named non-admin user accounts
There are a small number of non-admin user accounts in ServiceNow for various purposes.
These have the naming pattern *-actor.
These were created in 2014 at the request of the new Business Analysts. These accounts generally have the impersonator role, which grants these users the privilege of emulating other users.
Because these accounts have high levels of privilege, we manage them with entries in the post-clone script. Post-Clone Procedure
Local admin user accounts
There are a small number of accounts with admin privileges.
Accounts for our vendor Fruition are named with the pattern firstname.lastname
An example is:
allen.doering
Accounts for internal Yale employees are named with the pattern netid-admin
An example is:
ml34-admin
These accounts are most easily found by going to the admin role, and then looking for accounts associated with the role.
Notice that many admin accounts are non-Active in most environments. We retain these accounts as non-active in certain environments because cloning down will change the properties of local accounts, including their credentials. If we didn't have the accounts in the higher environments, we would need to recreate the users manually each time after we did a clone, and that would be a waste of time for everybody involved.
Maintaining the post-clone
The post-clone is stored at: Post-Clone Procedure
It must be hand-edited. Anybody who is granted admin rights in PROD should have the requisite skills to edit this directly.
It then must be hand-deployed out to the instances. CHANGES TO THIS SCRIPT ARE NOT CAPTURED BY UPDATE SETS.
We literally need to copy and paste the changes to each instance.
The script is stored at: System Definition > Scheduled Jobs > Post-Clone Script
So after the hand edit, and the save on the wiki, copy and paste the changes out to DEV, TST, PRE, TRN, PRD.
If you hit Execute Now, it will run now, and you can confirm any changes that could be tested at that time.
If you actually want to see output, you must run it from Scripts - Background
Any code errors you introduce will show up as errors on the Background script console.
Obviously, this will only capture logic code errors, and not failures of writing the script properly to do what you meant it to do.
Creating a new account, and cloning it around
Different people have different opinions about how to do this. None is correct absolutely, so here's an algorithm.