<I am currently posting this for our beginning SAS administrator over here.>
I need to move the sasuser location from a local drive on the SAS server to a network share on another server. We are running out of space on the SAS server. I understand that I need to make changes to –SASUSER path in the SASV9.CFG file but I have questions about what access permissions/user accounts that would need to be setup so the SAS server can access to the files when they are on a different server.
My thinking is I would need to change the SAS windows service accounts from “local system” to a domain user with admin access (we are using Windows AD) to the SAS server and then give that user access to the share. Am I correct?
If so which service account/s do I need to change? There are about 10 SAS related ones.
Thank you very much.
The access permissions on the SASUSER folder depend whether it is a writable or Read-Only SASUSER Library. This behaviour is controlled with the RSASUSER option.
If the SASUSER is Read Only, I don't think you need to move it somewhere else since - under normal circumstances - it won't store more than a few KBytes.
Usually, there are two system accounts used for your SAS platform : sas installation and binary owner (login 'sas') and sas session account under which the sessions are launched -
and access SASHELP or SASUSER libraries - is the login named "<DOMAIN>\sassrv" shared in metadata through the SAS General Server group (SAS Management Console / User Plugins )
=> DOMAIN\sassrv must have at least Read permission on SASUSER folder path.
If your SAS Window services are launched with LOCAL System account, well, that might not be100% safe but I am not sure a modification would be necessary to accomodate a change
of folder path for SASUSER. Local system just retrieves in SAS Metadata the SASSRV credentials then "spawns" a new SAS session (child process) running with SASSRV.
Be aware that the "Log on as batch job" Privilege is required for SASSRV.
RSASUSER /* Read Only SASUSER*/
NORSASUSER /* writable SASUSER*/
Your request doesn't make sense.
The sasuser is the personal home location used for some global settings. This storage location is normally closed within an EI SAS deployment, users cannot store data there. When using Eguide it is possible to store data in the user profile location (home). This location is normally on a desktop a roaming profile that is copied to a central storage location and back. The whole thing is the used space should be kept as small as possible. When not educate and guide the users to store data in a shared location (application or organization structured). As there is a strong dependency you should keep these on the same same machine as that run sas-processes. e
Let us assume you meant to store userdata (application or organization structured) to be used on different servers in the same Windows domain.
The you need a trust to an ohter server as this machine where the sas processes need resources on another. See: SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition. It is the spawners account that needs that setting. The by SAS documented approach is having the local system account getting those trusts. I expect that gets block by compliancy reasons and you will needing a dedicated account for that. The local system account is designed to be local not a domain user.
Doe me remember the local system account is rather restricted as you cannot get Windows admin rights (privilege escalation needed) with that.
Thank you to both Jaap & Ronan for your suggestions and responses. The person who is acting as our administrator is out for today. So I thought I would take the opportunity to specify the exact issue I am up against.
Background: I have been hard-core using SAS for a little over one year now. Previously I had tinkered with changing macros and running basic processes. But now I am "in the game" and enjoying it. A few months ago I performed some very memory intensive proc sqls for my work. Some of the procedures took around eight hours to run overnight. When we purchased SAS we did so in a way that it resides on its own server. So we purchased a new server to go with it as well. We worked with an agency that was going to act as our SAS administrator for the purposes of installation and technical support. We do not have a full time IT-specialist devoted to SAS administration over here. But I am working with one of my fellow co-workers who speaks the IT nomenclature- at least much better than I ever could.
We are now faced with a situation where I do not fully know or understand our status with the company that originally was to provide administrative support. This is due to varying circumstances. People I report to have suggested that both I and the IT support person work directly with SAS in figuring things out, but I am not entirely sure if we will inevitably have to partner with someone or an organization that would provide full support.
Back onto the issue of "full support..." We currently have a few tasks ahead of us. One is regarding the issue I originally wrote this e-mail about. We also are in the beginning stages of two other initiatives: (1) figure how to build a system of Disaster Recovery (DR) for testing our updates, and (2) Start updating our SAS versions - we have not done anything of this sort in a year.
And back onto the immediate issue... The SAS server we use here has the program installed on it. We also have our data files and syntax files stored on this server as well.
This is for both Enterprise Guide as well as Enterprise Miner. I think we are starting to get a decent handle on defining libraries within our Management Console instead of via syntax.
When the SAS Server was created it was somehow partitioned to have data files stored in part of it and other types of files (maybe code or installed software & drivers, etc.) stored in another partition. When I first ran my program it very much spiked in using hard-disk space in the middle of the night for creating temporary files, so ultimately it did not run. So my handy IT-person was able to adjust the partition so that 80% was devoted to data rather than 50% - or something like that. The program ran, and it provided good/useful results, but we do not believe this is a good long-term solution. Rather than having the data files be stored on the SAS Server our thinking was why don't we store our data files (both temporary & permanent) on our regular company servers where we have more than enough space and procedures for backing things up already in place. I feel confident that this is probably easy to do, and probably the right thing to do, but... that is why I am writing into Communities.
Maybe the ultimate solution is to add physical memory to the SAS Server, but what do I know?
Thank you very much in advance for your help. And I am very open to any suggestions that anyone has regarding how to do things correctly and efficiently.
Zachary, Doing things correctly should be defined more clear as there are many different players with different interests in this game.
1/ Your business goals with the internal business sponsor. This is the where the ROI/TCO must be done.
The BIA Business Impact Analyses at this area will make the requirements for the Confidentiality Integrity Availability (CIA) classifications that will lead to the IT implementations and specifications of the SAS installation. This is the theoretical approach, you have started with an installation and now trying to correct what is done to now known specifications.
2/ There is some in house IT department that is delivering IT that as some service (desktops applications Windows servers AD etc). These guys are important as when you are not aligned with them you will come into nasty troubles in the short or long term. The bad start is the were not involved from the beginning. The good is they have let you do al lot on you own and you someone talking their language. The common misalignment between IT departments and business is these days temporary overruled by the devops strategy. I don not know what your position is in your organization just make your plan with that.
3/ External suppliers like SAS or a fulltime external admin. They are commonly not aligned with your business goals they have their own.
Let me start with your Installation verification (renewal updates/fixes) and a DR machine. There should be something noted about that in you contract with SAS when it is machine based. When it is user based that could be little bit different. You will need 2 other machines from your internal IT department for that. The DR can be a cold standby, the Inst/verify machine must be up and running continuously as long as you are working on that. According to European law http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32009L0024&from=EN (article 6) there should be no need for additional costly sas licenses for those additional machines. You need to mention those to sas. It can be sas is claiming following those laws is illegal and wanted to be paid for those. There is your fist challenge to get tackled.
Having those additional machines you have to achieve:
a/ operational machine -> DR -machine (image to be copied) will that run in your business DR policies
Question: what about the more easy backup/restore issues?
b/ installation/verification -> operational machine (image to be copied fall-back scenario to be verified).
Question: would you think a redeploy of an image or a manually build new system by instructions (sdw) is the way to go?
The other is your performance and hardware design setup question.
You have seen that SAS is very IO intensive. The best thing is to optimize that IO. That is using internal hardware like SSD's top be used for SASWORK and having all data local on that machine. As network connections are always much slower they should be avoided. The SAN's however have the advantage of good availability (backup restore).
Check the papers on performance by M.Crevar like http://blogs.sas.com/content/sgf/2014/10/08/configuring-sas-what-to-know-before-you-install/
As you are Eminer I am little surprised by your focus on using SMC for libnames. Eminer does not benefit from that very well.
The SMC is hiding the libname and possible other options on you system. Your time could be better invested on those parts of tuning your system and getting to know how to optimize resource usage and/or appropriate algorithmes.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.
Find more tutorials on the SAS Users YouTube channel.