Performing Post-migration Tasks

Metadata Server Tier Post-migration Tasks

	Running and Reviewing the Authorization Differences Reports
	Update Third-Party Software Server Definitions

Running and Reviewing the Authorization Differences Reports

	Impact of Migration on Access Controls
	About the Authorization Differences Reports
	Run Authorization Differences Reports
	Identities Whose Access Has Changed
	Identities Who Are Removed or Added
	Causes of Authorization Differences
	Addressing Authorization Differences

Impact of Migration on Access Controls

The migration process preserves all metadata layer permission settings. However, the migration process can alter effective access to some metadata objects. The differences in effective access are caused by differences in access control inheritance. Access control inheritance for a migrated object can differ from access control inheritance for the corresponding original object for either or both of these reasons:

changes in the access control inheritance rules. The rules that govern access control inheritance are slightly different in 9.2 than they were in 9.1. For example, in SAS 9.2 tables, cubes, libraries, and OLAP schemas inherit permissions from only their parent folders. Permissions that these objects formerly inherited through their parent application server are no longer applicable.
relocation of objects. The migration process relocates some objects. For example, the process moves each ungrouped library into its own folder under SAS Folders\Shared Data. Another example is folders in custom repositories. Permissions can change for custom repository folders because in SAS 9.2 they become parented by the root folder of the foundation repository. When an object is moved to a new location, access to that object might change, because the object's new parent might have different settings than its old parent did.

About the Authorization Differences Reports

SAS provides reports that identify differences in access between your 9.1.3 environment and your 9.2 environment. You should run these reports after your migration has finished. For more information, see Run Authorization Differences Reports. Here are some key points about the reports:

There are five reports, each for a specific type of object (libraries, tables, folders, OLAP schemas, and cubes). These are the objects that are most likely to have authorization differences.
The reports identify differences in effective permissions. Effective permissions are a calculation of the net effect of all applicable permission settings in the metadata authorization layer.
Each report lists only those objects that have authorization differences. The reports are not inventory listings.
Each report lists objects by folder location and in alphabetical order within each folder location. For each object that has access distinctions, a separate table of changes is displayed.

Note: Even if a report has a long list of objects, it is usually the case that only a few folder locations are involved. Most libraries, tables, cubes, and schemas don't have explicit settings. Instead, these objects inherit settings from their parent folders. The migration process doesn't add or remove permissions that have been set on these objects.
The reports don't reflect additional access or any changes that have been granted to the SAS Administrators group or to the SAS Administrator in a 9.2 environment. This group either includes only the original SAS Administrator (sasadm) or includes both the original SAS Administrator and the members of your original SAS Administrators group.
The reports don't provide the reason why a particular access difference occurs.

Note: If there are differences in Name field values and Display Name field values between SAS 9.1.3 and SAS 9.2, you might see output similar to the following:

Removed: SAS Trusted User

Added: sastrust

Run Authorization Differences Reports

A good practice is to run the authorization differences reports on the SAS Metadata Server machine. Authorization differences reports list changes to metadata object inheritance relationships for libraries, tables, OLAP schema, and cubes. You manually run these reports after the SAS Deployment Wizard has finished executing on your SAS 9.2 migrated system.

[Example of a migration security report]

To run the authorization differences reports, follow these steps:

Log on to the metadata server machine.
Make sure that the SAS Deployment Wizard successfully extracted the authorization data from metadata.

The SAS Deployment Wizard extracts authorization information for folders, libraries, tables, OLAP schemas, and cubes and stores the information in data sets before it makes changes to the metadata. The wizard names these data sets bupxxxxx and stores them in the MetadataServer/reports directory.

Check the log for the metadata server migration log for encoding and extraction errors. Search for SecExtrBefore.sas to locate where in the log the program was executed, and where errors and warnings for this process would be found. The log resides here:
- Windows:
  
  SAS-configuration-directory\Levn\Logs\Configure\
  
  metadatasrv_configureMetadata_yyyy-mm-dd.hh.mm.log
- UNIX and z/OS:
  
  SAS-configuration-directory/Levn/Logs/Configure/metadatasrv_configureMetadata_yyyy-mm-dd.hh.mm.log
Copy the report (SecRptAfter.sas) to the reports directory under (Levn/SASMeta/MetadataServer).

The report resides in the following location:
- Windows:
  
  SAS-installation-directory\SASFoundation\9.2\
  
  core\sasmisc\sasconf\metadatasrv\config\Deployment
- UNIX:
  
  SAS-installation-directory/SASFoundation/9.2/
  
  misc/base/sasconf/metadatasrv/config/Deployment
