cloud & smarter infrastructure professional certification...

This information is IBM Copyrighted and may not be distributed without the approval of IBM.

Cloud & Smarter Infrastructure Professional Certification Program

Study Guide Series

Exam C2010-501 - IBM Maximo Asset Management V7.5 Infrastructure Implementation


Purpose of Exam Objectives ................................................................. 3

High-level Exam Objectives ................................................................... 4

Detailed Exam Objectives ...................................................................... 7

Section 1 - Planning ............................................................................................ 7

Section 2 - Installation ..................................................................................... 27

Section 3 - Configuration ................................................................................ 44

Section 4 - Performance Tuning and Problem Determination .............. 52

Next Steps ............................................................................................... 69


Purpose of Exam Objectives

When an exam is being developed, the Subject Matter Experts work together to define the role the certified individual will fill. They define all of the tasks and knowledge that an individual would need to have in order to successfully implement the product. This creates the foundation for the objectives and measurement criteria, which are the basis for the certification exam. The Tivoli Certification item writers use these objectives to develop the questions that they write and which will appear on the exam. It is recommended that you review these objectives. Do you know how to complete the task in the objective? Do you know why that task needs to be done? Do you know what will happen if you do it incorrectly? If you are not familiar with a task, then go through the objective and perform that task in your own environment. Read more information on the task. If there is an objective on a task there is about a 95% chance that you WILL see a question about it on the actual exam. After you have reviewed the objectives and completed your own research, then take the assessment exam. While the assessment exam will not tell you which question you answered incorrectly, it will tell you how you did by section. This will give you a good indication as to whether you are ready to take the actual exam or if you need to further review the materials. Note: This is the high-level list of objectives. As you review these objectives, click for a more detailed level of how to perform the task.


High-level Exam Objectives

Section 1 - Planning

1.1

Given a customers need to deploy IBM Maximo Asset Management (Maximo), evaluate the environment, user requirements, security considerations, language support and organizational processes so that an implementable, quantifiable, and scalable build plan for the installation of Maximo has been developed.

1.2 Given that a customer will have Maximo installed on a supported J2EE platform, explain the J2EE configuration concepts so that the customer understands how J2EE can be configured to meet their needs.

1.3 Given that a customer is planning for a Maximo Asset Management installation, explain JVM Performance and Optimization Settings and Concepts so that the tools to optimize the system have been explained.

1.4

Given that Maximo functionality is to be separated onto different JVMs for performance reasons, explain the JVM roles for Maximo so that an individual understands why roles should be separated onto different JVM and the benefits for doing so.

1.5 Given that Maximo is to be installed, define the installation system requirements so that the environment is ready for Maximo to be installed.

1.6 Given that Maximo security implementation decisions need to be made, explain the different options so that the correct planning decisions can be made.

1.7 Given that Maximo is to be installed, configure the security requirements needed to install Maximo so that pre-installation Security Configuration has been completed.

1.8

Given that Maximo is to be installed, review the Maximo search types with the customer and explain the impact that they can have on system performance so that search types and their implications have been reviewed with the customer.

1.9 Given a customers need to deploy Maximo, assess the proposed infrastructure so that the installation of Maximo can be implemented on the proposed infrastructure.

Section 2 - Installation

2.1 Given that IBM Maximo Asset Management (Maximo ) middleware has been defined and Maximo is to be installed explain the Maximo installation options so that the Maximo installation options are defined.

2.2 Given that Maximo is to be installed, explain the Maximo installation flow so that the Maximo, fix packs, add-ons and industry solutions installation flow is understood.

2.3 Given that Maximo is to be installed, explain the database script installation process so that process to update the Maximo database is understood.

2.4 Given that Maximo is to be installed, explain the different Maximo installation components so that the components and how they are used are understood.


2.5 Given that Maximo is to be installed, describe the use of the autonomic deployment engine so that the Maximo installation use of the deployment engine is understood.

2.6 Given that Maximo has been installed describe the use of the Maximo tools so that the Maximo tools usage is understood.

2.7 Given that an Maximo product is to be installed, perform the tasks to manually install Maximo so that Maximo is installed with the current fix pack.

2.8 Given that the middleware has been installed, validate core technology configurations so that users can connect to the installed Maximo system via the middleware.

2.9 Given that the Maximo product is in the process of installation or has been installed, describe the installation and tool log files so that the appropriate course of action can be taken.

2.10 Given that the Maximo product is installed, verify that the Maximo database has been installed correctly so that the Maximo system is ready to be configured.

2.11 Given that Maximo is to be upgraded, explain the Maximo upgrade process from 7.1 to 7.5 so that the customer understands the upgrade process.

2.12 Given that the IBM product is installed, verify which version of Maximo has been installed so that Maximo is installed to the targeted level.

Section 3 - Configuration

3.1 Given Maximo is already installed, enable Application Server Security within Maximo configuration and J2EE server so that users can connect to Maximo by using LDAP authentication.

3.2

Given Maximo is already installed and is ready to integrate with other systems, validate the Maximo Integration Framework (MIF) configuration is correct and functional so that Maximo can send and receive transactions to and from external systems.

3.3 Given Maximo is already installed,know, explain and utilize the maximo.properties file so that the Maximo system can be configured to use alternate middleware and database connection points.

3.4 Given that Maximo is already installed, manually build a Maximo EAR file and deploy it so that the Maximo application has been updated on J2EE server.

Section 4 - Performance Tuning and Problem Determination

4.1 Given that IBM Maximo Asset Management (Maximo) is installed,review and explain the Maximo performance log settings so that the Maximo system is running at optimal performance level.

4.2 Given that Maximo is installed, utilize basic database functionality to analyze installation/performance issues so that the database is normalized and tuned to top performance levels.

4.3 Given that the Maximo product is installed, determine if queries are efficient so that Maximo components queries are optimized.

4.4 Given that Maximo is installed, review the Start Center portlets so that users achieve a balance between system performance and key data accessibility.


4.5 Given that the application server instance requires performance analysis, assess the application server performance so that application server performance is analyzed and corrective actions can be taken.

4.6 Given that Thread Dumps and Heap Dumps are to be analyzed,perform the tasks to manually install Maximo so that the Heap Dumps are analyzed and Garbage Collection is tuned in the middleware.


Detailed Exam Objectives

Section 1 - Planning

1.1. Given a customers need to deploy IBM Maximo Asset Management (Maximo), evaluate the environment, user requirements, security considerations, language support and organizational processes so that an implementable, quantifiable, and scalable build plan for the installation of Maximo has been developed.

SUBTASK(S): 1.1.1. The type of environment that is being built:

Typically a Maximo environment will consist of a development, user acceptance test and Production system. When considering the topology to be built, or built upon, it is vital to understand the differences between these environments and to plan the installation accordingly. In each case Maximo requires the presence of an administrative system, a J2EE server, database server and optionally a directory server. How and where these components consume the resources that they require is dependent upon their expected utilization. 1.1.1.1. Determine the system build type(s) as a perquisite to the plan for

that environment. 1.1.1.2. Create an individual deployment plan for each environment to

cater for the differences in utilization. 1.1.1.3. It is important that a user acceptance testing (UAT) system

replicates the production environment as far as possible. 1.1.1.4. A UAT environment can simulate a production topology in a

scaled down manner.

1.1.2. Considerations for the implementation: To support the planning process it is important to understand the hierarchy of the infrastructure and to be aware that for the product to perform well the entire system must be robust and tuned. The size and scope of the environment may vary but the core of this structure is dependent upon: 1.1.2.1. The network architecture. 1.1.2.2. The hardware servers that operate within the network. 1.1.2.3. The software services such as application servers, report servers

and database servers that are installed on the hardware servers. 1.1.2.4. The Maximo product runs within the installed software services.

1.1.3. The number of users that are expected to use the system concurrently. Every user that makes a connection to Maximo consumes resources on both the application and database server, as well as utilizing bandwidth in the network. 32 bit hardware supports fewer users per Java Virtual Machine (JVM) than 64 bit versions. Consequently IBM Tivoli system management products recommend the use of 64 bit hardware when considering the installation of Maximo. In a 64 bit operating environment


when determining the quantity of users per JVM, a concurrency of between 40 and 70 users is often used as the planning benchmark. This planning process needs however to consider several important factors. 1.1.3.1. The expected workload per user in the organization. 1.1.3.2. Whether or not Maximo will be heavily customized. Overheads

in processing custom code will result in fewer supportable users per JVM.

1.1.3.3. The hardware available to the organization. 1.1.3.4. Whether or not the environment is expected to require interfacing,

cron tasks and reporting activities. 1.1.4. Planning for security:

How a user is able to interact with Maximo is dependent upon the application privileges established within the Maximo product itself. However during the planning and installation process a method should be established to determine which security model the deployment will utilize. 1.1.4.1. Use application server and LDAP for authentication and

user/group management, for those organizations requiring that a directory service maintain control of users, and primary responsibility for the groups.

1.1.4.2. Use application server and LDAP for authentication only, for organizations requiring that all of the security group assignment be retained within Maximo.

1.1.4.3. Use Maximo native authentication where all user and group security is to be managed exclusively within the product.

1.1.5. Determine the complexity of the environment based upon organizational

business process. Dependent upon the size and complexity of the business requirement, Maximo can be deployed into configurations that include horizontal and/or vertical clusters of JVMs. An environment may comprise of a single or multiple clusters dependent upon the expected usage and user count. 1.1.5.1. Isolate the user interface to a dedicated cluster. 1.1.5.2. Isolate other processes such as integration, cron tasks and

reporting to other JVMs or clusters as determined by predicted load.

1.1.5.3. Configure effective load balancing through the use of supplied software proxies or through the use of a hardware load balancer.

1.1.6. Planning language support:

Dependent upon the choice of database engine, Maximo Asset Management provides installation processes for languages supported by UTF-8 and UCS-2 character encodings. 1.1.6.1. Determine the base language for the installation. 1.1.6.2. Languages required by the organization, can be installed at

system conception.


1.1.6.3. Additional languages may be added either using the automated installer or manually at any point after the initial installation.

1.2. Given that a customer will have Maximo installed on a supported J2EE

platform, explain the J2EE configuration concepts so that the customer understands how J2EE can be configured to meet their needs.

SUBTASK(S): 1.2.1. Define technology concepts – JVM.

1.2.1.1. Define the use and configuration of memory heap sizes. When a Java program is started on a JVM, the JVM gets some memory from the operating system. The JVM uses this memory for all its needs and part of this memory is call java heap memory. Heap in Java generally located at bottom of address space and move upwards and includes a minimum amount of memory and a maximum amount. Whenever the application goes to create an object using a new operator or by any another means, the object is allocated memory from the Heap and when object dies or garbage collection is run, memory goes is returned back to the Heap space.

1.2.1.2. Define generic JVM arguments/common types of parameters. It is a common WebLogic practice to specify the JVM arguments in a custom startup script. These parameters are configured in WebSphere process definition for the JVM when you are looking at WebSphere. There are some common parameters that are typically configured in both platforms including garbage collection schemes and parameters for garbage collection.

1.2.1.3. Define the concept of garbage collection. Garbage collection is the JVM‟s way to free unused Java objects in the Java heap. The heap contains live objects, dead objects, and free memory. When the object is no longer a destination from a pointer in the running application, it is at that point garbage and will be subject to the next garbage collection run. The size of the heap and the scheme for doing garbage collection determines how often this will run. The end goal for performance of your application is to reduce the time and frequency of garbage collection to maximize the productive time of the application. The garbage collection schemes are associated with the java that you are using , not with the platform. The two main ones which are both supported by both Weblogic and WebSphere are the IBM Java and the Sun Java VMs.

1.2.1.4. Define the relationship between EARs and JVMs. The EAR file is a compressed zip file that contains the directory structure of the Maximo application. The EAR file is deployed (uncompressed into place) by the J2EE platform‟s tools. The application itself


runs within the confines of a JVM using these files as its source files set. An EAR is not a JVM, but rather it is the set of files that constitutes the application which runs via the JVM infrastructure. The EAR file can contain different preferences and configurations depending on the role of the JVM as in the case of a BROS JVM or a MIF JVM or a cron JVM or a UI JVM. The EAR that generates and is used for each of those roles may only contain slight differences from each other.

1.2.2. Define technology concepts – Clustering. 1.2.2.1. Define the concept and purposes of clustering (in general.)

Clustering is a means of delivering scalability and high availability to an application by means of providing an addressable JVM infrastructure whose members run the application within separate heap spaces. Users are directed to use different cluster members to provide scaling of the application by spreading workload across these different heap spaces. This is done by providing a means for the JVM to be communicated with using TCP/IP ports listening on predefined port numbers which connect to the different heap spaces and the JVM infrastructure underlying each. This is useful for high availability as well because the different JVMs can be physically isolated across different physical or logical host systems which operate independently of each other.

1.2.2.2. Define the concept and purposes of vertical clustering. Vertical clustering involves the creation and scaling of JVMs across a single host system. Vertical clusters provide scalability, ease of management, and reduced hardware costs. Their weakness is that they are all prone to system failures by a single system.

1.2.2.3. Define the concept and purposes of horizontal clustering. A horizontal cluster involves the creating and scaling of JVMs across multiple host systems. The use of a horizontal cluster typically also involves the use of vertical clustering, although it is not a requirement. By using multiple host systems, the failure of a single system is less likely to result in a complete application outage. Note that while horizontal clustering across multiple logical systems on a single physical system is still considered horizontal clustering, in a larger sense, it is not free from the weakness of an outage of the physical system. Logical VM cloud infrastructures usually work to cluster virtual systems across various physical systems for purposes of high availability and thus the moment to moment location of the system in that case is usually not considered in that particular case.

1.2.2.4. Define the concepts of computing the resource requirements for clustering. When deciding how resources of any given system can be divided into a number of JVMs there are some basic rules to be taken into consideration. The number of processors


required for a single JVM (1) times the number of JVMs to be deployed plus one (minimum) or more processors to account for the OS and the J2EE platform overhead must not exceed the physical number of processors (or logical) for the system. There are some exceptions to this logic including J2EE platform-specific hardware optimizations such as IBM Power Systems and System Z optimizations for WebSphere, but in general, this forms the most useful means of estimating hardware requirements for clustering and is the way that architects will estimate those requirements. Over extending the processor power with overallocation of resources is not recommended and will result in poor application performance with the only exception being some hardware optimizations in System Z for WebSphere where actually it is recommended to overallocate resources by 33% for the CPU due to efficiencies in the hardware (something not generally known by most consultants.) There are also memory allocations per JVM plus some memory for OS and J2EE platform overhead which should also be taken into consideration when sizing the hardware also. Different versions of Maximo have had different figures for calculations but the best practices guide indicates for version 7.5 Maximo products to allocate 4GB RAM to the heap space for the JVMs for WebSphere and 2-4GB RAM for the OS and WebSphere overhead. The best practices guide does not cover WebLogic.

1.2.3. Define technology concepts – Web Server. 1.2.3.1. Define Web server configuration options (generic, including

document root). The typically configured options within a Web server implementation for Maximo involve these set of options: key stores and other SSL configuration options, document root settings and MIME types (for linked documents.) Also included are tuning parameters such as threads, compression of Web traffic, and load balancing schemes.

1.2.3.2. Define the basics of Web server load balancing including methodologies. The purpose of load balancing is to spread theoretically equal workoad from users across different JVMs by means of setting different users to be hosted by different JVMs. Ultimately, you are seeking to achieve optimal resource utilization, maximize request throughput, minimize response time and avoid server overloading. Thus in one case, user A will be assigned to be hosted by a running application JVM X. The decision about where user B will be assigned to be hosted (in the case of 3 JVMs: X, Y, and Z) is based on a scheme implemented by the Web server. The simplest universal schema is called Round Robin. This involves a simple progression where the first user goes to the first JVM and the second to the next one, and the third user to the next JVM and so on, repeating the list of


