Steps for After an HP Service Manager QA Environment Refresh

Posted by Travis DePuy  I  April 22, 13

Refreshing the HP Service Manager QA or Dev environment from the Production environment is a very important part of keeping a healthy and well-functioning HP SM ecosystem. However, after copying the production database to the QA or Dev database, there are a handful of steps that need to be performed to reduce confusion for end users and erroneous notifications while testing and developing updates.

Techport Thirteen provides HP Service Manager services

The following is a list of steps collated from Techport Thirteen's various HP Service Manager client environments. Some may need to be altered or omitted and there might need to be others added, depending on the individual environment. But, this is a very good start.

  • Deal with accidentally sending emails:
    1. The easy, nuclear option, is to just never start the SCAuto or Connect-It processes. This is not a recommended solution as testing notifications becomes difficult because just turning on the service can send out hundreds of emails to end users about old tickets. It is recommended to purge the eventout table before turning on these services.
    2. Alternatively, this can be done by mass updating the operator email addresses to one email. All notifications would then go to that email.
    3. Add a "Trap Eventout" trigger record to change the email address to a whitelist. See the JS_trapEventout.txt code below for details on how to do this. Any event out records generated with an email address not in the whitelist will be updated to not be sent.

// Code to trap emails in a live fire connect-it scenario

var good = new Array();
good.push( "" );
good.push( "");

if( record.evtype == "email" ) {
fields = record.evfields.split( "^" );

goodStr = ("" + good).toLowerCase();
if( goodStr.indexOf( (fields[0]).toLowerCase() ) == -1 )
record.evtype = "emailDISABLED";


  • Update the Web Server URLs: The Web Server and ESS urls are stored in the Company Wide Information record (comp in the command line) and will have the Production URL instead of the QA or Dev url. This needs to be manually updated to reflect the correct address. These values are stored as $G values, so it is critical to make sure the background processes pick up the new value by restarting the whole system or individually restarting each background process.
  • Unlock the database: Service Manager adds a record to the infom1 table indicating a particular system is using this database. This prevents other systems from taking the database away and doing unexpected things. So, after the copy, run this command to release the database so that the QA/dev system can make its own lock:
      • SMHome\RUN\sm -unlockdatabase
  • Grant consultant-types (hopefully from Techport Thirteen) admin access: This might seem to be trivial, but it is always frustrating to have a fresh new system and only have ESS access when I am expected to do development work. This can cause delays in getting development started or moving.
  • If Knowledge Management is installed in the environment, the Help Server information will need to be updated. I believe this is in the KM environment record.
  • If Request Management is enabled and the Dev system is keeping track of the model record unique numbers (this ensures that model records in all environments have the same unique number, so that updates can be done with an unload), then the number record will need to be re-enabled depending on if the environment is Dev or QA.

There may be other steps, but it is very important that the steps above are followed each time a refresh occurs.

Have something else to add to this list? Please post a comment below so that we can all learn for each other's experience :-)

Tags:  HP Service Manager