Readme for the interim fixes for IBM Maximo Anywhere 7.6.3

To help you install the interim fixes for IBM Maximo Anywhere 7.6.3, you can use the following installation information:

Content

---------------------------------------------------------------------------------
Obtain the interim fixes
------------------------------------------------------------------------------------

The interim fixes are available on Fix Central:

Link to the first interim fix

Link to the second interim fix

Link to the third interim fix

----------------------------------------------------------------------------------
Pre-installation steps
----------------------------------------------------------------------------------

System requirements:

For the third interim fix, you must first install the MobileFirst interim fix, and you must install Android Build Tools 28.0.3 and Android SDK 28 platform tools.  You still run API 23 as a target.

A minimum of Oracle Java version 1.7 is required for iOS and Windows platforms.

Oracle Java 1.8 is required for Android.

Firebase Cloud Messaging (FCM) for push notifications on Android:

If you want to use Firebase Cloud Messaging (FCM) for push notifications on Android, follow steps 3 - 6 in the following article: Apply LAFIX to use FCM for Push Notification on Android device

Back up and record configurations:

Before proceeding, make a complete backup of the following folders. Default folder locations are provided below.

Maximo Admin Workstation: /IBM/SMP
Maximo Anywhere Build Server: /IBM/Anywhere

Also, make a complete backup of the Maximo database instance.

Check and record any custom WebSphere Application Server configurations, such as module bindings, virtual hosts, and environment property settings.

----------------------------------------------------------------------------------
Install the MobileFirst interim fix (IFIX)
----------------------------------------------------------------------------------

Install the MobileFirst interim fix (IFIX) from the following link by downloading MFPF-IF201903291256 

https://www-945.ibm.com/support/fixcentral/swg/downloadFixes?parent=ibm%2FOther%20software&product=ibm/Other+software/IBM+MobileFirst+Platform+Foundation&release=All&platform=All&function=fixId&fixids=7.1.0.0-MFPF-IF201903191506&includeRequisites=1&includeSupersedes=0&downloadMethod=http&login=true&login=true

Note: This version is required for FCM support on MobileFirst version 7.1 

Ensure that MobileFirst server is up and running.

1. Open Installation Manager

2. Go to the File menu, select Preferences, and add a new repository. 

3. Point the repository to the MobileFirst_Platform_Server\disk1\diskTag.inf file in the extracted IFIX folder. 

4. Click Update 

5. Select the MobileFirst Installation folder.

6. Click Next.

7. Click Next.

8. Accept the License agreement.

9. Click Update.

10. When the update has completed, open the Server Configuration Tool.

11. Select the Run time from top left hand corner.

12. From the Configurations menu, choose Upgrade a previous configuration.

13. Specify the passwords, and click OK.

14. Restart the MobileFirst server.

15. Open the MobileFirst Console, and open the About screen. The server version should be 7.1.0.00.20190329-1256

16. After you install the MobileFirst interim fix, back up your \IBM\Anywhere\MaximoAnywhere\libs\build directory.

17. Copy the following 3 files from the \IBM\MobileFirst_Platform_Server\WorklightServer directory, and paste them into the \IBM\Anywhere\MaximoAnywhere\libs\build directory:

• worklight-ant-builder.jar
• worklight-ant-deployer.jar
• worklight-jee-library.jar

----------------------------------------------------------------------------------

Install Android build tools 28.0.3 and Android SDK 28 platform tools, and run Android API 23 as a target 
----------------------------------------------------------------------------------

Windows:

Open SDK Manager.exe from c:\android-sdk directory and install android SDK build tools 28 and platform-tools 28

Mac:

Mac OS can be used as a build machine to generate .apk for android platform if android SDK has been installed

Open a terminal session and navigate to the /users/mayon/android-sdks/tools/bin directory

Enter ./sdkmanager --list command to show what has been installed

Output should show that the following have been installed:

Android SDK Build-Tools 23.0.3 

Android SDK Build-Tools 28.0.1

