Add a Portal application using the following url:

http://<your server>:<your port>/SASWebReportStudio/logonFromPortal.do

Good SAS Admin practice is not use either of these accounts to schedule your production batch runs, but to create a new user for this specific task.

Of course the steps to creating new LSF users is buried in the middle of a raft of user and admin guides so most customers I deal with don;t bother.

Michael from Scorpio (he is Australian and drinking out of saucers at the moment has written a step by step blog that describes what you need to do to achieve this process over here:

Platform Suite for SAS – Dev/Test/Prod Tips 

Found this table of roles for WRS on the SAS Support site here:

Predefined Roles and Capabilities for SAS Web Report Studio

By the way the trick on the edit tab is to make sure PUBLIC doesnt have access to the WRS roles, which is does seem to by default.

“Note: By default, the PUBLIC group is a member of both the Web Report Studio: Report Creation and the Web Report Studio: Report Viewing roles. So, when you are ready to restrict access to specific capabilities, remember to remove PUBLIC (which includes all users in your deployment) from the applicable roles.”

Usage Note 30789: Implementing the most basic view-only access to reports in SAS® Web Report Studio

In order to be functional, some capabilities have prerequisites. Following is an explanation of each capability and prerequisites for certain capabilities:

Basic:Comments

provide access to Comment Manager.

Basic:Print

generate PDF output.

Basic:Allow Direct Access to Information Maps

open information maps directly as reports. Without this capability, information maps are suppressed from the Open and Manage pages. With this capability, users can access information maps from the Open and Manage pages and view them as reports. Users who have the Create Report capability can select an Edit action when an information map is selected.

If you are using (or if you migrated from) SAS Web Report Studio 4.2, then the name of this capability is Open Maps as Reports.

Basic:Allow Direct Access to Cubes

open cubes directly as reports, or open cubes as information maps when specifying a data source. Without this capability, cubes are suppressed from the Open and Manage pages. With this capability, users can access cubes from the Open and Manage pages and view them as reports. Users who have the Create Report capability can select an Edit action when a cube is selected.

This capability is new in SAS Web Report Studio 4.3.

Basic:Allow Direct Access to Tables

open tables directly as reports, or open tables as information maps when specifying a data source. Without this capability, tables are suppressed from the Open and Manage pages. With this capability, users can access tables from the Open and Manage pages and view them as reports. Users who have the Create Report capability can select an Edit action when a table is selected.

By default, this capability is not assigned to any roles because it would allow users to bypass BI row-level permissions. If you have not implemented BI row-level permissions, then consider adding this capability to the same roles to which Allow Direct Access to Cubes is assigned.

This capability is new in SAS Web Report Studio 4.3.

Basic:Promote Web Report Viewer to Web Report Studio

displays the SAS Web Report Studio interface when a user requests to view a report from another product such as SAS Information Delivery Portal. Initially, this capability is assigned to all predefined roles. If this capability is unassigned, and a user’s request to view a report from within another product is granted, then the SAS Web Report Viewer interface is used to present the report. When this capability is assigned to a role to which a user belongs, the SAS Web Report Studio interface is displayed when that user requests to view a report through the SAS Information Delivery Portal or other products.

Basic:Refresh Data

refresh data for reports.

Basic:Modify Repository

provide basic modifications to repository such as copy, move, rename, and delete. This capability does not grant the ability to save changes to reports.

OLAP:Drill

perform an OLAP drill operation.

OLAP:Drill to Detail

drill through to detail data for a single OLAP value.

OLAP:Expand and Collapse

expand or collapse OLAP data.

OLAP:Expand and Collapse All

expand or collapse an entire OLAP hierarchy. This capability requires the Report Creation:Basic Edit capability and the OLAP:Expand and Collapse capability.

Output:Save

save changes to reports. This capability requires that the user also has Modify Repository capability.

Output:E-mail

e-mail a report link.

Output:Export

export report content to Microsoft Excel.

Output:Schedule Own Report

schedule reports authored by the users themselves. The Schedule All Reports capability is available in the SAS Web Report Studio’s Advanced role.

Report Creation:Create Report

create new reports. The Save capability is a prerequisite for this capability.

Report Creation:Basic Edit

perform basic editing operations for tables and graphs. Operations include:

• Assign Data
• Total dialog box access
• Control of Total Type for OLAP reports only (parent versus visual)
• Percent of Total
• Filter and Rank
• Conditional Highlighting
• Rotate Table
• View Data Details
• Sort, Sort Priority, Remove All Sort
• Move
• Hide
• Replace / Swap
• All Table Properties
• All Graph Properties

Report Creation:Aggregate or Detail

specify whether data is detail data or aggregated data (relational reports only)

Report Creation:Select All Data

able to choose “Select All” data items from the Select Data dialog box.

Report Creation:Select Data in View

use the Select Data dialog box to select data while viewing a report.

Report Creation:Copy Section

create a new report section that is a complete copy of another section. This capability is new in SAS Web Report Studio 4.3.

Advanced Report Creation:Create Cascade Prompts

create cascading prompts.

Advanced Report Creation:Create Report Links

create linked reports.

Advanced Report Creation:Create Remote Application Report Links

create linked reports that link to another SAS application. This capability is new in SAS Web Report Studio 4.3.

Advanced Report Creation:Advanced Edit

enable users to perform the following functions:

• Isolate
• Member Properties
• Suppress Empty

The Report Creation: Basic Edit capability is a prerequisite for this capability. In SAS Web Report Studio, the Include Member with Only Missing Values menu item is available only for multidimensional data sources. The Suppress Empty function in the Advanced Edit capability is required in order for users of multidimensional data sources to view and use the Include Member with Only Missing Values menu item under the Data Menu in SAS Web Report Studio.

Advanced Report Creation:Update Resources

update an invalid information map reference that is contained in a report definition. If you are using (or if you migrated from) SAS Web Report Studio 4.2, then the name of this capability is Repair Report.

Advanced Scheduling:Distribute

schedule a report distribution.

Advanced Scheduling:Save Archive

archive file versions. When creating a pre-generated version of a report (for example, a scheduled report), a version of the report is archived as a PDF file. Reports with archived versions are visually different in report selection dialog boxes, and access is allowed to these archived versions.

Advanced Scheduling:Schedule Any Report

schedule any report to which the users have WriteMetadata access, including the reports that they have authored.

Advanced Scheduling:Schedule Folder

schedule a folder.

Administrative:Manage Distribution List

create, edit, or delete a distribution list.

CAUTION:

Use of this capability creates a new physical table. Therefore, this capability must be restricted to few users. The distribution list contains e-mail addresses. Initially, this capability is not assigned to any SAS Web Report Studio role. An administrator can assign this capability to the Advanced role, or create a new role (for example, a role named as Manage Distribution) specifically for this capability and assign this role to a restricted number of users.   

Some recommendations I noted where:

• On Windows 2008 64-bit size: 4Gb of RAM per core. 1.5 x physical RAM for page file
• change default SORTSIZE to equal between 256MB-512MB (removes need for util files if it can be done in memory)
• up BUFSIZE to align with SAN storage stripe size
• undocumented settings UBUFSUZE and IBUFSIZE
• change default SAS MEMSIZE to between 512MB and 2Gb
• recommend between 30 and 50MB I/O throughput per core
• 9.3 metadata recommendations, separate server 4 cores, 4GB RAM – small, 8GB – med, 16GB large, I/O doesn’t really matter

One of the areas Margaret covered was the issues with file cache within Windows 2008.  Apparently Microsoft has re-written the file cahce system in Windows 2008 and R1 and then again in Windows 2008 R2.  Both of these versions have major problems with SAS environments that have a high I/O footprint.  SAS have raised the issue with Microsoft but have yet to have a resolution.

Interesting point was we experienced the same issue in Windows 2003:

Problem Note 36664: Potential issues with heavy SAS® I/O workloads on Windows 2003, 32- or 64-bit operating systems

You can read an excellent paper Margaret has authored at:

370-2011: Configuration and Tuning Guidelines for SAS®9 in Microsoft Windows Server 2008

Some other papers you may want to reference are:

The client has standardised on vSphere and I thought great SAS 9.2 supports vSphere (as much as the following SAS support page say’s SAS supports virtualisation)

SAS^® Product Support for Virtualization Environments

But after talking to Oracle about Weblogic support on VMware the answer is no, Oracle do not support any Oracle product on VMWare.

To quote from Oracle Metalink note: 249212.1 (found on a comment in response to another blog) :

“Oracle has not certified any of its products on VMware virtualized environments. Oracle Support will assist customers running Oracle products on VMware in the following manner: Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware. ”

“If a problem is a known Oracle issue, Oracle support will recommend the appropriate solution on the native OS. If that solution does not work in the VMware virtualized environment, the customer will be referred to VMware
for support. When the customer can demonstrate that the Oracle solution does not work when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required.”

So what does Oracle Weblogic support in terms of virtualisation?  OVM of course.  Does SAS support OVM, of course not! (well actually this doesn’t seem to be true more on that later)

If we look at  SAS Supported UNIX Operating Environments we see that Oracle Enterprise Linux (OEL) is not on the list. If we look at  SAS Support for Alternative Operating Systems we see that OEL is not support but SAS will offer “best efforts” support.

The question is does OVM require OEL?

Well the answer is no, according to this Oracle VM Server for x86 FAQ OVM support Red Hat Linux (REHL).  So in theory we can run Weblogic on REHL in a OVM environment.

Is this supported by Oracle, yes it seems from all the links above.

Is it supported by SAS, well waiting to here back officially, but remember this SAS^® Product Support for Virtualization Environments states that they support any virtualisation (but have the same get out of jail free card as Oracle), so that should be a yes, SAS should support the use of OVM!

Now the real issue if after installing SAS eBI, using Oracle Weblogic on RHEL 5 within a Oracle VM environment we strike a problem, who the heck do we ring first?  (you know its going to be SAS Support right

There is a good SAS paper on how to test the I/O throughput of a SAS server on both Windows and Linux/Unix including code examples you can use.

You can find the paper here: http://support.sas.com/rnd/scalability/grid/grid_testingbench.pdf

If you run the code you might get the following error:

“ERROR: Shell escape is not valid in this SAS session.”

If so you will need to turn x commands on for the server, a SAS note outlining how to do that is here:

Problem Note 41058: Unable to submit X commands from SAS® Enterprise Guide® connecting to a SAS® Metadata Server when running SAS® 9.2 or later

grid requires 30-50mb I/O through put per node

They typically are trying to use the Microsoft Systems Management Server (SMS) capability to create a no touch way of installing the SAS Clients (Enterprise Guide, AMO etc) on users PC’s.

In the SAS Administrators group chat at SAS Global Forum the folks from SAS R&D said they recommend that rather than packaging the SAS Client install via SMS it is a much better option to use a install recorder function of the SAS Deployment Wizard / SAS Install Depot and create a SMS package that calls that.

The SAS Install Depot will need to be made available to all the users PC’s via a mapped drive etc, but you can secure it so the users can’t see it and its only accessible for the installer account that SMS is using to do the deployment.

SAS have posted a set of tips and techniques at:

Installation Note 37041: SAS® 9.2 quiet deployment tips and techniques

So pass the link onto your IT people if they are struggling to package up the SAS Clients as automated install packages.

Go Linux.

Anyway once we got onto the discussion of I/O footprints we of course got onto the discussion of SAS on VMware.

Margaret mentioned she had just posted a Best Practice guide on SAS and VMware, which you can find here:

http://support.sas.com/resources/papers/MovingVirtuaVMware.pdf

As with all the papers Margaret seems to publish she actually puts the software through its paces in multiple scenarios before she posts her recommendations, so if you are looking at installing SAS on VMware its a paper well worth reading.

And importantly it was written in conjunction (or at least reviewed by) VMware themselves before publishing which is good news.

Actually overheard another conversation on Wednesday between a VMware person and a SAS R&D bod, which indicated that SAS was struggling to get to the right people in VMware for a while to form the relationships required, but that in the last few months the two companies have managed to connect the right people at the right level and things have accelerated quickly.  Good news for all SAS customers as virtualisation becomes more prevalent.

I wonder if the change is due to Oracle pushing its OVM platform much harder these days (some would say even mandating it) or its was just a matter of right people, right time?

Anyho main thing is the days of “no we don’t recommend running SAS on virtualised environments” seems a thing of the past, so one more step in the process of making SAS part of a standard operating environment for customers and less of an orphan.

We have got SAS 9.2 (actually SAS Grid but thats irrelevant for this post) installed on RedHat 5 Linux.  As we are using Linux and not Windows we lose the standard integration with Active Directory.  We didn’t want to implement PAM integration with AD (mainly because nobody can articulate clearly all the steps required to get it working).

So we were left with Host authentication. As we only had a few users in this phase thats not so bad, but as we have a few servers (i.e Grid) I really wanted a easy way to avoid creating userid’s on each server.

Aha I thought Ill use internal SAS user id’s and then get the user to inherit a trusted/host user id to run the SAS processes.

So I setup the user in Metadata with an internal id, made sure they didn’t have a standard user identity (i.e username/pwd against DefaultAuth).  Also assigned the user to be a member of SAS General Servers (to inherit sassrv, planned to change this when it worked) and for extra fun added a OraAuth with a username/pwd for the Oracle DB and assigned the user as a member of that as well.

So into DI Studio and Information Map Studio as the user using the internal userid/pwd and:

• Connect to metadata – tick
• Access SAS app – tick
• Access and SAS Table – tick
• Run a query – tick
• Access the Oracle table – tick
• Run a query – tick

Now connect using EG 4.3 with same internal userid/pwd and:

• Access metadata – tick
• Access SAS App – nope

mmmmm talk to helpful onsite SAS installer, he could get it to work by adding DefaultAuth in the EG connection in the Auth Domain field.  Ok try that and yip all good.  So carry on testing.

• Access SAS App – tick
• Access SAS Table – tick
• Run query – tick
• Access Oracle Table – nope

mmmmm get a could not access Auth Domain.

So into some more tesing, worked out you can type what ever you ant in the Auth Domain connection to get this behaviour (i.e x would do the same as DefaultAuth).

As you do we tried all the combinations we could think of, and no cigar.  So helpful SAS installer logged tech suport track and just go this back.:

How to Configure SAS Token Authentication

Followed the distructions and wahoo we have lift off.

So it looks like you can’t use the standard Username/Password authentication method if you want to use internal userid’s/passwords and EG 4.3.

But SAS Token Authentication does work.

Now to test all the other options to see if this change effects anything else, oh the joy of testing …..

One that is granted standard user rights(or developer user rights) and one that is granted administrator rights.

(remember nobody should use sasadm should they!)

The reason is that it stops the administrator users from accidentally doing something they didn’t mean to when in the SAS environment (like delete a workspace server definition), as they will be using their normal account login.

When they need to do something gnarly they use their Administrator login and believe me when I say it does put you in a different head space.

(again your not using sasadm are you!, and we also don’t recommend shared admin user accounts, you need to be able to trace changes back to the admin user who did them)

In SAS 9.1 you were forced to created to host userid’s or Active Directory userid’s for each admin.

In SAS 9.2 you can use a dual account technique outlined here.

Its a short article so copied it here to save me one click later when I need it again.

Users, Groups, and RolesHow to Create a Dual User

To enable someone to alternately function as an administrator and as a nonadministrator, create two user definitions for that person as follows:

• One definition is based on an internal account and is a member of the SAS Administrators group. See Add Administrators
• The other definition is based on an external account and is not a member of the SAS Administrators group. See Add Regular Users.

Dual users log on with their internal account when they need administrative privileges and with their external account the rest of the time.

Note:   The only way to make someone a dual user is to give that person two user definitions, each based on a different account. You can’t create a dual user by adding a login to a definition that already has an internal account or by adding two logins to one definition.
Note:   Dual users should use a dedicated client-side connection profile for their internal account. In that profile, the user should leave the Authentication Domain field blank. This optimizes credential reuse.