Run an .exe file from an Escalation in Maximo

An escalation may be set up in order to run an executable file at a specified interval of time.
The steps are:
1. Log in into Maximo as maxadmin user.
2. Go to -> System Configuration -> Platform Configuration -> Escalations
Create a new escalation with the following information:
Escalation: autonumber; description: any;
Applies To: ACTIONGROUP
Schedule: 1m – just for the test case, otherwise the needed interval;
Check “Create Successful Execution Entry” check box.
3. On the Escalation Points tab, click New Row;
Make sure to set
-Applies To – ACTIONGROUP
-Elapsed Time Interval to a value of -1 DAY (a negative value will indicate a time period in the future)
-Repeat check box checked.
4. On the Action tab, click New Row;
5. Action -> Go to Actions application
6. On Action application, create new Action, with the following information:
Action: autonumber ; description: ;
Object: ACTION
Type: Command Line Executable
Value: C:WINDOWSSystem32notepad.exe (or any .exe file you want to be launched)
Accessible From: ALL
This new Action will automatically be assigned to an Action Group, which is visible on the escalation tab under the Actions section (upper right corner), and it’s also present in the Actions application. It is essential in order for the executable to be run only once that the Action running the .exe file is only present once as Member in the ACTIONGROUP table.
7. Save Action;
8. “Return With Value” to Escalation application
9. Save Escalation
10. Select Action -> Validate; (should display a pop-up with “Validation successful.”)
11. Select Action -> Activate/Deactivate Escalation (should set the escalation to Active)
12. Save.
13. Log out/ Log back in.
Wait for 1 or 5 minutes, depending on time scheduled on the escalation.
The executable should be launched.

BMXAA6815E - The database connection failed running encryptproperties.bat

Problem(Abstract)

After trying to run encryptproperties.bat, the process completed with the following error message:
BMXAA6815E - The database connection failed: [xxx] Cannot open database "" 
requested by the login. The login failed.

Resolving the problem

Please, check the following information in your environment: 

1) Check to see if you are able to connect to the database using the SQL Studio Management tool using the same user and password 

2) Check to see if the procedure reported in the Technote 1314942 was run properly 
http://www-01.ibm.com/support/docview.wss?uid=swg21314942

SQL1768N Unable to start HADR

Problem(Abstract)

"SQL1768N Unable to start HADR, Reason Code = 7" occurs while initializing high availability disaster recovery (HADR).

Symptom

This is a generic error message which occurs when the primary database fails to establish a connection to its standby database within the HADR timeout interval.

Cause

There are a number of reasons you may see this error message. Most commonly it is due to:

A.     Network issues

B.     Standby database is not active

C.    Both the servers are not on the same db2level

D.    Due to firewall settings

E.     Mapping to the wrong instance name

F.     HADR_TIMEOUT database configuration value set to a very low value

Resolving the problem

A.     Verify the /etc/hosts and /etc/services configuration to ensure that both machines can ping each other.

Ping
 

B.     Ensure to start the HADR on the standby server as "standby". db2pd command can be used to check whether the database is active or not.

db2pd -db -hadr

Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:07:07 -- Date 01/20/2011 11:42:03

If the db2pd output shows that the database is not active, then run "start HADR" command on the standby server.

db2 start hadr on database as standby 
 

C.    Ensure both the servers are on the same db2level so that a mismatch situation does not occur. Run "db2level" command on both the servers to check whether they are on the same DB2 Version and Fix Pack.
 

D.    Ensure that the firewall is set to allow the connection.
 

E.     If the HADR_REMOTE_INST database configuration is incorrectly set, then SQL1768N with RC-7 is expected along with the ADM12504E error. The following message is reported in the db2diag.log of the primary server:

2011-01-20-17.14.12.771000-300        LEVEL: Error
PID     : 3448           TID  : 4488  PROC : db2syscs.exe
INSTANCE: DB2            NODE : 000
EDUID   : 4488           EDUNAME: db2hadrp (SAMPLE) 0
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrVerifySystem, probe:15570
MESSAGE : ADM12504E  Unable to establish HADR primary-standby connection because the value of HADR_REMOTE_INST at one of the instances does not match the actual instance name of the other instance. This is a sanity check to ensure that only the intended database pairing occurs. If any of the HADR_REMOTE_INST configuration parameters or instance names is set incorrectly, you may correct it and try again to start HADR.

To update the correct instance name in both the servers, use the following command:

db2 update db cfg for using HADR_REMOTE_INST
 

F.     Set the HADR_TIMEOUT database configuration to a minimum of 120 seconds(default value).

