SAS administrators

4月 172017
 

In this post, I will explain how LASR Servers (both Distributed and Non-distributed) are started from the SAS Visual Analytics Administrator application. We will also look at one particular issue and I will provide you with more details to understand the situation and two strategies to address this issue.

When you start a LASR Server from the Visual Analytics Administrator application, the system processes your request in slightly different ways depending on whether you are starting a distributed or non-distributed LASR Server.

What happens in the background for a distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the distributed LASR Server startup code generated in step 2, and the SAS Workspace Server session executes it.

6.     As soon as the distributed LASR Server startup code is executed, a distributed LASR Server instance is created. This instance is independent from the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection drop down. But the LASR Server instance is up and persistent until the administrator stops it.

What happens for a non-distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the non-distributed LASR Server startup code generated on step 2, and the SAS Workspace Server session executes it.

6.     As soon as the non-distributed LASR Server startup code is executed, a non-distributed LASR Server instance is created. This instance is dependent on the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection become persistent until the administrator stops the non-distributed LASR Server.
The SAS Workspace Server session and the client connection are required for the non-distributed LASR Server to be up and persistent.

Potential non-distributed LASR Server issue

The client connection between the JES and the SAS Workspace Server session in non-distributed deployment is crucial. This connection has to be persistent during the non-distributed LASR Server lifetime. As soon as the JES or SAS Workspace Server session goes down, the client connection is broken and the non-distributed LASR Server will go down as well. And, its data become unavailable.

If administrators manage their SAS non-distributed LASR Servers from the SAS Visual Analytics Administrator web application, this will create a dependency between the non-distributed LASR Servers and the middle tier - more specifically with the SASServer1_1 instance (the sas.wip.soapservices application). This dependency does not exist for distributed LASR Servers.

When the dependency exists, each time the middle tier or the SASServer1_1 instance is down, all non-distributed LASR Servers that were managed using the SAS Visual Analytics Administrator will go down automatically because the client connection to the non-distributed LASR Server is broken and its associated SAS Workspace Server session will go down.

This issue will also appear if the network connection between the Middle Tier and the SAS Visual Analytics Root Node is broken. This will break the client connection and terminate the SAS Workspace Server session(s) and their associated non-distributed LASR Server(s).

How can we prevent the issue?

I can think of at least two techniques you can use to prevent the dependency of your non-distributed LASR Servers upon your middle-tier:

  • Start your non-distributed LASR Servers from a SAS program.
  • Configure your LASR Server to start using the AutoLoad facility.

Start your non-distributed LASR Server from a SAS program

Here is a sample program that you might use to start a non-distributed LASR Server:

/* Start the LASR Analytic Server by defining the LASR library*/
libname LASRLIB SASIOLA 
        startserver  host="sasserver01.race.sas.com" port=10013
        signer="sasserver05.race.sas.com:7980/SASLASRAuthorization";
 
/* Keep the SAS session up until SERVERTERM received */
proc vasmp;
   serverwait  port=10013;
quit;

 

This program could be scheduled or set as a service under UNIX or Windows to be executed as soon as SAS Visual Analytics is started/restarted. Whichever strategy you use, you will want to have the code run after these services are up and available:

The SAS Metadata Server.
The Object Spawner on the SAS Visual Analytics Root Node.
The SASLASRAuthaurization service on the Middle Tier:

Start the non-distributed LASR Server Using the AutoLoad capability

AutoLoad runs as a periodic scheduled task. In the standard configuration, a new run of AutoLoad is started every 15 minutes.
AutoLoad periodically scans the contents of a designated host directory, which is referred to as the AutoLoad data directory or drop zone.
AutoLoad will automatically start the associated SAS LASR Server, if it is not yet started.

If you do not already have a LASR library configured with AutoLoad, you will need to use the SAS Deployment Manager application to configure an AutoLoad directory.

In Administration Tasks, choose Configure an AutoLoad Directory for SAS Visual Analytics. And follow the instructions.

Once you have AutoLoad setup, you must make sure certain LASR Library Extended Attributes are set correctly to ensure that the AutoLoad process will automatically start your LASR Server. You will want to set/verify the following attributes for the LASR library:

  • To enable the LASR Server AutoStart only:

  • VA.AutoLoad.AutoStart: YES to indicate that you want the associated LASR Server to be started if it is not already running.
  • VA.AutoLoad.Enabled: YES to enable the AutoLoad process for the Library.
  • To enable the LASR table(s) AutoLoad (optional):

  • VA.Default.MetadataFolder: to relocate the table(s) metadata registration against a specific metadata folder.
  • VA.Default.Location: to specify the location of the table directory at OS level.
  • VA.Default.Sync.*: to manage the table(s) from the VA.Default.Location.

