SAS 9.1 | Blogging about all things SAS

March 5, 2010

SAS Management Console 9.1.3 – Invalid Templates

Filed under: SAS 9.1 — Tags: sas SMC invalid templates — Shane Gibson @ 10:10 pm

Its been a full on week what with the SAS 9.2 migration and a whole lot of other work happening on another project.

Also this week I seem to have been shown a lot of tips and tricks I didn’t know you could do.

One of them was found by Rob and passed on to me (thanks Rob).

The issue was in SAS 9.1.3 Management Console and related to some of the screens not having all the relevant fields displayed. As an example the Libname edit screen might be missing the field where you normally define the file path.

The fix was to go into the Metadata Manager > Resource Templates tree in SMC and delete the relevant template.

Then logout of SMC and log back in and SAS will automagically re-create a new template, and it will be valid.

Comments (0)

February 14, 2010

DI Studio – Missing Nodes – DentityExpansionLimit=1000000

Filed under: DI Studio, SAS 9.1 — Tags: DentityExpansionLimit, SAS DI Studio — Shane Gibson @ 8:35 pm

I needed to install the SAS 9.1.3 Clients into a new Citrix server (yes it is unsupported in 9.1.3 but has worked well for the last 4 years, just don’t ask SAS Tech Support for help of course).

After the installs were all complete and we started migrating users from our old Citrix server, they started complaining of issues with DI Studio. These included:

- Nodes missing in the Inventory tree

- Options missing in the custom transform / custom code nodes

Adding the following option to the DI Studio ini file fixed both issues:

-DentityExpansionLimit=1000000

No idea why it fixed it and only reference on support.sas.com is a similar setting for Information Map studio here to fix it not being able to open more than 999 objects.

But as always fix it first, question it later.

Comments (0)

February 13, 2010

Creating Information Map Libnames (9.1.3)

Filed under: Architecture and Administration, SAS 9.1 — Tags: Information Map Libnames, SAS 9.1, sasioime — Shane Gibson @ 9:02 pm

If you want to use a Information Map as a data source for tasks such as DI Studio Jobs, Stored Processes, or building OLAP cubes, you can create a SAS Library that points to a folder that contains the Information Maps.

Each Information Map then gets treated as a table in the library.

To do this either use the following SAS code:

libname ImapLib sasioime
user=”username”
pw=”password”
metaserver=”servername”
metaport=8561
metarepository=”Foundation”
mappath=”/BIP Tree/InfoMaps/sales”

Of course you need to add your on environment settings for the variables.

Or you can create it in metadata by creating a libname with:

Create a generic libname
Type = sasioime
Options = user=”username” pw=”password” metaserver=”servername” metaport=8561 metarepository=”Foundation” mappath=”/BIP Tree/InfoMaps/sales”

Issues to be aware of:

It is slow as you are going through multiple layers to get to the data (i.e Libname > Infomap > Query and Reporting Services > Libname > Data)
The user is hard coded for the libname
If the libname has fields defined with gaps in the names the SAS Libname will not show the column.

Comments (0)

February 2, 2010

SAS 9.1.3 Client Metadata Profile Paths

Filed under: Architecture and Administration, SAS 9.1 — Tags: SAS .swa files, SAS 9.1.3 Metadata Profile Path — Shane Gibson @ 10:41 pm

I have been doing an install of SAS 9.1.3 clients on a a Citrix server (yes I know it is not supported) and all worked fine with Enterprise Guide etc but all the Java clients wouldn’t run.

Everytime they started up they couldn’t find some path and just gave an error saying path could not be found.

We troubled shooted it to the fact that we had changed the Citrix server layout from the last server and had used different drive mappings. As part of this we had moved where the SAS Client Metadata Profile settings (.swa files) were stored.

So when SAS Data Integration Studio, Management Console etc started they looked for the .swa files in the location defined on the previous Citrix server (as the Citirix profile travels with the user across servers).

The fix was to edit the app.smc file in the users directory (for us C:\Documents and Settings\~user). In that file is a line:

WorkspacePath=C:\\Documents and Settings\\~user\\Workspaces

Which defines where the Metadata profile files (.swa) are stored.

the other options (thanks SAS tech Support) is to put the following option on the clients .ini file (i.e C:\Program Files\SAS\SASManagementConsole\9.1\sasmc.ini):

-Duser.home=C:\SAS

