SCCD 7.5 install failing with error CTGIN0005E

Problem(Abstract)

Installing Smart Cloud Control Desk 7.5 fails with the error CTGIN0005E The deployment of D:\IBM\SMP\pmp\DIS_CMS_Tpae_Config_7.5.0.0.zip failed. The error text is CTGIN0143E: An

action error ocurred during the processing of a deployment operation. Action identifier: "Patch_webXML".

Symptom

The deployment of D:\IBM\SMP\pmp\DIS_CMS_Tpae_Config_7.5.0.0.zip failed. The error text is CTGIN0143E: An
action error ocurred during the processing of a deployment operation. Action identifier: "Patch_webXML".
This will be shown in the solutioninstaller logs as:
IBM\SMP\ant\bin\ant' is not recognized as an internal or external command,
operable program or batch file.

Cause

This is caused by the installer not being able to call the ant.bat file due to the PATHEXT system variable not being set correctly.

Diagnosing the problem

In command prompt run the command:
set PATHEXT
This will display what your path extension system variable is currently set to. If it is missing .bat and .cmd you will need to add them.

Resolving the problem

In Windows navigate to your Environment variables.
In Windows Server 2008, Right-click Computer and go to properties. Then Advanced System Settings. Then Environment variables.
Pre-Windows Server 2008, Right-click
In this menu you can see your system variables. Under system variables find PATHEXT. Edit this and add .BAT;.CMD with each new entry being separated by a semi-colon. Ensure that .BAT is before .CMD in the list from left to right.

After adding this to your Path Extention variable, you can re-run taskrunner CONTINUE STOPONERROR.

Forgot password and cannot access WebSphere Application Server administrative console

Problem(Abstract)

Forgot the password and cannot access WebSphere Application Server administrative console.

Cause

After enabling WebSphere Application Server with security, the administrator forgot the user id and password and could no longer access the server.

Resolving the problem

WARNING: Please use this as the last resort and make sure the server is not in the middle of processing any transactions.

There are 2 possible methods for disabling security:

By way of wsadmin command:

1. /bin/> wsadmin -conntype NONE
2. wsadmin> securityoff
3. wsadmin> exit
4. Restart the servers.
5. Enable the security from administrative console.
6. Restart the servers.

By way of manual edit of security.xml file, which is typically located in /config/cells /:

1. Create a copy for security.xml file, in case you need to roll back.
2. Disable the security from the security.xml file (change the very first occurrence of... enabled="true" to enabled="false")
3. Restart the servers.
4. Enable the security from administrative console.
5. Restart the servers.

For additional information regarding enabling administrative security, please refer to this link:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tsec_csec2.html

Backing up and restoring the Deployment Engine database

Question

How do I backup and restore the deployment engine found on my product's middleware servers and administrative system?

Answer

These instructions are for manually backing up and restoring the Deployment Engine
database to the state it was before installing middleware on middleware servers or
process managers on the administrative workstation.
In past releases, the deployment engine was automatically backed up during installation. This is no longer the case. In the latest releases of ISM products, deployment engine backups and restoration are the responsibility of the user.
You should back up the Deployment Engine database of the system before and
after applying any updates to an existing deployment. Having backups allows you
to recover from partial installation attempts where middleware or process manager
components were partially installed.
This procedure is not dependant on the state of the application server. The application server can either in a started or stopped state.
To backup the Deployment Engine database, complete the following steps:
1. Set up the environment using the following command:
Windows c:\Program Files\IBM\Common\acsi\setenv.cmd
UNIX cd /var/ibm/common/acsi ./setenv.sh
2. Run the command to backup the Deployment Engine registry:
Windows c:\Program Files\IBM\Common\acsi\bin\backupdb.cmd

UNIX cd /usr/ibm/common/acsi/bin ./backupdb.sh

Use a meaningful name for to reflect the fact that it contains the state of the registry after your installation of the product. For example, DEBackupAfterJune12Install.
If you have a backup of the Deployment Engine database, you can use the
following command to restore it:
Windows
c:\Program Files\IBM\Common\acsi\bin\restoredb

UNIX
cd /usr/ibm/common/acsi/bin
./restoredb.sh

where is the file containing the Deployment Engine backup
you made.

SmartCloud Control Desk version 7.5 Upgrade Guide.