JVMs each one right after the other (as in our example of JVM X, Y, and Z) as X, Y, Z, X, Y, Z, X, Y, Z, etc. One weakness of this scheme is that users connect and disconnect periodically and have uneven workloads that they demand from the application, thus the Round Robin can be very prone to overloading some systems when a number of nodes is small. Other schemes exist as choices depending on the Web server platform including Random (IBM HTTP Server and Apache) and Application Request Routing (Microsoft IIS). These other schemes use different methodologies to determine the target for a given user session. Note that session affinity is a requirement for Maximo meaning that a user‟s session must persist on the same JVM where it was initiated or the user is effectively a new session when the traffic is routed to a different JVM. There is no support for multiple JVMs to be able to share the same session memory, thus load from a single user is restricted to a single JVM. Hardware load balancers have additional load balancing schemes available to them including the use of application sensors to determine current workload on a particular JVM and select one that is truly less busy.

1.2.3.3. Define the components and use of SSL encryption. SSL (Secure Sockets Layer) technology is used to establish an encrypted link between a server and a client. Typically, in Maximo, this is done from the Web server to the browser client although it is generally recommended to encrypt the traffic between the Web server and the application server as well (another client-server pairing.) This is done by using a security certificate which is presented to the client and then subsequently used to encrypt and decrypt the traffic between the client and server. There are actually two parts to a certificate: public and private key pairs. They are both required in conjunction to create the secure connection. Additionally, the handshake between client and server involves something else: a session key. The handshake looks like this: (1) Browser connects to a Web server (Website) secured with SSL (https). Browser requests that the server identify itself. (2) Server sends a copy of its SSL Certificate, including the server‟s public key. (3) Browser checks the certificate root against a list of trusted CAs and that the certificate is unexpired, unrevoked, and that its common name is valid for the Website that it is connecting to. If the browser trusts the certificate, it creates, encrypts, and sends back a symmetric session key using the server‟s public key. (4) Server decrypts the symmetric session key using its private key and sends back an acknowledgement encrypted with the session key to start the encrypted session. At this point, the handshake is over (very processor intensive) and


from this point forward, the server and browser now encrypt all transmitted data with the session key (less processor intensive).

1.2.4. Define technology concepts – Virtual Host. The virtual host is the means by which the J2EE platform (both WebSphere and Weblogic) allow for multiple hosts and/or ports (JVMs) to be addressed as a single logical host. This virtual host forms the basis for how clustering works to create a single addressable application across vertical or horizontal (and vertical) cluster members. The virtual host requires virtual host aliases to provide this list of addressable ports for each server.

1.2.5. Define technology concepts – Hardware Load Balancer. A hardware load balancer is dedicated equipment (hardware-based instead of software-based as in the Web server‟s technology) which offloads the work of doing the load balancing scheme to an external system. Depending on the vendor, the capabilities of the hardware load balancer can be much more robust than software load balancers including very sophisticated sensors to monitor actual JVM loads and compute the least laden JVM for the next user to be assigned as well as other functions such as SSL encryption/decryption workload. The hardware load balancer will be configured to point to the PORT of the JVM typically. This allows the hardware load balancer to direct the user session to the JVM. Assigning the load balancer to only the Web server address/port serves no actual purpose other than perhaps some of the additional functionality such as SSL encrypt/decrypt. For the purposes of load balancing, it makes more sense to allocate the session directly to the JVM and remove the Web server from the picture at least as far as load balancing is concerned.

1.2.6. Define technology concepts – Single Sign-on (SSO) authentication. WebLogic and WebSphere both offer means to provide SSO capability. SSO offers the ability to secure multiple applications using a single user login so that once authenticated, the user is not challenged for application logins. SSO can also be done using a third party tool such as CA‟s Siteminder or IBM‟s Access Manager products. Both applications provide a means for the third party tool to become the authority for user authentication and authorization for all Web applications defined within them. SSO is closely related to a similar concept which is using a single source for application authentication where all users are challenged for each individual application, but a single account is used to authenticate all users, so the username and password are all the same across all systems. SSO differs in that your credentials, once authenticated, are actually stored as a cookie and are not required to be presented by the user again because the cookie itself is used to authenticate the user for the application. Only in the case where the user‟s cookie is not valid for the application would the user be challenged for credentials valid for that application.

1.3. Given that a customer is planning for a Maximo Asset Management

installation, explain JVM Performance and Optimization Settings and


Concepts so that the tools to optimize the system have been explained.

SUBTASK(S): 1.3.1. Standard JVM Performance Tuning settings - While both Sun and IBM

JVMs are essentially trying to achieve the same goal, they do so via different strategies. This leads to different behavior that needs tuning. 1.3.1.1. Initial/maximum Heap Sizes – Set the minimum and maximum

heap sizes to the same amount for maximum performance in the JVM. Minimum 4096 / Maximum 4096 for 64 Bit Minimum 2048 / Maximum 2048 for 32 Bit

1.3.1.2. Generic JVM Arguments For WebSphere - sun.rmi.dgc.ackTimeout: - Dsun.rmi.dgc.ackTimeout=10000 For WebLogic – not applicable Since Maximo products use RMI, and RMI allocates a large quantity of short-lived remote objects, setting the timeout to the default of five minutes prevents garbage collection from collecting the objects on the server fast enough, which can cause an out of memory problem. To prevent an out of memory problem, set the time out value to 10000 (10 seconds).

1.3.1.3. Explicit garbage collection Disable explicit garbage collection: Websphere : -Xdisableexplicitgc WebLogic : -XX:-DisableExplicitGC Disabling explicit garbage collection disables any System.gc() calls from triggering garbage collections. For optimal performance, disable explicit garbage collection.

1.3.1.4. Garbage collection policy gencon policy: -Xgcpolicy:gencon The gencon garbage collection policy places objects in separate areas of the heap based on their lifetime. The heap is split into a nursery, where objects are created, and a tenured area, where objects are promoted after having survived a certain number of garbage collections. The nursery can then be garbage collected frequently without the overhead of collecting the entire heap, which keeps garbage collection pauses to a minimum.

1.3.1.5. Nursery Size 25% of maximum heap size: -Xmn1024m As mentioned above, when using the gencon garbage collection policy, the heap is split into the nursery and the tenured space. Setting the size of the nursery when using this policy can be very important to optimize performance. Maximo products recommend that the nursery size be set to 25% of the heap size. If you further tune your heap sizes based on the


verbose garbage collection and available heap memory, remember to adjust the nursery size accordingly.

1.3.1.6. Max Perm Size 1.3.2. Standard JVM Thread Pool Performance Settings - While both Sun and

IBM JVMs are essentially trying to achieve the same goal, they do so via different strategies. This leads to different behavior that needs tuning. 1.3.2.1. Thread pools enable components of the server to reuse threads,

eliminating the need to create new threads at run time to service each new request. Based on the J2EE server being used the thread pool count should be increased to accommodate higher session counts.

1.3.3. Additional JVM Performance Tuning Concepts: 1.3.3.1. When planning for overall system memory consumption, include

additional overhead memory to be used by the JVM outside of the heap size as well as available RAM for the operating system. A general rule of thumb is to include an additional 30% - 40% of memory to account for this overhead.

1.3.3.2. JVM heap size parameters directly influence garbage collection behavior. Increasing the heap size permits more objects to be created before it triggers a garbage collection. However, a larger heap size means a larger amount of time is needed to find and process objects that need to be garbage collected. Consequently, JVM heap size tuning often involves a balance between the interval between garbage collections and the pause time needed to perform the garbage collection.

1.3.3.3. To tune the JVM heap size, enable verbose GC. When enabled, the JVM prints out useful information at each garbage collection, such as the amount of free and used bytes in the heap, the interval between garbage collections, and the pause time. This information is logged to the GC logs that can then be used to analyze the heap usage. Once tuning is complete, disable verbose GC and delete the GC log file, since the log file can grow quite large while verbose GC is enabled.

1.4. Given that Maximo functionality is to be separated onto different JVMs

for performance reasons, explain the JVM roles for Maximo so that an individual understands why roles should be separated onto different JVM and the benefits for doing so.

SUBTASK(S): 1.4.1. Explain JVM role of User Interaction (UI) JVM(s). The UI JVMs are used

as the application server JVMs that service user interaction requests for (most) users. The UI functionality is not disabled in other types of JVM role instances, so technically, with the correct port and Web context root information, a user could log in to any JVM to bring up a UI session. However, this JVM role type will have the Maximo Integration Framework


(MIF), Business Intelligence and Reporting Tool (BIRT) and cron tasks disabled and thus not service those types of requests in addition to the normal user interaction load. 1.4.1.1. Disabling MIF is done by commenting out the message driven

beans sections (4 of them) in the file maximo/applications/maximo/mboejb/ejbmodule/meta-inf/ejb-jar.xml and the message driven bean sections (2 of them) in the file maximo/applications/maximo/mboejb/ejbmodule/meta-inf/ibm-ejb-jar-bnd.xmi and rebuilding the EAR file to create a different configuration for this JVM role. Typically, your implementation will not have this enabled initialy, so this will be more a matter of enabling them for the MIF JVM instead of disabling for the UI, but this will need to be done where the integration framework was active and being used in a single JVM with all 4 roles integrated into a single JVM.

1.4.1.2. Disabling cron tasks is done by using the value of mxe.crontask.donotrun. When setting this value to =ALL, all cron tasks are disabled for the given JVM(s) where the generated EAR will be deployed. This should be done for the UI role JVMs.

1.4.1.3. BIRT functionality cannot be completely eliminated from the UI JVMs. The Direct Print reports, Direct Print with Attachments, and Ad Hoc reports (only at the initial creation, afterwards they will execute at BROS) are executed against the UI JVMs every time (except as noted.) However, by setting the mxe.report.birt.viewerrul property in the maximo.properties file for the UI JVMs will result in all other report cases to be executed at the indicated BIRT server. This server URL must have a different hostname than the UI server in it, otherwise, the sessions will become confused and create errors. The second parameter to set in maximo.properties is mxe.report.birt.disablequeuemanager=1 which disables scheduled reports from executing on the JVMs built with this maximo.properties file setting.

1.4.1.4. Clustering the UI JVMs is done to increase the number of users serviced by the application across multiple JVMs for performance reasons. Note that each consultant might have a number (typically 40-50 for 7.1 and 75-100 for 7.5) that they use, but those numbers are purely for estimation purposes as the real question becomes what load the user actually places upon the system based on their actual interaction with the system. The most active users can create workload in excess of tens of less active users quite easily depending on specific product and activity involved. When you consider the fact that the load balancing of users can result (at random) in multiple high-activity users on the same JVM(s) and others with less active users, these numbers are then seen to be viewed with some skepticism


as to any indication of expected performance from moment to moment.

1.4.2. Explain JVM role of MIF JVM(s). The MIF JVMs are used as the application server JVMs that service integration input/output processing for the application. The UI functionality is not disabled in this type of JVM role instances, so technically, with the correct port and Web context root information, a user could log in to any MIF JVM to bring up a UI session. However, this JVM role type will have the BIRT (effectively) and cron tasks disabled and thus not service those types of requests in addition to not servicing the user interaction load. 1.4.2.1. Disabling cron tasks is done by using the value of

mxe.crontask.donotrun. When setting this value to =ALL, all cron tasks are disabled for the given JVM(s) where the generated EAR will be deployed. This should be done for the UI role JVMs.

1.4.2.2. BIRT functionality really isn‟t “disabled” at MIF, but unless users are accessing the UI functionality of this JVM role by directly logging into the MIF JVM, it won‟t be utilized at all.

1.4.2.3. Clustering MIF JVMs can be done for performance reasons. You can also limit the number of message-driven beans (MDBs) on the continuous queue of the integration framework. You can also improve performance by processing inbound integration traffic on a different cluster member. A default installation of IBM Tivoli service management products does not have a specific number of MDBs in the deployment descriptor file. The Enterprise Java Bean container manages the number of MDBs that are created. Depending on the load on your system, you might need to reset this number. It is generally best to start with a small number, such as two MDBs. For a small or medium-sized implementation, two or three MDBs usually provide acceptable performance. As the system load increases, you might need to gradually increase the number of MDBs. You generally must not exceed ten MDBs. More than ten MDBs does not necessarily yield higher throughput and it can significantly increase resource usage (CPU cycles in particular). Test different numbers of MDBs in a development setting to determine an appropriate number before you establish the number of MDBs for your production system.

1.4.2.4. Depending on the number and type of integration activities, the number of cluster members for a MIF cluster can be 2 (recommended at a minimum for availability to have 2 members) or it might be 100 or more for something like a very large financial institution running transactions into Maximo to create requests, etc.

1.4.3. Explain JVM role of Cron JVM(s). The CRON JVMs are used as the application server JVMs that service particular tasks. The UI functionality is not disabled in the CRON JVM role instances, so technically, with the correct port and Web context root information, a user could log in to them


to bring up a UI session. Running cron tasks on separate computers improves throughput and can help improve fault tolerance. You can run cron tasks on several nodes within a cluster or even on several nodes in different clusters. If any one of the nodes fails, the surviving nodes can still run the cron tasks. 1.4.3.1. However, this JVM role type will have the MIF and BIRT

(effectively) disabled and thus not service those types of requests in addition to the normal cron task load.

1.4.3.2. If you want the cron tasks to run on different JVMs in the cron task cluster, perform the following steps: Give each JVM a different name in the cron task cluster by adding -Dmxe.name=<server name> to the JVM generic argument list in each JVM. Use the System Properties application to set different mxe.crontask.donotrun properties for each server in the cron task cluster. This allows you to separate cron tasks on isolated JVMs, but remember that if that cron task‟s JVM goes down, unless it is also paired with another one with duplicate cron task configuration, that cron task will not run.

1.4.3.3. For the same cron task definition, you can create multiple cron task instances to increase performance. Ensure that the instances do not interfere with each other. For example, you can set up reorder cron task instances so that each instance handles a different site.

1.4.3.4. When you define multiple instances on the same server, set them up so that they do not all start and run at the same time. A simultaneous start or run of multiple cron tasks can adversely affect the performance of the server. Prime numbers are good and will rarely intersect with another instance: 1 (if you must), 3, 5, 7, 11, 13, etc. are good choices to minimize the overlapping times of execution across different JVMs and cron tasks.

1.4.4. Explain JVM role of BROS JVM(s). The BROS JVMs are used as the application server JVMs that services scheduled BIRT reports and some BIRT report functionality. The UI functionality is not disabled in the BROS JVM role instances, so technically, with the correct port and Web context root information, a user could log in to them to bring up a UI session. The MIF and non-report-related cron tasks should be disabled at the BROS JVM.

1.5. Given that Maximo is to be installed, define the installation system

requirements so that the environment is ready for Maximo to be installed.

SUBTASK(S): 1.5.1. Explain the pre-requisites to be examined for system preparation for

installation of middleware components.


1.5.1.1. Verify that the system architecture is a supported architecture by using an appropriate OS command or utility to identify the hardware architecture and compare with the installation guide if there is any question of it being a supported architecture type.

1.5.1.2. Check system for appropriate disk space requirements and disk permissions for being able to write the required directory structure.

1.5.1.3. Check the system for available network ports. This also includes validating with the firewall for appropriate firewall rules to allow for communication between client and server as well as between server components.

1.5.1.4. Validate a fully qualified DNS name is available for the system. 1.5.1.5. Validate the fully qualified DNS name is resolvable. 1.5.1.6. Verify that the type of OS is supported by identifying by OS-