Android SDK Platform-Tools 28.0.2

Android API 23

----------------------------------------------------------------------------------
Update the IBM Maximo Asset Management environment
----------------------------------------------------------------------------------

1. Download and extract the oslcos_pmp_deploy_latest.zip and anywhereadmin_pmp_deploy_latest.zip files to the ../IBM/SMP/maximo directory.

2. Update the database and build and deploy the EAR file from the Tivoli's process automation suite configuration tool. Run the Update Database and Build and Deploy Application EAR Files option.

---------------------------------------------------------------------------------
Install the apps
---------------------------------------------------------------------------------

To install the apps, complete the following steps:

1. Download and extract the platform-Latest.delta.zip file to the install_home/MaximoAnywhere/platform directory.

2. On Windows and Linux, extract the MaximoAnywhere_7.6.3.latest.delta.zip file to the install_home/MaximoAnywhere directory. Overwrite the existing MaximoAnywhere directory.

For Mac OS x systems, extract the file to a different location. Do not use Finder to overwrite the existing MaximoAnywhere directory. Instead, in a terminal, use ditto and run the following command: ditto <from_folder> <destination_folder>.

3. Extract the MaximoAnywhere/build/config/app_artifacts_previous.zip file into the MaximoAnywhere/apps path.

4. Run the following command to upgrade your WorkExecution.xml file to the latest version:

ant -f app-sparse-xml-processor.xml upgrade-previous-release-app-artifacts

6. If you are building Android apps, update your build.properties property to specify the version of the Android SDK that you are using, for example, Android_TARGET_DEVICE_NAME=android-23. Also, you must download the same Android SDK in your Android SDK Manager. Android 23 SDK is the minimum supported version for Android 7 apps. Otherwise, Android 21 SDK is the minimum supported version.

7. For Windows, run the following command:

build.cmd update-platform

For Mac OS X, run the following command:

./build.sh update-platform

8. Run the anywhere-rdfs-puller.xml file that is in the MaximoAnywhere directory.

9. For Windows, run the following command:

build.cmd all

For Mac OS X, run the following command:

./build.sh all

----------------------------------------------------------------------------------
Post-installation steps
----------------------------------------------------------------------------------

If you have customized your Maximo Object Structures rerun the OSLC RDF Puller to pull the latest OSLC RDF documents:

https://www.ibm.com/support/knowledgecenter/SSPJLC_7.6.3/com.ibm.si.mpl.doc/integration/t_import_resource_data.html

Reapply any changes you might have made to the app-feature.properties file to reenable any custom properties you might have changed.

Verifying that your local customizations still exist:

Run a comparison tool like Beyond Compare to compare your backed up directory to the newly updated one.

Verify that any (class files, device native code or javascript) customizations you have made are still in place, and reapply them if not.

Verify that your app.xml file changes are still there.

Verify that the bundleids in your application-description.xml file are correct.

Verify that any custom WebSphere Application Server configurations, such as module bindings, virtual hosts, and environment property settings are still there.

If you have customized the logos on the login screen or any of the platform XML files, you must manually reapply those changes.

----------------------------------------------------------------------------------
Resolved issues
----------------------------------------------------------------------------------

The following issues are resolved in the Maximo Anywhere 7.6.3 interim fixes:

First interim fix:

IJ03970 COMPLETED WORKORDERS NOT CLEARED FROM WORKLIST IF FINAL ACTION IS AN ERROR
IJ04305 BMXAA4214E REPORTING DOWNTIME ON MULTIPLE ASSETS & LOCATIONS
IJ06743 MANUAL KEY IN FROM DATE PICKER DOESN'T UPDATE DATE FIELD
IJ07714 MAXIMO ANYWHERE ISSUES AND RETURNS CREATING DUPLICATE TRANSACTIONS
IJ08275 NO PUSH NOTIFICATION SOUND ON IOS DEVICES running on IOS 10 and above

Second interim fix:

