 |
|
| Troubleshooting Your Initial SAS 9.2 Deployment |
Troubleshooting the SAS Server Tier
The following table lists some SAS server-tier errors and what to do to resolve them.
| 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 Usage and Best Practices in SAS Logging: Configuration and Programming Reference. |
| Pooled workspace server fails to start during the configuration of SAS Shared Services. | One cause for this problem on Windows is that during installation, the SAS installer did not domain qualify 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. |
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 tab of SAS Management
Console (User Manager ![[arrow]](../../../../common/63294/HTML/default/images/arrow.gif){kind=icon} SAS General
Servers Accounts Edit). |
| You cannot validate the logical workspace server from SAS Management Console 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 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 File Clear 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 the
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 the 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). |
| 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 the 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. |
The JUnit JAR is available from the Third-Party Software Downloads site
at http://support.sas.com/resources/thirdpartysupport/v92.
Place the JUnit JAR in this location:
|
|
|
Copyright © 2011 by SAS Institute Inc., Cary, NC, USA. All rights reserved.