Broken SAS web components

[aclegg]

Hi Community

I am a sysadmin in an environment that contains a SAS foundation server at 9.4M1 on Windows server, it is a single server deployment.  All web components on this server appear to be broken, all return a 503 service temporarily unavailable error e.g. http://hostname/SASAdmin or http://hostname:/SASContentServer

I have reviewed the logs in SAS\Config\Lev1\Web\Logs\SASServer1_1.  All of them have errors like this:

Caused by: java.lang.IllegalStateException: Unable to retrieve requested user, sastrust@saspw. Is one defined in the remote UserService with the required name?

I have confirmed that the sastrust@saspw user is valid and that wherever it is referenced in configuration files reflects the SAS002 encoded version of the password.

I have also tried running the SAS Deployment Manager to update passwords, this has a separate error.  I feel like this might be because all of the web apps are not running.  Are there any other areas I should be looking?

[JosvanderVelden]

Has anything changed in the environment that could impact session timeout, firewall or network communication?

[aclegg]

Nothing has changed, and from the logs it looks like it has been like this for quite some time

[gwootton]

Is the WIP database running?

[aclegg]

Hi - all services are running including "SAS [Config-Lev1] Web Infrastructure Platform Data Server", and the server has been rebooted many times with this issue persisting.  This is not affecting the day to day use of SAS at all as none of the web components are used by users, however it is preventing the SAS Migration Tool from running without error.

[aclegg]

What this did do is get me to check the logs from this pgsql database.  while it is running, any access is met with a log entry of 

WSTLOG: could not receive data from client: No connection could be made because the target machine actively refused it.

In addition I have noticed that sasadm@saspw gets locked out if the 2 web services (WIP, Webappserver) are restarted.  So I feel like sasadm@saspw could be the next thing to find configuration references to and check

[gwootton]

I agree this sounds like the sasadm@saspw password is incorrect somewhere, and should probably be reset using the SAS Deployment Manager.