IJ11274   UNABLE TO CREATE WORK CENTER SERVICE REQUEST WHEN ENVIRONMENT HAS ANYWHERE
IJ07847 MAXIMO ANYWHERE PHYSICAL COUNTS APPLICATION ALLOWS RECOUNTS TO HAPPEN ON OBSOLETE ITEMS
IJ03352 ANYWHERE TRANSFERS APP CREATES DUPLICATE RECEIPTS OF THE SAME PURCHASE ORDER
IJ07518 CANNOT READ PROPERTY 'GETMETADATA' OF NULL WHEN UNDOING CHANGES TO A WORK ORDER CREATED WITH AN ERROR
IJ05616 THE LAST SPECIFICATIONS ON THE WORK ORDER ARE NOT RETAINING THE VALUE WHEN HITTING THE NEXT ARROW
IJ10682 ANYWHERE CELLULAR & WIFI CONNECTION SETTING PLACES DEVICE IN OFFLINE MODE OR WRONG STATE
IJ11174 MAXIMO ANYWHERE  WORK EXECUTION APP WORK ORDER SPECIFICAITON LOOKUP WON'T  BRING UP CORRECT DOMAIN TABLE CONTENT
IJ05819 CLASSIFICATION NUMERIC ATTRIBUTES CUTS DECIMALS TO 2 PLACES
IJ11540 UNABLE TO LOG IN TO MAXIMO ANYWHERE AFTER DEVICE\SERVER TIMEOUTOCCUR

Third interim fix:

IJ15005 - MAXIMO ANYWHERE HANGS ON LAUNCH SCREEN AFTER CHROME UPDATE 73
IJ15853 - AFTER APPLYING AN INTERIM FIX CONTAINING APAR IJ15005 THERE ARE SCROLLING ISSUES ON iOS DEVICES FOR MAXIMO ANYWHERE
IJ10628 - RETURNING FROM TASK DETAILS TO THE TASK LIST IN ANYWHERE WORK
IJ11540 - UNABLE TO LOG IN TO MAXIMO ANYWHERE AFTER DEVICE\SERVER TIMEOUT OCCURS
IJ11154 - AUTO-LOGOUT AND PERFORMANCE ISSUE IN LOW BANDWIDTH AREA
IJ14460 - ERROR HANDLING ISSUES ON NEW WORK ORDERS IN MAXIMO ANYWHERE
IJ14461 - DEFAULT VALUES DISPLAYED WHEN CREATING A NEW WORK ORDER IN WORK EXECUTION
IJ14055 - ANYWHERE WORK EXECUTION GREEN TIMER RESETS AFTER DOWNLOADING
IJ15606 - AFTER APPLYING FIX FOR IJ13998, WHEN NAVIGATING TO A DATA SHEET, THEN TO AN ASSET FUNCTION, AN ERROR MESSAGE APPEARS
IJ13998 - DATA SHEETS DO NOT SHOW UP ON RECORDS WHEN SELECTED IN OFFLINE
IJ11400 - BROKEN IMAGE DISPLAY FOR REFRESH WHEN WORK LIST UPDATE IS DONE
IJ03230 - INCORRECT PASSWORD SENDS MULTIPLE LOG IN REQUEST
IJ16052 - USER IS ABLE TO CLICK 'LOGIN' BUTTON TWICE IN ANYWHERE WORK
IJ08694 - VALIDATION REQUIRED WHEN RECEIVING SERVICES OR MATERIALS IN ISSUES & RECEIVING
IJ15676 - MOVING ASSET DOES NOT UPDATE THE LOCATION DESCRIPTION
IJ05430 - ASSET AUDIT LOCATION SEARCH FAILS OFFLINE
IJ15054 - ANYWHERE OFFLINE, MAPS: UNABLE TO CREATE REPLICA FOR A MAP WITH MORE THAN 60000 FEATURES
IJ16220 - UNABLE TO UPLOAD MAXIMO ANYWHERE APPLICATIONS TO GOOGLE PLAY
IJ14041 - THE MAP VIEW ON THE ANYWHERE WORK EXECUTION MAP IDENTIFY CONTROL IS NOT POSITIONING CORRECTLY

