The customer logs successfuly on LMS 3.1, but the Portal Home Page does not open. Instead comes the folowing error:
HTTP Status 404 - /cwportal/html/cwhp/cwhp.applications.do
type Status report
description The requested resource (/cwportal/html/cwhp/cwhp.applications.do)is not available
Solved! Go to Solution.
The platform is Windows under VmWare
When using /cwportal/c/portal the error is the following:
HTTP Status 500 -
type Exception report
description The server encountered an internal error () that prevented it from fulfilling this request.
note The full stack trace of the root cause is available in the Apache Tomcat/5.5.17 logs.
Post a screenshot of your Services control panel showing all of the CiscoWorks services. Post the output of the pdshow command and the output of pdreg -l Apache.
The customer is generating the screen shots. Meanwhile I want to inform that the applications are available by direct calling with the following links:
That's your problem. You have set all the services to Automatic startup. You must NEVER change the CiscoWorks service startup types unless instructed to do so by TAC.
Change all of the services back to Manual start except for CiscoWorks Daemon Manager, the tftp server, the rsh server, and the syslog server. Then reboot the server.
The customer has changed back to Manual start all services except for CiscoWorks Daemon Manager, the tftp server, the rsh server, and the syslog server and rebooted the server, but the problem is still the same, can not open the Portal Home Page.
After making the TAC procedure for a similar problem shown o thread: http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=Network%20Management&topicID=.ee71a02&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.2cc21958/16#selected_message
The original problem, Daemon Manager not starting occurred again. I found several erros on the attached file licenseCheck.log. The resetCasuser seems to recover, the Daemon Manager not starting. Any info about the errors on this log file?
It appears your license file is corrupt. But that would not affect Daemon Manager. If resetCasuser corrects the problem with Daemon Manager not starting, then someone is either changing casuser's password, or changing the access requirements. We typically see this when the server is part of a domain, and the domain policy keeps overwriting the policy setup by resetCasuser. Make sure no one is changing casuser's password or access rights.
The first complain of the customer was that after login the Portal page shown instead of the menus, this message for all applications: License Server/Daemon Manager is down. Please check license.log for more information. I asked them to run resetCasuser and set a password for casuser in acordance with the password policy. That made the Daemon start but then came the problem of the Portal Page not oppening even after correcting the services to start mannualy. After recovering the portal.* files after a TAC suggestion from that other thread everything went fine until yesterday. I dont think the license file is corrupted because after the resetCasuser it runs properly. I will ask them about any procedure that can be changing the casuser password or the file permissions.
The license file and resetCasuser have nothing to do with one another. If you can launch applications such as RME and Campus without a license error, then you're fine in that regard.
The problem is recurring. After resetCasuser the customer can start the Daemon Manager, but after some days it occurs again. The customer told me that there is no change of policy or change on the permissions.
Any log to look at?
Something is changing the policy or password. The customer may not be aware of it, but that is what is happening. Perhaps the server is part of a domain, and there are domain policies being pushed to it. Someone must be in charge of Windows administration, and can check what changes are being made to the SAM or security policy databases.
Is there a way to check the casuser permissions before running resetCasuser again? So we could convince the customer that something is being changed on the server/domain.
You can check the local security policy using the Local Security Policy administrator tool. The password cannot be checked.
OK, I have located the User Rights Assignment. I saw there is a way to export on a text file the settings of the User Rights Assignment.
Would you mind checking it if I post it here?
Thanks. From the customer exported file I saw there is no information for casuser user nor casusers group policies in place like yours.
So the question:
1 - Does the resetCasuser correct this and right after the UserRightsAssignment exported file will show the policies in place?
The customer needs a way to investigate with the server Administrator what is going on and make sure the casuser/casusers will not be changed any more