Hi, You could try to specify the entire work folder location as an environment variable: -work "!USERSASWORK" ... and set USERSASWORK on a per-user basis. You might prefer to derive this in the WorkspaceServer_usermods.bat script. Will this requirement apply to other servers too, like stored process server, batch server etc.  If so, or you see the potential for other group-based customizations like different memory settings, library assignments, etc, then you might also consider creating multiple application servers and directing users to specific application servers via access controls that hide the ones they shouldn't use.  One group sees only SASApp1 whilst another group sees only SASApp2.  Each application server has its own config dir, scripts, shared formats, autocalls and so on. It allows considerable group level configuration/isolation but does come with greater management overhead so is not always appropriate, especially for simple differences that can be handled through things like environment variable customizations. Cheers Paul ... View more

To add to what both LinusH and SASKiwi have said, if your metadata server and application server machines don't share an authentication provider (e.g. AD, LDAP), and you only have local accounts, then you would need to create an account on both machines: an account on the metadata server machine so the user can be authenticated by the metadata server and an account on the application server machine so they can be authenticated by the object spawner to start a SAS process on that machine. With independent accounts on different machines the passwords could get out of sync, so to avoid this possibility and to avoid having to create accounts on the application server machine you could configure your standard workspace server for SAS Token Authentication. When configuring for SAS Token Authentication you provide the credentials for a service/proxy account (e.g. sassrv) that will be used to launch workspace server processes so the users don't have to have operating system accounts on the application server machine.  There is a downside to this in that all users will appear to the operating system as a single user (the service/proxy user) which will limit your flexibility in securing file system resources. Personally I would prefer to reconfigure the two UNIX servers to share an authentication provider (eg. AD or LDAP) and get the benefit of operating system identities without duplication of accounts, but I appreciate this is not always possible or easy. ... View more

Hi Carl, There's a great document about this in the Third-Party Software Reference and JBoss Application Server Documentation for SAS® 9.3 section of support.sas.com: Configuring the JBoss Application Server for Secure Sockets Layer and Client-Certificate Authentication on SAS® 9.3 Enterprise BI Server Web Applications It sounds like you just want One Way SSL-Authentication which is covered in the first part of the document.  The document also covers Two-Way SSL Authentication where, in addition to the server having an SSL certificate, the clients are also issued with individual SSL certificates for client authentication. I hope this helps. Cheers Paul ... View more

Hi Suresh, You can write a SAS program using the User Import Macros to do it if you can source the user information from somewhere. These SAS provided macros are usually used for synchronizing with Active Directory or LDAP, but the information can come from other places too (CSV, XML, database etc.) There is more information in the SAS 9.3 Intelligence Platform: Security Administration Guide in the User Import Macros appendix. Cheers Paul ... View more