Maximo and LDAP - Configuration from Start to Finish

Maximo and LDAP - Configuration from Start to Finish

Body

Security is more important than ever, and securing applications is a priority to every company. Many clients ask for documentation on configuring Maximo for LDAP authentication. You end up having to review many different articles to address a single topic, so I've decided to lay out a basic LDAP configuration using WebSphere 7 and Maximo 7.5.0.5. This will walk through connecting WebSphere to your domain right down to the synchronization process and hopefully give a more clear understanding of the configuration process. For the purpose of this blog were going to discuss this configuration with Microsoft Active Directory (MSAD or AD). However these steps can be applied with Tivoli Directory Server (TDS) as well.

So, where do you start?

Your first thoughts should be who needs access to Maximo and how are we going to filter just these users into the environment. For our purpose here, we're going to restrict all users by using the memberOf attribute, and make sure our Maximo users are members of a maximousers group that will be filtered on.

For a new Maximo implementation, we need three users to exist in the directory

maxadmin – default administrative user

maxreg – default user registration security user

mxintadm – default integration framework user

If your environment is already running and your admin users have different IDs, you can replace the above with your own users as long as they are in the database and the LOGINID from your database matches the Common Name (CN) from the directory server. Add these users to your maximousers group along with the rest of your base Maximo users.

Now to get started with your configuration. When configuring Maximo for LDAP there are three parts.

1. Configure WebSphere to connect and authenticate against your directory server
2. Enable Maximo to authenticate logins with the Federated Repository, the user database maintained in WAS)
3. Configure Maximo to synchronize users from the Federated Repository configured in WebSphere which contains the users that are brought over from Active Directory.

Step 1: Configuring WebSphere

1. From the WebSphere Console, Expand Security in the left hand frame and click on Global Security. From the Global Security page choose Federated Repository as your available realm definitions and click configure.

     2. Once you click Configure you will be brought to the federated repositories page, this will show the current repositories configured with WebSphere. By   default the repository called InternalFileRepository will exist. This repository contains the wasadmin user and its group. For the purpose of this tutorial we are going to leave this intact so that the wasadmin DOES NOT need to be added to the directory server. Click on Manage Repositories to configure your realm.

Note – if wasadmin exists on your directory server you will need to remove the file-based realm or remove wasadmin from the realm.

3. From the Manage Repositories screen, click Add

4. Once you click add you will be brought to the properties page to configure your directory server. From the drop down menu, choose your directory type; here we chose Active Directory. Enter the hostname and port of your directory server and your principal user to make the connection between WebSphere and your directory. I created a user named “principal” for this purpose.

For Active Directory, we changed the login property to CN. This would be left as UID for TDS. Once done, click Apply and Save to the master configuration.

5. Once you have saved to the master configuration you will be brought back to the Manage Repositories screen that will show your newly created repository. From here head back to the main configuration screen for the repository by clicking on “Federated Repositories.”

6. Now we need to configure our base entries. This will be the container that WebSphere looks in on your directory for users and groups. You can configure multiple entries on this screen, but we are just going to point our realm to the top of the directory. To start click Add Base Entry to Realm.

7. From the Add Base Entry screen enter the DN you want WebSphere to look in, as mentioned earlier we are going to pull in the entire domain and filter at the Maximo level. So I've entered dc=mxeam13, dc=torolab, dc=ibm, dc=com for the top level of the domain. Once done click apply and save to your master configuration.

8. Once you have your Base entries configured you need to enable application security for WebSphere. You do this on the main Global Security page. Check 'Enable Application Security' and click on 'Set as current' so your Current Realm Definition becomes Federated Repositories. Then apply and save to the master configuration.

9. Now that your configuration is complete for WebSphere ,you will need to do a full node synchronization and restart your Deployment Manager (dmgr) and Node (nodeagent) Windows services before continuing to the Maximo configuration.
10. Once you have restarted your services, log into the WebSphere Console. On the left hand side, expand Users and Groups and click on Manage Users. Search for a known directory user to confirm that your configuration is correct