Note: All HADR db cfg parameters can be changed without an instance stop/start. They do, however, require a database deactivate/activate (if already active).

IBM Maximo -- Useful Links

IBM Documentation

• IBM Maximo Asset Management Information Centers wiki lists all the links to Maximo official manual for each version.
• Product Configuration Matrix for Maximo is an Excel spreadsheet documenting all the supported OS, middleware, system requirements, etc.
• IBM Maximo Redbooks are a very good source of information.

IBM Resources

• Fixes by versions for Maximo and TAMIT
• Support Technical Exchanges (STEs): Great education resources from IBM experts.
• Tivoli RSS feeds: Stay updated about new product fixes/fixpacks and IBM TechNotes.
• IBM Education Assistant: Narrated presentations, tutorials and resource links to on Maximimo.

Unofficial Maximo information sources

• IBM developerWorks Maximo and process automation solutions: Active forum hosted by IBM to ask for help.
• Maximo Knowledge Base (not active)
• Maximo Times (registration fee required for some articles)
• Maximo Yahoo! Group (not public)

Public Demo sites

• Maximo 7
• IBM SmartCloud Control Desk

Troubleshooting Forgotten Password and User Self Registration Problems in Maximo

Problem

From the main login page, if a user clicks the "Forgot Password" or "Register Now" hyperlink, the error BMXAA4038E "Cannot log in to perform this action" may be displayed.

Symptom

BMXAA4038E "Cannot log in to perform this action" when selecting "Forgot Password" or "Register Now", or other errors upon completing the Forgot Password or Self Registration screens.

Resolving the problem

The system property mxe.system.reguser is used internally to connect to the system for the Forgotten Password and User Self Registration applications. The value of this property should correlate with a user record on the database (maxuser.loginid) which has permissions for the FORGOTPSWD and SELFREG applications.

In the 6.x release, properties are stored in the maximo.properties file. In later releases, properties are stored on the maxpropvalue table (or overridden in maximo.properties) and can be seen in the System Properties application. If you change any properties via the System Properties application, make sure that you check the box next to the property and use the Live Refresh menu option to make the changes take effect.

Follow the list below to identify the cause of the "Cannot log in to perform this action" problem.

1) Find the value for the mxe.system.reguser property and ensure that a user exists having a loginid equal to this value.

2) Find the value for the mxe.system.regpassword property and ensure that the user found above has a password equal to this value. If you are not sure, you can reset the user's password and/or the property. (Users and passwords are managed via the Users application.)

3) Ensure that the mxe.system.reguser property is in the proper case. If it is in the proper case, find the value of the mxe.convertloginid property. When this property equals 1, the entered value of loginid is internally converted to upper case prior to authentication. If this property is 1 and the value of maxuser.loginid is not upper case, the user will not be able to log in.

4) Ensure that the user belongs to a security group that has permissions for the Forgotten Password and User Self Registration applications. (Use the Profile tab in the Users application.) Out of the box, the reguser belongs to the MAXREG security group, which has these permissions. If your reguser does not have these permissions then either add the user to the MAXREG group or configure the MAXREG group to have permission for these applications. (Group permissions are maintained via the Security Groups application.)

5) If the system is in Admin Mode, then Forgotten Password and User Self Registration are not permitted (by default). A superuser can access the Database Configuration application, Admin Mode option to see whether Admin Mode is on. Alternatively, you can perform a sql query "select value from maxvars where varname = 'ADMINRESTART'". If the value is ON then Admin Mode is on or in the process of being turned on.

If your end user is able to access the Forgotten Password or User Self Registration applications, but encounters errors when completing the transaction whose cause is not self-evident, then follow the steps below.

6) Ensure that email has been set up properly. The mail server is identified by the property mail.smtp.host. Later versions of 7.x support authentication to the email server. If your email server requires authentication, ensure that the properties mxe.smtp.user and mxe.smtp.password are correct.

7) If the problem is with Self Registration, ensure that the workflow process is configured. The maxvar SELFREGWF identifies the name of the workflow process (select varvalue from maxvars where varname = 'SELFREGWF'). The default value is SELFREG. Find this value in the Workflow Designer application and ensure that this is active and enabled. If you have Communication Templates associated with this workflow, ensure that Send From is a valid email address and that the Communication Template is active.

8) To complete the workflow process, the administrative user should log in and look at the Workflow inbox. There should be entries labeled "Review and approve/reject the self-registered user." Click Route on the notification inbox and approve or reject the self-registration. If the registration is accepted, then assign the new user to the appropriate security groups.

9) The approved new user should receive an email with notice of the registration approval. By default, the first time the user logs in, there will be a prompt to change the password.