BookmarkSubscribeRSS Feed
Quartz | Level 8


We have 3 servers -  SASApp, SASAppBI and SASAppVA.  SASApp is for DI work, SASAppBI is for Enterprise Guide users and SASAppVA for Visual Analytics users.  The physical servers have been spec'd appropriately for the product set that is being used on each of them.  I have hidden the SASApp server from anyone other than an Administrator or Developer, however I am wanting to know if there is a way to only make SASAppBI available when users are in Enterprise Guide or Add in for Microsoft Office and SASAppVA available only when using Visual Analytics e.g. we don't want users running queries in Enterprise Guide on the SASAppVA server. Most users have access to both e-guide and VA so it won't work using security groups as I have done with the SASApp server.  Is there a way to hide a server based on the tool that is being used? 





Are you running on a SAS Grid? (Presumably so.) An inelegant solution I've used in the past is some AUTOEXEC code to test the &_CLIENTAPP macro and abort the SAS session if on SASVA.

However, I would also prefer not to see SASVA in the list of available EG servers.


Quartz | Level 8

Andrew - not that I'm aware of

Linus/Jaap - we want to make the same data available on both SASAppBI and SASAppVA but that they only run processes on SASAppBI in e-Guide and SASAppVA in Visual Analytics

Jaap - Good memory. I did previously work for a not for profit but have since moved on

Tourmaline | Level 20

Another way is to chose the proper assignment for your data.  I assume that most data used in SASAppVA is LASR data. Might not give you a 100% server segmentation but perhaps good enough?

Data never sleeps
Barite | Level 11

The best way is segregation at the data-content not the tools.  The data is more becoming to see as a really valuable business asset. Treat it that way!.
Tools are far less important and can change and should change continuously.

SAS-VA is build on the same kind of components and solutions as all other SAS product lines. Marvelous for integration and a win-win cooperation.

Not wanting integration is building a lot of incompatible technical solutions, easy to achieve by buying all tools of all suppliers in the market and than trying to exchange the data by SOA with messaging and file-transfer busses.

Going into a data-governance with roll base access on data your question will be an non-issue.

Tammy I remember I previous post. I think you starting situation was a non-profit only sas-base desktop approach.
Ah I see you change to a bigger company in the insurance/financial area. In that kind of environment you have those "Standard of Good Practice - Wikipedia, the free encyclopedia" as guidelines coming in and having a IMS with RBAC being set. At the same time a lot of internal battles are going on making work unnecessary complicated. 

---->-- ja karman --<-----
Barite | Level 11

Tammy, it makes sense to have one metadata server serving the VA work the BI classic one and the data-mining.That brings you at the same level of an AD security administration with Windows and RBAC.

The VA work (end users) are accessed by lasr-servers. You can define many of those. The simple bi work for less advanced users you can organize by SAS APP users on some compute servers. Putting that data and users  there. You can define many SAS APP servers as they are meant as applications data and code by SAS.

Those data miners can have their own SAS APP servers on dedicated compute servers. By that segregation you are needing groups to assign the users to all of these data segregated appservers. This approach is quite common.

There is a problem with special roles like a person doing bi work and administration. In that case a dual account is normally mandatory. That solves also the part of data administration with VA. Windows  admins are using that approach theirself but seeing SAS as something like excel do not make the association to do it similar with SAS.

I am wondering how you would go on to protect system resource usage and data security by trying to prohibit excel.

---->-- ja karman --<-----

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

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.

Discussion stats
  • 6 replies
  • 5 in conversation