SAS administrators


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.


$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.


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  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:

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

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

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.


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 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.


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.


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.


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


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

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.

十二 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 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.

十二 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.


One very useful type of auditing for a SAS administrator is to have summary data about the availability and performance of various resources (platforms, servers, services) from the 30,000-foot view.  Using SAS Environment Manager, it's easy to go in and look at the availability of any one resource over various time spans--for the past few hours, past day, past week, or past month and more.  This is a very powerful way to summarize how much of the time a given resource was "up and responsive."


However, there's no way to see that type of information, or even a summary of that information, for all your servers at once.  A typical deployment will have anywhere from 10 to 50 or more different servers, and to view the availability of them all, over an extended period, you would have to visit and drill down each resource, one at a time.

To help answer this problem, I've developed a simple report that summarizes the availability for all servers.  It uses two data sets that are automatically generated as part of the SAS Environment Manager Data Mart - availability and resourceinventory. It doesn't provide  the hour-by-hour information like the Monitoring interface of SAS Environment Manager does, but it gives you  a percent of time available, for each server, for either the past day, week,  month, or even quarter, in one summary report (if you have the data for it).  For a production environment, this could provide helpful "big-picture" information on availability.

Building the report will involve copying an existing report, used as a template, modifying a bit of the metadata for that report, and copying the SAS code that generates the report.  The report uses a stored process to do the work.

Here's how to create the report.

1. Copy the SAS code provided here and save it in a local file:

If you are working on a remote machine, such as through Remote Desktop or mobaXterm, then upload the file to the machine running the metadata server so it will be available to copy into the report metadata.

2. Log into SAS Management Console as sasadm@saspw, the SAS administrator.

3. Select the Folders tab (upper left), right mouse on the Shared Data folder, select New->Folder, and name it Custom Reports:


4. Navigate to the folder Products->SAS Environment Manager->Custom and locate the existing example report called Example 2 Call EV Macros with prompts.


5. Copy the example report into the new Custom Reports folder created in Step 3 above, then use the right mouse menu to rename it to Availability Report.  When complete, you will see the new folder and report inside it:


6. Select the new Availability Report, right mouse, select Properties.

7. On the General tab, specify Name, Description, and Keywords as shown:


It's especially important to have the keywords "Environment Manager" in the Keywords field, so that the report will appear in the Report Center of Environment Manager.

8. On the Execution tab, select your Application server, and below, specify Store source code in metadata.  Then click the Edit Source Code... button:


9. Copy/paste the SAS code (Step 1 above) into the source code window and click OK to save it.


10.  On the Parameters tab, you'll see Titles and Footnotes, and Output Formats and Debugging.  Select and Delete the Titles and Footnotes group; leave the Output Formats and Debugging group as is.


11. Select General, then click the New Group... button (right side), and specify:

Group type:  Standard group

Displayed text: Time Period

Click OK button


12. Select the new group, Time Period.  Click the New Prompt button.  Type the string "TimePeriod" (no space) in the Name field and “Time Period” in the Displayed Text field.  Then click OK.


13.  Select the new prompt TimePeriod, click the Edit button on the right side.  Select the Prompt Type and Values tab at the top.  On the Edit Prompt screen, specify:

Prompt type:   Text

Method for populating prompt:  User selects values from a static list

Number of values: Single value

Use the Add button (right side) to insert the following four choices shown below:


Set the "week" value as the default as shown.   Click the OK button.  Now, select the new Time Period prompt and click the Move Up button (right side), so that the Time Period prompt appears first:


If desired, you can try the Test Prompts button to make sure your prompts are correct.  Click OK again to save all changes.

14. Test the new report:
Log into SAS Environment Manager as an administrator and go to the Report Center. Open the Shared Data / Custom Reports folder and find the new report "Availability Report."  (If you were already logged into Environment Manager, you have to log out/log in again to pick up the new metadata.)