https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=e25892f0-20f7-46ff-bbe9-c7c03fb3036f#fullpageWidgetId=Wb33da0c91d92_4cec_a8a7_57df877f617b&file=9ff971b9-237a-4713-a944-c1e322efff78

Upgrade Service Request Manager 7.1 to 7.2.1

http://pic.dhe.ibm.com/infocenter/tivihelp/v32r1/index.jsp?topic=%2Fcom.ibm.srm.doc_721%2Fupgrade%2Fc_upgrade_71to7201.html

Why Service Level Agreements (SLAs) are not being applied

when you configure SLAs with commitments and try to apply them, only to get the message: "BMXAQ0090E - No service level agreement was found." This message might be displayed for one of the following reasons:

 

 

1. The SLA status is DRAFT or not ACTIVE.
2. The dates that have been entered are not valid, for example, they may be in the past.
3. The SLA has different conditions to the work order or ticket.
4. The SLA has a different location to the work order, ticket, or asset and configuration items.
5. The SLA organization and site does not match with the work order or ticket organization and site.
6. The SLA has different shifts than the work order or ticket.
7. The date specified in the SLA is a non-working day.

Configuring Service Level Agreements (SLAs)

The setup of your calendars and shifts plays an important part in calculating the target dates for SLA.

Now that you know how to apply it  let's see if the dates are being calculated correctly.

Let's create a calendar first.

1. In the Calendar application, create a calendar.
   
2. In the Calendar field, enter 2013.
   
3. From the Select Action menu, select Define/Apply Shifts.
   
4. In the Define/Apply Shifts window, click New Row.
   
5. Enter the name WORK for the shift name.
   
6. Specify that the shift lasts from Monday to Friday, 08:00 to 17:00. There are 8 hours in the work shift and a one hour lunch break.
   

 

 

Now, create the SLA:

 

1. From the Service Level Agreement application, click New SLA.
2. In the SLA field, specify SLA_SR.
3. In the Applies To field, specify Service Requests.
4. Create commitments for the service level agreement
   1. In the Commitments table window, click New Row.
   2. In the Type field enter  RESPONSE
   3. In the Value field, enter 4. This is the target start time.
   4. In the Unit of Measure field, enter HOURS.
5. Create another commitment.
   1. In the Commitments table window, click New Row.
   2. In the Type field enter  RESOLUTION
   3. In the Value field, enter 32 hours. This is the target finish time.
   4. In the Unit of Measure field, enter HOURS.

 

 

 

Notice that if the SR has an associated asset, we want to use the asset's calendar to calculate the dates and not the SLA default calculation calendar (this options is only enabled by IBM Maximo for Service Providers).

 

Now, let's see how it works on a service request. The details of the service request are as follows:

• Asset: ASSET_TEST (uses DAY calendar, with a 07:00~15:00 shift, 8 work-hours, Mon~Fri)
• Reported Date: 25/Oct/13 12:30 (Friday)

 

In the service request, we select the Apply SLA action, and the following message is shown:

 

We want the SLA to use the asset's calendar to calculate the target dates as first option.

RESPONSE = Reported Date + 4 hours. Using the asset's calendar (shifts end at 15:00), we have only 2:30 hours left for the day. So, we should carry 1:30 to the next working day. The result: Target start date = 28/Oct/13 08:30 (Monday).

RESOLUTION = Reported Date + 32 hours. Again using the asset's calendar (8-hour shift), we have to add 4 working days to the reported day.  The result:  Target finish date = 31/Oct/13 12:30 (Thursday).

 

 

So far, so good.

 

Now let's try a service request, without an asset.

 

SR:

• Reported Date: 25/Oct/13 12:30 (Friday)

 

As the SR doesn't have an asset, the SLA should use the default calculation calendar to calculate the dates (WORK calendar).

 

So we have:

• Target start date = 25/Oct/13 16:30
• Target finish date = 31/Oct/13 08:30

 

 

Note that the target finish date isn't 31/Oct/13 12:30, but 31/Oct/13 08:30.

 

That's because the shift is from 08:00 to 17:00, having a total of 9 hours. Even though the shift is set as 8 working hours, we have no information about this 1 hour break. So the SLA considers just the start/end time of the shift to make the date calculation. Any value added to work hours won't be considered by SLA calculations.

 

For holidays, you should use the Apply non-working days action on the calendar. It won't work if you just use 0 (zero) work hours for that particular day (same for weekends).