specific means what the OS installation is. 1.5.1.7. Check the area to be used as temporary directory space for

sufficient space. 1.5.1.8. Validate there is sufficient free paging space available on the

system. 1.5.1.9. Verify system libraries (per installation guide) for UNIX/Linux

platforms (including things like shell, C++ libraries, etc.). 1.5.1.10. Validate the amount of RAM on the system. 1.5.1.11. Determine if any product firewalls, antivirus, etc. are disabled

prior to the installation. 1.5.1.12. Check ulimits on AIX/UNIX/Linux and OS thread

parameters/settings in the Windows registry. 1.5.1.13. Check very large page size support on AIX. 1.5.1.14. Make certain that passwords to be used do not violate password

rules for your particular middleware to be installed (certain characters are not allowed by particular middleware.)

1.5.2. Examine the system for any required software. 1.5.2.1. AIX/UNIX/Linux requires tar utility to be installed 1.5.2.2. Windows should have available ability to uncompress zip files

either by OS or using 3rd party utility 1.5.2.3. AIX/UNIX/Linux should have truetype font software options

installed. 1.5.2.4. Make certain an appropriate JRE has been installed on the

system. 1.5.2.5. For remote installation, make sure that an appropriate remote

access technology is in place (SMB for Windows, SSH for UNIX/Linux) and functional and an appropriate userid has been set up for the installation.

1.6. Given that Maximo security implementation decisions need to be

made, explain the different options so that the correct planning decisions can be made.


SUBTASK(S): 1.6.1. Explain the J2EE Server security options and points for decision. These

decisions are completely independent of Maximo security options and decisions and also completely independent of infrastructure decisions as this is for AUTHENTICATION and not authorization. 1.6.1.1. Both WebSphere and WebLogic have the ability to have no

authentication required to access their administration server (or console as the term may be.) Whether or not the administration server/console should have a password protection turned on may vary based on the specific type of environment and any network/VLAN security measures in place as well as customer-specific security requirements.

1.6.1.2. The application server security provides a means to integrate your authentication mechanism (typically LDAP) with your application so that a user is being authenticated against a given security authority. This requires configuration within the Maximo Application by editing configuration files and by making changes to LDAP. This is covered in a separate topic in the exam.

1.6.1.3. The application server security also provides (both WebLogic and WebSphere) for the external use of third party authentication via mechanisms such as in the case of SSO products. This really occurs outside the space that would be considered within J2EE server and Maximo application and should always be completely transparent to the application.

1.6.1.4. There is a mapping that exists between authenticated users and Maximo user roles. It differs between WebLogic and WebSphere in implementation, but conceptual is the same.

1.6.2. Explain Maximo security options and points for decision. These decisions are dependent on using Application Server Security where LDAP is concerned to some extent, however, it is important to notice the differentiation between authentication and authorization. 1.6.2.1. Within Maximo, one choice is to manage users and groups

outside Maximo (using LDAP) for authorization (in addition to authentication.) These users and groups are populated within the Maximo database using the LDAPSYNC or VMMSYNC cron task.

1.6.2.2. The import of Maximo users and groups from LDAP to populate tables in Maximo can also be done using the Maximo Integration Framework. This is not typically done, but can be done in the case of an unsupported LDAP provider where the provider does not conform to standard LDAP queries.

1.6.2.3. mxe.LDAPUserMgmt=0 also can be set as a system property value (in systems property application) which results in LDAP being used for authentication but for purposes of authorization, the users and groups are created and managed at Maximo.


1.6.2.4. mxe.LDAPUserMgmt=0 also can be set as a system property value (in systems property application) and can also be used in conjunction with LDAPSYNC/VMMSYNC to import the users from LDAP and populate the user table and person table, but will allow groups to be managed from within Maximo.

1.6.2.5. Users and groups are also possible to be managed completely from within Maximo without the involvement of LDAP. In this event, user and person records can be initially pre-populated using LDAPSYNC or VMMSYNC or via the Maximo Integration Framework.

1.6.3. Explain infrastructure choices and points for decision. These decision points are completely independent of the other two topic areas as they have nothing to do with authorization, authentication, or users or groups as far as the Maximo application is concerned. 1.6.3.1. SSL (Secure Sockets Layer) can be configured for Web browser

to Maximo application server communication. This provides end-to-end encryption between those two points using certificates.

1.6.3.2. SSL can be configured between the Web server (or load balancer) and the application server to encrypt communication between those two points.

1.6.3.3. SSL can be effectively offloaded to a hardware load balancer where such product provides for this. This has an advantage for speed as the application server resources are not being used for encryption/decryption of traffic.

1.6.3.4. Firewalls typically play a role in most corporate environments. 1.6.3.4.1. The database server typically will require firewall ports

to be opened to allow for communication between the database server and the application server. The user never receives data transferrence from the database outside the context of the Maximo application, so ports do not need to be opened between the user and the database directly.

1.6.3.4.2. If VLANs are used to control access to the database server, the firewall may be an unnecessary step except for extremely secure environments.

1.6.3.4.3. Corporate antivirus policies may prevent traffic on specified ports.

1.6.3.4.4. Poorly configured proxy servers may prohibit the flow of network traffic needed by the Maximo components.

1.6.3.4.5. Firewall policies related to corporate VPNs may present different behaviour than those with direct LAN access.

1.7. Given that Maximo is to be installed, configure the security

requirements needed to install Maximo so that pre-installation Security Configuration has been completed.


SUBTASK(S): 1.7.1. Create Local Administrative User:

1.7.1.1. Right-Click My Computer and Select Manage. 1.7.1.2. Expand Users and Groups. 1.7.1.3. Select New User. 1.7.1.4. Add User information. 1.7.1.5. Click OK. 1.7.1.6. Double-Click newly created user account. 1.7.1.7. Select tab: Member of. 1.7.1.8. Add the {local} Administrators Group. 1.7.1.9. Click OK.

1.7.2. Disable Simple File Sharing: 1.7.2.1. Start Windows Explorer. 1.7.2.2. Click Tools -> Folder Options. 1.7.2.3. Clear the Use Simple File Sharing check box.

1.7.3. Disable Windows Firewall: 1.7.3.1. Click Start -> Run. 1.7.3.2. Type “services.msc” and press Enter. 1.7.3.3. Select Windows Firewall service and stop the service. 1.7.3.4. Change the Startup type to “disabled”. 1.7.3.5. Exit the Services Control Panel Applet.

1.7.4. Disable User Account Control(UAC): 1.7.4.1. Click Start -> Control Panel. 1.7.4.2. Select User Accounts. 1.7.4.3. In the User Accounts window, select User Accounts. 1.7.4.4. In the User Accounts Tasks window, click Turn User Account

Control on or off. 1.7.4.5. If UAC is currently configured in Admin Approval Mode,

the UAC message appears. Click Continue. 1.7.4.6. Clear the UAC to help protect your computer check box, and

then click OK. 1.7.5. Disable Admin Approval Mode:

1.7.5.1. Click Start -> Run. 1.7.5.2. Type secpol.msc in the Open box, and then click OK. 1.7.5.3. If the User Account Control dialog box appears, confirm that the

action it displays is what you want, and then click Continue. 1.7.5.4. From the Local Security Settings console tree, Double-click Local

Policies. 1.7.5.5. Double-click Security options. 1.7.5.6. Select the Disabled option, and then click OK. 1.7.5.7. Close the Local Security Settings window.

1.8. Given that Maximo is to be installed, review the Maximo search types

with the customer and explain the impact that they can have on


system performance so that search types and their implications have been reviewed with the customer.

SUBTASK(S): 1.8.1. Identify the four different Search Methodologies used in Maximo.

1.8.1.1. Exact 1.8.1.2. None 1.8.1.3. Text 1.8.1.4. Wildcard

1.8.2. All fields in the Maximo database can use any of the above search methods, except numeric columns cannot use text searching.

1.8.3. Search Types: 1.8.3.1. “Exact” default searching: Uses the exact value the user enters.

This method is case sensitive and will not find items where the case of the value entered is different. Exact searching is the most efficient database search method as long as the field searched is indexed.

1.8.3.2. None default method: Disables searching on a particular field. 1.8.3.3. Text default searching: Uses a complex text algorithm to

determine the root of the word searched. Searches are performed for all instances that contain the root word or any derivative of the root word. This method is not case sensitive and will find items regardless of the case entered.

1.8.3.4. Wildcard default searching: Uses the “%” wildcard on the beginning and end of the search value the user enters. This method is case sensitive and will not find items where the case of the value entered is different.

1.8.4. Documented best practices for use of search types: 1.8.4.1. Use Search Types consistently for similar field types and lengths. 1.8.4.2. Set all fields longer than 25 characters to “Text” style searching

and all other character fields to Exact. 1.8.4.3. Non-indexed searching is very inefficient and is known as a Full

Table Scan. 1.8.5. Out-of-box search method configuration:

1.8.5.1. Character fields under 26 characters are set to Wildcard. 1.8.5.2. Character fields over 25 characters are set to Text.

1.8.6. Change the default search method of fields: 1.8.6.1. Method 1: Through the Maximo User interface (UI)

1.8.6.1.1. Log in to Maximo and Click Go to -> System Configuration -> Platform Configuration -> Database Configuration.

1.8.6.1.2. From the List tab, Click Select Action- > Manage Admin Mode.

1.8.6.1.3. Enable Admin Mode. 1.8.6.1.4. On the List tab, Search for and select the desired

object.


1.8.6.1.5. Click the Attributes tab. 1.8.6.1.6. Search for and Select the Desired Attribute. 1.8.6.1.7. In the Advanced section, change the Search Type to

the desired format. 1.8.6.1.8. Save the Record. 1.8.6.1.9. On the List tab, Click Select Action -> Apply

Configuration Changes. 1.8.6.1.10. From the List tab, Click Select Action -> Manage

Admin Mode. 1.8.6.1.11. Disable Admin Mode.

1.8.6.2. Method 2: Mass Update of the maxattribute table: 1.8.6.2.1. Shutd own the Maximo Application Server(s). 1.8.6.2.2. Execute the following two updates against the Maximo

schema via an interactive SQL utility: update maxattribute set searchtype = 'EXACT' where searchtype = 'WILDCARD' update maxattributecfg set searchtype = 'EXACT' where searchtype = 'WILDCARD'

1.8.6.2.3. Start the Maximo Application Server(s). 1.9. Given a customers need to deploy Maximo, assess the proposed

infrastructure so that the installation of Maximo can be implemented on the proposed infrastructure.

SUBTASK(S): 1.9.1. Network performance.

Clients connect to the Maximo application through the network and any proposed topology requires confirmation that the network infrastructure sufficiently supports the product. The installed application is dependent upon the application server, the database and the report server. Any deterioration in the performance of any/all of these components is likely to degrade the end user experience. 1.9.1.1. Test and ensure that the inter-connectivity between the hardware

servers is within expected internal network parameters. 1.9.1.2. The approximate Maximo network utilization based on general

benchmark results from tests performed by IBM is an average throughput of 6.3KB/s per active user.

1.9.1.3. Network response time for a round trip packet between the client and the server should be at least 50ms.

1.9.1.4. Ensure where possible that the network is free from contention caused by heavily demanding applications such as audio and/or video streaming.

1.9.1.5. If required network performance can be measured with bandwidth monitoring tools, including scheduled pings, HTTP request/return analysis and TCP/IP packet analysis.

1.9.2. Server configurations.


Regardless of the size, complexity or platform that Maximo is installed to, it is vital that both the hardware and software server configurations are sufficient to support the planned build. 1.9.2.1. The operating system, available CPU and available memory

must be sufficiently sized in the hardware. 1.9.2.2. For each configured JVM enough memory to cover the

maximium heap size plus an additional 30-40% for overhead is required.

1.9.2.3. For each JVM there should be at least one CPU core available. 1.9.2.4. The database should be sized and/or configured to cope with the

initial data load and expected growth rate. 1.9.2.5. The database memory process should be configured to handle

the expected user connection concurrency levels. 1.9.2.6. Maximo should be configured to optimize the quantity of initial

database connections dependent upon the quantity of configured JVMs.

1.9.3. System Performance. The deployment planning phase of the implementation requires an understanding of the planned Maximo implementation choices, and how they may affect system performance. The decisions made when planning and customizing the deployment are critical factors in the delivery of good system performance. The architecture should therefore be assessed in terms of the planned utilization of Maximo. 1.9.3.1. Automated workflows can be created to enforce business

processes and validate inputs. The addition of complicated workflows requires additional processing power and can effect performance.

1.9.3.2. How many transactions per hour will the average user perform? 1.9.3.3. Will users utilize the system at the same times of day and/or

night?. 1.9.3.4. Heavy customization, such as the use of conditional expressions,

complex queries and Java class code extensions can require fewer users per JVM.

1.9.3.5. Does the JVM, or cluster of JVMs, support the user concurrency?. 1.9.3.6. Does the implementation include high volume, high frequency

and/or complex cron tasks? Will this be configured to utilize a separate dedicated JVM cluster?

1.9.3.7. Does the implementation include integration components and interfacing to external systems? Will this be configured to utilize a separate dedicated JVM cluster?

1.9.4. System Security. There are three security models that may be utilized as part of the Maximo deployment, two of which provide an interaction with either Tivoli Directory Services or Microsoft Active Directory.


1.9.4.1. The physical server hardware requires appropriate network permissions to see and be seen by the physical servers that support the security model.

1.9.4.2. The Maximo application servers must be configured to support LDAP with appropriate user permissions in place.

1.9.4.3. The mxe.useAppServerSecurity parameter and associated LDAP configurations for the chosen type of authentication in Maximo must be enabled.


Section 2 - Installation

2.1. Given that IBM Maximo Asset Management (Maximo ) middleware has been defined and Maximo is to be installed explain the Maximo installation options so that the Maximo installation options are defined.

SUBTASK(S): 2.1.1. Installation folder is the location where the Maximo fileset will be installed

and the description is notes regarding what the installation reflects 2.1.1.1. When the location is chosen the existence of Maximo is checked

at that location. If no Maximo is found at that location, the installation continues as a new installation. If an existing Maximo is found at that location, the installation assumes an upgrade and continues as an upgrade installation.

2.1.2. Deployment option: 2.1.2.1. Simple deployment installs DB2 and WebSphere and uses all

default values on a single system. 2.1.2.2. Custom deployment allows flexibility in the middleware and

setting choices. 2.1.3. Import middleware configuration Information:

2.1.3.1. If any middleware was installed via the Maximo middleware installer the values can be imported into the Maximo install and field values will be populated with those settings. Enter the connection information for the server where the middleware was installed.

2.1.3.2. If the choice is to not import the middleware all middleware configuration values will be entered during the installation.

2.1.4. Database type is the database platform where the Maximo database will be created. Once the database is selected (DB2, Oracle, SQL Server).

2.1.5. Database information defines the location and connectivity information for the database. 2.1.5.1. To have the installation create and configure the database select

to automate the database creation and configuration. If the database has been created and configured select The database has already been created and configured.

2.1.5.2. To allow the Maximo installation to create and configure the database, the location of the database installation, user credentials are need to allow the installation to create the database.

2.1.6. Storage locations are the tablespaces/segments where the Maximo tables and indexes will be created.

2.1.7. The Application Server is the J2EE server where the Maximo application runs. The options are WebLogic and WebSphere. If WebSphere is the chosen application server there is an option to allow the installation to configure WebSphere for use with Maximo. If this option is selected the installation will configure the Maximo application server, virtual host and


messaging engine. If this option is not selected, that configuration will have to be done before the Maximo installation.

2.1.8. Security options: 2.1.8.1. Use application server and LDAP for authentication and