On your SAS Visual Analytics machine, you have to:

  • Set the appropriate security against the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef] to be sure that the appropriate LASR Server administrator will be allowed to manage it.
  • Set the AutoLoad process frequency (default is 15 minutes).
    “TIME_INTERVAL_MINUTES=[Your-Value]” in the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] file.
    Note: Reference the SAS Visual Analytics Administration Guide for more about  the timing of AutoLoad.
  • Schedule the AutoLoad process using the LASR Server administrator account responsible to manage this particular LASR Server by executing the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] script.

Validate the AutoLoad setup by stopping the SAS LASR Server from SAS Visual Analytics Administrator application, or using SAS code. Wait for the “TIME_INTERVAL_MINUTES=[Your-Value]“, and look at the LASR Server status in SAS Visual Analytics Administrator application, and the AutoLoad logs in [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/Logs (one log file each time the AutoLoad process is executed).

Whichever technique is used, the non-distributed LASR server will no longer be dependent on the middle-tier.

I hope this article has been helpful to you.

How LASR servers are started from SAS Visual Analytics Administrator was published on SAS Users.

4月 172017
 

In this post, I will explain how LASR Servers (both Distributed and Non-distributed) are started from the SAS Visual Analytics Administrator application. We will also look at one particular issue and I will provide you with more details to understand the situation and two strategies to address this issue.

When you start a LASR Server from the Visual Analytics Administrator application, the system processes your request in slightly different ways depending on whether you are starting a distributed or non-distributed LASR Server.

What happens in the background for a distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the distributed LASR Server startup code generated in step 2, and the SAS Workspace Server session executes it.

6.     As soon as the distributed LASR Server startup code is executed, a distributed LASR Server instance is created. This instance is independent from the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection drop down. But the LASR Server instance is up and persistent until the administrator stops it.

What happens for a non-distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the non-distributed LASR Server startup code generated on step 2, and the SAS Workspace Server session executes it.

6.     As soon as the non-distributed LASR Server startup code is executed, a non-distributed LASR Server instance is created. This instance is dependent on the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection become persistent until the administrator stops the non-distributed LASR Server.
The SAS Workspace Server session and the client connection are required for the non-distributed LASR Server to be up and persistent.

Potential non-distributed LASR Server issue

The client connection between the JES and the SAS Workspace Server session in non-distributed deployment is crucial. This connection has to be persistent during the non-distributed LASR Server lifetime. As soon as the JES or SAS Workspace Server session goes down, the client connection is broken and the non-distributed LASR Server will go down as well. And, its data become unavailable.

If administrators manage their SAS non-distributed LASR Servers from the SAS Visual Analytics Administrator web application, this will create a dependency between the non-distributed LASR Servers and the middle tier - more specifically with the SASServer1_1 instance (the sas.wip.soapservices application). This dependency does not exist for distributed LASR Servers.

When the dependency exists, each time the middle tier or the SASServer1_1 instance is down, all non-distributed LASR Servers that were managed using the SAS Visual Analytics Administrator will go down automatically because the client connection to the non-distributed LASR Server is broken and its associated SAS Workspace Server session will go down.

This issue will also appear if the network connection between the Middle Tier and the SAS Visual Analytics Root Node is broken. This will break the client connection and terminate the SAS Workspace Server session(s) and their associated non-distributed LASR Server(s).

How can we prevent the issue?

I can think of at least two techniques you can use to prevent the dependency of your non-distributed LASR Servers upon your middle-tier:

  • Start your non-distributed LASR Servers from a SAS program.
  • Configure your LASR Server to start using the AutoLoad facility.

Start your non-distributed LASR Server from a SAS program

Here is a sample program that you might use to start a non-distributed LASR Server:

/* Start the LASR Analytic Server by defining the LASR library*/
libname LASRLIB SASIOLA 
        startserver  host="sasserver01.race.sas.com" port=10013
        signer="sasserver05.race.sas.com:7980/SASLASRAuthorization";
 
/* Keep the SAS session up until SERVERTERM received */
proc vasmp;
   serverwait  port=10013;
quit;

 

This program could be scheduled or set as a service under UNIX or Windows to be executed as soon as SAS Visual Analytics is started/restarted. Whichever strategy you use, you will want to have the code run after these services are up and available:

The SAS Metadata Server.
The Object Spawner on the SAS Visual Analytics Root Node.
The SASLASRAuthaurization service on the Middle Tier:

Start the non-distributed LASR Server Using the AutoLoad capability

AutoLoad runs as a periodic scheduled task. In the standard configuration, a new run of AutoLoad is started every 15 minutes.
AutoLoad periodically scans the contents of a designated host directory, which is referred to as the AutoLoad data directory or drop zone.
AutoLoad will automatically start the associated SAS LASR Server, if it is not yet started.

If you do not already have a LASR library configured with AutoLoad, you will need to use the SAS Deployment Manager application to configure an AutoLoad directory.

In Administration Tasks, choose Configure an AutoLoad Directory for SAS Visual Analytics. And follow the instructions.

Once you have AutoLoad setup, you must make sure certain LASR Library Extended Attributes are set correctly to ensure that the AutoLoad process will automatically start your LASR Server. You will want to set/verify the following attributes for the LASR library:

  • To enable the LASR Server AutoStart only:

  • VA.AutoLoad.AutoStart: YES to indicate that you want the associated LASR Server to be started if it is not already running.
  • VA.AutoLoad.Enabled: YES to enable the AutoLoad process for the Library.
  • To enable the LASR table(s) AutoLoad (optional):

  • VA.Default.MetadataFolder: to relocate the table(s) metadata registration against a specific metadata folder.
  • VA.Default.Location: to specify the location of the table directory at OS level.
  • VA.Default.Sync.*: to manage the table(s) from the VA.Default.Location.

On your SAS Visual Analytics machine, you have to:

  • Set the appropriate security against the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef] to be sure that the appropriate LASR Server administrator will be allowed to manage it.
  • Set the AutoLoad process frequency (default is 15 minutes).
    “TIME_INTERVAL_MINUTES=[Your-Value]” in the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] file.
    Note: Reference the SAS Visual Analytics Administration Guide for more about  the timing of AutoLoad.
  • Schedule the AutoLoad process using the LASR Server administrator account responsible to manage this particular LASR Server by executing the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] script.

