I needed to change the hostname and IP Address of the CiscoWorks server (LMS2.6).
As I dont have LMS V3 so I dont have the changehostname.pl script.
I followed a few threads and the cisco document on how to successfully change the hostname on our CW2k server. However, it hasnt worked and is a bit bizarre.
Whereas the Splash-screen and the main GUI (after login) shows the new_name, the various modules show the old_name.(e.g. Common Services [Old_name] etc).
Looking in each of the modules, e.g. Common Services, the menu item Server (in this case) points to the new_name, yet each option (Security, Reports, Admin and HomePage Admin) point to the old_name.
This happens in each of the modules.
In Common Services, the "Server" url points to https://new_name/cwhp/cwhp.applications.do#
If I look at the other modules, they each have similar issues.
If I click on one of the links, say "Security", it obviously times out because of the
old_name in the url, however if I change the url manually to new_name, this then works.
I thought that most things (processes) were running however looking at the CiscoWorks
processes in the GUI (Server->Admin->Processes) I see that the ANIServer and the
CTMJrmServer have never started.
Now going back to what I did to change the hostname, I followed a Cisco document on this as
Step1 & 2 - Change the hostname. (I am using Win2003 server)
Step3 - Search and replace Registry entries (old_name to new_name)
Step4 - Change hostname in regdaemon.xml
Step5 - Change hostname in web.xml
Step6 - Create changehostname.info file with the line old_name:new_name.
I put this at the top of the file with no spaces. I understand that this file is removed
when the services are restarted, however this didnt happen and the file remains.
Step7 - Delete gatekeeper.ior file. I did this and understood that this would be recreated,
however it didnt.
Step8 - I wasnt sure whether I needed to do this but I did it anyway and took me a few goes getting it to not throw up an error.
dbisql -c "uid=cmfDBA;pwd=<pwd>;eng=cmfEng;dbf=%NMSROOT%\databases\cmf\cmf.db" -q update PIDM_app_device_map SET app_hostname='new_name' where app_hostname='old_name'
When I realised that I had to type the "where app_hostname='old_name' " as well, this finished without showing an error.
Step9 - Regenerate new certificate - I did this and checked the certificate using sslutil.pl in the Apache directory to confirm the name.
So apart from Step 6 and Step7, everything worked correctly, however the server does not work correctly.
Would any one have any ideas?
The CTMJrmServer problem can be fixed easily. In regedit, go to HKLM\SOFTWARE\Cisco\Resource Manager\CurrentVersion\Daemons\CTMJrmServer, and replace the old hostname with the new hostname in the Args property. Then restart Daemon Manager.
The CMIC problem with your application registrations may be less easy. The fact that the changegostname.info file was not deleted means CMIC never processed it. Make sure this file is owned by casuser, and contains the short hostname values, then restart Daemon Manager again
Thanks for your quick reply. I spotted the CTMJrmServer bit in one of your earlier replies to others and so had already done this.
-cw d:\PROGRA~1\CSCOpx -cw:jre lib/jre -cp:p MDC/tomcat/webapps/rme/WEB-INF/classes;MDC/tomcat/webapps/rme/WEB-INF/lib/ctm.jar;MDC/tomcat/webapps/rme/WEB-INF/lib/log4j.jar com.cisco.nm.rmeng.jrmwrapper.server.CTMJobManagerServer NEW_NAME
(not sure if there needs to be a space after the name - I believe that what I have is correct).
I checked the security privileges of the .info file and they allowed the group casusers, containing user, casuser.
I have now changed the owner to the .info file to group, casusers. I didnt change the owner of the holding directories tho.
Changed the case of the names in the .info file to Uppercase.
Restarted. The .info file still remains, however now, I am getting duplicate applications on the main GUI.
So Common Services is duplicated, one being called "Common Services" and the other being called "Common Services [Old_name]". This is repeated for all apps.
However, the one which just says "Common Services" has the correct URLs pointing to the new server name.
The only problem now is that the ANI Server refuses to start as does the CTMJrmServer. Both say "Never Started".
The CTMJrmServer line looks right. You can also simply delete the duplicate applications from Common Servers > Server > Homepage Admin.
As for the daemons not starting, please post the output of the pdshow command.
Looks like the deregistering the apps isn't working.
"Problem with File /WEB-INF/screens/cmic/Application_Registration/Registered_Applications.jsp!!!Cannot find bean applicationList in scope null "
Have attached PDSHOW as requested.
First, shut down Daemon Manager. Then make sure the PX_HOST property in NMSROOT\lib\classpath\md.properties is correct. Then, check NMSROOT\lib\vbroker\gatekeeper.cfg to make sure the IP addresses in this file (if any) are correct. Then delete everything under NMSROOT\MDC\tomcat\work\Standalone\localhost. Then restart Daemon Manager.
Finally had chance to do the work.
You were right about the Gatekeeper.cfg file - thanks for that one.
I came across this file in a different version (when investigating dual-homing of a CiscoWorks server). I didnt think of this this time.
I deleted everything under the localhost.
I have now got all the processes working which is very good - I suspect that this was caused by the gatekeeper file issue.
I am not sure what impact the localhost directory had.
The only thing left now - although I have not tested everything - is to remove the references to the old server modules.
They are still duplicated.
Any ideas on this one as I am not sure how the web page is generated. Is it dynamic? or based on xml files?
The registered applications are stored in a binary data file. If the registration UI isn't working, there is a command line procedure available from TAC that will cleanup this data file, and re-register all of the installed applications.
Thanks for the info.
I guess I will have to raise a TAC? Or would this process be documented?
Thanks for your help. The server is now stable again.
You need to contact the TAC. The procedure is too complicated and error-prone to make publicly available.