user/group management – All users and groups created in the directory server.

2.1.8.2. Use application server and LDAP for authentication only – users and groups can be created in the directory server or Maximo.

2.1.8.3. Use Maximo internal authentication – All users and groups managed by Maximo.

2.1.9. Maximo users: 2.1.9.1. Maximo administration user - The product administrator user ID

that is used for initial configuration and adding users. 2.1.9.2. Maximo system registration user - The user ID that is used for the

self-registration of users. 2.1.9.3. Maximo system integration user - The user ID that is used with

enterprise adapters. 2.1.10. Integration Adapter JMS configuration:

2.1.10.1. If configuring message persistence during the installation, a DB2 database is required. Other database types can be configured after the installation.

2.1.11. SMTP configuration – the SMTP server that is used for workflow, admin mode, etc. The administrator e-mail is the user that receives Maximo admin emails. If you leave the fields blank, you must configure the SMTP parameters through the product interface as a post-installation task.

2.1.12. Base Language Selection – The base language for the Maximo implementation.

2.1.13. Additional Language Selection – optionally additional languages can be selected for the Maximo implementation.

2.1.14. Run configuration step. 2.1.14.1. Copy files now, but perform the installation configuration step

later - Select this option to copy files from the installation source to the administrative workstation. You must perform the configuration step at a later time to complete the deployment. This option is selected if the maxdemo database is to be created. The configuration is completed by using the taskrunner utility, in the install_home\scripts directory. Run the taskrunner utility from the command line. install_home\scripts\taskrunner CONTINUE STOPONERROR

2.1.14.2. Deploy application files manually later – Select this option to manually deploy the Maximo and help EARs to the application server.

2.1.14.3. Defer the update of the Maximo database -Select this option if you want to manually run the database update task for the product deployment.


2.2. Given that Maximo is to be installed, explain the Maximo installation

flow so that the Maximo, fix packs, add-ons and industry solutions installation flow is understood.

SUBTASK(S): 2.2.1. Maximo installation – Maximo is installed on the administrative machine. 2.2.2. Verify successful installation. 2.2.3. Maximo fix pack installation – The current fix pack is installed to the same

location as Maximo. 2.2.4. Verify successful installation. 2.2.5. Maximo interim fix installation – The current interim fix for that fix pack is

installed to the same location as Maximo. 2.2.6. Verify successful installation. 2.2.7. Add-on installation – The add-ons are installed. 2.2.8. Verify successful installation. 2.2.9. Add-on fix pack installation - Install the current fix pack for that add-on if

exists. 2.2.10. Verify successful installation. 2.2.11. Repeat steps above for each add-on. 2.2.12. Industry Solution installation – Install the industry solution. 2.2.13. Verify successful installation. 2.2.14. Industry solution fix pack installation – Install the current fix pack for that

industry solution if exists. 2.2.15. Verify successful installation. 2.2.16. Repeat steps above for each industry solution. 2.3. Given that Maximo is to be installed, explain the database script

installation process so that process to update the Maximo database is understood.

SUBTASK(S): 2.3.1. Every product installed, including Maximo, fix packs, add-ons, industry

solutions update the database. The product and version has a version. The version information is stored in the maxvars table. When a product is installed part of the process is to run updatedb. Updatedb looks to the products installed list and for each product and component checks the database version that should be against what the database version is from the maxvars table. If the software version is higher than the database version, scripts are run in numerical order to bring the database to the software level. After each script is successfully executed the maxvar for that product or component is updated. When all the scripts are executed, the database now matches the software level.

2.3.2. Maximo 7.5.0 installation software version - DB Build V7500-721. The database version would be 7500-721 for the MAXUPG maxvar


2.3.3. <mx_home>\maximo\tools\maximo\log\updatedb.log is the log for the database script execution.

2.3.4. <mx_home>\maximo\tools\maximo\<language folder>\script is where the script files are located.

2.4. Given that Maximo is to be installed, explain the different Maximo

installation components so that the components and how they are used are understood.

SUBTASK(S): 2.4.1. Process Solution Installer.

The Process Solution Installer (PSI) provides a common deployment mechanism for both Process Manager Products (PMP) and Integration Modules (IM). The PSI is used to install PMP and IM components that are contained within zip files and payload packages. 2.4.1.1. The PSI is located in the \ibm\smp\bin folder. 2.4.1.2. The PSI may be run using a user interface by utilizing the

command solutionInstallerGUI.bat. 2.4.1.3. The PSI may be run at the command line by utilizing the command

solutionInstaller.bat. 2.4.1.4. The PSI is typically used in deferred deployment scenarios and

installation of some fix packs. 2.4.2. Use the PSI GUI to install a package not previously installed.

2.4.2.1. Open the solutionInstallerGUI.bat. 2.4.2.2. At the Tivoli Process Automation Engine splash screen, click on

OK. 2.4.2.3. At the Introduction Screen,click on NEXT. 2.4.2.4. At the Choose PSI Package screen ,ensure that the

\ibm\smp\PMP folder is selected and click on Choose . 2.4.2.5. For demonstrative purposes, select the MAM.zip package and

click on Open. 2.4.2.6. At the Choose PSI Package screen,click on Next. 2.4.2.7. The package is validated. 2.4.2.8. At the Choose PSI Package screen,click on Next. 2.4.2.9. Package validation results appear to confirm that the package is

or is not already installed. 2.4.2.10. If no instance of the package is installed,click on Next. 2.4.2.11. In this example, click on the check box against „Defer Maximo

Application Redeployment‟ and „Defer the Update of the Maximo Database‟.

2.4.2.12. Click on Next. 2.4.2.13. A pre-install summary will be displayed. 2.4.2.14. Click on Next. 2.4.2.15. The Deployment Progress Window is displayed. 2.4.2.16. The Package Successfully Deployed window is displayed.


2.4.2.17. Click on Next. 2.4.2.18. At the Install another Package window ,Click on Next to exit.

2.4.3. Taskrunner.

Deferred deployments made during the utilization of the Process Solution Installer must be completed at a later time and before the installation of another product. The taskrunner process makes a record of the last successful deployment process and provides a mechanism of resuming where an installation left off. 2.4.3.1. The taskrunner utility is located in the \ibm\smp\scripts folder. 2.4.3.2. The taskrunner data repository is stored in a file named

CCMDBTaskRunnerStore and is located in the \ibm\smp\etc folder. 2.4.3.3. If taskrunner is run with the NOSTOPONERROR parameter the

process will continue regardless of any errors. 2.4.3.4. If taskrunner is run with the STOPONERROR parameter the

process will stop when it encounters an error. STOPONERROR allows the rectification of the cause of any errors and resumes the installation at the point where the last successfully completed task was recorded by starting the taskrunner with the CONTINUE option.

2.4.4. Use the taskrunner to complete a deferred installation.

2.4.4.1. Open a command window at the \ibm\smp\scripts folder. 2.4.4.2. Run taskrunner stoponerror continue. 2.4.4.3. The remaining tasks will display their progress through to the next

error or through to completion if no errors. 2.4.4.4. The taskrunner will exit upon completion.

2.4.5. Use the installvalidation utility to confirm the components – Run

Installvalidation.bat 2.4.5.1. From command prompt change to ibm\smp\scripts folder. 2.4.5.2. Verify JAVA_HOME is defined to version 1.6 . 2.4.5.3. run installvalidation with appropriate parameters for validation. 2.4.5.4. Review log for success.

2.4.6. Use the listiu utility to confirm the components.

2.4.6.1. From command prompt change to ibm\smp\ctg_de\acsi\bin folder. 2.4.6.2. Run Listiu.bat. 2.4.6.3. Verify the components listed are those expected.

2.4.7. Use the solution installer utility to confirm the components.

2.4.7.1. From the command prompt, change to \ibm\smp\bin folder. 2.4.7.2. Run solutioninstaller -action showinstalled -type all. 2.4.7.3. Verify the components listed are those expected.


2.5. Given that Maximo is to be installed, describe the use of the autonomic deployment engine so that the Maximo installation use of the deployment engine is understood.

SUBTASK(S): 2.5.1. The deployment engine (DE) defines an installable package format and

provides a set of runtime services used to install those packages. The DE database contains information regarding products installed in the environment. When a product is installed the DE is checked to verify if that package has already been installed and if the pre-requisition packages have been installed. If any condition from the DE that does not satisfy the product installation, that product cannot be installed into the environment.

2.5.2. DE location – ibm\smp\ctg_de\acsi 2.5.3. DE logs - ibm\smp\ctg_de\acsi\logs\<user> 2.5.4. DE private to the Maximo installation 2.5.5. DE version 1.4 installed 2.5.6. DE updated prior to the updatedb and EAR deploy steps of the installation

during an automated installation 2.5.7. View contents of DE:

2.5.7.1. Run listiu – show all components in the DE database. 2.5.7.1.1. From a command prompt, change to

ibm\smp\ctg_de\acsi. 2.5.7.1.2. Run setenv. 2.5.7.1.3. Change to bin folder. 2.5.7.1.4. Run listiu.

2.5.7.2. Run solutioninstaller – shows only Maximo related components. 2.5.7.2.1. From a command prompt change to ibm\smp\bin. 2.5.7.2.2. Run solutioninstaller –action showinstalled –type all.

2.6. Given that Maximo has been installed describe the use of the Maximo

tools so that the Maximo tools usage is understood. SUBTASK(S): 2.6.1. All Maximo utilities must be run as administrator. 2.6.2. Prerequisite verification utility is used to verify the that installation program

prerequisitions are present on the system. 2.6.2.1. The prerequisite verification utility checks the following items:

2.6.2.1.1. Operating system requirements, including fix packs 2.6.2.1.2. Hardware requirements, including memory and hard

disk space 2.6.2.1.3. Port availability 2.6.2.1.4. Middleware requirements such as software packages,

library files, directory permissions, host names, and installation locations.


2.6.2.2. Launched from Maximo installation launchpad or from a command line 2.6.2.2.1. From launchpad, run in interactive mode. 2.6.2.2.2. From command prompt, utility accepts parameters.

2.6.2.3. Must be run locally on the system hosting the prerequisite, cannot be used to check remote system.

2.6.3. Install validation utility is used to validate the product installation. This command-line utility is used to verify the installation and configuration of the product in a more complete manner. This utility can also be used to verify an existing deployment after changes in the environment, such as changes to host names, user IDs, and passwords. 2.6.3.1. Utility located in ibm\smp\scripts folder – installvalidation.bat 2.6.3.2. Logs located in ibm\smp\logs folder

2.6.4. Updatedb is used to update the database meta data when a product, fix pack, interim fix, etc is installed. Updatedb runs a number of database scripts. 2.6.4.1. Utility located in ibm\smp\maximo\tools\maximo folder –

updatedb.bat 2.6.4.2. Logs located in ibm\smp\maximo\tools\maximo\log folder

2.6.5. Configdb is used to apply the database configuration changes defined in the Database Configuration application. 2.6.5.1. Utility located in ibm\smp\maximo\tools\maximo folder –

configdb.bat. 2.6.5.2. Logs located in ibm\smp\maximo\tools\maximo\log folder.

2.6.6. Drop backup is used to drop backup files that where created during a configdb process but not dropped during that process. 2.6.6.1. Utility located in ibm\smp\maximo\tools\maximo folder –

dropbackup.bat. 2.6.6.2. Logs located in ibm\smp\maximo\tools\maximo\log folder.

2.6.7. Restore from backup is used to restore tables from a backup of that table created during a configdb process but not restored during that process. 2.6.7.1. Utility located in ibm\smp\maximo\tools\maximo folder –

restorefrombackup.bat 2.6.7.2. Logs located in ibm\smp\maximo\tools\maximo\log folder

2.6.8. Encrypt properties is used to encrypt the maximo.properties file. The process encrypts the database user password so there is not a clear text password in the file. 2.6.8.1. Utility located in ibm\smp\maximo\tools\maximo folder –

encryptproperties.bat 2.6.8.2. Logs located in ibm\smp\maximo\tools\maximo\log folder

2.6.9. Integrity checker is used to check the Maximo database and report on common meta data errors. Integrity Checker checks “same-as” information, identifies indexes and related information, identifies nonsequential primary-key sequences, identifies pending configuration changes, identifies inconsistencies between user and group accounts and security tables in Maximo, checks the existence of various Maximo tables


and columns across meta data tables, and at the database (system) level, checks the definitions of tables and columns across meta data tables, and at the database (system) level. 2.6.9.1. Utility located in ibm\smp\maximo\tools\maximo folder –

integrityui.bat. 2.6.9.2. Logs located in ibm\smp\maximo\tools\maximo\log folder

2.6.10. Maxinst is used to create a maximo or maxdemo database. Maxinst is called during the Maximo installation process. 2.6.10.1. Utility located in ibm\smp\maximo\tools\maximo folder –

maxinst.bat 2.6.10.2. Logs located in ibm\smp\maximo\tools\maximo\log folder

2.6.11. Buildmaximoear is used to create the maximo.ear file. The maximo.ear contains the Maximo code and is deployed and executed to a J2EE application server. 2.6.11.1. Utility located in ibm\smp\maximo\deployment folder –

buildmaximoear.bat 2.7. Given that an Maximo product is to be installed, perform the tasks to

manually install Maximo so that Maximo is installed with the current fix pack.

SUBTASK(S): 2.7.1. Before Installing Maximo 7.5, ensure the following has been downloaded

and unzipped to a temporary folder. NOTE: The install images will vary according to Platform Version and bit count 2.7.1.1. LaunchPad Installation Utility 2.7.1.2. Current Maximo fix packs

NOTE: If Middleware is being deployed as part of the Installation, ensure the Middleware images are also downloaded and unzipped to one folder

2.7.2. Ensure the database has text searching installed and enabled. 2.7.2.1. DB2:

Review sqllib/db2tss to confirm the existence of the bin, lib, and other subdirectories.

2.7.2.2. Oracle: Using a SQL tool, execute the following as the Maximo schema ID and confirm successful results: create table x (y varchar2(2000)). insert into x values ('the quick brown fox'). create index xi on x(y) indextype is ctxsys.context. select * from x where contains (y, 'fox') > 0. drop table x purge.

2.7.2.3. SQL Server: Using a SQL tool, execute the following as the Maximo ID and confirm a return of 1: SELECT FULLTEXTSERVICEPROPERTY('IsFullTextInstalled')

2.7.3. Install Middleware (WebSphere, WebLogic).


2.7.4. Install Maximo 7.5. 2.7.4.1. Log in to server with an ID having Local Admin access. 2.7.4.2. Launch the LaunchPad Installer (Run As Administrator). 2.7.4.3. In the Left Pane, Click Install Product. 2.7.4.4. In the Main Pane, Click Maximo . 2.7.4.5. The following screen is displayed: 2.7.4.6. At the Language Selection screen, Click OK. 2.7.4.7. At the Introduction screen, Click Next. 2.7.4.8. At the Choose installation folder screen, Ensure desired Drive and

Folder, Click Next. 2.7.4.9. At the Verify installation location screen, Click Next. 2.7.4.10. At the Package Summary screen, Click Next. 2.7.4.11. At the Software License Agreement screen, Click “I accept…”,

Click Next. 2.7.4.12. At the Choose Deployment screen, Select Custom, Click Next. 2.7.4.13. At the Import Middleware Configuration information screen,

choose whether or not to import WebSphere Configuration If WebSphere was installed using the Maximo MWI:

Select the Import Middleware Configuration Information check box.

Input the following, Click Next. o Tick the Import middleware configuration information

check box. o Host name: FQDN of WebSphere server o User ID: WebSphere Administrator ID o Password: WebSphere Administrator Password o Confirm password: WebSphere Administrator

Password. o Workspace location: As configured during WebSphere

