Hostname Change for WebSphere 7+

Hello, this post is also about WebSphere. As you may prolly know WebSphere family is a `hostname dependent`, uhmm let's say, architecture. If you want to migrate your server or even take a clone of the OS and sysprep it and start it, you are going to need some extra steps to start Websphere correctly. Even many cases without below steps you may not be able to start even Deployment Manager. Frankly the errors WebSphere generate are also no help at all, messy and confusing. So doing as below will save you a lot of trouble.

Let's assume you successfully migrated your server (or clone etc...), everything is in order and starting WebSphere is the next thing in place. Great! As you are aware since we cannot start DMGR and wsadmin.sh connects to DMGR upon initialized we are in a little bit trouble. We need to start wsadmin.sh without connecting, fortunately IBM thought a parameter to do so. In some cases this parameter is unnecessary, cause if it cannot connect to an active DMGR it simply goes offline mode, this is exactly what we need but most of the cases it will give and error and you are not going to be able to do anything with it. So let's be safe and use the parameter. Start the wsadmin.sh under the bin directory of DMGR profile like below;

./wsadmin.sh -conntype NONE -lang jython

After this we have 2 choices to change the hostname config of the DMGR. An interactive one and a automated silent one. Let's do the interactive one. You can easily automate the process if you write some python code. Type the below command to start interactive mode;

AdminTask.changeHostName ('[-interactive]')

*Node Name (nodeName):

type the nodeName of the DMGR node. Usually people use dmgr01 or something like that. Type it an press enter.

*Host Name (hostName):

Type the new hostname. This hostname should be pingable from the machine you are working on. So if there is a dns suffix or anything type it as it should be.

System Name (systemName):

Type the name of the cell that the DMGR manages.

Regenerate Certificates (regenDefaultCert):

Just press enter. This'll generate the cell and node certificates so the dmgr and nodes can talk to each other securely as before. It is at this point an unavoidable thing to do in fact. You can change them later if your company's internal security dictates or anything like that. Anyways press enter and let it renew them.

After that, it'll ask to finish or cancel it;

Select [F, C]: [F] F

Finish is the default answer. Just press enter or type F and press enter. It'll give the wsadmin command line back. We should save our new config;

AdminConfig.save()

After saving the config we can exit.

At this point our DMGR is in working order once again. But if we have any other node on this machine, we should change their hostnames too... Let's start wsadmin.sh the same way and start the interactive way and change the hostname for the other node. Below the commands and an example;

AdminTask.changeHostName ('[-interactive]')

*Node Name (nodeName): AppServerNode01
*Host Name (hostName): newhostnameoftheserver
System Name (systemName): wascell
Regenerate Certificates (regenDefaultCert):

Finish it and save the config just like we do for DMGR. Exit the wsadmin.sh for good and return to shell or command prompt.

We still have some work to do, as this is not enough; nodeAgent won't start if you try to do so. we need to manually sync the node, so node will know the new configuration and start correctly. Go to the profile's binary directory.

sh syncNode.sh DMGRHOST DMGRSOAPPORT

Type the username and the password if the console security is enabled. Let it sync itself. That's it, now the node agent should start normally and we are done.

PS: If you are doing all this when your original server is running, there is a probability that new dmgr connects to the old machine's working nodeagent. I know it is silly, just to be safe after all this just restart the dmgr and nodeagent one last time and you are done.

WebSphere Messaging Engine and Stuck Messages

Hi, in this post we are going to do some house keeping to WebSphere Messaging Engine. In some cases messages got stucked in committing or removing state (IBM calls them indoubt messages). When that happens, it is impossible to manage them via administration console.

Service Integration > Buses > xyzServiceBus > Messaging Engines > abcMEBus > Queue Points > queueA > Runtime > message > delete etc...

So we need to use wsadmin.sh and some commands. I always use the wsadmin.sh under the DMGR profile. So start the wsadmin.sh and connect to DMGR, type your username and password if your cell is secure. What we need first is to get the correct message id. Use below command;

$AdminControl invoke [$AdminControl queryNames type=SIBMessagingEngine,*] getPreparedTransactions

This will give us a very long string, expect something like

!V0FTRAAAACQAAAFC72342347HesQAAAAIAAj8tAnvvXi34ge4rh5tjhe4f43e3wov5krh54i-r62ZrKqTBuEAAAAAAA2AAABQu*x3rEAAAACAAI-LQJRGDRHDRGS7714qL*ZK432fw4r2eeIv6*tmayqkwbhAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAC

Did you get such an id? Good. Now we are going to use this id in another command.

$AdminControl invoke [$AdminControl queryNames type=SIBMessagingEngine,*] commitPreparedTransaction msgid

Do not use quoation or anything just paste the message id we got from previous command as a whole instead of where I wrote msgid in italic.

This will commit any stuck messages in any state, if this does not solve your problem we have another parameter for rolling back the message.

$AdminControl invoke [$AdminControl queryNames type=SIBMessagingEngine,*] rollbackPreparedTransaction msgid

This will rollback, but I usually don't need to use it, committing manually solves almost all stuck messages.

Have a nice debugging.