Notice that you have the custom prompt for Time Period , where you can choose either "day," "week," "month" or "quarter" for the time window, and the standard prompt for Outputting Styles and Logging and Debugging settings.   Click the Run button at the bottom, and you should see your new report, similar to this:  (Yellow indicates any percent less than 100.)


You can install this report for any site with the SAS Environment Manager Data Mart active and have it running in just a few minutes.  You could pull the SAS code from it and create your own scheduled run, weekly or monthly, as a means to help to evaluate a deployment for reliability.

A few cautions are in order:

  • You need to have at least some data in your data mart in order to run this report. If you don't have enough data to cover the time period that you request, you will get an error message.
  • The data this report provides is summary level, so if you find one or more servers
    that have been down a significant amount of time, the next step would be to use the SAS Environment Manager to focus in on those troubled resources and examine exactly WHEN they were down, for exactly how long, how many times they were down, and/or look at other metrics on those resources as a way to ascertain causes.
  • This is a simple program without much error checking.  However, you can specify in the parameters to see the SAS log, which should enable you to debug it should issues occur.  And of course feel free to enhance it or add to it!

One easy check you can do by hand is to verify the existence of the data sets being used, and that the libref used, ACM, has been defined.  This is what they looked like on my compute machine, where the SAS Environment Manager Service Architecture was installed:



For additional insight on how you can use SAS Environment Manger and the report center to analyze the "big picture" on a SAS deployment's availability, check out this YouTube video.

SAS code referenced above.

/*       SAS 9.4   M3                             */
/*      Runs report in SAS EV (Report Center) on availability of     */
/*      server resources.  Requires macro variable to be defined     */
/*      TimePeriod, with value of (dtday, dtweek, dtmonth, or dtqtr) */
/*      Requires data sets:  acm.resourceinventory                   */
/*                           acm.availability                        */
/*            from Service Architecture Framework datamart           */
/*                          Dave Naden August 2016                   */
%global _DEBUG
%include "&SASEVCONFIGDIR/Datamart/";
ods _ALL_ CLOSE;
%let evbegin=%ev_startdate(%sysfunc(date()),-10);
%let evend=%sysfunc(datetime(),datetime.);
%let period=&TimePeriod;     /* can be dtday, dtweek, dtmonth, or dtqtr */
%macro available;
/* get the resource IDs for servers only  */
data servers;
   set acm.resourceinventory(keep=id name type invLevel);
      if (invlevel = "SERVER");
     /* remove a few servers that are not really servers  */
      realserver = 1;
      if (index(type,"Directory") > 0) then realserver = 0;
      if (index(type,"Data Mart") > 0) then realserver = 0;
      if (index(type,"Server Context") > 0) then realserver = 0;
      if (index(type,"System Info") > 0) then realserver = 0;
      if (realserver) then output;
      rename id = resource_id;
 proc sort data=servers;
    by resource_id;
/* get availability data, prepare for merge */
 proc sort data = acm.availability(keep=resource_id name avail starttime endtime minutes)
    by resource_id;
 /* keep data only if it's server data, and if there's any records  */
 /*  in the availability data set   */
 data avail;
    merge servers(in=a)
       by resource_id;
       format now datetime24. ;
      if (a) and (avail ne .) ;
 /* get maximum (most recent) endtime  */
 proc summary data=avail;
    output out=timewindow(rename=(endtime=maxendtime)) max=; 
    var endtime;
 /* Get earliest start time for this data set  */
 proc summary data=avail;
    output out=earliesttime(rename=(starttime=earliest)) min=;
    var starttime; 
%let enoughdata=1;  
 /* establish the time window for report requested, and check whether  */
 /* data goes back far enough to run the report.  If not, set flag     */
 data timewindow;
    set timewindow ;
    set earliesttime;
       period = symget('period');
       begintime = intnx(period,maxendtime,-1,'S');
       format begintime datetime24.  ;
       totalminutes = intck('DTMINUTES',begintime,maxendtime,'C');
       if (earliest > begintime) then call symput('enoughdata','0');