Validate the AutoLoad setup by stopping the SAS LASR Server from SAS Visual Analytics Administrator application, or using SAS code. Wait for the “TIME_INTERVAL_MINUTES=[Your-Value]“, and look at the LASR Server status in SAS Visual Analytics Administrator application, and the AutoLoad logs in [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/Logs (one log file each time the AutoLoad process is executed).

Whichever technique is used, the non-distributed LASR server will no longer be dependent on the middle-tier.

I hope this article has been helpful to you.

How LASR servers are started from SAS Visual Analytics Administrator was published on SAS Users.

4月 102017
 

You can expand on the functionality of SAS Visual Data Builder in SAS Visual Analytics by editing the query code, adding code for pre- and post-processing, or even writing your own query.   You can process single tables or join multiple tables, writing the output to a LASR  library, a SAS library, or a DBMS library.  But you can also easily schedule your queries, right from the Visual Data Builder interface.

Here’s how.

When a query is open in the workspace of Visual Data Builder, you can schedule the query from the application by clicking the Schedule (clock) icon.

The scheduling server used is determined by the SAS Visual Data Builder Scheduling preferences setting, shown below.

By default, the Visual Analytics deployment includes the Operating System Services scheduling server, so it appears automatically as the default.

The Server Manager plug-in to SAS Management Console identifies the scheduling servers that are included in your deployment. You can specify a different scheduling server, such as Platform Suite for SAS server, if your deployment includes it.

Note:  The Distributed In-process scheduling server is not supported.

Any scheduling preferences that you change are used the next time you create and schedule a query. If you need to change the settings for a query that is already scheduled, you can use SAS Management Console Schedule Manager to redeploy the deployed job for the query.

When you schedule a query, the SAS statements are saved in a file in the default deployment directory path: SAS-config-dir/Lev1/SASApp/SASEnvironment/SASCode/Jobs.

In the examples in this blog, the SAS-config-dir is /opt/sasinside/vaconfig.
The metadata name of the directory is Batch Jobs.
The default SAS Application Server name associated with the directory is SASApp.

If you are working in a VA environment where multiple application servers are defined, you should be aware of the following SAS Notes at the links below, relating to the application’s choice of application servers for scheduling.

SAS Note 58186SAS® Visual Data Builder might use the wrong application server for scheduling
SAS Note 52977SAS® Visual Data Builder requires the default SAS® Application Server and the default scheduling servers to be located on the same physical machine

To schedule a query, open the query and select the Schedule (clock) icon. (The clock is grayed out if you have not saved the query.)

You can schedule the query to run immediately (Run now) or at a specified time event.  To define a time event, select the Select one or more triggers for this query button and click New Time Event.  Grouping events are not supported for the default server, but may be supported for other scheduling servers, such as Platform Suite.

You can schedule for One time only, or More than once, running Hourly, Daily, Weekly, Monthly, or Yearly.  The appearance of the interface and scheduling parameters change with your specification.

In this example, a One time only event is specified.

 

The time event specification gets recorded in the Trigger list on the Schedule page, and is selected in the Used column.

After you click OK in the Schedule window, you will get the confirmation below.

After the time event has passed, you can verify that the table has been loaded on the LASR Tables tab of the Visual Analytics Administrator.

When you schedule, the Visual Data Builder:

  • creates a job that executes the query.
  • creates a deployed job from the job.
  • places the job into a new deployed flow.
  • schedules the flow on a scheduling server.

The files are named according to vdb_query_id_timestamp.
In this example the files are named vdb_CustomerInfoData_1490112883364_timestamp.
When the query executes at the scheduled time, the SAS code that is written to the /opt/sasinside/vaconfig/Lev1/SASApp/SASEnvironment/SASCode/Jobs directory.  The query is run with the user ID that scheduled it.

If you right-click on Server Manager in SAS Management Console and view Deployment Directories, you will see that this is the Deployment directory (Batch Jobs) for SASApp.

In the /opt/sasinside/vaconfig/Lev1/SASApp/BatchServer/Logs directory, you can view the SAS Log.

The scheduling server script and log are in /opt/sasinside/vaconfig/Lev1/SchedulingServer/Ahmed/vdb_CustomerInfoData_14900112883364

Observe that the script was written to this location at the time the job was scheduled, rather than at execution time.

If you edit a data query that is already scheduled, you must click the schedule icon again so that the SAS statements for the data query are regenerated and saved.

If you edit the query again and specify additional time events, each event appears in the trigger list, and you can check which time event is to be used for scheduling.

If scheduling a query according to time events, you should also be aware of this Usage note:

Usage Note 55880: Scheduled SAS® Visual Data Builder queries are executed based on the time zone of the scheduling server 

And to add to the fun, also keep in mind that if your deployment includes SAS Data Integration Studio, you can also export a query as a Job and then perform the deployment steps using DI Studio.

Just right-click on the query in the SAS folder panel in Visual Data Builder and Select Export as a Job!

Easy Scheduling in Visual Data Builder - SAS Visual Analytics 7.3 was published on SAS Users.

3月 222017
 

Editor's note: The following post is from Scott Leslie, PhD, Manager of Advanced Analytics for MedImpact Healthcare Systems, Inc. Scott will be one of the Code Doctors at SAS Global Forum 2017.

Learn more about Scott.

VISIT THE CODE CLINIC AT SASGF 2017

$0 copay, no deductible.  No waiting rooms, no outdated magazines. What kind of doctor’s office is this? While we might not be able to help with that nasty cough, SAS Code Doctors are here to help – when it comes to your SAS code, that is.

Yes, the Code Doctors return to SAS Global Forum 2017! This year the Code Clinic will have over 20 SAS experts on-call to answer your questions on syntax, SAS Solutions, best practices and concepts across a broad range of SAS topics/applications, including Base SAS, macros, report writing, ODS, SQL, SAS Enterprise Guide, statistics, and more. It’s a fantastic opportunity to review code, ask questions, develop and brainstorm with peers who have decades of experience using SAS. Bring your code on paper, a flash drive, or a laptop. We’ll have 3-4 laptops with several versions of SAS software installed: 9.1.3 to 9.4 and EG 4.1 to 7.1. And if we can’t answer your coding question at the clinic, we can easily refer you to a specialist, namely the SAS R&D section of the Quad.

So, take advantage of this personalized learning experience in the Lower Quad area of the conference. Clinic office hours are:

  • Monday 4/3, 10:00 am - 3:30 pm
  • Tuesday 4/3, 9:30 am – 2:00 pm and 3:30 pm – 6:00 pm

Here’s the detailed schedule of our all-star code doctor lineup. If you haven’t heard of these names yet, you have now...

/*Just by reading this blog…*/.

 

About Scott Leslie

Scott Leslie, PhD, is Manager of Advanced Analytics for MedImpact Healthcare Systems, Inc. with over15 years of SAS® experience in the pharmacy benefits and medical management field. His SAS knowledge areas include SAS/STAT, Enterprise Guide, and Visual Analytics. Scott presents at local, regional and international SAS user group conferences as well at various clinical and scientific conferences. He is a former executive committee member of the Western Users of SAS Software (WUSS) and contributes to the San Diego SAS Users’ Group (SANDS).

Visit the code clinic at SAS Global Forum was published on SAS Users.

3月 022017
 

SAS Global Forum 2017 is just a month away and, if you’re a SAS administrator, it’s a great place to meet your peers, share your experiences and attend presentations on SAS administration tips and tricks.

SAS Global Forum 2017 takes place in Orlando FL, April 2-5. You can find more information at https://www.sas.com/en_us/events/sas-global-forum/sas-global-forum-2017.html.  This schedule is for the entire conference and include pre and post conference events.

If you’re an administrator, though, I wanted to highlight a few events that would be of particular interest to you:

On Sunday, April 2nd from 2-4 pm there is a “Helping the SAS Administrator Succeed” event. More details can be found here.

On Monday, April 3rd from 6:30-8:00 pm the SAS Users Group for Administrators (SUGA) will be hosting a Community Linkup, with panelists on hand to help answer questions from SAS administrators. Location will be in the Dolphin Level – Asia 4.

There are two post-conference tutorials for the SAS Administrators:

Introduction to SAS Grid Manager, Wednesday, April 5th from 2:30-6:30pm
SAS Metadata Security, Thursday, April 6th from 8:00am-noon
More details can be found here.

For a list of the papers on the topic of SAS Administration, you can visit this link. You will see that SAS Administration has been broken down to Architecture, Deployment, SAS Administration and Security subtopic areas.

Some of the key papers under each sub-topic area are:

Architecture
Twelve Cluster Technologies Available in SAS 9.4
Deploying SAS on Software-Defined and Virtual Storage Systems
Shared File Systems:  Determining the Best Choice for your Distributed SAS Foundation Applications
Do You have a Disaster Recovery Plan for Your SAS Infrastructure

Deployment
Pillars of a Successful SAS Implementation with Lessons from Boston Scientific
Getting the Latest and Greatest from SAS 9.4: Best Practices for Upgrades and Migrations
Migrating Large, Complex SAS Environments: In-Place versus New Build

SAS Administration
SAS Metadata Security 201:  Security Basics for a New Administrator
SAS Environment Manager: Advanced Topics
The Top Ten SAS Studio Tips for SAS Grid Manager Administrators
Implementing Capacity Management Policies on a SASLASR Analytic Server Platform: Can You Afford Not To?
Auditing in SAS Visual Analytics
SAS Viya: What it Means for SAS Administration

Security
Guidelines for Protecting Your Computer, Network, and Data from Malware Threats
Getting Started with Designing and Implementing a SAS® 9.4 Metadata and File System Security Design
SAS® Metadata Security 301: Auditing your SAS Environment
SAS® Users Audit: An Automated Approach to Metadata Reporting
SAS® Metadata Security

In addition to the breakout sessions, there is an Administration Super Demo station where short presentations will be given. The schedule for these presentations is:

Sunday, April 2nd:
17:00     Shared File Systems for SAS Grid Manager
18:00     Where to Place SAS WORK in your SAS Grid Infrastructure

Monday, April 3rd:
11:00     Hands-on Secure Socket Layer Configuration for SAS 9.4 Environment Manager
12:00     Introduction to Configuring SAS Metadata Security for Mutlitenancy
13:00     SAS Viya Overview
14:00     Accelerate your SAS Programs with GPUs
15:00     Authentication and Identity Management with SAS Viya

Tuesday, April 4th:
11:00     Accelerate your SAS Programs with GPUs
12:00     Accelerating your Analytics Adoption with the Analytics Fast Track
13:00     New Deployment Experience for SAS
14:00     Managing Authorization in SAS Viya
15:00     Clustering in SAS Viya
16:00     A Docker Container Toolbox for the Data Scientist

As you can see, there is lots for SAS Administrators to learn and opportunities for SAS Administrators to socialize with fellow SAS Administrators.

Here’s to seeing you in sunny Florida next month.

P.S. SAS administrators don’t have to go to SAS Global Forum to get help administering their environment. In addition to SAS Global Forum and the SUGA group mentioned above, you can find out more information on resources for administrators in this blog. You can also visit our new webpage devoted just to users who administer their organization’s SAS environment. You can find that page here.

Resources for SAS Administrators at SAS Global Forum 2017 … and beyond was published on SAS Users.

2月 102017
 

Since the SAS 9.4 M2 release in December 2014, there have been several refinements and updates to the middle tier that are of interest to installers and administrators. In this blog, I’m going to summarize them for you. What I’m describing here is available in the newest SAS release (9.4 M4). I’ll describe them at a high level, and refer you to the documentation for details and how to implement some of these changes.

Security enhancements

Preserve your TLS Customizations:
For security purposes, many of you will manually add TLS configurations, either to the SAS Web Server, the SAS Web Application Server, or both. In addition, you may prefer to use your own reverse proxy server (such as IIS), either instead of, or in addition to, the SAS Web Server. Before the 9.4 M4 release, when upgrading or applying maintenance, you had to undo these custom configurations, perform the upgrade, and then apply the custom configurations again. Now, the upgrade will preserve them, making the process much easier. See Middle-Tier Security in the Middle Tier Administration Guide, Fourth Edition for full details.

Newer versions of OpenSSL are now provided (see doc for specific version numbers):
A Java upgrade enables enforcement of TLSv2. TLS is now considered the security standard for https connections, (SSL is obsolete) and this can be enforced with configurations to the SAS Web Server and the SAS Web Application Server. The new version of Java SAS is using (Ver 1.7+) now allows for this. One important thing to be aware of is that certificates are completely independent of which protocol you are using, and therefore any certificates you may have been using with SSL should work equally with newer TLS protocols.

Management of the trusted CA (Certificate Authority) bundle:
SAS now has a trusted CA bundle, that can be managed by the SAS Deployment Manager, in a new location:  SASHome/SASSecurityCertificateFramework/1.1/cacerts/. The CA certificates can be root certificates, intermediate certificates, or both. Here’s what the menu item looks like:

Middle Tier Changes and Upgrades in SAS 9.4 M4

Previously it was necessary to manually add your root/intermediate certificates to the Java truststore “cacerts,” located inside the JRE; now it’s done through the new interface. If you are on Windows, you must also add trusted CAs to the Windows store (as before), which will make them available to any browsers running there. This is documented at http://www.sqlservermart.com/HowTo/Windows_Import_Certificate.aspx and elsewhere online.

Security Support for SAS Web Applications – white list external sites, and HTTP request methods:
For added security, web sites hosting SAS web applications can now maintain a white list of external URLs that are allowed to connect in. This provides protection against Cross Site Request Forgeries, and other vulnerabilities. This is what the prompt looks like in the SDW:

Middle Tier Changes and Upgrades in SAS 9.4 M4

HTTP request methods can also be specified as allowed/not allowed. The list of URLs can be specified during installation in the SDW (shown above), or using the SAS Management Console. You can disable whitelist checking entirely, and you can add a “blacklist” or specific sites to always block. You can also block based on request method–ie, GET, POST, PUT, etc. See the Middle Tier Administration Guide for details.

Forward Proxy Configuration:
You can now set up SAS web applications to forward external URL requests through a proxy–here it’s called a forward proxy server. Many organizations do this behind their firewalls. See details for how to set this up in the administration guide.

Other miscellaneous changes:
As an administrator you can now force users to Log Off using SAS Web Administration Console.    You can also send emails to one or more users from the same window.  This is what the menu looks like:

Middle Tier Changes and Upgrades in SAS 9.4 M4

Faster start-up time for the SAS Web Application Server

JMS Broker (ActiveMQ) now uses Version 5.12.2 (fixed bugs).

SAS Web Server now uses version 5.5.2 and includes an updated mod_proxy_connect module for TLS tunneling.

References

SAS 9.4 Intelligence Platform: Middle Tier Administration Guide, Fourth Edition

Encryption in SAS 9.4, Sixth Edition

 

tags: SAS 9.4, SAS Administrators, SAS Professional Services, security

Middle Tier Changes and Upgrades in SAS 9.4 M4 was published on SAS Users.

2月 012017
 

SAS® Federation Server provides a central, virtual environment for administering and securing access to your data. It also allows you to combine data from multiple sources without moving or copying the data. SAS Federation Server Manager, a web-based application, is used to administer SAS Federation Server(s).

Data privacy is a major concern for organizations and one of the features of SAS Federation Server is it allows you to effectively and efficiently control access to your data, so you can limit who is able to view sensitive data such as credit card numbers, personal identification numbers, names, etc. In this three-part series, I will explore the topic of controlling data access using SAS Federation Server.

The series covers the following topics:

SAS Metadata Server is used to perform authentication for users and groups in SAS Federation Server and SAS Federation Server Manager is used to help control access to the data. Note: Permissions applied for particular data source cannot be bypassed with SAS Federation Server security. If permissions are denied at the source data, for example on a table, then users will always be denied access to that table, no matter what permissions are set in SAS Federation Server.

In this blog post, I build on the example in my previous post and demonstrate how you can use SAS Federation Server Manager to control access to columns and rows in tables and views.

Previously, I gave the Finance Users group access to the SALARY table. Robert is a member of the Finance Users group, so he has access to the SALARY table; however, I want to restrict his access to the IDNUM column on the table. To do this, first I view the SALARY table Authorizations in Federation Server Manager, then I select the arrow to the right of the table name to view its columns.

Next, I select the IDNUM column. I then add the user Robert and set his SELECT permission to Deny for the column.

Note: There are 5 columns on the SALARY table.
Since he was denied access to the IDNUM column, Robert is only able to view 4 out of 5 columns.

Susan is also a member of the Finance Users group, so she has access to the SALARY table; however, I want to restrict her access to only rows where the JOBCODE starts with a “Q.” To do this, first I view the SALARY table Authorizations in Federation Server Manager.

Next, I select the Row Authorizations tab and select New Filter. I use the SQL Clause Builder to build my condition of JOBCODE LIKE Q%.

Next, I select the Users and Groups tab and add Susan to restrict her access to the filter I just created.

Finally, I select OK to save the changes I made to Row Authorizations.

Susan is now only able to view the rows of the SALARY table where the JOBCODE begins with “Q.”

In this blog entry, I covered the second part of this series on Securing sensitive data using SAS Federation Server at the row and column level:

Part 1: Securing sensitive data using SAS Federation Server at the data source level
Part 2: Securing sensitive data using SAS Federation Server at the row and column level
Part 3: Securing sensitive data using SAS Federation Server data masking

More information on SAS Federation Server:

tags: SAS Administrators, SAS Federation Server, SAS Professional Services

Securing sensitive data using SAS Federation Server at the row and column level was published on SAS Users.

1月 172017
 

Editor's note: Charyn Faenza co-authored this blog. Learn more about Charyn.

As the fun of the festive season ends, the buzz of the new year and the enchantment of SAS Global Forum 2017 begins. SAS Global Forum is a conference designed by SAS users, for SAS users, bringing together SAS professionals from all over the world to learn, collaborate and network in person. Sure, online communication is great, but it’s hard to beat the thrill of meeting fellow SAS users face-to-face for the first time. It feels like magic! To help you prepare for the event, Charyn and I wanted to share a few things including information on metadata security. Read on for more.

Start your SAS Global Forum journey now!

SUGAWant to stay up to date with SAS Global Forum activities, and get a head start on your conference networking? Join the SAS Global Forum 2017 online community. Here you can post questions, share ideas, and connect with others before the event. While you are at it, the SAS User Group for Administrators (SUGA) community also feels magical for me.  As part of the committee, we regularly get together (virtually!) to discuss and plan exciting events on behalf of SAS administrators around the world.  Join the SUGA community and watch for upcoming events, including a live meet-up at SAS Global Forum! That event is scheduled for Monday, April 3, from 6:30-8:00 p.m.

Security auditing

During his workshop at SAS Global Forum 2014, Gregory Nelson pointed out that the SAS administrator role has evolved over the years, and so has one of their key responsibilities: security auditing. Once you’ve set up an initial security plan, how do you ensure that the environment remains secure? Can you just “set it and forget it?” Probably not. Especially if you want to ensure regulatory compliance, to maintain business confidence and keep your SAS platform in line with its design specifications as your business grows and your SAS environment evolves.

Thinking about your own SAS platform:

  • What would happen in your organization if someone accessed data they shouldn’t?
  • When was your last SAS platform security project?
  • When was it last tested? How extensive was it? How long did it take?
  • Have there been any changes since it was last tested? Whether they are deliberate, accidental, expected or unexpected.
  • How do you know if it’s still secure today?

Presenting at SAS Global Forum

If security is important to you and your organization, please join us at this year’s magical SAS Global Forum, as I co-present with Charyn Faenza on SAS® Metadata Security 301: Auditing Your SAS Environment. Hold your horses… “301?,” Did I hear that right? “What about 101 and 201?" Glad your curious mind asked... At the last two SAS GLOBAL FORUM events, Charyn has presented SAS Metadata Security 101 and 201 papers that step through the fundamentals on authentication and authorization. Check them out at:

Our upcoming 301 paper will focus on auditing to complete the three ‘A’s (Authentication, Authorization and Auditing), including how you can use Metacoda software to regularly review your environment, so you can protect your resources, comply with security auditing requirements, and quickly and easily answer the question "Who has access to what?"

Here are the details for our paper:
Session Title: 786 -  SAS Metadata Security 301: Auditing your SAS Environment
Type: Breakout
Date: Tuesday, April 4
Time: 4:00 PM - 5:00 PM
Location: Dolphin, Dolphin Level III - Asia 4

Our security journey

sas-security-journey

Whether you’re a new SAS administrator or an experienced one, you’ll know that security is a journey rather than a destination.

To help make sure you’re on the right path, check out the SUGA virtual events, SAS administrator tagged blog posts, Twitter #sasadmin and platformadmin.com.

sas-security-journey02If you’d like to chat more about SAS security auditing, please comment below, join our chat in the SAS Global Forum community, or connect with us on Twitter at @HomesAtMetacoda, @CharynFaenza.

Looking forward to seeing you in April at SAS Global Forum 2017 in the enchanting and magical Walt Disney World Swan and Dolphin Resort, Orlando, Florida!


About Charyn Faenza

charynMs. Faenza is Vice President and Manager of Corporate Business Intelligence Systems for First National Bank, the largest subsidiary of F.N.B. Corporation (NYSE: FNB). An accountant by training, she is passionate about not only understanding the technology, but the underlying business utility of the systems her team supports. In her role she is responsible for the architecture and development of F.N.B.’s corporate profitability, stress testing, and analytics platforms and oversees the data collection and governance functions to ensure high data quality, proper data storage and transfer, risk management and data compliance.

Throughout her tenure at F.N.B. her experience in data integration and governance has been leveraged in several cross functional projects where she has been engaged as a strategic consultant regarding the design of systems and processes in the Finance, Treasury and Credit areas of the Bank.

Ms. Faenza earned her bachelor’s degree in Accounting from Youngstown State University where she is currently serving on the Business Advisory Board of the Youngstown State University Laricccia School of Accounting and Finance.

tags: papers & presentations, SAS Administrators, SAS Global Forum, SAS User Group for Administrators

Take a SAS security journey at SAS Global Forum 2017 was published on SAS Users.

12月 272016
 

We have seen in a previous post of this series how to configure SAS Studio to better manage user preferences in SAS Grid environments. There are additional settings that an administrator can leverage to properly configure a multi-user environment; as you may imagine, these options deserve special considerations when SAS Studio is deployed in SAS Grid environments.

SAS Studio R&D and product management often collect customer feedback and suggestions, especially during events such as SAS Global Forum. We received several requests for SAS Studio to provide administrators with the ability to globally set various options. The goal is to eliminate the need to have all users define them in their user preferences or elsewhere in the application. To support these requests, SAS Studio 3.5 introduced a new configuration option, webdms.globalSettings. This setting specifies the location of a directory containing XML files used to define these global options.

Tip #1

How can I manage this option?

The procedure is the same as we have already seen for the webdms.studioDataParentDirectory property. They are both specified in the config.properties file in the configuration directory for SAS Studio. Refer to the previous blog for additional details, including considerations for environments with clustered mid-tiers.

Tip #2

How do I configure this option?
By default, this option points to the directory path !SASROOT/GlobalStudioSettings. SASROOT translates to the directory where SAS Foundation binaries are installed, such as /opt/sas/sashome/SASFoundation/9.4 on Unix or C:/Program Files/SASHome/SASFoundation/9.4/ on Windows. It is possible to change the webdms.globalSettings property to point to any chosen directory.

SAS Studio 3.6 documentation provides an additional key detail : in a multi-machine environment, the GlobalStudioSettings directory must be on the machine that hosts the workspace servers used by SAS Studio. We know that, in grid environments, this means that this location should be on shared storage accessible by every node.

Tip #3

Configuring Global Folder Shortcuts

SAS Studio Tips for SAS Grid Manager Administrators

In SAS Studio, end users can create folder shortcuts from the Files and Folders section in the navigation pane. An administrator might want to create global shortcuts for all the users, so that each user does not have to create these shortcuts manually. This is achieved by creating a file called shortcuts.xml in the location specified by webdms.globalSettings, as detailed in

SAS Studio repositories are an easy way to share tasks and snippets between users. An administrator may want to configure one or multiple centralized repositories and make them available to everyone. SAS Studio users could add these repositories through their Preferences window, but it’s easier to create global repositories that are automatically available from the Tasks and Utilities and Snippets sections. Again, this is achieved by creating a file called repositories.xml in the location specified by webdms.globalSettings, as detailed in tags: SAS Administrators, SAS Grid Manager, SAS Professional Services, sas studio

More SAS Studio Tips for SAS Grid Manager Administrators: Global Settings was published on SAS Users.

12月 212016
 

The report-ready SAS Environment Manager Data Mart has been an invaluable addition to SAS 9.4 for SAS administrators. The data mart tables are created and maintained by the SAS Environment Manager Service Architecture Framework and provide a source of data for out-of-the box reports as well as custom reports that any SAS administrator can easily create. As you can imagine, the size of the tables in the data mart can grow quite large over time so balancing the desired time span of reporting and the size of the tables on disk requires some thought. The good news: SAS 9.4 M4 has made that job even easier.

The Environment Manager Data Mart (EVDM) has always provided a configuration setting to determine how many days of resource records to keep in the data mart tables. You can see below that in a fresh SAS 9.4 M4 installation, the default setting for “Number of Days of Resource Records in Data Mart” is set to 60 days. This means that EVDM data records older than 60 days are deleted from tables whenever the data mart ETL process executes.

EV Data Mart Tables in 9.4M4

The space required to house the Environment Manager Data Mart is split across three primary areas.

  • The ACM library tables contain system level information
  • The APM library tables contain audit and performance data culled from SAS logs
  • The KITS library tables contains miscellaneous tables created by data mart kits that collect specialty information about HTTP access, SAS data set access, and such.

Prior to SAS 9.4M4, the ACM and APM libraries duly archived data according to the “Number of Days of Resource Records in Data Mart” setting, but the KITS library did not. For most of the KITS tables this is not such a big deal but for some deployments, the HTTPACCESS table in the KITS library can grow quite large. For administrators who have enabled the VA feed for the Service Architecture Framework, the size of the HTTPACCESS table directly impacts the time it takes to autoload the results of each refresh of the data mart, as well as the amount of memory consumed by the LASR Server used for the Environment Manager Data Mart LASR library.

So what is the big change for SAS 9.4 M4?

The KITS library now respects the “Number of Days of Resource Records in Data Mart” setting and removes data older than the threshold.  If you are a SAS administrator, you can now forget about having to separately manage the KITS library which should simplify space management.

SAS administrators may need to adjust the “Number of Days of Resource Records in Data Mart” setting to strike a balance between the date range requirements for reporting and the amount of disk space they have available for storing the EVDM tables.  With SAS 9.4 M4, however, administrators can rest assured that all EVDM tables will self-manage according to their wishes.

More on the Service Architecture Framework.

tags: SAS 9.4, SAS Administrators, SAS Environment Manager, SAS Professional Services

Easier Space Management for EV Data Mart Tables in 9.4M4 was published on SAS Users.