- z/OS:
  
  SAS-installation-directory/SASFoundation/9.2/
  
  base/sasconf/metadatasrv/config/Deployment
For example, on Windows, the command would resemble the following:

copy "C:\Program Files\SAS\SASFoundation\9.2\core\sasmisc\sasconf\

metadatasrv\config\Deployment\SecRptAfter.sas"

C:\SAS\Config\Lev1\SASMeta\MetadataServer\reports
Using a text editor, open SecRptAfter.sas, add metadata server connection information and the report directory path, and then save the file. This information should be on the first two lines of the file. The report directory path should be an absolute path. The following examples use common SAS configuration paths, but this path can be specific to your site. The user credentials that you specify must be for an unrestricted user. (Either the user ID is listed in adminUsers.txt with an asterisk beside it, or the user ID is a member of the Metadata Server: Unrestricted role.)

Note: Depending on your operating system, the path must end with either a backslash (\, Windows) or with a forward slash (/, UNIX and z/OS).
- Windows:
  
  options metaserver=localhost metaport=8561 metauser="mydomain\myuserid" metapass="mypassword";
  
  %let rptdir="SAS-config-dir\Levn\SASMeta\MetadataServer\reports\";
- UNIX:
  
  options metaserver=localhost metaport=8561 metauser="myuserid" metapass="mypassword";
  
  %let rptdir="SAS-config-dir/Levn/SASMeta/MetadataServer/reports/";
- z/OS:
  
  options metaserver=localhost metaport=8561 metauser="myuserid" metapass="mypassword";
  
  %let rptdir="SAS-config-dir/Levn/SASMeta/MetadataServer/reports/";
  
  filename sampsrc "SAS-install-dir/SASFoundation/9.2/base";
Open an operating system command prompt, change directory to the reports directory, and then run the report using the appropriate SAS invocation for your operating system.

On Windows and UNIX, we recommend that you run the reports using the UTF-8 encoding option. Use a non-UTF-8 execution command only when an error during extraction of the report files indicates that UTF-8 could not be used.

Here is an example that shows how to run the SAS command for UTF-8 systems:
- Windows:
  
  "C:\Program Files\SAS\SASFoundation\9.2\sas" -config "C:\Program Files\SAS\SASFoundation\9.2\nls\u8\SASV9.CFG" -sysin SecRptAfter.sas
- UNIX:
  
  /usr/local/SAS2/SASFoundation/9.2/bin/sas_u8 -sysin SecRptAfter.sas
- z/OS:
  
  On z/OS, there is no UTF-8 option. The report always uses the default session encoding.
Here is an example that shows how to run the SAS command for non-UTF-8 systems:
- Windows:
  
  "C:\Program Files\SAS\SASFoundation\9.2\sas" -config "C:\Program Files\SAS\SASFoundation\9.2\SASV9.CFG" -sysin SecRptAfter.sas
- UNIX:
  
  /usr/local/SAS2/SASFoundation/9.2/sas -sysin SecRptAfter.sas
- z/OS:
  
  /usr/lpp/SAS/Installs/MITB/SAS92/SASFoundation/9.2/sas.sh
  
  -input /u/mitbsas/ServerConfig92E/Lev1/SASMeta/MetadataServer/reports/SecRptAfter.sas
  
  -log /u/mitbsas/ServerConfig92E/Lev1/SASMeta/MetadataServer/reports/SecRptAfter.log
The report generates data sets and reports in the reports directory. Log output will also be in the report directory.
Open the HTML output in a Web browser to view the reports.
- librpt.html - Security changes for libraries
- ptabrpt.html - Security changes for tables
- oschsrpt.html - Security changes for OLAP schemas
- cubesrpt.html - Security changes for cubes
- fldrrpt.html - Security changes for folders
Note: On z/OS, contact the administrator for the HTTP server and request that the reports directory be available. As an alternative, you can copy the HTML and GIF files from the reports directory to another location that is already available through the HTTP server. You might want to restrict access to these reports, so consider the security of the directories to which they are copied and the audience which might access them.

Rerunning the reports can be useful when you are making authorization changes and want to analyze the effects of your changes. In these situations, be sure to copy the original reports so that you can compare newer versions of the reports with your original reports.

Identities Whose Access Has Changed

The following figure depicts part of the libraries report from an example migration.

Example: Authorization Differences for a Library

[Example: Authorization Differences for a Library]

The report provides basic identifying information for the DemoLibrary and displays a list of access changes. Here are some details:

The Location is the object's new, post-migration location for SAS 9.2.
The Changed rows contain the object's new, post-migration settings for SAS 9.2. In these rows, the symbols indicate effective access as grant , denial , or conditional grant .
The Original rows contain the object's pre-migration settings for SAS 9.1.

