Can not open LMS 3.1 Portal Home Page

Answered Question
Jul 14th, 2009

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/

type Status report

message /cwportal/html/cwhp/

description The requested resource (/cwportal/html/cwhp/ not available

Apache Tomcat/5.5.17

I have this problem too.
0 votes
Correct Answer by Joe Clarke about 7 years 3 months ago

These are wrong. The casuser/casusers setting are missing. This is what they should be.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Joe Clarke Tue, 07/14/2009 - 11:04

On what platform is LMS running? If you manually go to /cwportal/c/portal does the portal come up?

rgomes Tue, 07/14/2009 - 11:42

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.


Apache Tomcat/5.5.17

Joe Clarke Tue, 07/14/2009 - 11:52

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.

Joe Clarke Tue, 07/14/2009 - 12:43

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.

rgomes Tue, 07/14/2009 - 13:07

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.

rgomes Mon, 07/20/2009 - 13:36

After making the TAC procedure for a similar problem shown o thread:

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?

Joe Clarke Mon, 07/20/2009 - 14:04

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.

rgomes Tue, 07/21/2009 - 04:02

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.

Joe Clarke Tue, 07/21/2009 - 07:54

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.

rgomes Thu, 07/30/2009 - 10:56

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?

Joe Clarke Thu, 07/30/2009 - 11:14

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.

rgomes Thu, 07/30/2009 - 11:19

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.

Joe Clarke Thu, 07/30/2009 - 11:30

You can check the local security policy using the Local Security Policy administrator tool. The password cannot be checked.

rgomes Thu, 07/30/2009 - 12:14

Please look the atachement and say if that is the place where I should check for policies that hurt the behavior of the casuser.

This screen shot is not from the actual server.

Joe Clarke Thu, 07/30/2009 - 12:19

The policies will be in this control panel, but under User Rights Assignment.

rgomes Thu, 07/30/2009 - 13:19

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?

Correct Answer
Joe Clarke Thu, 07/30/2009 - 16:47

These are wrong. The casuser/casusers setting are missing. This is what they should be.

rgomes Fri, 07/31/2009 - 06:05

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


This Discussion