This will then make all users access the .swa files under a workspace dir under this path. But of course they all access the same ones, so lock them down so they can’t be changed.

Trick for young players on that one, make sure it is after the “-Dsas.app.class.dirs=” option as if you add it at the end it gets ignored for some reason.

And of course do it for each of the SAS clients.

One of the

Comments (0)

November 12, 2009

SAS 9.1 Toolpool entries dead in SAS 9.2, we can resurrect the dead!

Filed under: SAS 9.1, SAS 9.2 — Shane Gibson @ 9:17 pm

I have heard from a few SAS customers who have been using some of the SAS Toolpool entries in SAS 9.1 that they no longer work with SAS 9.2.

And as of course they are toolpool entries they are not officially supported by SAS so there may not be an immediate upgrade path to SAS 9.2.

But of course some of them are still providing additional functionality that is not available in SAS 9.2.

So I have been thinking of ways to keep the development team busy over Xmas, and recreating some of these might be the ticket.

So if you have one that you need, let us know what it does, and you will never know what Santa and his elves may deliver

Please don’t send us a copy (we write all our sasInct Portlets from scratch) but feel free to post here what it does, or create a support track at http://support.sasinct.com/login

And lastly we will post any that we develop on our website for the usual one off USD $1,000, unlimited users/no expiration, (these elves are not cheap) and of course if it is a biggy (aka Metadata Explorer etc) then we probably wont.

Comments (0)

October 21, 2009

October 19, 2009

SAS 9.1.3 I/O Errors on a Windows 2003 server

Filed under: Architecture and Administration, SAS 9.1 — Tags: SAS 9.1 Disk Errors, SAS 9.1 I/O Errors — Shane Gibson @ 10:10 pm

A while ago we had a major problem as a result of upgrading our Windows servers and operating system, where we started to get a large number of I/O errors when running our batch schedule.

In the end we fixed it by changing the Paged Pool Usage Maximum set from 80% to 40% on the servers as our Windows guru’s worked out that SAS was filling the Windows cache faster than Windows could clear it, causing the I/O errors.

SAS support also suggested we follow this instrauctions in this tech support note:

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

If you have struck another fix then let me know.

Comments (0)

October 1, 2009

SAS 9.1 / WRS 3.1 – Changes to Metadata Roles takes it time

Filed under: Architecture and Administration, SAS 9.1, Web Report Studio, x - Notes to Self — Shane Gibson @ 7:00 pm

While researching and testing the default Web Report Studio metadata security I noticed this little trick for young players, which means changes to WRS/WRV Metadata Security for a user are not instantly applied/recognised in WRS/WRV.

Words from the SAS tech support note “Changes to SAS® Web Report Studio role memberships might not immediately be enforced“:

“SAS Web Report Studio analyzes role memberships every 30 minutes. So, for example, if you move a user from the WRS Report Author role to the WRS Report Consumer role, the user will continue to have author privileges until the next time that he logs in after the next role membership analysis is performed. ”

So effectively the WRS/WRV applications are caching the Metadata security to remove the need for the web server to query the Metadata Server each time a user logins.

So try not to be fast when testing your WRS Metadata security changes, else you will think you have done something wrong. And remember to logout and log back in after the cache has been updated.

You can update the LocalProperties.xml file to change the refresh time, and therefore make the changes appear sooner. Details on how to do this are in the SAS Tech Support note.

Comments (0)

September 30, 2009

SAS 9.1 / WRS 3.1 Metadata Roles defined

Filed under: Architecture and Administration, SAS 9.1, Web Report Studio, x - Notes to Self — Tags: SAS 9.1 Web Report Studio Metadata Roles — Shane Gibson @ 7:29 pm

Researching definitions for each of the WRS default roles as part of the Advanced Metadata Security course.

The roles are documented in the SAS 9.1.3 Intelligence Platform: Web Application Administration Guide, Second Edition on page 130. What it says is:

“By default, everyone who can log on to SAS Web Report Studio can view, edit, and create new reports.

To implement security, each user of SAS Web Report Studio can be assigned to one or more standard roles. A user’s role assignments determine which SAS Web Report Studio menu items are available to that user.

By default, all SAS Web Report Studio users implicitly have the role. However, if you explicitly assign any members to the role, then only the explicitly-assigned members will have the role. This enables you to start using SAS Web Report Studio immediately after installation, yet still have the ability to restrict user access when locking down your deployment.