/* subset data set to include only records within that time window requested  */
%if &enoughdata %then %do;
data avail;
   if (_N_ = 1) then set timewindow;
   set avail;
      if (endtime < begintime) then delete;
 /* aggregate to resource level (server), calculate percent available */
 data avail(keep=name type resource_id minutesdown percentup  );
    set avail;
       by resource_id;
       retain minutesdown;
          if first.resource_id then minutesdown=0;
          if (avail < 1) then do;
             if (starttime < begintime) then do;
             /* get number of minutes between begintime and endtime */
                minutes = intck('DTMINUTES',begintime,endtime,'C'); 
             minutesdown = minutesdown + minutes;
          if last.resource_id then do;
             if (minutesdown = 0) then percentup = 100;
             else percentup = ((totalminutes - minutesdown) / totalminutes) * 100;
   call symput("begintime",put(begintime,datetime24.));
   call symput("maxendtime", put(maxendtime,datetime24.)) ;
   call symput ("currentdatetime",put(datetime(),datetime24.)) ;
   %let period = %substr(&period,3);        
proc sort data=avail;
   by percentup;
proc report data=avail center split="*";
title "Server-type resources, showing percent up time up, past &period only";
title2 "Date Interval used: &begintime to &maxendtime "; 
footnote "Date of Report:  &currentdatetime ";
   column name type minutesdown percentup; 
   compute percentup;
      if percentup.sum
tags: SAS Administrators, SAS Environment Manager, SAS Professional Services

Auditing SAS server availability from 30,000 feet was published on SAS Users.


SecurityIn a number of my previous blogs I have discussed auditing within a SAS environment and how to identity who has accessed data or changed reports. For many companies keeping an audit trail is very important. If you’re an administrator in your environment and auditing is important at your organization, here are a few steps to take to secure the auditing setup and possibly audit any changes made to it, all the while ensuring there are no gaps in collecting this information.

In a SAS deployment the logging configuration is stored in XML files for each server configuration.  The xml files can be secured with OS permissions to prevent unauthorized changes. However, there are a number of ways in which a user can temporarily adjust logging settings which may allow them to prevent audit messages from reaching a log.

Logging can be adjusted dynamically in:

SAS Code using logging functions and macros
SAS Management Console

As an example of how a user could circumvent the audit trail let’s look at an environment where logging has been configured to audit access to SAS datasets using the settings described in this blog. When auditing is enabled, messages are recorded in the log when users access a table. In the test case for the blog we have a stored process that prints a SAS dataset. When the stored process runs, the log will record the table that was opened and the user that opened it.


A user could turn auditing off by adding a call to the log4sas_logger function. The code below included at the start of the Stored Process (or any SAS program) would turn dataset audit logging off for the duration of the execution. Any access of datasets in the Stored Process would no longer be audited.

data _null_;
rc=log4sas_logger(“Audit.Data.Dataset.Open”, “level=off”);

There is an option we can add to the logger to prevent this from happening. The IMMUTABILITY option specifies whether a logger’s additivity and level settings are permanent or whether they can be changed by using the SAS language. In the code above the level of the logger was changed using the log4sas logger function.

If we add the immutability=”true” setting to the logger, this will prevent a user from adjusting the logging level dynamically using the DATA step functions. Attempts to adjust the logger's level will fail with an error. More about the Logging Facility.

< appender-ref ref=”TimeBasedRollingFileAudit”/>
< level value=”Trace”/>
< /logger>


However, this setting does not fully prevent dynamic changes to logging configuration. IMMUTABILITY is ignored for configuration changes made by administrators using SAS Management Console or the IOMOPERATE procedure.

Users who have access to the SAS Management Console Server Manager plug-in can change logging on the fly. In SAS Management Console select Server Manager > SASApp > SAS App Logical Stored Process Server > <machine> right-click and select Connect.  This will display the process ID of an active Stored Process Server. Select the PID and select the loggers tab. This tab displays the current setting for the active loggers on the SAS server. The Audit.Data.Dataset.Open logger has a level of TRACE, this is the setting that is writing audit messages about activity on the dataset to the log.