Step 2: Enabling Maximo authenticate against your directory server

Once WebSphere is configured for LDAP authentication we need to configure Maximo. This is done by enabling LDAP security in 4 XML files as well as the maximo.properties file or the maxpropvalue table.

1. The first XML file we will modify is the maximouiweb web.xml. By default, you will find it in \ibm\smp\maximo\applications\maximo\maximouiweb\webmodule\WEB-INF\web.xml.

We first want to search for the <security-constraint> tag and uncomment to the bottom of </login-config> as seen below:

2. In the same file search for useAppServerSecurity and change the value from false to 1 as seen below.

3. If you wish to keep the BASIC authentication method, you can now save the file. If you want Maximo to display the normal login screen, you will need to update the file to use FORM authentication, by commenting out the BASIC login config and uncommenting the FORM login-config. Text in green below is the commented-out section:

4. Repeat the above step without the the auth-method in the following 3 web.xml files – that is, uncomment the <security-constraint> sections and change useAppServerSecurity=1:

• IBM\SMP\maximo\applications\maximo\mboweb\webmodule\WEB-INF
• IBM\SMP\maximo\applications\maximo\meaweb\webmodule\WEB-INF
• IBM\SMP\maximo\applications\maximo\maxrestweb\webmodule\WEB-INF

5. Now that your web.xml files are configured for LDAP we need to update the maximo.properties or the maxpropvalue table for application security.

If you want to set this in the database you can update the value with the following statement in a SQL tool connected to your database as the schema owner (default maximo):

update maxpropvalue set propvalue='1' where propname='mxe.useAppServerSecurity'

If you want to set this in your maximo.properties you will need to add the line mxe.useAppServerSecurity=1 to the properties file and save it If choosing this method you will need to re-encrypt before building your ear.

See http://www.ibm.com/support/docview.wss?uid=swg21314942 for complete information on modifying maximo.properties.

6. Once your file changes are made you can rebuild and redeploy your ear files
7. Before starting your application, you need to map the security role to the group of users you wish to authenticate. Our users are part of the maximousers group, so we have already mapped that role. If you don't have a specific group, you may choose “All Authenticated in Applications realm” to give all authenticated directory users the ability to connect to Maximo.

To map your role from the WebSphere console, click on Enterprise Applications then on your Maximo ear. Under Detail properties click security role to user/group mapping. Then click Map Groups to map the groups your users are contained in.

3. Configure Maximo to synchronize users from your repository.

Our final step is to setup the VMMSYNC crontask to bring users in to Maximo from the directory server.

1. Open System Configuration - > Platform Configuration and click on Crontask Setup. From here filter for VMMSYNC.
2. Enter the principal user that can access the repository to bring users into Maximo as well as the password for this user in the credential field.

3. Once you credentials are setup, you can set up your group mapping to sync the groups you want into Maximo.

4. Between the <basedn></basedn> tags specify the path on your directory to where your groups reside. In our case it will be in the SWG OU, see the example below.

         <basedn>ou=SWG, dc=mxeam13, dc=torolab, dc=ibm, dc=com</basedn>

5. Next, we need to do the same for our users, however at the same time we will be just bringing in users that are members of the maximousers group.

        <basedn>ou=SWG, dc=mxeam13, dc=torolab, dc=ibm, dc=com</basedn>

        <filter>PersonAccount' and memberof='cn=maximousers, ou=SWG, ou=maximo groups, dc=torolab, dc=ibm, dc=com</filter>

6. Once these changes are done, activate your crontask and reload it's configuration. If you are having problems with the memberOf filter, it is likely because it doesn't exist as a property under the PersonAccount entity in the repository. You can add it using the instructions below

Adding the memberof to the PersonAccount entity to VMM

1) From IBM\WebSphere\AppServer\bin run wsadmin.bat

