Troubleshooting the SAS Server Tier

The following table lists some SAS server-tier errors and what to do to resolve them.
Troubleshooting the SAS Server Tier
Error
Explanation
Resolution
When you attempt to run a SAS server for the first time, you receive an error message about the IOMServerAppender not finding a location for storing temporary utility files.
There is no temporary directory defined on the host machine's operating system.
Use the method appropriate for the server machine's operating system to define a temp directory. For more information, see IOMServerAppender in SAS Logging: Configuration and Programming Reference.
Pooled workspace server fails to start during the configuration of SAS Web Infrastructure Platform.
On Windows, the SAS installer might not have domain-qualified the SAS Spawned Servers user account (sassrv). This account is entered as a login in the SAS General Servers group, so it is required to have a domain prefix as are all Windows logins. Without domain qualifying the login, connections by this account become PUBLIC connections. By default, PUBLIC users cannot access the repository, which prevents the pooled workspace server from launching successfully.
On UNIX, there might be a problem with the host name value returned by TCP.
On Windows, using SAS Management Console, edit the login associated with the SAS General Servers group and add a domain to it (for example: myhost\sassrv). You can edit logins in the Plug-ins tab of SAS Management Console (User Manager then selectSAS General Serversthen selectAccounts then selectEdit).
On UNIX, modify /etc/hosts or use the -hostknownby option. For more information, see General Options in SAS Intelligence Platform: Application Server Administration Guide.
You cannot validate the logical workspace server from SAS Management Console (SASApp) using the Server Manager plug-in.
By default, the unrestricted user is a SAS internal account. The workspace server needs an operating system user account and an identity in metadata to be able to authenticate itself to the machine on which it runs.
Re-try the validation from SAS Management Console. You should be prompted for user account credentials. Enter credentials for a user account that the workspace server can authenticate and that has (on Windows) the Log in as a batch job user rights. One account that meets these requirements is the SAS Spawned Servers account (sassrv).
After you have updated the user's credentials to allow access, you are denied access when trying to connect to or validate a server or spawner.
The credentials cache must be cleared before you try to connect or validate again.
To clear the credentials cache, in SAS Management Console, click Filethen selectClear Credentials Cache.
If the object spawner denies access to a server because of the lack of ReadMetadata permissions, and the user is then granted the needed permission, you must reset the object spawner's authorization cache before the user tries to connect again. To do so, expand the Server Manager tree in SAS Management Console. Next, expand the object spawner, right-click the host node, and choose Connect in the pop-up menu. After you have connected, right-click the host node again, and choose Refresh Spawner in the pop-up menu.
Unable to start a pooled workspace server and unable to start a stored process server.
Most likely, something is wrong with the object spawner.
The metadata server might not be able to authenticate the object spawner.
Make sure that the object spawner is running. For more information, see Operating Your Servers in SAS Intelligence Platform: System Administration Guide.
If you cannot start the object spawner, make sure that the metadata server is running.
Check the log for the object spawner and determine whether the spawner is able to find the server's definition. For more information, see Using SAS Management Console to Monitor SAS Servers in SAS Intelligence Platform: System Administration Guide. Also check the event log on Windows or the syslog on UNIX or z/OS.
You can correct the credentials used to authenticate the spawner in the SAS-configuration-directory/ObjectSpawner/metadataConfig.xml file, or reconfigure the spawner using the SAS deployment tools. For more information, see Overview of Managing Your SAS Deployment.
Make sure that no one has assigned user admin capabilities to the SAS Trusted User account (sastrust@saspw, by default).
On UNIX, check the Object Spawner log just after it starts for an entry similar to: Objspawn is executing on host machine.name.domain.com (10.101.0.98). If you see something similar to: Objspawn is executing on host localhost (127.0.0.1) or, if you see a host name that you cannot ping from a remote machine, you might need to replace the -dnsMatch option with the -hostknownby option. Refer to the following SAS Note: http://support.sas.com/kb/42/905.html.
You cannot start your SAS server.
The file sas.servers might not be automatically generated. This does not imply any issue with your configuration and does not indicate something is wrong.
Generate the sas.servers file manually by running SAS-configuration-directory/data/SAS/BIServer/Levn/generate_boot_scripts.sh. For more information, see Using the sas.servers Script on UNIX or z/OS to Start or Stop All Servers in SAS Intelligence Platform: System Administration Guide.
You see an error message about the location of the JUnit JAR file not being specified for SAS Deployment Tester.
The SAS Deployment Tester tests other products that use JUnit for validation. Without JUnit, these products might operate properly, but you will not be able to validate them using the SAS Deployment Tester.
On Windows, The JUnit JAR is available from the Third-Party Software Downloads site at: http://support.sas.com/resources/thirdpartysupport/v93/othersw.html#tab_junit. Place the JUnit JAR in this location: C:\junit3.8.1\junit.jar.
On UNIX, modify provider.config in SAS-configuration-directory/Lev1/DeploymentTesterServer/Config and update the ReadOnlyVar._junitJar parameter (for example, ReadOnlyVar._junitJar=/apps/sas/third_party/junit/junit4.8.1/junit-4.8.1.jar).
A Deployment Tester error message in the Windows Event Viewer reads: 
System error 1067
The Deployment Tester cannot start because it is configured to run as a Windows Local Service instead of a Local System account.
The workaround is to use the Windows Services snap-in to change the Deployment Tester Service logon from LocalService to LocalSystem. For more information, see http://tsdsrv05.unx.sas.com:7777/iw/docs/sasnotes/fusion/35/418.html.
Copyright © SAS Institute Inc. All rights reserved.