An administrator can change the level of the logger by right-clicking on the logger name, and selecting Properties. In this example we will turn logging off for the Audit.Data.Dataset.Open logger.


Now any run of a stored process will no longer record audit messages about data access to the log.

Users could also use PROC IOMOPERATE to change the logging configuration on a server. The code below dynamically finds the serverid of the stored process server and then turns audit logging off. The key piece of code is the set attribute line near the end:

%let spawnerURI = %str(iom://server:8581;Bridge;user=sasadm@saspw,pass=???);
proc iomoperate ;
connect uri=”&amp;spawnerURI”;
list spawned;
list spawned out=obj_spawned;
data _null_;
set work.obj_spawned;
where upcase( serverComponent ) like ‘%STORED%’;
call symput(“stpid”, strip(serverid) );
proc iomoperate;
connect uri=”&amp;spawnerURI”
spawned=”&amp;stpid”   ;
set attribute category=”Loggers” name=”Audit.Data.Dataset.Open” value=”OFF”;

You must be a SAS Administrator to change logging configuration dynamically with SAS Management Console and PROC IOMOPERATE. While access to this functionality can be restricted, it does leave a potential gap in the auditing setup.  As a further failsafe you can actually configure auditing so that any changes made to logging configuration results in audit messages about the change in a log file. Effective with SAS 9.4, the following loggers capture these changes:

  • Logging.Configuration.Logger
  • Logging.Configuration.Appender
  • Logging.Configuration.Config

Let’s see how we can audit changes that are made to the Stored Process server’s logging configuration file.  In the existing configuration file, add a new appender. The new appender (below) will write messages to a separate log in the audit directory of the Stored Process server (make sure this directory exists). The log will have a name similar to  AuditLogsSASApp_LoggingChange_2016-09-15_sasbi_16024.log

&lt;!– Rolling log file with default rollover of midnight for Logging Auditing –&gt;
&lt; appender class=”RollingFileAppender” name=”TimeBasedRollingFileLogging“&gt;
&lt; param name=”Append” value=”false”/&gt;
&lt; param name=”Unique” value=”true”/&gt;
&lt; param name=”ImmediateFlush” value=”true”/&gt;
&lt; rollingPolicy class=”TimeBasedRollingPolicy”&gt;
&lt; param name=”FileNamePattern” value=”D:SASvaconfigLev1SASAppStoredProcessServerAuditLogsSASApp_LoggingChange_%d_%S{hostname}_%S{pid}.log”/&gt;
&lt; /rollingPolicy&gt;
&lt; layout&gt;
&lt; param name=”HeaderPattern” value=”Host: ‘%S{hostname}’, OS: ‘%S{os_family}’, Release: ‘%S{os_release}’, SAS Version: ‘%S{sup_ver_long2}’, Command: ‘%S{startup_cmd}'”/&gt;
&lt; param name=”ConversionPattern” value=”%d %-5p [%t] %X{Client.ID}:%u – %m”/&gt;
&lt; /layout&gt;
&lt; /appender&gt;

Now we will add a logger that references the new appender. The Audit.Logging logger will write all changes to loggers and appenders to the referenced appender.  After you make changes to logging configuration make sure you validate the server in SAS Management Console; syntax errors in logging configuration files can render SAS servers inoperable.

&lt; level value=”Trace”/&gt;
&lt; appender-ref ref=”TimeBasedRollingFileLogging”/&gt;
&lt; /logger&gt;

Once you have this set up, any dynamic changes made to logging configuration, either through the SAS language, PROC IOMOPERATE or SAS Management Console, will write a record to the new logging configuration auditing log.


When auditing is a critical requirement for a SAS deployment it is important for administrators to close any gaps which would allow actions to fail to write audit records.

These gaps can be closed by:

  • Securing the logging configuration file using operating system permissions
  • Ensuring that key loggers are configured as immutable
  • Restricting access to the SAS Management Console Server Manager plug-in
  • Ensuring that only key administrators have access to credentials that can change auditing configuration using SAS Management Console and PROC IOMOPERATE
  • Configuring auditing for changes to the logging configuration
tags: SAS Administrators, SAS Professional Services

How to protect your audit trail in a SAS environment was published on SAS Users.


In a previous blog post I explained how end users should code and use shared locations for SAS artifacts, to avoid issues in a SAS Grid Manager environment. Still, they could still fall in some sharing issues, which could have very obscure manifestations. For example, users opening SAS studio might notice that it automatically opens to the last program that they were working on in a previous session… sometimes. Other times, they may logon and find that SAS Studio opens to a blank screen. What causes SAS Studio to “sometimes” remember a previous program and other times not? And why should this matter, when all I am looking for, are my preferences?

Where are my preferences?

SAS Studio has a Preferences window that enables end users to customize several options that change the behavior of different features of the software. By default, these preferences are stored under the end-user home directory on the server where the workspace server session is running (%AppData%/SAS/SASStudio/preferences in Windows or ~/.sasstudio/preferences in UNIX). Does this sentence ring any alarm bells? With SAS Studio Enterprise Edition running in a grid environment, there is no such thing as “the server where the workspace server session is running!” One invocation of SAS Studio could run on one grid node and the next invocation of SAS Studio could run on a different grid node.  For this reason, it might happen that a preference that we just set to a custom value reverts to its default value on the next sign-in. This issue can become worse because SAS Studio follows the same approach to store code snippets, tasks, autosave files, the WEBWORK library, and more.

Until SAS Studio 3.4, the only solution to this uncertainty was to have end users’ home directories shared across all the grid nodes. SAS Studio 3.5 removes this requirement by providing administrators with a new configuration option: webdms.studioDataParentDirectory. This option specifies the location of SAS Studio preferences, snippets, my tasks, and more. The default value is blank, which means that the behavior is the same as in previous releases. An administrator can point it to any shared location to access all of this common data from any workspace server session.

Tip #1

This option sounds cool, how can I change its value?

SAS Studio 3.5: Administrator’s Guide provides information on this topic, but the specific page contains a couple of errors – not to worry, they have been flagged and are in the process of being amended. The property is specified in the file in the configuration directory for SAS Studio. Remember that when you deploy using multiple Web Application Servers (which is common with many SAS solutions, and mandatory in modern clustered environments), SAS Studio is deployed in SASServer2_1, not in SASServer1_1. It is also worth noting that, in case of clustered middle tiers, this change should be applied to every deployed instance of SAS Studio web application.

The documentation page also incorrectly states how to enforce this change. The correct procedure is to restart the Web Application Server hosting SAS Studio, i.e. SASSerrver2_1.

Tip #2

I do not want that all my users to share a common directory, they would override each other’s settings!

This is a fair request, but, unfortunately, the official documentation can be confusing.

The correct syntax, to have a per-user directory, is to append <userid> at the end of the path. SAS Studio will substitute this token with the actual userid of the user currently logged on. For example, given the following configuration:


will lead to this directory structure:


Tip #3

You – or your SAS Administrator – changed the value of the webdms.studioDataParentDirectory option. How can you know if the change has been correctly applied? This is the same as asking, how can I know where this option is currently pointing to? Here is a quick tip. This property influences the location of the WEBWORK directory. Simply open the Libraries pane, right click on WEBWORK to select “Properties”, and here you are. The highlighted path in the following screenshot shows the current value of the option:


As you may have understood, the daily duties of SAS Administrators include ghost hunting as well as debugging weird issues. I hope that the tips contained in this post will make your lives a little easier, leaving more time for all the other paranormal activities. And I promise, more tips will follow!

tags: SAS Administrators, SAS Grid Manager, SAS Professional Services, sas studio

SAS Studio tips for SAS Grid Manager Administrators: Where are my preferences? was published on SAS Users.