Posted by Shane Gibson on July 9, 2010
So we have a few customers where we have installed SAS 9.2 M2 on either on a live or a test environment.
We wanted to test applying the M3 maintenance release before the 4.3 clients come out as there are dependent.
So the process is to apparently run the download manager again and the install depot will be updated.
But before you do this you will need to talk to your account manager to get a new license code, or the download manager wont update the install depot.
Is it me or just this seem like one extra unnecessary step to apply a maintenance release for software a customer has paid for?
Or have I got the wrong end of the stick on this one and this is not required?
And of course when searching for documentation on installing/applying the M3 release you get nada.
Posted by Shane Gibson on May 3, 2010
I have been doing a bit more Solution Architecture work around SAS 9.2 lately, and I keep needing to validate what versions of Operating System works with what version of SAS etc.
So here are the links (please note I have only included links to SAS 9.2 TM2Mx, not TM1M0):
Posted by Shane Gibson on April 9, 2010
I have been doing a number of installations of SAS 9.2 eBI / eDI over the last week, to get a bit of practice in.
When I did installs on VM instances everything worked fine.
But when I did the install on a native machine, none of the Web Apps (SAS Portal, Web Report Studio etc) would deploy and I would just get an error when trying to access the url via a browser (i.e /SASPortal/).
Eventually I tracked it down to an issue with the IPv6 setting.
So I changed the setting in the wrapper.conf file under:
<sas-config-dir>/Lev1/Web/Applications/RemoteServices/
And changed the line:
wrapper.java.additional.6=-Djava.net.preferIPv4Stack=true -Djava.net.preferIPv6Addresses=false -Dmulticast_udp_ip_ttl=0
to become
wrapper.java.additional.6=-Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true -Dmulticast_udp_ip_ttl=0
So effectively switching from IPv4 to IPv6. Reboot the server and we are away.
No idea what IPv6 does so need to do some research.
Update: May 2010
There is some more detail on IPv4 vs IPv6 and SAS 9.2 in this tech support note:
Usage Note 37509: Using SAS® 9.2 successfully with Dynamic Host Configuration Protocol (DHCP) in Microsoft Windows operating environments
Posted by Shane Gibson on April 5, 2010
In SAS 9.2 two different typos of connection profiles are stored for each user, one for windows applications (AMO, EG etc) and the pother for Java applications (DI Studio, Info Map Studio etc).
Java Applications:
Connection profiles are stored on the hosts of the desktop applications at C:\Documents and Settings\user name\Application Data\SAS\MetadataServerProfiles. In the Windows Vista operating environment, the path is C:\Users\user name\AppData\Roaming\SAS\MetadataServerProfiles. The names of the profiles use the file extension.swa.
Windows Applications:
These profiles are stored in the ConfigurationV42.xml file in the users home directory C:\Documents and Settings\user name\Application Data\SAS\MetadataServerProfiles.
And of course recommended good practice is to only change these files via the profile editing capability provided within each of the SAS client applications.
Posted by Shane Gibson on March 6, 2010
Just saw this post on Chris H’s blog here and I am replicating it so I can find it when I need it. (cause half my posts are there so I can find them when I need them)
If you want to know what version of SAS/Access works with what operating system and what release and what database etc, then look here:
http://support.sas.com/matrix/list?SAS=All&Engine=All&OS=All&googleTrack=on
Posted by Shane Gibson on February 13, 2010
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.
Posted by Shane Gibson on February 2, 2010
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
Posted by Shane Gibson on October 19, 2009
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.
Posted by Shane Gibson on October 1, 2009
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.
Posted by Shane Gibson on September 30, 2009
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.
|