Installation If WebSphere was not installed via the Maximo MWI:

Deselect the Import Middleware Configuration Information check box.

Click Next. 2.7.4.14. At the Database Type screen, Select database type, Click Next. 2.7.4.15. In the Database-specific input screens, Input the required values,

Click Next: Examples of values for all database types are as follows:

Host Name: Database Server FQDN or IP address

Port: database port number

Database Name: Database instance name

Database User ID:Database schema name

Database password: Database schema password

Confirm password: Database schema password 2.7.4.16. At the Automate Database Configuration screen, Select whether

or not to automate database creation. Then Click Next.


2.7.4.17. On the Application Server Type screen, select WebSphere or WebLogic, Click Next. NOTE: There is no option to “Automate” Middleware Configuration if WebLogic is selected as the Application Server Type

2.7.4.18. On the Security screen, Select the appropriate Security Configuration for this install, then Click Next:

Use application server and LDAP for authentication and user/group management. o Configure security so that an LDAP resource is used for

user authorization and authentication, as well as group management.

o If this option is selected, the User base Entry and Group base entry are also required.

Use application server and LDAP for authentication only o Configures security so that an LDAP resource is used

for user authentication only. Group management is managed from the Maximo Asset Management application. Authorization data is stored in the database.

Use Maximo internal authentication. o Configure security so that user authentication and

authorization are both managed from the Maximo application. Authentication and authorization data is stored in the database.

2.7.4.19. On the Specify Maximo users screen, Input Passwords, Click Next:

Maximo administration user o Product administrator user ID used for initial

configuration and adding users. o Default value is maxadmin.

Maximo system registration user o User ID used for the self registration of users. o Default value is maxreg

Maximo system integration user o User ID used with enterprise adapters. o Default value is mxintadm

2.7.4.20. The Integration Adapter JMS Configuration screen will only be displayed only if WebSphere Configuration was chosen, Select the appropriate choice, Click Next:

Persist JMS Messages o Select this option to enable the Maximo Asset

Management installation program to set the JMS implementation to persist messages within DB2.

Do Not Persist JMS Messages o If you select this option, the Maximo Asset Management

installation program does not set the JMS


implementation to persist messages automatically in DB2. You can configure the JMS implementation manually at a later date.

2.7.4.21. On the SMTP Configuration screen, Input Field Information {if available}, Click Next.

NOTE: The SMTP string is not required for the installation to be successful; however it is required to be configured in the product interface for successful operation of specific product components, such as Workflow.

2.7.4.22. On the Base Language selection screen, Select the Base Language, Click Next.

2.7.4.23. On the Additional Language selection screen, Select Any Additional Required Languages for this installation, Click Next:

NOTE: Additional Languages can be added after the installation is complete, but require a series of manual steps.

2.7.4.24. On the Run Configuration Step screen, select the option which corresponds to the desired installation choice, then Click Next

Copy files now, but perform the installation configuration step later. o Copies files from the installation source to the

administrative workstation. o The configuration step must be manually executed, via

the taskrunner utility, to complete the deployment o To prevent corruption of the Deployment Engine (DE),

do not install any other products until the manual step is successfully completed.

o Taskrunner options are: CONTINUE – The taskrunner resumes the installation

at the point of of the last successfully completed task. NOSTOPONERROR – The taskrunner continues

despite errors. STOPONERROR – The taskrunner stops when it

encounters an error.

Deploy application files manually later. o This option applies only to WebSphere and pertains to

having the installation deploy the EAR files, or manually deployment after installation is complete.

Defer the update of the Maximo database. o Copies files to the administrative system and registers

product process solution packages, but prevents update of the Maximo database during the product installation.

o The UpdateDB command must be manually executed to write the Maximo data to the database and complete the deployment.

o This option is typically used in cases where there is a fix pack or additional product installations required.


2.7.4.25. On the Choose Shortcut Folder screen, Select the option which corresponds to the installation requirement, then Click Next

In a new Program Group. o Create Maximo shortcuts in a new program group.

In an existing Program Group. o Create Maximo shortcuts in a program group of your

choosing.

In the Start Menu: o Create Maximo shortcuts in the Windows Start menu. o To use the Start menu shortcut within Internet Explorer,

add the Maximo URL to the trusted sites Web content zone and disable the option of requiring server verification for all sites in the zone.

On the Desktop: o Create Maximo shortcuts on the user’s desktop.

In the Quick Launch Bar: o This option must not be used. o Selecting this option does not create a shortcut in the

Quick Launch bar.

Other. o Create Maximo shortcuts in the selected location.

Don‟t create icons. o Prevents creation of Maximo shortcuts.

Create Icons for All Users. o Create Maximo desktop icons for all system users.

2.7.4.26. On the Input Summary screen, Review selections, click Next. 2.7.4.27. On the Pre-Installation Summary screen, click Install. 2.7.4.28. On the Installation Complete screen, click Done. 2.7.4.29. Locate the current Maximo fix pack and uncompress the

installation files to a temporary folder. 2.7.4.30. Right-Click the appropriate installation EXE file and Run-as

Administrator. 2.7.4.31. At the Tivoli process automation engine screen, click OK. 2.7.4.32. At the Introduction screen, click Next. 2.7.4.33. At the Choose Installation folder screen, Browse to the Maximo

Installation Location, Click Next. 2.7.4.34. At the Verify Installation location screen, click Next. 2.7.4.35. At the Package Summary screen, click Next. 2.7.4.36. On the SMTP Configuration screen, Input Field Information {if

available}, click Next. 2.7.4.37. At the Run Configuration Step screen (WebSphere Only), select

only if automatic WebSphere Configuration is desired. click Next. 2.7.4.38. At the Input Summary screen, click Next. 2.7.4.39. At the Pre-Installation Summary screen, click Install. 2.7.4.40. At the Installation completed screen, click Done.


2.7.4.41. Manually Deploy the EAR files, if not automatically deployed during the installation.

2.7.4.42. Start the JVM in the middleware. 2.7.4.43. Log in to Maximo 7.5. 2.7.4.44. At the Main menu, click Help | System Information. 2.7.4.45. Log Off Maximo 7.5. 2.7.4.46. Back up the <drive>\ibm folder (i.e., c:\ibm). 2.7.4.47. Back up the database.

2.8. Given that the middleware has been installed, validate core

technology configurations so that users can connect to the installed Maximo system via the middleware.

SUBTASK(S): 2.8.1. Explain the processes to validate core technology configuration so that the

installation can be done and product can be used with these technologies. 2.8.1.1. The first sign of a problem is generally a log entry that expresses

some issue with the particular technology. These log entries will typically tell whether the issue is availability (cannot be reached) or authentication/authorization (not authorized).

2.8.1.2. Testing port availability can be a first step in determining if SOAP or the desired technology is available. This can be done using netstat command on (all platforms) to determine if the port is listening (requires knowledge of the configured port number.)

2.8.1.3. Telnet can be an effective tool to determine if the port is responding if you do not have direct access to the system (remote) by using the telnet command for your client platform telnet IP (space) port.

2.8.1.4. Specific technologies have other testing means available. 2.8.1.4.1. SOAP can be tested using wsadmin command

(WebSphere), or by various SOAP clients from test suites or by constructing a SOAP request file and posting to the server using a SOAP client. This works for either J2EE platform.

2.8.1.4.2. RMI can be tested using wsadmin command (WebSphere) and by use of a java program in WebLogic.

2.8.1.5. Remote technologies are always vulnerable to firewall rules so pay particular attention to whether or not the port is remotely available.

2.8.1.6. If Maximo is to be configured for LDAP authentication, then it must be tested using an LDAP client of which there are many available options for free. The components of a successful test are the user (assuming anonymous queries are disallowed) and LDAP query. Constructing a successful query and getting the value expected in return to the query is a key skill for implementation consultants in


order to understand how to configure the LDAPSYNC or VMMSYNC cron tasks.

2.9. Given that the Maximo product is in the process of installation or has

been installed, describe the installation and tool log files so that the appropriate course of action can be taken.

SUBTASK(S): 2.9.1. Identify critical logs and log locations.

2.9.1.1. General Installation logs (including taskrunner) 2.9.1.1.1. ibm\smp\logs\

2.9.1.1.1.1. CTGSummaryXX.log - Contains a summary of the information currently traced in the trace log.

2.9.1.1.1.2. CTGInstallTraceXX.log – Contains full install trace information.

2.9.1.1.1.3. CTGErrorXX.log - Captures only failure output

2.9.1.1.1.4. CTGInstallMessageXX.log 2.9.1.1.2. <users home directory> (Used prior to SMP file set lay

down) 2.9.1.1.2.1. CTGSummaryXX.log – Contains a

summary of the information currently traced in the trace log.

2.9.1.1.2.2. CTGInstallTraceXX.log - Contains full install trace information

2.9.1.1.2.3. CTGErrorXX.log - Captures only failure output

2.9.1.1.2.4. CTGInstallMessageXX.log 2.9.1.2. Solution Package logs

2.9.1.2.1. ibm\smp\solutions\logs 2.9.1.2.1.1. Each package will have its own folder

containing logs. 2.9.1.3. Deployment Engine logs

2.9.1.3.1. ibm\smp\ctg_de\acsi\logs 2.9.1.3.1.1. Folder name is named as user id

performing install 2.9.1.3.1.1.1. de_trace.log 2.9.1.3.1.1.2. de_Install.log 2.9.1.3.1.1.3. de_cbe.log 2.9.1.3.1.1.4. de_msg.log 2.9.1.3.1.1.5. acu_de.log

2.9.2. Indentify tool logs. 2.9.2.1. ibm\smp\maximo\tools\maximo\log

2.9.2.1.1. UpdateDB.log – Show results of running the UpdateDB command, including errors and completion.


2.9.2.1.1.1. Errors may be specific to type of DB being used

2.9.2.1.1.2. This log shows meta data changes being made as a result of installation.

2.9.2.1.2. ConfigDB.log - Show results of running the ConfigDB command, including errors and completion. 2.9.2.1.2.1. Errors are related to DB structure.

2.10. Given that the Maximo product is installed, verify that the Maximo

database has been installed correctly so that the Maximo system is ready to be configured.

SUBTASK(S): 2.10.1. Verify completion via log file:

2.10.1.1. ibm\smp\maximo\tools\maximo\log\maxinst.log 2.10.1.1.1. look for message: BMXAA6820I - Maxinst

completed without errors. 2.10.1.2. ibm\smp\maximo\tools\maximo\log\updatedb.log

2.10.1.2.1. no error messages typically indicates no errors. 2.10.1.3. ibm\smp\logs\CTGInstallTraceXX.log

2.10.1.3.1. look for message: CTGIN2079I: process automation engine database configuration completed successfully (This message indicates that maxinst finished successfully.)

2.10.2. Check MAXVARS table: 2.10.2.1. Connect to DB via Query tool. 2.10.2.2. Execute SELECT * FROM MAXVARS WHERE VARNAME =

„MAXUPG. 2.10.2.2.1. Value should return “7500-721” for Maximo 7.5.0.0

without FP or IF. 2.11. Given that Maximo is to be upgraded, explain the Maximo upgrade

process from 7.1 to 7.5 so that the customer understands the upgrade process.

SUBTASK(S): 2.11.1. Upgrade to 7.5.0.0:

2.11.1.1. Check Prerequisites. 2.11.1.1.1. Confirm 7.1 environment is at appropriate fixpack

level for upgrade. 2.11.1.1.2. Confirm existing database MAXUPG Value. 2.11.1.1.3. Verify that Maximo 7.5.0.0 implementation will be

configured on documented platform requirements. 2.11.1.1.4. Identify custom triggers. 2.11.1.1.5. Identify unsupported database index types. 2.11.1.1.6. Identify existing reports.


2.11.1.1.7. Run Maximo 7.1.x Integrity Checker. 2.11.1.1.8. Verify that the database has sufficient free space.

2.11.1.2. Review, prepare, and update environment. 2.11.1.2.1. Determine existing industry solutions or other

products installed and appropriate fix pack level. 2.11.1.2.2. Update database properties - Before you can

upgrade your version of Maximo, you must record any database changes that have been made in your environment since the original deployment. You update the database properties in the maximo.properties file.

2.11.1.2.3. Update Install properties - Before you can upgrade your version of Maximo you must record any installation program properties changes that have been made in your environment since the original deployment. You update the installation properties in the install.properties file.

2.11.1.2.4. Disable custom trigger. 2.11.1.2.5. Archive existing reports. 2.11.1.2.6. Remove unsupported database index types.

2.11.1.3. Install/configure middleware. 2.11.1.4. Migrate database or Directory Server Data. 2.11.1.5. Run the Maximo installation program.

2.11.1.5.1. Defer the database update. 2.11.1.6. Install MAM fix pack (if needed). 2.11.1.7. Run fix pack for industry solutions and add-ons. 2.11.1.8. Migrate customizations. 2.11.1.9. Run the Maximo Installation program to upgrade database

content or manually run updatedb. 2.11.1.10. Run Integrity Checker. 2.11.1.11. Perfrom post-upgrade tasks.

2.12. Given that the IBM product is installed, verify which version of Maximo

has been installed so that Maximo is installed to the targeted level. SUBTASK(S): 2.12.1. Determine Maximo version.

2.12.1.1. LISTUI 2.12.1.1.1. Navigate to ibm\smp\ctg_de\acsi folder. 2.12.1.1.2. Run setenv. 2.12.1.1.3. Change to bin folder. 2.12.1.1.4. Run listiu. 2.12.1.1.5. Version is displayed.

2.12.1.2. Version.bat 2.12.1.2.1. Navigate to ibm\smp\maximo\applications\maximo

folder.


2.12.1.2.2. Run version.bat. 2.12.1.2.3. Version is displayed.

2.12.1.3. Solution installer 2.12.1.3.1. Navigate to ibm\smp\bin folder. 2.12.1.3.2. Run solutioninstaller -action showinstalled -type all. 2.12.1.3.3. Version is displayed.

2.12.1.4. Database 2.12.1.4.1. Connect to database with a database query tool. 2.12.1.4.2. Query MAXVARS table for the varvalue of each

Maximo component. 2.12.1.4.3. Version is displayed.

2.12.1.5. Maximo 2.12.1.5.1. Log in to Maximo. 2.12.1.5.2. Click Help. 2.12.1.5.3. Click System Information. 2.12.1.5.4. Version is displayed.


Section 3 - Configuration

3.1. Given Maximo is already installed, enable Application Server Security within Maximo configuration and J2EE server so that users can connect to Maximo by using LDAP authentication.

SUBTASK(S): 3.1.1. Enable Application Security within J2EE server.

3.1.1.1. Enable Application Security. 3.1.1.2. Enter BIND user that has rights to connect to LDAP. 3.1.1.3. Enter base DN. 3.1.1.4. Save configuration. 3.1.1.5. Restart J2EE server.

3.1.2. Define files required to configure to use application server security:

3.1.2.1. ibm\SMP\maximo\applications\maximo\properties\maximo.properties

3.1.2.2. ibm\SMP\maximo\applications\maximo\maximouiweb\webmodule\WEB-INF\web.xml

3.1.2.3. ibm\SMP\maximo\applications\maximo\mboweb\webmodule\WEB-INF\web.xml

3.1.3. Configure Maximo files to use global security.

3.1.3.1. Add the following property in the maximo.properties file. 3.1.3.2. mxe.useAppServerSecurity. 3.1.3.3. Set the value of the property to .1 3.1.3.4. Save the file. 3.1.3.5. Uncomment the following lines in the file:

ibm\SMP\maximo\applications\maximo\maximouiweb\webmodule\WEB-INF\web.xml