Each role is a superset of the preceding role. For example, members of the “WRS Report Author” role have all the permissions that apply to the “WRS Report Consumer”.

Once you explicitly assign members to a role, you must explicitly assign membersto each superset role. For example, if you assign members to the “WRS ReportAuthor” role, then all of the subsequent superset roles (in this example, “WRSAdvanced User”) also become explicitly-assigned roles. The reason is that WRSAdvanced User is a superset of WRS Report Author.

Once you explicitly assign members to a role, then any user who is not assigned to a role, or who has no metadata identity, can only view reports and manipulate reports (for example, select new data items to view in report objects).

WRS Report Consumer	Users who have this role can view reports and manipulate report data in the View Report view. Users can copy, move, save, rename, or delete reports. Users cannot create new reports with the report builder or report wizard.
WRS Report Author *	In addition to the abilities assigned to WRS Report Consumers, users who have this role can create reports with the report builder or report wizard. Users can also schedule reports.
WRS Advanced User	In addition to the abilities assigned to WRS Report Authors, users who have this role can distribute reports. Users cannot create or delete recipient lists that are used for report distribution.
WRS Administrator	Users who have this role can perform all tasks that are associated with SAS Web Report Studio, including the ability to create and delete recipient lists that are used for report distribution. This role provides full permissions to SAS Web Report Studio and should be safeguarded accordingly. This role provides application level administrator functionality. However, this role has no effect on metadata access (authorization) rights to report data.
WRS Prohibited	Users who have this role cannot log on to SAS Web Report Studio. Regardless of the user’s membership in any of the previous roles, if the user attempts to log on, the logon page displays the following error message: “This user is not allowed to access SAS Web Report Studio. Please contact your administrator.” Some organizations might apply this role for users who are allowed to access some SAS applications but not SAS Web Report Studio. Alternatively, if an organization has multiple Web Report Studio installations, this role can be used to restrict some users from specific instances. The corresponding metadata group entity is not created during installation. You must manually create the group in metadata if you want to use this user role.
*By default, WRS Report Authors can schedule reports, though you can change the default behavior and limit the scheduling feature to WRS Advanced Users. To do this, in your LocalProperties.xml file, specify true for the schedulingRequiresAdvancedUserRole property.

Comments (0)

September 29, 2009

SAS 9.1.3 Metadata Security – Go ask your mother

Filed under: All Things Metadata, Architecture and Administration, SAS 9.1 — Tags: SAS Metadata Security — Shane Gibson @ 4:33 pm

So i’m attending the advanced metadata security course for SAS 9.1.3 at the moment.

It is a complex area and really does my head in. But here is a way that (I think) I understand how it works.

There are two different rules that are applied to any metadata object:

1) Direct – When security is applied directly to an object (i.e in Management Console you HAVE ticked a metadata security box for the object, so its white or green)

2) Inherited – When security is not applied to an object, it is inherited (i.e in Management Console you have NOT ticked a metadata security box for the object, so its grey)

So here is how I think the rules for each of these works:

1) Direct – when Security is directly applied to an object.

The identity hierarchy model applies. This means it looks at the levels permissions have been applied to the object and whether it is applied as an ACT or ACE.

Permissions closest to user wins
A deny always wins over a grant, if at the same level (and type)
ACE’s always win over ACT’s

Or in something I can understand:

If you ask your mother and she says yes, then you ask your father and he says no, the answer is no (deny at same level)
If you ask your mother and she says yes, then you ask your grandfather and he says no, the answer is yes (permission closest to user)
If you ask you mother (ACE) and she says yes, then you ask your teacher (ACT) and she says no, then the answer is yes (ACE always wins)

2) Inherited – When security is not applied to an object

The inheritance model applies. This means every permission is placed in a bucket and if a grant is found anywhere, you have got it.

Levels don’t count
A single grant always wins over any and all denies
ACE’s vs ACT’s have no impact

Or using the same analogy:

You are at a family reunion, you yell out a question, somebody yells yes, the answer is yes

And the last thing I learnt was if somebody said no (i.e you can’t see something as a user) then if you ask why, the only answer you will get is “because I said so”.

Which means it is very very hard to find out what stopped you seeing it. Although I believe Paul at metacoda.com has some cool tools in the pipeline to help with this.

* Thanks to Adam Player for a great course and even better analogy's!

Comments (0)

Older Posts »