Note: In SAS 9.1.3, the Authorization tab does not always display effective permissions. For this reason, the settings in the Original rows in the reports might not always match the settings that are displayed in the SAS 9.1.3 Authorization tab. The SAS 9.2 Authorization tab always displays effective permissions.
The Change Indicator rows separate entries for different identities. In these rows, the down arrows help draw attention to the settings that differ.

Note: This object happens to have only access changes. An object can have any combination of access changes, added identities, and removed identities. [cautionend]

Identities Who Are Removed or Added

The following figure depicts part of the cubes report from an example migration.

Example: Authorization Differences for a Cube

[Example: Authorization Differences for a Cube]

The change table in the preceding figure indicates that UserA is removed. This means that UserA is listed on this cube's SAS 9.1 Authorization tab but is not listed on this cube's SAS 9.2 Authorization tab. It is important to understand the following points:

UserA has not been removed from the environment.
No explicit settings (or ACT settings) for UserA have been removed from this cube (or from any of this cube's parents).
The permission settings that the report displays for UserA are for the original environment.

Note: For an added identity, the displayed permissions indicate the identity's access in the SAS 9.2 environment.
UserA's access to this cube is not necessarily discontinued. UserA is just no longer a named participant in the permission settings for this cube.

Note: If you want to look up the effective permissions that UserA has for this cube in SAS 9.2, click the Advanced button on the cube's Authorization tab and select the Explore Permissions tab. The Advanced button is available to only unrestricted users.
Removal of UserA from this cube's Authorization tab is a side effect of changes in access control inheritance. The report documents that side effect.

Note: This object happens to have only one removed identity. An object can have any combination of access changes, added identities, and removed identities. [cautionend]

Causes of Authorization Differences

If you migrate an object that derives a grant from an inheritance rule that is discontinued in SAS 9.2, access to that object might be reduced. The following inheritance rules are discontinued in SAS 9.2:

cube OLAP schema application server
table library application server
DBMS table DBMS schema DBMS server

The following figure depicts some of these rules.

Selected Inheritance Rules

[Selected Inheritance Rules]

In the preceding figure, the solid arrows indicate selected SAS 9.2 inheritance rules. The hollow arrows indicate selected inheritance rules that existed in SAS 9.1 but are discontinued in SAS 9.2. In SAS 9.2, libraries, tables, OLAP schemas, and cubes inherit from only their parent folders.

Note: You can use the Inheritance tab to identify any item's parents. In SAS 9.2, you access this tab by clicking the Advanced button on any object's Authorization tab. The Advanced button is available to only unrestricted users. [cautionend]

Here are some other causes of authorization differences:

If you migrate a custom repository, ReadMetadata access to that repository (and, through inheritance, its contents) might be expanded. The new repository is parented by both its repository ACT and by the SAS Folders node in the folder tree.

Note: We recommend that you manage ReadMetadata access on the folder that represents the custom repository. Don't make changes on the custom repository's repository ACT.
If you migrate a SAS Data Integration Studio custom tree, access to ungrouped objects might change.

Addressing Authorization Differences

Your priorities influence how you address any authorization differences that the reports identify. You might use any of these approaches:

Make minimal changes so that access is sufficiently available again. This might not require any action. Or, this might require only adding grants on existing folders.
Make incremental changes to restore access to the SAS 9.1.3 state. If you have access distinctions among groups, this approach can require that you create some additional folders, set appropriate permissions on those folders, and redistribute content. For more information, see Working With SAS Folders in the SAS Intelligence Platform: System Administration Guide.
Set up a new folder structure, set appropriate permissions on the folders, and redistribute content.

Note: We recommend that you make any changes to settings on the appropriate parent folders, rather than adding settings to specific objects. [cautionend]

Update Third-Party Software Server Definitions

Your SAS 9.2 migrated system can contain metadata describing third-party servers, such as Web application and database servers. These server definitions are stored in SAS metadata repositories and might need to be modified on the SAS 9.2 system using SAS Management Console to reflect changes to the new system. Examples of such changes might include new host names, ports, connection attributes, or security information. A list of migrated third-party metadata is provided in your SAS Migration Utility analysis report. To view your migration analysis report, point a Web browser to the AnalysisReport.xml file in the AnalysisReport subdirectory underneath the output directory you specified when you last ran the SAS Migration Utility.

Refer to your Instructions.html file for more information about what steps you might need to perform. Instructions.html resides under the SAS configuration directory in the Levn\Documents subdirectory (or example, C:\SAS\Config92\Lev1\Documents).

Top of Page