Inactivity timer throws negative minutes in message

When the inactivity timer sends a message, the onscreen message is ok but the popup message looks like:

Your inactive HP Service Manager session (UID# 5) will be automatically disconnected in -2132464512 minute(s) 270643684 second(s)

One scmessage record seems to be wrong in the database. This could be caused by migration from earlier SM versions.

Wrong scmessage record :


Message number=130

Text: Your inactive HP Service Manager session (UID# %ld) will be automatically disconnected in %d minute(s) %d second(s)

To fix this issue overwrite the Text in scmessage record

Your inactive HP Service Manager session (UID# %ld) will be automatically disconnected in %d minute(s) %d second(s)
Your inactive session will terminate in %ld minutes,do you want to extend your session time?

How to modify the scmessage record:

1. Command db

2. Table: scmessage

3. Search

4. Search for this scmessage record with class “scbase” and message number “130”.

5. Correct the Text

6. Save the record

How exactly does “Build List on Startup” (field build.startup) option work for globallists

Current Helpserver:

Once you have created a global list with the Build List on Startup option selected, Service Manager automatically rebuilds the global list when users log in.


This is not completely true.

For globallists with “filename” and “limiting SQL” the background process “lister” must run and update the globallist if something has changed.

This kind of global list is not “_automatically rebuild when users log in_”. lister process is neccessary.

The “Build List on Startup” flag does not initiate a “Rebuild” of the list, it just makes the current list available to a new logged in user.

A globallist is new build on either one of these actions:

– press “Rebuild Global list” (current and new sessions get the new list)

– lister process runs on this globallist (expiration is in the past and background process “lister” runs).

This is neccessary for globallists with “filename” and “limiting SQL”.

In SM941 there is an optimization called “lazy loading Global Lists”. In SM940 and before, all globallists (GL) were loaded by applications (APPs) which caused a long login delay.

Since SM941, GL will be loaded into memory by RunTimeEnvironment (RTE) only when it is needed, and for a newly added Global List, a restart of RTE is needed unless the name begins with “$”.

Reopen closed Incident from Interaction is now allowed

Service Desk Interactions with a Notify By value of Telephone will set to Callback status when the linked Incident is closed. However, the ability to reopen the Incident from within the Interactions Required Actions does not exist. Users are presented with a Closed Incident with no ability to reopen it.


The following steps will work around the problem.

1. Create a new RuleSet with the following:

Name: im.reopen

Available as Action: true

Name: Reopen Incident

Table name: probsummary

Rules: Call a Process "im.reopen"

2. Copy the Workflow "Incident" – along with the RuleSets – and give it a new name

Select the Phase "Closure" in the chart.

In tab "Action", add one action:

Id: Reopen

Action: Reopen Incident

Location: Tray

Action Condition: $G.ess="false" (select Variable $G.ess equal Value false)

3. Assign the new Workflow

4. The ability to reopen the closed Incident is present

Equivalent RAD command for the “PROCEED” button

When automating the SM deployment process via HPOO, while taking an unload, we need the equivalent RAD command for the "PROCEED" button.

1. Firstly create an unload script to query all backup code, for example, in OOB, there is unload script named "SQL Upgrade Utility"

2. Secondly create a folder to place the generated unload file, for example, C:\unload

3. Execute command, for example, in Windows, sm.exe -bg us.unload.automation NULL NULL "SQL Upgrade Utility" "C:\\unload\\SQL_Upgrade_Utility.unl" NULL

– For Linux, the folder could be for example /opt/unload, so the parameter in the command is "/opt/unload"

Format control calculation initialize Resolve time as NULL

There is an OOB calculation on format control IM.update.incident which initializes resolved.time, NULL on initialization of format.

Steps to reproduce:

1. Resolve an Incident

2. Save the Incident

3. Exit and again search the Incident

4. Resolve time is NULL

If user saves the record it make the resolve time NULL. in $file=NULL; in $file=NULL;resolved.time in $file=NULL; in $file=NULL;adj.resolution.time in $file=NULL


Go to trigger and set a trigger –>add.resolution.infomation

Table name–>probsummary

Tigger Type –>3 – Before Update

Application –>leave blank

if(record.problem_status==’Resolved’ && oldrecord.problem_status !=record.problem_status)





How the File Upload Servlet and Attachment Upload Servlet be de-activated in web.xml

The functionality for File Upload Servlet, as well as Attachment and Image Upload servlet does not match the table extensionstate, and it requires maintaining this list in addition to maintaining the extensionstate table.

The idea with the allowed extension is to provide additional protection using a so-called “white list”. From the web client, you can submit only attachments whose file types are in this whitelist.

The extensionstate on the other hand, is meant to manage the restrictions, so the “black list”. So actually the File, Image and Attachment Upload Servlet Parameters complement the protection of the table. At startup, the web tier and the Windows client retrieve the forbidden list, which is stored in the extensionstate table in the database; if no list is available, the clients use a default list of forbidden file types stored on the client side. With the new feature you can limit what can be submitted from web client, while you might allow other file types added from Windows client or web services, if they are not restricted in the extensionstate table.

The functionality cannot be disabled directly as there is no switch parameter provided. The fast way is to remove the whole xml label including “allowed” as follows

If this is done, the files with any file types not restricted in the extensionstate table will be allowed to upload, so disabling this functionality you take the risk.

Service Manager Web Tier: How to determine if the JAVA certificate is expired

How to check the JAVA certificate validation period for the Web Tier. A message about “Java Application Blocked” may appear on screen if the certificates are expired. The message may say “Application Blocked by Java Security”.


The certificate validation period can be checked using the following steps:

  1. Locate the SMWorkflow.jar file. For example, navigate to the <webtier webapps folder>\ext

cd <webtier webapps folder>\ext

  1. In a DOS command prompt, run command:

jarsigner -certs -verbose -verify SMWorkflow.jar > SMWorkflow.jar.certs.txt

“jarsigner” can be found in $JAVA_HOME\bin directory. the call could also look like:

“C:\Program Files\Java\jdk1.7.0_40\bin\jarsigner” -certs -verbose -verify SMWorkflow.jar > SMWorkflow.jar.certs.txt

NOTE: If the JRE is installed instead of the JDK, the “jarsigner” utility will likely not be available.

3.Open SMWorkflow.jar.certs.txt, check if there is [certificate is valid from xxx to xxx] or [certificate expired on 11/16/14 7:59 AM]

If the output indicates that the certificate is expired, it is necessary to locate and deploy a version of the Web Tier with a valid certificate to avoid the expired java certificate errors. If a version of the Web Tier with a valid certificate can’t be located on the HPE Software Support Site, please contact customer support for further assistance.

Only the first certificate duration is the one that is important to consider.

For example, it may look like this:

>>>>>> SMWorkflow.jar.certs.txt

s      16470 Tue Jun 28 18:04:10 CST 2016 META-INF/MANIFEST.MF

[entry was signed on 6/28/16 6:04 PM]

X.509, CN=Hewlett Packard Enterprise Company, OU=HP Cyber Security, O=Hewlett Packard Enterprise Company, STREET=3000 Hanover Street, L=Palo Alto, ST=CA, OID., C=US      [certificate is valid from 1/14/16 8:00 AM to 1/14/18 7:59 AM]

X.509, CN=COMODO RSA Code Signing CA, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB      [certificate is valid from 5/9/13 8:00 AM to 5/9/28 7:59 AM]

X.509, CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB      [certificate is valid from 5/30/00 6:48 PM to 5/30/20 6:48 PM]

X.509, CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE      [certificate is valid from 5/30/00 6:48 PM to 5/30/20 6:48 PM]