I am trying to deploy SAS server license across the company.
I have a few questions and additional advice is welcome.
1. How to install client (in this EG)? Will the same server license link be sufficient?
2. Can some SAS projects executing in the Server be restricted to some users?
3. Can users be allocated certain hard disk space?
4. Can desktop license and server license be used in parallel? (both running EG on the desktop)?
Any quick reference guides online to roll out SAS to the organization with appropriate control?
Thanks in advance
1. EG has no license. Only the server(s) that EG connects to need a license.
2. Projects are files for EG, every user can make his own and name them any way they like, so your question makes no sense.
3. Yes. Look for the quota enforcing method for the system on which the SAS server is installed.
4. If you have a license for the server and another for the desktop, you can install SAS on the desktop where EG is installed and use it in EG as the "Local" server.
As I never accessed SAS on a Server, some of my questions may sound silly. Sorry about that. I would be obliged if you could answer a few more.
1. I understand that once SAS is installed on server anyone having access to server will be able to login and use the EG+other modules in the server. Correct me if I am wrong. But they will NOT be able to read the SAS data sets so produced in their PCs unless they have a desktop license as well? If they want to create SAS data sets, in the server, from excel files in their PCs, will they be able to do the same from server? Any particular SAS license required to import MS files into SAS server or does such feature come as a default with all SAS server licenses?
2. What I meant was, can users password protect the EG projects, tables, etc. they create on the server?
3. I have EG desktop license and will also soon have server access that has EG, OR & ETS. Could I use the EG on my machine to directly connect to server and exchange data between 2 programs, EG on desktop and OR on Server?
Thanking you in anticipation.
1. Enterprise Guide can read SAS datasets (.sas7bdat files) without a local SAS system on the desktop. All further processing needs to be done with a SAS system, but EG will implicitly do the transfer for you if that SAS system is on a remote server.
EG is very good at helping you import data from external sources into SAS datasets. To directly import Excel data on the server, you need the SAS/ACCESS to PC Files License. If you export the data from excel to a text-based format (.csv), you do not need a license beyond Base SAS at all.
2. SAS datasets can be password protected, but not EG project files or SAS programs (which are simple text files, most often with a .sas extension). To protect any data against improper access, you best use the tools of the operating system you work on (file permissions, umask of the users, etc)
3. EG is a non-licensed(!) Windows-based frontend for the SAS system, so it's only purpose is to communicate with a SAS system. Aside from displaying data, it can't do much on its own.
So I guess that by "EG desktop license" you actually mean a locally installed SAS system. EG can help you in transferring data between the platforms.
FYI, it is possible to password protect a SAS Enterprise Guide project which is like a zip file. This and some other aspects of security and SAS Enterprise Guide is described at http://support.sas.com/resources/papers/proceedings13/420-2013.pdf
1. EG license - agree answer.
2. The question only makes sense as interpreting that as needing a security model for all your data.
As all data is stored on the OS level you are well having a security method for this. Nothing new for Windows AD as that is common practice.
The problem with a SAS server installation is that is not conforming common known Windows policies.
With a Unix server that could be more though. The first hurdle is getting Unix accepted to be used like Windows for self-service free data analysis usage by endusers (Excel).
There are many Unix admins being limited to installing just a RDBMS a router a webservers handing over the work an handing over all the rest to the users of those tools.
Yep agree with Kurt (mostly we do) as the second reply no 2.
The assumption with this is you are going to use host level authentication and not using a shared account for all users.
Many default installations (using sassrv) however are doing that shared account approach as avoiding security guidelines / policies.
3. Quota on the OS level. For Windows well known, for Unix (!@#$) sorry couldn't keep polite.
It is the firt prereq of acceptance (free data analysis usage). The file-systems mount points give you a huge control at quota. For the /home (unix level) think on splitting that up in several when having many user groups. /home/<gprorg1>/<usr's> it is one level more than the default single level below /home. Also this will give you all control on data/quota at that level.
This one you should give attention. At a default Unix installation all is run and inhirited by one single process (object spawner) inheriting aal those settings and not the users registered one. (sasauth).
4. Server/local - agree answer
For #2, you also have the option of saving the project inside the SAS Content Server - this comes with some additional options for metadata security, but at the cost of it's not so trivial to just copy a project around and send to others or use against different server. But you could save it into a Shared Data folder, and setup the permissions how you want to allow only certain users to use it, but also share it. The help inside Enterprise Guide covers this somewhat in the 'Working with Projects - Saving and Closing a Project'
To save a new project to a SAS folder
Yep David, I know that option of storing data (DI) en EGP's in the content-server with metadata associations to that.
Still needing a security design in this case with folders in the metadata instead of folders at the OS level. It could be the same logic as the logic and requirements are the same (RBAC).
Why making is more difficult be building something different when there is something already in place. That only can result in conflicts in the organization.
Another more bothering question with that is how to fulfill the possible random restore requests by person accidently made a failure (overwriting the wrong egp).
I did not find an easy way to restore just one object from the last (which one metadata or content server?) backup. Do you have that one somewhere?
Of course when there are too many obstructions by not cooperative people (IT OS level support at business) at the OS level you have to store it at the metadata as only left option.
It would be great to get more support from SAS getting those people (IT OS level guys at business) getting more cooperative in using SAS.
To make it more complete: http://blogs.sas.com/content/sasdummy/2014/10/12/eg-71-new-programmer-features/
"For programs that are embedded in the EGP, the Git history is also part of the EGP file. So yes -- back up those files! "
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.