2) Once the wsadmin command line displays run the following command

$AdminTask addIdMgrPropertyToEntityTypes {-name memberof -dataType string -entityTypeNames PersonAccount}

-name : This value is the name of the attribute on the directory server, for this example it will be  memberof

-dataType  : This is the database for the field, in our case string

3) After running the command you will see that your attribute was successfully added

4) Synchronize your node and restart the services.

You synchronization will now be able to use memberof as a filter.

Maximo Anywhere and LDAP

Maximo Anywhere and LDAP

Body

I took a bit of a hiatus from blogging during the month of February being out for a large portion of it at the IBM Interconnect Conference. But I'm back in the full swing of things now and want to share a bit of knowledge on Authenticating to your LDAP secured Maximo environment. This may be common knowledge to some as it is documented by other means. However for those who haven't ventured into configuring Maximo Anywhere to authenticate with LDAP, you need not worry as there isn't much to it!

To get started we have one prerequisite and that's that your current Maximo environment is configured to authenticate users via LDAP. If you need more information on this please see my previous blog Maximo and LDAP - Configuration from Start to Finish. Now that Maximo is configured for LDAP, what else needs to be done to configure Maximo Anywhere to authenticate with LDAP? Unlike the LDAP blog above this will be short and sweet as we only have two modifications to make to achieve this functionality.

Configuring Maximo Anywhere to authenticate with LDAP

1. The first change to make is to your \ibm\smp\maximo\applications\maximo\maximouiweb\webmodule\web-inf\web.xml file. We want to search for security-constraint and along with the UI pages ensure the OSLC section of the constraint is not commented.

Once the comments are removed (if not already removed during your original LDAP implementation) rebuild and redeploy the maximo.ear file

2. The second step to take, is to modify the \ibm\AnywhereWorkManager\server\conf\worklight.properties file. Search the file for si.auth.type and change this to match the authentication method used by Maximo (defined in the web.xml).  So if your using normal Maximo authentication your property should remain 'maximo', if using form based ldap authentication change this to 'form' and if using basic authentication (network prompt), then set this to 'basic'. In our test we are using form authentication for LDAP on the base Maximo side, so we set this property to 'form'.

Once done, save the file, then finish up by running the build all command and then redeploy your worklight.war using the config tool. 

Now that everything is redeployed and started up, you should now be able to authenticate to your Maximo environment via the Maximo Anywhere application using your LDAP credentials.

That's all for now. As always, any questions, comments or concerns please post below.

Clearing WebSphere temporary file caches for Maximo Asset Management

This document shows the correct directories to delete to clear the WebSphere 7.0, 8.0, 8.5.5 and 9.0 Maximo application server cache.

Symptom

New changes, such as Fix Pack, Interim Fix Pack, LAFIX/hot fix or XML changes do not take effect after deploying a new maximo.ear file.

Resolving The Problem

Follow the steps below to clear the WebSphere application server cache when deploying the maximo.ear.
Add this procedure of clearing WebSphere cache every time you rebuild and redeploy the ear files.

---

Note: If you are not going to redeploy the MAXIMO.ear, skip steps 3 and 5 through 7.

1. Log into the WebSphere Integrated Solutions Console.

2. Shut down the Maximo application server (default name MXServer).

3. Under Applications > Application Types > WebSphere enterprise applications, select and uninstall the Maximo enterprise application (maximo.ear) completely.

4. Delete cached files from temp and wstemp and, optionally, logs directories:

Windows (where the WebSphere location is C:\Program Files\IBM\WebSphere\AppServer, the application server profile is called ctgAppSrv01, the node is called ctgNode01, and the Maximo server is called MXServer). *.* means contents of the named directory:

• C:\Program Files\IBM\WebSphere\AppServer\profiles\ctgAppSrv01\temp\ctgNode01\MXServer\*.*
  C:\Program Files\IBM\WebSphere\AppServer\profiles\ctgAppSrv01\wstemp\*.*
  (optional) C:\Program Files\IBM\WebSphere\AppServer\profiles\ctgAppSrv01\logs\MXServer\*.*

