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.

So here are the links (please note I have only included links to SAS 9.2 TM2Mx, not TM1M0):

• SAS 9.2 Supported Operating Environments
• SAS 9.2 Support for Web Application Servers and HTTP Servers
• SAS 9.2 Support for Additional Software Products
• SAS 9.2 Support for Web Browsers and Plug-Ins
• SAS® Product Support for Virtualization Environments
• SAS/ACCESS 9.2 Validation Matrix
• SAS 9.2 (TM2Mx) System requirements
• SAS 9.2 Support for Java Development Kits
• SAS 9.2 Support for Java Runtime Environments
• Metadata Bridges

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

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.

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

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.

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

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.

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.

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