Fixing an invalid Bind account

We have been going through a bunch of password changes and mistakenly change the password on a account in one environment that broke another environment. One of the things I learned (other then never reuse accounts ! ) was that when the bind account is invalid, even the wasadmin account will not be able to access the console. The environment we were working in was development and needing a fix I tried to edit the profiles\Dmgr01\config\cells\Cell01\wim\config\wimconfig.xml and updated the value for bindPassword and the bind account to a value from another instance .  What made this interesting was the fact that I was able to use a encrypted password from a WebSphere 6.1 environment in a WebSphere 7.0 environment. I was also able to update the bind password value with a clear text copy, allowing me access to the console. After I entered the console I went to
Secure administration, applications, and infrastructure > Federated repositories > repository
 and was then able to re encrypt the password by reentering it in the bind password box, clicking apply and then save.

WebSphere System Management & Config

My study notes from the following redbook

System Management Overview
    Terminology

• Stand-alone server environment refers to a single server environment that is not managed as part of a cell. This is your only option for base and express version of WebSphere but Network Deployment can be configured as a stand-alone server. 
• Distributed server environment refers to a environment that has multiple servers that are managed by a deployment manger in the cell. 
• Manage Process refers to deployment manager nodes (and node agents) and application servers. 

Stand-alone Single Server

 Distributed Server Environment 

Java Management Extensions (JMX)

   WebSphere system management functions are based on JMX a standard way to expose management objects. JMX  

  

SECJ0305I Error, Node Agent not Running

This morning I got to work and learned that one of our node agents was not running. What made this unique was that the node agent in question was running on a virtual machine that had recently been moved from one data center to another, across town changing the IP address. After checking the node agent's System.out  I determined that the last time the server been restated the node agent had started successfully.

WSVR0001I: Server nodeagent open for e-business

Puzzled at this point I pinged all three servers from each server and got a reply every time. I then restarted the windows service that was running the node agent and it failed to restart. Looking into the log I discovered a new error stack that started with a

CWWIM4512E The password match failed.

and ended with

SECJ0305I: The role-based authorization check failed for admin-authz operation

I did some goggling and found this tech note from IBM that recommends "restart(ing) the deployment manager, node agents, and servers." This resolved the original issue where the node agent showed as not running but when I tried to restart the node agent service to show what I had done to a peer I got the same error but the node agent status never changed from running in the Deployment manager  : (  I will post a follow up to this issue at a later date (when it is worked out).

Growing access.logs for IBM HTTP Server

While working on some performance issues in Prd we discovered that our web server access.logs were in excess of 2GB and still growing strong. After some research we decided it was time to implement piped logs . We first tried to edit the httpd.conf file for the web server through the WebSphere admin console. We replaced the following 

CustomLog logs/access.log common

with

CustomLog "|bin/rotatelogs logs/access.%Y.%m.%d 86400" common 

Stopped the web server , tried to start it and after a 30 sec pause we got a msg back saying that the web server could not be started. Further research into the log files for the deployment manager and web server did not shed any light on why. After some digging on IBM's support site I found this technote explaining that the full path must be specified. I replaced the above with this, (adjusting the formatting to better fit our needs) and the server started without issue and our log files were now rolling on a 24hr bases.

CustomLog "|C:/IBM/HTTPServer/bin/rotatelogs.exe -l C:/IBM/HTTPServer/logs/access-%a-%m-%d-%Y.log 86400" common 

Maximo 7.5.0.2 and WebSphere 8

We are in the process of setting up Maximo 7.5.0.2 and recently my lead ran across this link from IBM that outlines how to do just that but with WebSphere 8 as the middleware. Currently we have Maximo 7.5 set up with WebSphere 7 but are evaluating upgrading WebSphere to 8. This tech journal from IBM outlines some interesting points on why this might be a good idea. The one that I found the most interesting was the modification to the addnode command providing an add existing option.

Node recovery

A new optional argument for the addNode command, asExisitingNode, makes it easier to move or recover nodes. When this command argument is used, the node is added using the configuration from the Deployment Manager for that node. As a result, a node can be easily moved to a new server and, if need be, there are provisions for changing the host name during this process. In the case of a hardware failure, the node can be easily recovered back to the last configuration reflected in the cell configuration maintained by the Deployment Manager. These two scenarios are depicted in Figure 5.

When in Dought Encrypt It !

Recently I ran into trouble getting two Maximo environments up one 7.1 and the other 7.5.  We got several different errors and none pointed us in a single direction. After working with IBM we identified one important step that we were missing, running the encryptproperties.bat . This is required with any change to the Maximo property file on all 7.x versions of Maximo.

 http://www-01.ibm.com/support/docview.wss?uid=swg21314942 

Here are some of the errors we got

• BMXAA6539E - Failed to initialize the MAXIMOStartupServlet 
• WSVR0209E: Unable to start EJB jar mboejb.jar
• java.lang.NoClassDefFoundError: psdi.iface.jms.JMSListenerBean
• WSVR0100W: An error occurred initializing, MAXIMO
• WAE0008E An error occurred reading mbojava.jar

Another anomaly that will be researched further had to do with the sequence required to get past the errors above.

1. Deploy and Start the app to the App Server/ Cluster - Expect Class loading WSVVR like error 
2. Stop App Server / Cluster
3. Start App Server / Cluster  - App should load pass the error in step 1.  

manageprofiles.bat doc

Great link that outlines the use of the manageprofiles command.