<login-config> <auth-method>BASIC</auth-method> <realm-name>Maximo Web Application Realm</realm-name>

</login-config> 3.1.3.6. Set the useAppServerSecurity setting to 1 in the same file. 3.1.3.7. Uncomment the following lines in the file:

ibm\SMP\maximo\applications\maximo\maximouiweb\webmodule\WEB-INF\web.xml

<security-constraint> <web-resource-collection> <web-resource-name>Maximo UI pages</web-resource-name> <description>pages accessible by authorised users</description> <url-pattern>/ui/*</url-pattern> <http-method>GET</http-method>


<http-method>POST</http-method> </web-resource-collection> <web-resource-collection> <web-resource-name>Maximo UI utility pages</web-resource-name> <description>pages accessible by authorised users</description> <url-pattern>/webclient/utility/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to Maximo UI</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description>

<transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint>

3.1.3.8. Save the file. 3.1.3.9. Uncomment the following lines in the file:

ibm\SMP\maximo\applications\maximo\mboweb\webmodule\WEB-INF\web.xml

<security-constraint> <web-resource-collection> <web-resource-name>MaximoReportTool</web-resource-name> <description>pagesaccessiblebyauthorisedusers</description> <url-pattern>/reporttool/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>RolesthathaveaccesstoMaximoReportTool</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>datatransmissiongaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint>

3.1.3.10. Set the useAppServer Security setting to 1 in the same file. 3.1.3.11. Save the file.


3.1.3.12. Build the Maximo EAR file. 3.1.3.12.1. Open a command prompt.Run as administrator. 3.1.3.12.2. Change to ibm\SMP\maximo\deploymentfolder. 3.1.3.12.3. Type buildmaximoear. 3.1.3.12.4. Press Enter. 3.1.3.12.5. Deploy the Maximo.ear file in the appropriate

Application server. 3.1.4. Set up synchronization cron task.

3.1.4.1. Open the cron task setup application. 3.1.4.2. For LDAPSYNCorVMMSYNC,set cron task(s) to Active. 3.1.4.3. Set as chedule. 3.1.4.4. Define the following parameters for theLDAPSYNC cron task and

the VMMSYNC cron task. LDAPSYNCParameter Description Credential LDAPcredentials GroupMapping TheGROUPXMLthattheLDAPtaskuses Host LDAPconnectionhost Port LDAPconnectionport Principal LDAPprincipal SSLEnabled LDAPconnectionSSLenabled SynchAdapter LDAPsynchronizationadapter SynchClass LDAPsynchronizationClass SynchParameter Parametername,valuepairsdelimitedbycomma UserMapping TheUSERXMLthattheLDAPtaskuses

VMMSYNCParameter Description Credential VMMadmincredentials GroupMapping TheUSERXMLthattheVMMtaskuses GroupSearchAttribute VMMsearchattributetoquerygrouprecords Principal VMMadminprincipal SynchAdapter VMMsynchronizationadapter SynchClass VMMsynchronizationClass UserMapping TheUSERXMLthattheVMMtaskuses UserSearchAttribute VMMsearchattributetoqueryuserrecords

3.1.5. Test Application server security

3.1.5.1. Launch Maximo application and log in with LDAP credentials. 3.2. Given Maximo is already installed and is ready to integrate with other

systems, validate the Maximo Integration Framework (MIF)


configuration is correct and functional so that Maximo can send and receive transactions to and from external systems.

SUBTASK(S): 3.2.1. Log in to J2EE check JMS configuration on J2EE server.

3.2.1.1. Although the configuration differs between WebSphere and WebLogic,the queue naming convention remains the same.

3.2.1.2. Validate cqin queues exists with JNDInamejms/maximo/int/queues/cqin

3.2.1.3. Validate sqin queue exists with JNDInamejms/maximo/int/queues/sqin

3.2.1.4. Validate sqout queue exists with JNDInamejms/maximo/int/queues/sqout

3.2.1.5. Validate cqinerr queue exists with JNDInamejms/maximo/int/queues/cqinerr

3.2.2. Log in to Maximo and check MIF work with MaximoI ntegration ->External

Systems. 3.2.2.1. From List tab,hitenter to drop-down all available external systems. 3.2.2.2. ClickonEXTSYS1 3.2.2.3. From Select Action drop-down menu: 3.2.2.4. Select Add/Modify queues. 3.2.2.5. Validate cqin queue exists with

QueueJNDIName:jms/maximo/int/queues/cqinwithInboundradioboxchecked.

3.2.2.6. Validate sqin queue exists with QueueJNDIName:jms/maximo/int/queues/sqinwithInboundradioboxchecked

3.2.2.7. Validate sqout queue exists with QueueJNDIName:jms/maximo/int/queues/sqoutwithsequentialradioboxchecked

3.2.2.8. Validate cqinerrqueue exist swith QueueJNDIName:jms/maximo/int/queues/cqinerrwithsequentialradioboxchecked

3.2.3. Enable MIF global directory.

3.2.3.1. Log in to Maximo and navigate to GoTo ->System Configuration -> Platform Configuration ->System Properties.

3.2.3.2. Type „global‟ in Filter and hitente.r 3.2.3.3. Expand propertymxe.int.globaldir. 3.2.3.4. Enter desired location form MIF globald irectory

e.g.<drive>\MEAGLOBALor\\Servername\Share. 3.2.3.5. Save setting by clicking save icon in too lbar. 3.2.3.6. Click checkbox next to mxe.int.globaldir. 3.2.3.7. Click Select Action drop-down menu and select Live Refesh.


3.2.3.8. Validate setting change in LiveRefresh pop-up window,and OK to set.

3.2.3.9. Restart Maximo application. 3.2.4. Basicly test if MIFoutbound processing.

3.2.4.1. Log in to Maximo and navigate to Integration Framework with Maximo Integration -> External Systems.

3.2.4.2. From List tab,hitenter to drop-down all available external systems. 3.2.4.3. Click on EXTSYS1. 3.2.4.4. To test outbound messaging, click on Published Channels. 3.2.4.5. Chose any Publishe dChannel,i.e.MXPERSONInterface. 3.2.4.6. Expand and click Data Export. 3.2.4.7. Enter Condition,i.e.where person=maxadmin. 3.2.4.8. Hit OK to complete export. 3.2.4.9. Check mxe.int.global dir ,for exported

xml,i.e.<drive>\MEAGLOBAL\xmlfiles\MXPERSONInterface.xml 3.2.5. Basicly test if MIFoutbound processing.

3.2.5.1. Log in to Maximo and navigate to IntegrationFramework with Maximo Integration ->External Systems.

3.2.5.2. From List tab,hitenter to drop-down all available external systems. 3.2.5.3. Click on EXTSYS1. 3.2.5.4. To test outbound messaging,click on Enterprise Services. 3.2.5.5. Chose any Published Channel, i.e.MXPERSON Interface. 3.2.5.6. Expand and click Data Import. 3.2.5.7. Select XML or Flat file. 3.2.5.8. Select Browse to specify Import file and OK to complete. 3.2.5.9. Check database table to newly added entry.

3.3. Given Maximo is already installed,know, explain and utilize the

maximo.properties file so that the Maximo system can be configured to use alternate middleware and database connection points.

SUBTASK(S): 3.3.1. Modify the maximo.properties file:

3.3.1.1. To locate maximo.properies file,navigate to IBM\SMP\maximo\applications\maximo\properties.

3.3.1.2. Back up the existing maximo.properties file and do not edit it. 3.3.1.3. Copy IBM\SMP\etc\maximo.properties_orig to

IBM\SMP\maximo\applications\maximo\properties\maximo.properties.

3.3.1.4. Open maximo.properties with editor of choice,Edit maximo.properties.

3.3.1.5. Add password for mxe.db.password=CHANGETHISVALUE. 3.3.1.6. Verify all other settings are correct,mxe.db.user,mxe.db.url,etc,

save maximo.properties.


3.3.1.7. Open command prompt as administrator and cd toIBM\SMP\maximo\tools\maximoandexecuteencryptproperties.bat.

3.3.1.8. Rebuild Ear file from IBM\SMP\maximo\deployments\buildmaximoear.cmd.

3.3.1.9. Stop Maximo JVM. 3.3.1.10. Redeploy EARfile to J2EE server. 3.3.1.11. Start Maximo JVM. 3.3.1.12. Log in to Maximo.

3.3.2. maximo.properites available options for Oracle database:

3.3.2.1. mxe.adminuserid=ADMINUSERNAME 3.3.2.2. mxe.adminEmail=ADMINEMAILADDRESS 3.3.2.3. mxe.db.driver=oracle.jdbc.OracleDriverORACLEJDBCDRIVER 3.3.2.4. mxe.db.user=maximoDATABASESCHEMAUSER 3.3.2.5. mxe.int.dfltuser=mxintadmDEFAULTINTERGRATIONUSER 3.3.2.6. mail.smtp.host=smtp.someserver.netSMTPHOST 3.3.2.7. mxe.encrypted=trueMAXIMOSCHEMAPASSWORDISENCRY

PTED 3.3.2.8. mxe.useAppServerSecurity=0APPLICATIONSERVERSECURI

TY0=DISABLED1=ENABLED 3.3.2.9. mxe.db.url=jdbc:oracle:thin:@<DATABASEHOSTNAME>:1521:o

raORACLEDATABASEJDBCCONNECTIONSTRIN 3.3.2.10. mxe.system.reguser=maxregDEFAULTSYSTEMREGUSER 3.3.2.11. maximo.min.required.db.version=7500DB/MAXIMOVERSIO 3.3.2.12. mxe.rmi.port=0DEFAULTRMIPORT 3.3.2.13. maximo.int.dfltuserpassword=SOMEVALUEINTDEFAULTPAS

SWORD 3.3.2.14. mxe.db.schemaowner=maximoSCHEMAOWNER 3.3.2.15. mxe.adminuserloginid=maxadminADMINUSERFORMAXIMOA

PPLICATION 3.3.2.16. mxe.registry.port=13400REGISTRYPORT 3.3.2.17. mxe.name=MAXPRDMAXIMOSERVERNAME 3.3.2.18. mxe.db.password=maximoMAXIMOSCHEMAPASSWORD

3.3.3. maximo.properites available options for DB2 database:

3.3.3.1. mxe.adminuserid=ADMINUSERNAME 3.3.3.2. mxe.adminEmail=ADMINEMAILADDRESS 3.3.3.3. mxe.db.driver=com.ibm.db2.jcc.DB2DriverDB2JDBCDRIVER 3.3.3.4. mxe.db.user=maximoDATABASESCHEMAUSER 3.3.3.5. mxe.int.dfltuser=mxintadmDEFAULTINTERGRATIONUSER 3.3.3.6. mail.smtp.host=smtp.someserver.netSMTPHOST 3.3.3.7. mxe.encrypted=trueMAXIMOSCHEMAPASSWORDISENCRY


TY0=DISABLED1=ENABLED


3.3.3.9. mxe.db.url=jdbc:db2://localhost:50000/dbaliasDB2DATABASEJDBCCONNECTIONSTRING

3.3.3.10. mxe.system.reguser=maxregDEFAULTSYSTEMREGUSER 3.3.3.11. maximo.min.required.db.version=7500DB/MAXIMOVERSION 3.3.3.12. mxe.rmi.port=0DEFUALTRMIPORT 3.3.3.13. maximo.int.dfltuserpassword=SOMEVALUEINTDEFUALTPAS


PPLICATION 3.3.3.16. mxe.registry.port=13400REGISTRYPORT 3.3.3.17. mxe.name=MAXPRDMAXIMOSERVERNAME 3.3.3.18. mxe.db.password=maximoMAXIMOSCHEMAPASSWORD

3.3.4. maximo.properites available options for SQLServer database: 3.3.4.1. mxe.adminuserid=ADMINUSERNAME 3.3.4.2. mxe.adminEmail=ADMINEMAILADDRESS 3.3.4.3. mxe.db.driver=com.inet.tds.TdsDriverSQLJDBCDRIVER 3.3.4.4. mxe.db.user=maximoDATABASESCHEMAUSER 3.3.4.5. mxe.int.dfltuser=mxintadmDEFAULTINTERGRATIONUSER 3.3.4.6. mail.smtp.host=smtp.someserver.netSMTPHOST 3.3.4.7. mxe.encrypted=trueMAXIMOSCHEMAPASSWORDISENCRY


TY0=DISABLED1=ENABLED 3.3.4.9. mxe.db.url=jdbc:inetdae7a:servername:1433?database=databas

ename&language=us_english&nowarnings=trueMSSQLDATABASEJDBCCONNECTIONSTRING

3.3.4.10. mxe.system.reguser=maxregDEFUALTSYSTEMREGUSER 3.3.4.11. maximo.min.required.db.version=7500DB/MAXIMOVERSION 3.3.4.12. mxe.rmi.port=0DEFUALTRMIPORT 3.3.4.13. maximo.int.dfltuserpassword=SOMEVALUEINTDEFAULTPAS


PPLICATION 3.3.4.16. mxe.registry.port=13400REGISRTYPORT 3.3.4.17. mxe.name=MAXPRDMAXIMOSERVERNAME 3.3.4.18. mxe.db.password=maximoMAXIMOSCHEMAPASSWORD

3.3.5. Disabe CRON option:

3.3.5.1. Add mxe.cron task.Do not run=alltomaximo.properties to disableallcronstasksfromrunning

3.3.5.2. Add mxe.crontask.do not run=crontask.instance name to disable a particular cron task from running withproper format,i.e.crontask.instance name.


3.3.5.3. Add mxe.crontask.do not run=crontask.instance name,crontask.instance name to disable multiple CRONS from running separated by comma.

3.3.5.4. Business Intelligence Reporting Tool Properties options 3.3.5.5. mxe.report.birt.disablequeuemanager=1 or

01=disable0=enable 3.3.5.6. mxe.report.birt.viewerurl=rpt_jvm_urlwhererpt_jvm_ur,lis the URL

of the report cluster. 3.4. Given that Maximo is already installed, manually build a Maximo EAR

file and deploy it so that the Maximo application has been updated on J2EE server.

SUBTASK(S): 3.4.1. Navigate to Maximo deployment directory

drive:\IBM\SMP\maximo\deployment 3.4.1.1. Note: Ensure that the commands are run as admin. 3.4.1.2. Single EAR with all components Maximo Integration Framework,

CRON, Business Intelligence Reporting Tool, and User Interface contained, execute buildmaximoear.cmd.

3.4.1.3. Validate maximo.ear file has been built by navigating to drive:\IBM\SMP\maximo\deployment\default .

3.4.2. Deploy maximo.ear to already installed J2EE server. 3.4.2.1. Copy maximo.ear file from Maximo Asset Management

Administrative Workstation to J2EE server. 3.4.2.2. Stop JVM on target J2EE server. 3.4.2.3. Depending on what J2EE (WebSphere) server it may be required

to uninstall the existing Maximo application before installing. Uninstall maximo application from J2EE server.

3.4.2.4. Deploy maximo.ear to J2EE server with the appropriate parameters. 3.4.2.4.1. For WebSphere, perform Mapping, Virtual Host, and

Security. 3.4.2.4.2. For WebLogic, Update maximo.ear

3.4.2.5. Clear Maximo application cache on J2EE server. 3.4.2.6. Start Maximo JVM. 3.4.2.7. Launch Maximo and log in..


Section 4 - Performance Tuning and Problem Determination

4.1. Given that IBM Maximo Asset Management (Maximo) is installed,review and explain the Maximo performance log settings so that the Maximo system is running at optimal performance level.

SUBTASK(S): 4.1.1. There are useful properties in Maximo that can be used to troubleshoot

and monitor Maximo performance. These properties are configured through a combination of configuration in the System Properties and Logging applications.

4.1.2. mxe.db.fetchResult Log Limit 4.1.2.1. Used to capture the number of objects an MBO loads while it is

processing. It is common for an MBO to load several thousand objects temporarily and then release them.

4.1.2.2. Excessive object loads may indicate a problem. 4.1.2.3. The number associated with mxe.db.fetchResultLogLimit is the

number of objects that should be loaded before a log entry is made.

4.1.2.4. For troubleshooting performance and memory issues this value should be set to 200,otherwise it should be set to1000.

4.1.3. mxe.db.logSQLTimeLimit 4.1.3.1. Used to capture SQL statements that take longer than the

specified amoun to time to return. 4.1.3.2. The database should be able to return most SQL statements in

less than1 second. 4.1.3.3. When there is a possible database performance issue, this

property can capture long running SQL. 4.1.3.4. The number associated with the property is presented inmilli

seconds,e.g.1000=1second. 4.1.3.5. The property does not effect performance but large amount so

recorded SQLcan make the log more difficult to read. 4.1.4. mxe.mbocount

4.1.4.1. Used to capture snapshot interval sof memory usage. 4.1.4.2. The MBO Count property includes logging of user counts,users

perJVM,MBOsin memory,memory utilization and cron task execution.

4.1.5. To set up logging perform thefollowing: 4.1.5.1. Open the Logging application. 4.1.5.2. Select Action–Manage Maximo Root Logger. 4.1.5.3. Set the Root Logger Log Level to INFO and the appender to

Rolling. 4.1.5.4. Set the Rolling Appender to a file size of 20 and a backup index of

24. 4.1.5.5. Apply Settings. 4.1.5.6. Go to the SystemProperties application. 4.1.5.7. Set the mxe.db.logSQLTimeLimit=1000 and perform a live refresh.


4.1.5.8. Set the mxe.mbocount=1 and perform a live refresh. 4.1.5.9. Set the mxe.db.fetchResultLogLimit=1000 (200 for troubleshooting)

and perform a live refresh. 4.1.6. Logging appenders, either at the root, or configured within a targeted

process may be configured with any one of a hierarchical level choice. 4.1.6.1. DEBUG- Logs messages that are useful in debugging. 4.1.6.2. ERROR–Logs messages indicating errors in application

functionality. 4.1.6.3. FATAL–Logs very severe error messages. 4.1.6.4. INFO–Logs informational messages. 4.1.6.5. WARN–Logs messages indicating harmful situations in

functionality. 4.1.6.6. The levels are in the following order from highest to lowest:

FATAL > ERROR > WARN > INFO > DEBUG. 4.2. Given that Maximo is installed, utilize basic database functionality to

analyze installation/performance issues so that the database is normalized and tuned to top performance levels.

SUBTASK(S): 4.2.1. Primary Database Server Processing Concerns:

4.2.1.1. The database server processes all transactions from the applications.

4.2.1.2. The integrated reporting function accesses the data in the database to generate documents such as work orders and purchase orders.

4.2.1.3. Reporting also generates resource-intensive management reports. 4.2.2. Database Pool Properties:

4.2.2.1. Initial connections (mxe.db.initialConnections) 4.2.2.1.1. The number of database connections created for

immediate use, upon Application Server Startup 4.2.2.1.2. This should be set to a higher value to accommodate

large numbers of users simultaneously logging into Maximo

4.2.2.1.3. This number should not exceed the maximum free connection, because extra connections are freed if not used.

4.2.2.2. Maximum free connections (mxe.db.maxFreeConnections) 4.2.2.2.1. As user transactions are completed, connections are

freed back to the pool. If the connections put back are greater in number than the connections being requested, the number of free connections increases.

4.2.2.2.2. When the server detects that the number of free connections exceeds this setting, the server closes the extra connections to keep the number of free


connections within the range specified by the properties value

4.2.2.3. Minimum free connections (mxe.db.minFreeConnections)

4.2.2.3.1. When a connection is requested by a user operation, a free

connection in the pool is assigned to this user. 4.2.2.3.2. If more free connections are taken from the pool than

the connections freed back to the pool, the free connection number drops.

4.2.2.3.3. When the server detects that the free connection number is below this setting, it creates new connection(s) to fill the pool so that they are ready for the new requests.

4.2.2.4. New connections (mxe.db.newConnectionCount) 4.2.2.4.1. When the connection number drops below the

threshold of minimum free connections, new connections are created in the batch of this setting to fill the pool.

4.2.1. DatabaseTuning: 4.2.1.1. Indexing:

4.2.1.1.1. Each record of data in the table must have associated data in the index.

4.2.1.1.2. Indexing can greatly increase search speeds. However, a drawback of indexes is that for each insert, update, or delete, the index must also be updated.

4.2.1.1.3. Indexes should be separated from the data and placed into a different tablespace. Use the Database Configuration Application to move the indexes.

4.2.1.1.4. Large tables, like Assets and Work orders, should be moved into their own tablespace.

4.2.1.2. Special Index Types: 4.2.1.2.1. Some special index types are available on each database

platform that are not available in the Database Configuration application. These index types can be created and maintained from the back end, and they can improve performance in specific cases. For example, on Oracle bitmap index or a function-based index can be used if a determination is made that these indexes would improve certain queries.

4.2.1.2.2. If special index types are used, the system administrator must remember to remove any special indexes before configuring database changes. After the database is configured, the special indexes must be replaced.

4.2.1.3. Statistics: 4.2.1.3.1. Statistics should be periodically generated and updated on

all the tables and indexes, including text search indexes. 4.2.1.3.2. In the Database Configure application, use Select Action ->

Generate Statistics to perform this from within the Maximo


application. Statistics can also be updated at the database level.

4.2.1.4. Sequences (available on only DB2 and Oracle) 4.2.1.4.1. Sequence caching in available database platforms is highly

recommended for improved performance. The suggested cache size for all sequences is 20 with the exception of the maxseq sequence, which is used for rowstamps.

4.2.1.4.2. The recommended size for maxseq sequence is 200. To enable or modify sequence caching, perform the following steps:

4.2.1.4.3. Reorganize Tables and Indexes 4.2.1.4.4. Use the reorgchk and reorg tools, which are provided with

IBM DB2 and Microsoft® SQL server, to optimize tablespaces and indexes

4.2.1.4.5. General recommendations for reorganizations are: 4.2.1.4.5.1. Only run a reorganization against a table when

careful analysis has been performed to determine that a reorg corrects the performance problem.

4.2.1.4.5.2. Only reorg tables to reclaim space which have had many deletes and updates when it has been determined that no further inserts will be done in the near term.

4.2.1.4.5.3. Meta data tables should not be reorganized. 4.2.1.4.5.4. A reorg check should be run on the table to

determine if the table needs to be reorganized before performing the reorg; however, this should not be the only indicator of whether a reorg needs to be done. For example, reorgchk flags a table for reorg if the table size in bytes is not more than 70% of the total space allocated for the table. Running a reorg in this case does not resolve the issue. For instance a table using 56% of the space allocated could be improved to 66%, but that still does not meet the 70% requirement, so it is again flagged for reorganization.

4.2.1.4.5.5. If it has been determined that a reorg improves a performance issue with the table/index, then careful consideration should be given on whether the reorg should be done online or offline while the system is down. System resources are required to do reorgs and this can slow down the system during the reorg. As well, consider that users will have to wait for

locks during an online reorg... 4.2.1.4.5.6. Carefully maintain the size of the database by

archiving and trimming tables where appropriate to

reduce the time needed for reorgs.. 4.2.1.5. Customization

4.2.1.5.1. Customizing Maximo products can change the way information is selected from the database. Some customizations include additional tables and columns.


4.2.1.5.2. If there are customized Maximo products, the indexes should be carefully compared to the user functions that use them.

4.2.1.5.3. Ensure the right balance of indexes is implemented. 4.2.1.6. Database-Specific Settings:

4.2.1.6.1. Oracle 4.2.1.6.1.1. Set the CURSOR_SHARING parameter to SIMILAR

or FORCE so that the user-entered literal values are converted to bind variables.

4.2.1.6.1.2. Set the NLS_LENGTH_SEMANTICS parameter to CHAR when the database character set is a double-byte or unicode character set.

4.2.1.6.1.3. Use Program Global Area (PGA) WORKAREA_SIZE_POLICY=AUTO setting to automatically size work areas.

4.2.1.6.1.4. Ensure Optimizers are set to your current Oracle version and not an older one. OPTIMIZER_FEATURES_ENABLE 4.2.1.6.1.4.1. Use System Global Area (SGA)

management by setting the following on Oracle: SGA_TARGET= memory value (for both Oracle 10g and 11g) SGA_MAX_SIZE= memory value (both Oracle 10g and 11g).

4.2.1.6.1.4.2. MEMORY_TARGET= memory value (for Oracle 11g)

4.2.1.6.1.4.3. MEMORY_MAX_TARGET= memory value (for Oracle11g)

4.2.1.6.1.5. Increase the process number to handle more concurrent users by setting the PROCESSES= initialization parameter to the maximum number of users who can access Oracle concurrently.

4.2.1.6.2. DB2 4.2.1.6.2.1. Set DB2_WORKLOAD=Maximo 4.2.1.6.2.2. Use the following DB2 registry setting:

4.2.1.6.2.2.1. db2setDB2_USE_ALTERNATE_PAGE_CLEANING=ON1

4.2.1.6.2.2.2. db2setDB2_FMP_COMM_HEAPSZ=65536

4.2.1.6.2.3. For optimal performance, use the following DB2 database configuration settings: 4.2.1.6.2.3.1. db2 update db cfg for <dbname>

using CHNGPGS_THRESH 402 4.2.1.6.2.3.2. db2 update db cfg for <dbname>

using DFT_QUERYOPT 5 4.2.1.6.2.3.3. db2 update db cfg for <dbname>

using LOGBUFSZ 1024 4.2.1.6.2.3.4. db2 update db cfg for <dbname>

using LOGFILSIZ 8096


4.2.1.6.2.3.5. db2 update db cfg for <dbname> using LOGPRIMARY 20

4.2.1.6.2.3.6. db2 update db cfg for <dbname> using LOGSECOND 100

4.2.1.6.2.3.7. db2 update db cfg for <dbname> using LOCKLIST AUTOMATIC

4.2.1.6.2.3.8. db2 update db cfg for <dbname> using LOCKTIMEOUT 300

4.2.1.6.2.3.9. db2 update db cfg for <dbname> using MAXFILOP 61440 (UNIX / Linux)

4.2.1.6.2.3.10. db2 update db cfg for <dbname> using MAXFILOP 65535 (Windows)

4.2.1.6.2.3.11. db2 update db cfg for <dbname> using NUM_IOCLEANERS AUTOMATIC

4.2.1.6.2.3.12. db2 update db cfg for <dbname> using NUM_IOSERVERS AUTOMATIC

4.2.1.6.2.3.13. db2 update db cfg for <dbname> using SOFTMAX 1000

4.2.1.6.2.3.14. db2 update db cfg for <dbname> using STMTHEAP 20000

4.2.1.6.2.4. For optimal performance, use the following DB2 database manager settings: 4.2.1.6.2.4.1. (UNIX / Linux): db2 update dbm cfg

using AGENT_STACK_SZ 1024

4.2.1.6.2.4.2. (Windows): db2 update dbm cfg using AGENT_STACK_SZ 1000

4.2.1.6.2.4.3. db2 update dbm cfg using RQRIOBLK 65535

4.2.1.6.2.4.4. db2 update dbm cfg using HEALTH_MON OFF

4.2.1.6.3. SQL Server 4.2.1.6.3.1. Row Locking:

4.2.1.6.3.1.1. Enabling the SQL Server row-level locking feature provides SQL Server Database performance improvements.

4.2.1.6.3.1.2. Enabling row-level locking reduces the locked areas of the database. However, row-level locking also can result in a higher number of locks, because locks are based on record instead of memory page. This can further reduce


performance in large databases, or where there are > 250 concurrent users.

4.2.2.4.1.1.1. To enforce Row locking on SQL Server execute:

sp_indexoption 'workorder.workorder_ndx1','AllowPageLocks','false'

4.2.2.4.1.1.2. To enforce row level locking on all of the indexes on a table, execute the following statements: sp_indexoption 'workorder','AllowPageLocks','false'

sp_indexoption 'workorder','AllowRowLocks','true'

4.2.1.7. User Queries: 4.2.1.7.1. Set the appropriate Search Type

4.2.1.7.1.1. EXACT 4.2.1.7.1.2. TEXT 4.2.1.7.1.3. WILDCARD 4.2.1.7.1.4. NONE

4.2.1.7.2. Limit query times to improve performance 4.2.1.7.2.1. mxe.db.QueryTimeout

4.2.1.7.2.1.1. Determines how long an SQL query is allowed to run without producing a result set.

4.2.1.7.2.1.2. The default value is 300 seconds

4.2.1.7.2.2. webclient.ResultSetQueryTimeout 4.2.1.7.2.2.1. Determines how long Query

By Example (QBE) queries are allowed to run without producing a result set.

4.2.1.7.2.2.2. Constructed from user input that is specified on forms and fields in the user interface. Users do not specify the SQL commands or verbs needed to run the query. Instead, QBE queries are translated into SQL queries by a QBE program that processes form input.

4.2.1.7.2.2.3. The default timeout for QBE and filter queries is 360


seconds; if users do not click the control to cancel a query, the query stops when this timer expires.

4.2.1.7.3. Reset the DATETIME Data Type of a Column

4.2.1.7.3.1. When DATETIME fields are searched, the resulting database query uses TO_TIMESTAMP in the WHERE clause.

4.2.1.7.3.2. Queries that use TO_TIMESTAMP are time-consuming.

4.2.1.7.3.3. Queries that use TO_DATE in the WHERE clause yield a faster search.

4.2.1.7.3.4. The WHERE clause can be edited manually by replacing TO_TIMESTAMP with TO_DATE. However, the query must be edited each time a search is performed on a manually edited DATETIME field.

4.2.1.7.3.5. It is recommended to change the data type of routinely queried DATETIME fields to the data type DATE. Fields with a data type of DATE use TO_DATE in the WHERE clause.

4.2.1.7.3.6. Use the Database Configuration application to change the data type of a column.

4.2.1.7.4. Determine what users will query: 4.2.1.7.4.1. Users can create and save their own

queries, and can share queries with other users.

4.2.1.7.4.2. Saved queries are stored in a table named QUERY and should be periodically reviewed for inefficient conditions and use of unindexed columns, and to remove order by clauses.

4.2.1.7.4.3. Set up efficient default queries for the most-used applications, so users see the preferred record set when they enter the application.

4.2.1.7.4.4. Prevent users from performing queries that retrieve hundreds of thousands of records. These types of queries adversely affect database performance, causing slower user response times.

4.2.1.7.4.5. To reduce the likelihood of performance robbing queries, define default queries for your users, or educate users about how to use efficient queries.

4.2.1.7.5. List Panel Order by Queries:


4.2.1.7.5.1. Queries with order by clauses can be expensive, especially list panel queries, since these are heavily used.

4.2.1.7.5.2. The presentation XMLs ahould be edited and order by clauses removed from the queries.

4.2.1.7.6. Restrict Querying in Applications: 4.2.1.7.6.1. Control or restrict user access to query

features and user ability to query on specific columns by using a combination of methods: 4.2.1.7.6.1.1. Application Designer 4.2.1.7.6.1.2. Application cloning 4.2.1.7.6.1.3. Security groups

4.2.1.7.6.2. Application Designer 4.2.1.7.6.2.1. Use the Application Designer

to customize an application by adding or removing columns from the List tab.

4.2.1.7.6.2.2. Ensure the columns to be queried are all indexed.

4.2.1.7.6.3. Application Cloning 4.2.1.7.6.3.1. Clone an application and use

the Application Designer to create an alternate version of an application with a restricted number of columns to be queried.

4.2.1.7.6.4. Security Groups 4.2.1.7.6.4.1. After Cloning applications, use

security groups to assign users to specific application clones.

4.2.1.7.6.4.2. Use security groups to prohibit access to the More Search Fields and Where Clause advanced query options, thus limiting users to querying on the List tab of the application.

4.2.1.8. Database Maintenance: 4.2.1.8.1. Key Performance Indicators (KPI)

4.2.1.8.1.1. KPIs display the state of systems and processes in Maximo products.

4.2.1.8.1.2. Because KPIs can be user-defined, they should be periodically monitored for efficiency.


4.2.1.8.2. Live KPIs on Start Centers: 4.2.2.4.1.2. When a KPI is defined on a Start Center,

information can be retrieved by on of two methods:

4.2.1.8.2.1. 4.2.1.8.2.1.1. An immediate query can be

executed to get the information.

4.2.1.8.2.1.2. The information can be retrieved from a table that is updated by a cron task.

NOTE: The immediate query runs every time the Start Center opens. This approach can cause a long delay in opening the Start Center, and it puts a load on the database.

4.2.1.8.3. KPI Queries 4.2.1.8.3.1. You should periodically review queries that

you write for KPIs.. 4.2.1.8.3.2. Check for SQL efficiency and index usage.

4.2.1.8.4. KPI cron Task Frequency 4.2.1.8.4.1. Determine how up-to-date each KPI

information need to be and consider using the longest possible interval between execution of KPI cron tasks because longer KPI cron task intervals reduce the load on the database from KPIs and can improve system performance.

4.2.1.8.4.2. Use longer rather than shorter KPI cron task frequency intervals when the value of the data to the end user is essentially the same at longer intervals.

4.2.1.8.5. KPI Best Practices：

4.2.1.8.5.1. Set all KPIs to retrieve their data from the KPI table.

4.2.1.8.5.2. Use cron tasks to run KPI queries at reasonable intervals.

4.2.1.8.5.3. Consider moving cron tasks to a separate server

4.2.2. Escalations Escalations are batch users that do not have the overhead of a user interface. Escalations are very resource intensive when executing. 4.2.2.1. Efficiency and Frequency

4.2.2.1.1. An escalation selects a set of records and performs a list of one or more actions on the result set. The columns in the WHERE clause of the selection should be efficiently indexed.


4.2.2.1.2. Set the frequency or schedule of an escalation according to its importance: 4.2.2.1.2.1. An escalation that dispatches emergency

work orders for critical safety issues might warrant a frequency of 5 minutes.

4.2.2.1.2.2. An escalation that ensures that service requests from executives are dealt with promptly might need to run every 15 minutes.

4.2.2.1.2.3. An escalation that closes work orders that were completed 90 or more days ago might need to run only once a week at an off-peak time.

4.2.3. Reports 4.2.3.1. Review custom reports for efficient SQL and use of indexes. 4.2.3.2. Most reports receive a WHERE clause from Maximo products.

For all these cases, improving the efficiency of user queries also improves the efficiency of reports.

4.2.4. Properties file 4.2.4.1. Maximum lookup count

4.2.4.1.1. The property mxe.db.lookupmaxrow controls how many records are returned by the lookup. Because unfiltered lookups can take a long time to perform, this property can be used to prevent database degradation by limiting the number of records being processed by a lookup.

4.2.4.2. Fetch stop limits 4.2.4.2.1. New properties are available to set a limit the number of

objects that can be fetched from the database, and then constructed on the server into a single set.

4.2.4.2.2. The following properties are documented on the support Web site: 4.2.4.2.2.1. mxe.db.fetchStopLimit Enabled

Enables or disables checking of the fetch stop limit 0 to disable, 1 to enable. Default is 1..

4.2.4.2.2.2. mxe.db.fetchResultStopLimit The fetch stop limit used when checking of the fetch stop limit is enabled. The limit applies to all objects for which a specific fetch stop limit property is not specified. -1 means no limit. 5000 is the default.

4.2.4.2.2.3. mxe.db.fetchResultStopLimit.OBJECTNAME

The fetch stop limit for the specified object. If this property exists, its value is used as the


fetch stop limit for this object only. To disable the fetch stop limit for a specific object, create this property and sets its value to -1.

Any integer value can be used. -1 means no fetch stop limit for this object.

4.2.4.2.2.4. mxe.db.fetchStopExclusion A comma-separated list of object names. If

an object name is in the list, the fetch stop limit check is disabled for the object. If an object name is in the list and the same object is specified in an mxe.db.fetchResultStopLimit.OBJECTNAME property, the exclusion overrides the other property.

Comma-separated object name list, as they appear in the MAXOBJECT table.

4.2.5. Load Testing：

4.2.5.1. If possible, perform load testing during the implementation phase to expose performance problems before putting Maximo products into production.

4.2.5.2. If the equipment to perform load testing is available, use load testing after Maximo products are in production to determine if there is any performance impact from patches or from data growth over time

4.3. Given that the Maximo product is installed, determine if queries are

efficient so that Maximo components queries are optimized. SUBTASK(S): 4.3.1. Determine efficient queries

4.3.1.1. Review user queries 4.3.1.2. Review Workflows conditions 4.3.1.3. Review queries in reports 4.3.1.4. Review escalation conditions 4.3.1.5. Review KPI queries 4.3.1.6. Remove wildcard statement to prevent full table scans 4.3.1.7. Add indexes as needed based on where clauses 4.3.1.8. Test query through database tool outside of Maximo to show and

tune based on results 4.3.1.9. Set the mxe.db.logSQLTimeLimit property to log long running SQL

statements and review the logs for those queries and tune based on results.

4.4. Given that Maximo is installed, review the Start Center portlets so that

users achieve a balance between system performance and key data accessibility.


SUBTASK(S): 4.4.1. Good Start Center design is dependent upon the creation of efficient and

structured portlets. Logging into Maximo can take time to load the Start Center, and moving from an application back to a Start Center can take time to load. 4.4.1.1. A complex Start Center with numerous portlets that access the

database can be slow to load. 4.4.1.2. Every portlet runs queries against the database and displays the

result set. 4.4.1.3. If 5 portlets require that 5 queries of 1 second each need to run,

then the Start Center will require at least 5 seconds to load. 4.4.2. Start Center performance can be improved by:

4.4.2.1. Minimizing the number of portlets to those necessary to support the business requirement.

4.4.2.2. Ensuring that the SQL used to select data is efficient, targeted and supported by appropriate indexes.

4.4.2.3. By creating multiple Security Groups with differing Start Centers assigned.

4.4.2.4. Add heavy usage users to these groups so that their Start Center requirements are spread across multiple tabs.

4.4.2.5. Set the default tabbed Start Center with a minimal number of portlets to increase the load speed.

4.4.3. Review and limit the number of roles per user to minimize the number of Start Center tabs presented to the user on log-in.

4.5. Given that the application server instance requires performance

analysis, assess the application server performance so that application server performance is analyzed and corrective actions can be taken.

SUBTASK(S): 4.5.1. Perform an analysis of JVM configuration settings including heap size

(minimum and maximum heap size) and garbage collection for conformance with known best practices. 4.5.1.1. WebLogic and WebSphere heap sizes should be tuned using a

performance tuning methodology involving starting with a standard value and reviewing logs to analyze for heap size errors (out of heap space) and increasing the value until the messages are not frequently seen. This is in coordination with garbage collection.

4.5.1.2. WebLogic and WebSphere garbage collection should be tuned and analyzed on a regular basis after setting the scheme as appropriate for the type of JVM.

4.5.2. Perform analysis of operating system parameters such as network performance and volume disk sizing.


4.5.2.1. Network performance tools are typically customer-owned tools or owned by a service provider (i.e., AT&T if networking is out-sourced) and may require some planning and coordination to get much detail

4.5.2.2. Review performance and tuning guide or product manual (depending on J2EE platform) to select appropriate OS tuning and OS settings)

4.5.2.3. Use OS skills to determine adequacy of system resources (df –k on UNIX vs storage management snap-in on Microsoft Windows)

4.5.3. Perform a detailed analysis of JMS parameters including those related to persistence, throttling, and error handling. 4.5.3.1. Review product manuals for comparison of implementation to

suggested implementation from the documentation 4.5.4. Perform a detailed analysis of database/data sources.

4.5.4.1. Review database using database vendor performance tools including system parameters, open cursors, memory configuration, index creation, etc.

4.5.4.2. Review database config in J2EE platform for such things as data sources.

4.5.5. Review server error logs to identify areas of concern from the log entries. 4.5.5.1. Examine for java errors and errors from customization(s). 4.5.5.2. Scan logs using tools such as “grep” (for UNIX or Windows Grep)

to look for key words such as “FATAL”, “FAIL”, etc. 4.5.5.3. Use tools such as IBM Smarter Performance Analysis suite to

review logs of J2EE platform looking for common patterns (can be used with any application)

4.5.6. Review other server configuration parameters including: security, threads, and communication protocols.

4.6. Given that Thread Dumps and Heap Dumps are to be analyzed,perform

the tasks to manually install Maximo so that the Heap Dumps are analyzed and Garbage Collection is tuned in the middleware.

SUBTASK(S): 4.6.1. Overview

4.6.1.1. Memory utilization can impact system performance significantly. 4.6.1.2. One of the most common memory problems is memory leak,

which causes severe performance degradation. 4.6.1.3. In theory, memory leaks should not happen in Java™ because it

has Garbage Collection (GC). However, GC only cleans up unused objects that are not referenced anymore. Therefore, if an object is not used, but is still referenced, GC does not remove it, which leads to memory leaks in JVM problems.

4.6.1.4. Beside memory leaks, other memory problems that you might encounter are: 4.6.1.4.1. Memory Fragmentation


4.6.1.4.2. Large Memory Objects (LMO) 4.6.1.4.3. Tuning Configuration Issues.

4.6.1.5. In most cases, memory problems can cause the application server to crash. Users first notice that application server performance gradually declines, and eventually crashes with java.lang. Out Of Memory exceptions.

4.6.1.6. Memory problems are hard to trouble shoot because they have multiple causes.

4.6.2. Set verbose Garbage Collection for the Application Server logs. 4.6.3. Analyze verbose GC.

4.6.3.1. The tool to be used for verbose GC log analysis should abstract useful information and illustrate the trend of JVM heap size usage over time.

4.6.3.2. After analyzing the log files, charts should be generated with the following information: 4.6.3.2.1. Occupancy(MB) 4.6.3.2.2. AllocationRate(KB/sec) 4.6.3.2.3. TotalGCpausetime(ms) 4.6.3.2.4. MarkandSweepTime(ms) 4.6.3.2.5. CompactTime(ms) 4.6.3.2.6. GC Cycle length and distribution (ms) 4.6.3.2.7. Free Space after GC (MB) 4.6.3.2.8. Free Space before AF (allocation failure) (MB) 4.6.3.2.9. Size of Request that caused AF (Bytes)

4.6.3.3. Strategies for monitoring the effects of GC and detecting problems include: 4.6.3.3.1. GC Cycle length and distribution" to analyze GC

frequency and distribution 4.6.3.3.2. 4.6.3.3.2 "Free Space after GC" to analyze memory

leak 4.6.3.3.3. 4.6.3.3.3 "Free Space before AF" and "Size of Request

that caused AF" to analyze fragmentation or large objects.

4.6.3.4. Examples of Good and Bad Free Space after GC: 4.6.3.5. In a normal "Free Space after GC" graph, where the application is

using the Java™ heap properly, the heap line should be approximately on a horizontal line. The declining heap line means

that the free space available to allocate is decreasing 4.6.4. Tune the max heap size.

4.6.4.1. The duration of each GC cycle should be monitored and not exceed 10 seconds, except for a compaction occurring within the cycle. In this situation, the heap is probably too large for the application and GC takes a long time to clean up objects in this large heap, so reduce the maximum heap size.


4.6.4.2. In the other cases where GC frequency is too high, the heap is probably too small for the application and GC needs to run frequently, so increase the maximum heap size.

4.6.4.3. To tune the JVM Heap Size 4.6.4.3.1. Change the Max Heap Size to a larger value. 4.6.4.3.2. Cycle the application server(s).

4.6.4.3.3. Try the test case to determine if the issue remains. 4.6.5. Performe the heap dump:

4.6.5.1. If a memory leak is suspected, performing a heap dump is recommended. 4.6.5.1.1. If an out of memory condition occurs, the system will

automatically generate a heap dump. 4.6.5.2. Utilize a tool to analyze a heap dump. The tool will display leak

candidates and the relationship of the objects in the heap. 4.6.5.3. Analyze and drill in to the leak suspects to determine the memory

issue. When the Garbage Collector allocates areas of storage in the heap, an object continues to be live while a reference to it exists somewhere in the active state of the JVM; therefore the object is reachable.

4.6.5.4. When an object ceases to be referenced from the active state, it becomes garbage and can be reclaimed for reuse. When this reclamation occurs, the Garbage Collector must process a possible finalizer and also ensure that any internal JVM resources that are associated with the object are returned to the pool of such resources. Java heap dumps are snap shots of Java heaps at specific times.

4.6.6. Analyze a thread dump. 4.6.6.1. If an application server performance issue is suspected,

performing a thread dump is recommended. 4.6.6.2. Utilize a tool to analyze a thread dump. The tool will display the

transactions that the threads were processing at the time of the thread dump.

4.6.6.3. Analyze the threads to determine the application server performance issue.

4.6.7. Troubleshoot installation. 4.6.7.1. If an error was encountered during the installation, perform the

following: 4.6.7.1.1 Review the log files in folders: 4.6.7.1.2 <drive>\ibm\SMP\logs

4.6.7.1.3 <drive>\ibm\SMP\maximo\tools\maximo\log 4.6.7.2. Correct the issue

4.6.7.2.1 Execute Maxinst.bat on the database: 4.6.7.2.2 Open command prompt and CD to

<drive>\ibm\SMP\maximo\tools\maximo 4.6.7.2.3 Execute maxinst.bat {with the appropriate parameters}. 4.6.7.2.4 For Demo data:maxinst.bat-e-sMAXIMO_INDEX-


tMAXIMO_DATA 4.6.7.2.5 For No Demo data:maxinst.bat-e-iMAXIMO-

sMAXIMO_INDEX-tMAXIMO_DATA 4.6.7.2.6 -i=Createsblankdatabase(usingfilemaximo) 4.6.7.2.7 -e=CausesSQLtobeexecuted 4.6.7.2.8 -s=indextablesspacepopulated 4.6.7.2.9 -t=datatablespacepopulated 4.6.7.2.10 --Note:-eand-sand–tarerequired

4.6.8 Manually complete the installation: 4.6.8.2 Open command prompt and CD to D:\ibm\SMP\scripts. 4.6.8.3 Execute taskrunner.bat CONTINUESTOPONERROR.


Next Steps

1. Take the IBM Maximo Asset Management V7.5 Infrastructure

Implementation assessment test using the promotion code csistudy for $10 ($20 USD savings).

2. If you pass the assessment exam, visit pearsonvue.com/ibm to schedule

your testing sessions. Use the promotion code tivguide to receive 20% off.

3. If you failed the assessment exam, review how you did by section. Focus attention on the sections where you need improvement. Keep in mind that you can take the assessment exam as many times as you would like ($10 per exam), however, you will still receive the same questions only in a different order.

http://www-03.ibm.com/certify/tests/samC2010-501.shtml



cloud & smarter infrastructure professional certification...

Documents