Unix (where the WebSphere location is /opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01, the application server profile is called ctgAppSrv01, the node is called ctgNode01, and the Maximo server is called MXServer). *.* means contents of the named directory:

• /opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/temp/ctgNode01/MXServer/*.*
  /opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/wstemp/*.*
  (optional) /opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/logs/MXServer/*.*

5. Delete MAXIMO.ear from /installedApps, both the contents of the directory and the directory itself:

Windows (locations as above):

• C:\Program Files\IBM\WebSphere\AppServer\profiles\ctgAppSrv01\installedApps\ctgCell01\MAXIMO.ear

Unix (locations as above):

• /opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/installedApps/ctgCell01/MAXIMO.ear

You do not need to delete MXIEHS.ear directory.

6. Deploy the Maximo enterprise application. If using LDAP server authentication, make sure that the security permissions are set as previously for the MAXIMO Enterprise Application.

7. Synchronize nodes. System Administration > Nodes, check the node to synchronize, then click the Synchronize button.
[Use Full resynchronize if you have made manual file edits on the node. Deploying a Maximo ear does not make manual file edits on the node, so it should not be necessary to use this function. Full synchronize can take a much longer to complete. If Synchronize fails immediately, manual synchronization will be necessary.]

8. Restart MXServer.

Note: In WebSphere 8.0 and 8.5.5 on Windows, the default installation directories may be in C:\Program Files (x86)\IBM rather than C:\Program Files\IBM.

See also the WebSphere Java SDK technote on how to clear the WebSphere class caches . Clearing the WAS class and OSGi caches may resolve class mismatch problems.

How to clear the WebSphere class caches

Problem

Instructions on clearing the java class caches in IBM WebSphere Application Server. Both the JVM's shared class cache and WebSphere Application Server's OSGi class cache.

Resolving The Problem

IBM Support may ask you to clear the class cache. There are several reasons for this. After an upgrade, it is possible that the class cache's are still holding onto previous versions of classes. It is also possible that the caches became corrupted.

Please remember there are two caches that will need to be cleared, the JVM's cache and the OSGi cache. The server has to be stopped before clearing the cache.

To clear the OSGi class cache:

• For UNIX platforms, run the following script in each profile:
  <WebSphere_HOME>/profiles/profile_name/bin/osgiCfgInit.sh
  
  For Windows platforms, run the following script in each profile:
  <WebSphere_HOME>\profiles\profile_name\bin\osgiCfgInit.bat

To clear the JVM's class cache (Linux, AIX, z/OS and Windows):

• For UNIX and z/OS platforms, run the following script:
  <WebSphere_HOME>/bin/clearClassCache.sh
  
  For Windows platforms, run the following script:
  <WebSphere_HOME>\bin\clearClassCache.bat
  
  And clear the following directory contents:
  <WinUsers_home>\Local Settings\ApplicationData\javasharedresources\
  
  where WinUsers_home is either C:\Documents and Settings\DefaultUser OR C:\Users depending on your current version of Windows.
  
  Please note:
  
  1. You should not delete the cache while any of the JVM's are running and using the cache. The server has to be stopped before clearing the cache.
  
  2. You must be logged in as the user who started WebSphere Application Server.
  
  3. For Windows the clearClassCache.bat may not work if you are using Windows Services. Please follow these steps:
  
  Clear the following directory contents:
  
  For Windows XP/Windows 2003:
  
  C:\Documents and Settings\DefaultUser\Local Settings\ ApplicationData\javasharedresources\
  
  For Window Vista/Windows 7/Windows 2008:
  
  C:\Users\[WSAS_User]\AppData\Local\javasharedresources\
   

       For Windows 2008/Windows 2012/Windows 2016:

       C:\Windows\System32\config\systemprofile\AppData\Local\javasharedresources
       or
       C:\Windows\SysWOW64\config\systemprofile\AppData\Local\javasharedresources