SAP System Parameters Review
++++++++++++++++++++++++++++++++++++++
This overview describes how security and controls can be implemented through system parameters. System parameters are used to maintain configuration over the operation of the SAP system. System parameters may define key settings for the whole system on which SAP runs, individual hosts systems (e.g. configuration for only one of many application servers) or the instances that are running on these servers. The majority of system parameters ensure that SAP operates effectively on the customer’s preferred hardware, operating system and database platforms. System parameters also control how SAP operates and provides system wide control over some aspects of Security. System parameters are set using transaction RZ10. To make the parameters globally effective set them in the default profile, DEFAULT.PFL. To make them instance-specific, you must set them in the profiles of each application server in your R/3 System. System parameters can be reviewed with transaction TU02 or from the standard SAP report RSPARAM using transaction SA38.
Incorrect Logon, Default Clients and Default Start Menus
======================================================================
• Login/fails_to_session_end (default value - 3)
defines the number of times a user can enter an incorrect password before the system terminates the logon attempt.
• Login/fails_to_user_lock (default value - 12)
the number of times a user can enter an incorrect password before the system locks the user. If the system locks, an entry is written to the system log, and the lock is released at midnight.
• Login/failed_user_auto_unlock (default value - 1)
unlocks users who are locked by logging on incorrectly. The locks remain if the parameter value is 0.
• Login/system_client
This parameter specifies the default client. This client is automatically filled in on the system logon screen. Users can enter a different client.
• Login/ext_security
Since release 3.0E, external security tools such as Kerberos or Secude have managed R/3 System access. If this parameter is set, an additional identification can be specified for each user (in user maintenance) where users log on to their security system. To activate, set the value to X.
• rdisp/gui_auto_logout (default value - 0)
Maximum time allowed between input from the GUI before the frontend is automatically logged out. The value is set in seconds and the value of zero is used when this facility is not active.
• Start_menu
This parameter specifies the default start menu for all users and can be overwritten with the user-specific start menu (transaction SU50). The default is S000, and this value can be set to any other area menu code.
Password Security
===================================
System profile parameters define the minimum length of a password and the frequency with which users must change passwords.
• Login/min_password_lng
minimum password length. The minimum is three characters and the maximum eight characters.
• Login/password_expiration_time
number of days after which a password must be changed. The parameter allows users to keep their passwords without time limit and leaves the value set to the default, 0.
• To prevent use of a certain password, enter it in table USR40. Maintain this table with transaction SM30. In USR40, you may also generically specify prohibited passwords.
There are two wild-card characters:
– ? means a single character
– * means a sequence of any combination characters of any length
Examples:
– 123* in table USR40 prohibits any password that begins with the sequence 123.
– *123* prohibits any password that contains the sequence 123.
– AB? prohibits passwords that begin with AB and have an additional character, such as ABA, ABB, and ABC.
Securing SAP* user master record
==================================================
• login/no_automatic_user_sapstar
By default SAP is installed with a user master record SAP*. This user has the profile SAP_ALL with access to all transactions and programs in SAP. By default if this user master record is deleted then SAP allows logon using SAP* and a password of ‘PASS’. Although the user master record does not exist, SAP grants unrestricted system access privileges to SAP*. By setting this parameter value to ‘1’ this ‘backdoor’ access is blocked in the event the SAP* user master record is deleted. Prior to version 4.0 this parameter was login/no_automatic_user_sap*.
Tracing Authorizations
========================================
• Auth/check_value_write_on (default value - 0)
Authorization failures can be evaluated immediately they occur by running transaction SU53. This functionality is only active if the parameter is set to a value greater than zero in the system profile parameter.
• Auth/authorization_trace (version 4.0B onwards - default value - ‘N’)
When the parameter is set, any authorization checks performed are validated against existing entries in table USOBX. If the table does not contain the transaction/authorization object combination, then a new entry is added to the SAP reference table (i.e. USOBT not USOBT_C). Due to significant performance issues, SAP does not recommend this parameter being set in customer systems.
• Auth/test_mode (version 4.0B onwards - default value ‘N’)
When activated every authority check starts report RSUSR400. However SAP recommends not activating this parameter as the system is paralyzed if syntax errors occur in running the report and it has a significant performance impact .
Authority Check De-activation
===============================================
• Auth/no_check_on_sucode (version 3.0E to version 3.1H - default value ‘N’), Auth/no_check_on_tcode (version 4.0 onwards - default value - ‘N’)
From release 3.0E, the system checks on object S_TCODE. In upgrades from versions prior to 3.0E to set this flag to ‘Y’ to ensure that old profiles operate in the new system. By default, the function is inactive.
The flag should not normally be switched on because of the degradation in security that results.
• Auth/no_check_in_some_cases (version 3.0F onwards -default value depends on release)
This parameter needs to be set to ‘Y’ for installation of the profile generator. It defines the use of table USOBT in the authority checks undertaken and allows authority checks to be disabled in individual transactions. Whilst SAP recommends switching off unnecessary authority checks, the full impact of this should be considered carefully.
• Auth/object_disabling_active (default value -‘N’)
Whilst_no_check_in_some_cases allows authority checks to be switched off in for individual transactions, this parameter allows checks on individual objects to be switched off globally within SAP. It is recommended that this parameter is not set.
Number of Authorizations in User Buffers
=========================================================
• Auth/auth_number_in_userbuffer
When a user logs onto SAP, the authorizations contained in the user’s profiles are copied to a user buffer in memory. The maximum number of authorizations copied is set by this parameter. The size of the buffer must always exceed the maximum number of authorizations as authorization checks are made only against those in the buffer.
The default value is 800, but this can be set to between 1–2000. Refer to OSS notes 84209 and 75908 for more detailed information regarding changes to the size of the user buffer.
Transaction SU56 shows the contents of the user’s user buffer and a total for all the authorizations in a user master record.
Table, ABAP and RFC system parameters
=======================================================
• Rec/client (default value - ‘N’)
The parameter switches automatic table logging on. Images of the table before and after are logged rather than just changes and so consideration to which tables are to be logged and log volumes must be made before using this as part of a control solution.
• Auth/rfc_authority_check (default value - ‘1’)
The parameter determines how object S_RFC is checked during RFC calls. The object has three fields, activity, the name of the function being called and the function group in which the function resides. The parameter defines whether S_RFC object is checked and if so, whether the function group field is included in the validation.
Value = 0, no check against S_RFC
Value = 1, check active but no check for SRFC-FUGR
Value = 2, check active and check against SRFC-FUGR
• Auth/system_access_check_off (default value - ‘0’ - check remains active)
This parameter inactivates the automatic authorization check for particular ABAP/4 language elements (file operations, CPIC calls, and calls to kernel functions). This parameter ensures the downward compatibility of the R/3 kernel.
Useful Transactions
=====================================
• TU02 Shows current parameters for all hosts and gives a history of changes to parameters
• RZ10 Maintain system parameters
• RZ11 View single system parameters and their functional area.
• SU56 Shows all authorizations a user has in their user master record and the total number. This is useful to
identify apparent authorization failures caused by user buffer overflow.
Useful Reports
===============================
RSPARAM displays all system parameters set and applicable to the system and instance in which it is run.
From version 4.0 the RSUSR003 report also shows the settings for some of the critical password parameters. The report also shows identifies whether SAP*, DDIC or CPIC have insecure passwords by comparing value of the encrypted password field with the encrypted values of the standard shipped passwords. It also shows whether the SAP* user master record is absent from any clients.
This information can be very useful specially for the Production Systems...
Thursday 4 September, 2008
Thursday 1 May, 2008
How to manage Control Files in Oracle
How to manage Control Files??
+++++++++++++++++++++++++++++++++++++++++++++++++
The control file of an Oracle database is created at the same time as the database.
A control file is a small binary file that records the physical structure of the database and
includes:
The database name
Names and locations of associated data files and online redo log files.
If RMAN is configured additional records as required for RMAN are also stored (such as archive log records and various backup records).
The timestamp of the database creation
The current log sequence number
Checkpoint information
The maximum control file size is operating system specific. See your operating system-specific Oracle documentation for more information and try to manage the control file size always within those limits.
The size of the control file can be limited by setting the initialization parameter CONTROL_FILE_RECORD_KEEP_TIME.
The default value is 7. Set it to 0.
CONTROL_FILE_RECORD_KEEP_TIME specifies the minimum number of days before a reusable record in the control file can be reused. In the event a new record needs to be added to a reusable section and the oldest record has not aged enough, the record section expands. If this parameter is set to 0, then reusable sections never expand, and records are reused as needed.
Note:
This parameter applies only to records in the control file that are circularly
reusable (such as archive log records and various backup records). It does not
apply to records such as datafile, tablespace, and redo thread records, which are
never reused unless the corresponding object is dropped from the tablespace.
Check v$controlfile_record_section for your knowledge
Remember that the control file is to be always available to Oracle for an OPEN Database.
You specify control file names using the CONTROL_FILES initialization parameter in the database's initialization parameter file. The instance startup procedure recognizes and opens all the listed files. The instance writes to and maintains all listed control files during database operation.
If you do not specify files for CONTROL_FILES before database creation, and you are not using the Oracle Managed Files (OMF is to be discussed at a later point) feature, Oracle creates a control file and uses a default filename. The default name is operating system specific.
Every Oracle database should have at least two control files, each stored on a different disk. If a control file is damaged due to a disk failure, the associated instance must be shut down. Once the disk drive is repaired, the damaged control file can be restored using the intact copy of the control file from the other disk and the instance can be restarted. In this case, no media recovery is required.
Never ever forget to multiplex the control files.
Recreating Control files
Only recreate the control file under very special circumstances:
(1) All current copies of the control file have been lost or are corrupted.
(2) You need to change a "hard" database parameter that was set when the database was first created, such as MAXDATAFILES, MAXLOGFILES, MAXLOGHISTORY, etc.
(3) You are restoring a backup in which the control file is corrupted or missing.
(4) Oracle Customer Support advises you to do so.
(5) If you are moving your database to another machine, which is running the same operating system, but the location of the data files, log files is not the same. This is also understood as cloning database.
Note: Never attempt to clone the database
(1) If the OS is different. Ex source on Sun, HP, AIX and you want to clone on different OS. This kind of problem is not seen on Windows flavors if the version of Oracle is certified for that OS version of Windows
(2) If oracle data block size is to be different than the source database.
What are the default values of MAXDATAFILES??
The default and the range of values of maxdatafiles and db_files are
operating system specific. Please refer to your operating system specific
Oracle manuals.
Oracle Version 7.3.4 8.0.5 8.1.6 9.2.1 10.1
UNIX 30 30 30 30 30
VMS 32 32 - 32 -
Windows 32 254 254 32 32
Why is there a limit on MAXDATAFILES?
Each platform uses a port-specific number of bits to store the ORACLE file numbers. Thus, this number limits MAXDATAFILES.
What are the limits on MAXDATAFILES?
Oracle Version 7.3.4 8.0.5 8.1.6 9.2.1 10.1
UNIX 1022 1022 per TS 65536 per DB 1022 per TS 65536 per DB 65534 65534
VMS 1022 1022 per TS 65536 per DB - (999999999) -
Windows 1022 1022 per TS 65536 per DB 1022 per TS 65536 per DB 65534 65534
Why would one set MAXDATAFILES to anything less than the port-specific maximum?
Increasing the value of MAXDATAFILES increases the size of the CONTROL FILE
Why would one set DB_FILES to anything less than MAXDATAFILES?
Increasing the value of DB_FILES increases the size of the PGA, or Program Global Area, which is allocated for every user process connected to ORACLE.
How can I determine my machine's maximum limit on MAXDATAFILES?
Check your ORACLE Installation and User's Guide. The index should point to a port-specific limit.
How can I determine where my CONTROL FILE(s) are?
In SVRMGR (if you are using Oracle 8.1.7 or lesser version) or SQL*PLUS depending on the version (hope you know that SVRMGR is not available in Oracle 9 or higher versions),
type:
show parameter control_files;
If you have multiple control files, you may find that some of them may be cut off in the output from show parameter. In this case, you can query from V$CONTROLFILE;
What common error messages I may get if I exceed the limits???
ORA-01118: cannot add any more database files: limit of 32 exceeded
ORA-01165: MAXDATAFILES may not exceed when attempting to add data files to the database.
Then, how can I resolve them??
There are various options. Metalink Doc ID 119507.1 is best suggested for a close reading.
+++++++++++++++++++++++++++++++++++++++++++++++++
The control file of an Oracle database is created at the same time as the database.
A control file is a small binary file that records the physical structure of the database and
includes:
The database name
Names and locations of associated data files and online redo log files.
If RMAN is configured additional records as required for RMAN are also stored (such as archive log records and various backup records).
The timestamp of the database creation
The current log sequence number
Checkpoint information
The maximum control file size is operating system specific. See your operating system-specific Oracle documentation for more information and try to manage the control file size always within those limits.
The size of the control file can be limited by setting the initialization parameter CONTROL_FILE_RECORD_KEEP_TIME.
The default value is 7. Set it to 0.
CONTROL_FILE_RECORD_KEEP_TIME specifies the minimum number of days before a reusable record in the control file can be reused. In the event a new record needs to be added to a reusable section and the oldest record has not aged enough, the record section expands. If this parameter is set to 0, then reusable sections never expand, and records are reused as needed.
Note:
This parameter applies only to records in the control file that are circularly
reusable (such as archive log records and various backup records). It does not
apply to records such as datafile, tablespace, and redo thread records, which are
never reused unless the corresponding object is dropped from the tablespace.
Check v$controlfile_record_section for your knowledge
Remember that the control file is to be always available to Oracle for an OPEN Database.
You specify control file names using the CONTROL_FILES initialization parameter in the database's initialization parameter file. The instance startup procedure recognizes and opens all the listed files. The instance writes to and maintains all listed control files during database operation.
If you do not specify files for CONTROL_FILES before database creation, and you are not using the Oracle Managed Files (OMF is to be discussed at a later point) feature, Oracle creates a control file and uses a default filename. The default name is operating system specific.
Every Oracle database should have at least two control files, each stored on a different disk. If a control file is damaged due to a disk failure, the associated instance must be shut down. Once the disk drive is repaired, the damaged control file can be restored using the intact copy of the control file from the other disk and the instance can be restarted. In this case, no media recovery is required.
Never ever forget to multiplex the control files.
Recreating Control files
Only recreate the control file under very special circumstances:
(1) All current copies of the control file have been lost or are corrupted.
(2) You need to change a "hard" database parameter that was set when the database was first created, such as MAXDATAFILES, MAXLOGFILES, MAXLOGHISTORY, etc.
(3) You are restoring a backup in which the control file is corrupted or missing.
(4) Oracle Customer Support advises you to do so.
(5) If you are moving your database to another machine, which is running the same operating system, but the location of the data files, log files is not the same. This is also understood as cloning database.
Note: Never attempt to clone the database
(1) If the OS is different. Ex source on Sun, HP, AIX and you want to clone on different OS. This kind of problem is not seen on Windows flavors if the version of Oracle is certified for that OS version of Windows
(2) If oracle data block size is to be different than the source database.
What are the default values of MAXDATAFILES??
The default and the range of values of maxdatafiles and db_files are
operating system specific. Please refer to your operating system specific
Oracle manuals.
Oracle Version 7.3.4 8.0.5 8.1.6 9.2.1 10.1
UNIX 30 30 30 30 30
VMS 32 32 - 32 -
Windows 32 254 254 32 32
Why is there a limit on MAXDATAFILES?
Each platform uses a port-specific number of bits to store the ORACLE file numbers. Thus, this number limits MAXDATAFILES.
What are the limits on MAXDATAFILES?
Oracle Version 7.3.4 8.0.5 8.1.6 9.2.1 10.1
UNIX 1022 1022 per TS 65536 per DB 1022 per TS 65536 per DB 65534 65534
VMS 1022 1022 per TS 65536 per DB - (999999999) -
Windows 1022 1022 per TS 65536 per DB 1022 per TS 65536 per DB 65534 65534
Why would one set MAXDATAFILES to anything less than the port-specific maximum?
Increasing the value of MAXDATAFILES increases the size of the CONTROL FILE
Why would one set DB_FILES to anything less than MAXDATAFILES?
Increasing the value of DB_FILES increases the size of the PGA, or Program Global Area, which is allocated for every user process connected to ORACLE.
How can I determine my machine's maximum limit on MAXDATAFILES?
Check your ORACLE Installation and User's Guide. The index should point to a port-specific limit.
How can I determine where my CONTROL FILE(s) are?
In SVRMGR (if you are using Oracle 8.1.7 or lesser version) or SQL*PLUS depending on the version (hope you know that SVRMGR is not available in Oracle 9 or higher versions),
type:
show parameter control_files;
If you have multiple control files, you may find that some of them may be cut off in the output from show parameter. In this case, you can query from V$CONTROLFILE;
What common error messages I may get if I exceed the limits???
ORA-01118: cannot add any more database files: limit of 32 exceeded
ORA-01165: MAXDATAFILES may not exceed
Then, how can I resolve them??
There are various options. Metalink Doc ID 119507.1 is best suggested for a close reading.
RAM Funda - SAP (RAM Recommendation for SAP)
RAM:
========
UNIX: Note 146528
-----------------
A swap space size of 3 to 4 times the RAM size is recommended, even though a swap space of 10 GB or more might have to be created. The virtual memory available for a process is divided into "shared memory" and "local memory". All processes of an instance can access the shared memory, while only one process can access the local memory.
Most memory used in the R/3 environment is shared memory. Experiences has shown that the memory used is divided into 80% shared memory and 20% local memory.
In individual cases, there might be exceptions to this rule. Shared memory restrictions by the operating system affect the configuration options of the R/3 System drastically. The shared memory includes all R/3 buffers, such as program, table, roll buffers and R/3 extended memory.
The local memory includes the local memory of the work processes or heap.
In the 32-bit technology used so far, it is theoretically possible to address a maximum of 4 GB of memory from one process. Since a lot of memory cannot be used at all due to fragmentation effects, the memory that is actually available to an R/3 work process is much smaller in practice. The following sections specify the restrictions for some operating systems.
With the 64-bit technology, the above problems are solved. In 64-bit technology, an address space of many terabytes is available to a work process. To be able to use the 64-bit technology, you need a 64-bit operating system, a 64-bit version of the database software, and a 64-bit version of the R/3 kernel.
Compared to the 32-bit version, the 64-bit R/3 kernel has no new functions.
Compared to the 32-bit version, using the 64-bit version remains the same for users and administrators. Memory management becomes considerably simpler when you use the 64-bit kernel as compared to the 32-bit version.
Details can be found in Note 146289.
========
UNIX: Note 146528
-----------------
A swap space size of 3 to 4 times the RAM size is recommended, even though a swap space of 10 GB or more might have to be created. The virtual memory available for a process is divided into "shared memory" and "local memory". All processes of an instance can access the shared memory, while only one process can access the local memory.
Most memory used in the R/3 environment is shared memory. Experiences has shown that the memory used is divided into 80% shared memory and 20% local memory.
In individual cases, there might be exceptions to this rule. Shared memory restrictions by the operating system affect the configuration options of the R/3 System drastically. The shared memory includes all R/3 buffers, such as program, table, roll buffers and R/3 extended memory.
The local memory includes the local memory of the work processes or heap.
In the 32-bit technology used so far, it is theoretically possible to address a maximum of 4 GB of memory from one process. Since a lot of memory cannot be used at all due to fragmentation effects, the memory that is actually available to an R/3 work process is much smaller in practice. The following sections specify the restrictions for some operating systems.
With the 64-bit technology, the above problems are solved. In 64-bit technology, an address space of many terabytes is available to a work process. To be able to use the 64-bit technology, you need a 64-bit operating system, a 64-bit version of the database software, and a 64-bit version of the R/3 kernel.
Compared to the 32-bit version, the 64-bit R/3 kernel has no new functions.
Compared to the 32-bit version, using the 64-bit version remains the same for users and administrators. Memory management becomes considerably simpler when you use the 64-bit kernel as compared to the 32-bit version.
Details can be found in Note 146289.
SAP Work Process Calculation
Work Process Calculation
=======================================================
SAPinst installs SAP systems with a minimum number of work processes, which
are calculated using the following formula:
- Number of dialog work processes = RAM/256 (min 2, max 18)
- Number of update work processes = RAM/768 (min 1, max 6)
- Number of update2 work processes = RAM/1024 (min 1, max 3)
- Number of batch work processes = RAM/1024 (min 2, max 3)
- Number of enqueue work processes = 1
- Number of spool work processes = 1
=======================================================
SAPinst installs SAP systems with a minimum number of work processes, which
are calculated using the following formula:
- Number of dialog work processes = RAM/256 (min 2, max 18)
- Number of update work processes = RAM/768 (min 1, max 6)
- Number of update2 work processes = RAM/1024 (min 1, max 3)
- Number of batch work processes = RAM/1024 (min 2, max 3)
- Number of enqueue work processes = 1
- Number of spool work processes = 1
UNIX (AIX HP-UX) : Setting Environment Variables (setenv,set,export...)
UNIX (AIX, HP-UX): Setting Environment Variables
====================================
- SAPinst needs the JAVA_HOME environment variable to be set on the
host(s) where SAPinst will run.
- Set the JAVA_HOME environment variable for the root user to
.
- Ensure that your DISPLAY environment variable is set to:0.0,
where is the host on which the SAPinst GUI will be displayed.
- Only for a Unicode installation:
Add /sapmnt//profile to the library path environment variable.
=================================
Use the following commands, based on your shell, to set the environment variables:
- Bourne Shell (bsh) JAVA_HOME= export JAVA_HOME
DISPLAY=:0.0 export DISPLAY
- C Shell (csh) setenv JAVA_HOME
setenv DISPLAY:0.0
- Korn Shell (ksh) export JAVA_HOME=
export DISPLAY=:0.0
Name of the library path environment variable:
- AIX: LIB_PATH
- HP-UX:SHLIB_PATH
- LD_LIBRARY_PATH (for all other UNIX operating systems)
====================================
- SAPinst needs the JAVA_HOME environment variable to be set on the
host(s) where SAPinst will run.
- Set the JAVA_HOME environment variable for the root user to
- Ensure that your DISPLAY environment variable is set to
where
- Only for a Unicode installation:
Add /sapmnt/
=================================
Use the following commands, based on your shell, to set the environment variables:
- Bourne Shell (bsh) JAVA_HOME=
DISPLAY=
- C Shell (csh) setenv JAVA_HOME
setenv DISPLAY
- Korn Shell (ksh) export JAVA_HOME=
export DISPLAY=
Name of the library path environment variable:
- AIX: LIB_PATH
- HP-UX:SHLIB_PATH
- LD_LIBRARY_PATH (for all other UNIX operating systems)
NFS Mount...Start..Stop NFS Service...
NFS Mounting (AIX and other Unix flavors)
MAKE ENTRY IN /etc/exports file and also check the NFS service whether started or not...
===================================
exportfs Lists all exported filesystems
exportfs -a Exports all fs's in /etc/exports file
exportfs -u (filesystem) Un-exports a filesystem
mknfs Configures and starts NFS services
rmnfs Stops and un-configures NFS services
mknfsexp -d /directory Creates an NFS export directory
mknfsmnt Creates an NFS mount directory
***mknfsmnt -f filesys -d remotedir -h host
mount hostname:/filesystem /mount-point Mount an NFS filesystem
nfso -a Display NFS Options
nfso -o option=value Set an NFS Option
nfso -o nfs_use_reserved_port=1
=====================================
Example
----------
To add the mount of a remote directory, enter:
mknfsmnt -f /usr/share/man -d /usr/share/man -h host1
In this example, the mknfsmnt command mounts the remote directory /usr/share/man on the /usr/share/man directory that resides on host1.
Files
------
/etc/filesystems -- Lists the remote file systems to be mounted during the system restart.
=======================================
The output of exportfs command should be
/usr/sap/trans -public,sec=sys,rw,root=142.147.101.33
This will give the same group of the folder which is NFS mounted as in Source system.
======================================
MAKE ENTRY IN /etc/exports file and also check the NFS service whether started or not...
===================================
exportfs Lists all exported filesystems
exportfs -a Exports all fs's in /etc/exports file
exportfs -u (filesystem) Un-exports a filesystem
mknfs Configures and starts NFS services
rmnfs Stops and un-configures NFS services
mknfsexp -d /directory Creates an NFS export directory
mknfsmnt Creates an NFS mount directory
***mknfsmnt -f filesys -d remotedir -h host
mount hostname:/filesystem /mount-point Mount an NFS filesystem
nfso -a Display NFS Options
nfso -o option=value Set an NFS Option
nfso -o nfs_use_reserved_port=1
=====================================
Example
----------
To add the mount of a remote directory, enter:
mknfsmnt -f /usr/share/man -d /usr/share/man -h host1
In this example, the mknfsmnt command mounts the remote directory /usr/share/man on the /usr/share/man directory that resides on host1.
Files
------
/etc/filesystems -- Lists the remote file systems to be mounted during the system restart.
=======================================
The output of exportfs command should be
/usr/sap/trans -public,sec=sys,rw,root=142.147.101.33
This will give the same group of the folder which is NFS mounted as in Source system.
======================================
Logon Load Balancing (SMLG) - SAP....
Go to transaction code SMLG and create Logon Group and do assignments of the instances as required by you...
Users workstation 'services' file requires an entry defining the serviceport of the new logon group. (ex. sapmsSID 3602)
where SID is your system ID. Port # can change, I believe the default is 3600.
User uses 'groups' button on SAP GUI to create new logon pad entry.Enter SID and message server hostname.
Click 'generate list' and thelogon group you defined should appear in the white box below. Choosethe correct group and click button 'add and logon'. Usually no AProuter string is required (depending on your network setup).
Logon groups appear with a different icon (in the SAP Logon Pad list)than single server logons. Single servers show a little orange manbeside an SAP logo, logon groups show 3 boxes (supposed to representservers I guess) close together.
If you create multiple logon groups to segregate users by user group(ex. FI users in FI_GROUP and SD users in SD_GROUP), then you adjust thedesktop settings (as above) accordingly.
==========================
Check in DEFAULT profile rdisp/mshost
You need enter this server's I.P address in the group selection --> message server i.p
You need to add the service port sapmsSID 3600/tcp in services file..
(you may need to give an additional ENTER after this entry else it doesn't work at times :) )
If it still doesn't work, create a file sapmsg.ini in
c:\windows or c:\winnt for the presentation machine and add the following entry
[Message Server]
SID= I.P address of message server
======================
You need to define the sapms in the windows services files located
under "C:\Windows\System32" or "C:\Windows\System32\drivers\etc" (WinXP)
Add the line at the end of the file
sapmsSID port number of the message server/tcp
Example
sapmsPRD 3602/tcp
===========================
Users workstation 'services' file requires an entry defining the serviceport of the new logon group. (ex. sapmsSID 3602)
where SID is your system ID. Port # can change, I believe the default is 3600.
User uses 'groups' button on SAP GUI to create new logon pad entry.Enter SID and message server hostname.
Click 'generate list' and thelogon group you defined should appear in the white box below. Choosethe correct group and click button 'add and logon'. Usually no AProuter string is required (depending on your network setup).
Logon groups appear with a different icon (in the SAP Logon Pad list)than single server logons. Single servers show a little orange manbeside an SAP logo, logon groups show 3 boxes (supposed to representservers I guess) close together.
If you create multiple logon groups to segregate users by user group(ex. FI users in FI_GROUP and SD users in SD_GROUP), then you adjust thedesktop settings (as above) accordingly.
==========================
Check in DEFAULT profile rdisp/mshost
You need enter this server's I.P address in the group selection --> message server i.p
You need to add the service port sapmsSID 3600/tcp in services file..
(you may need to give an additional ENTER after this entry else it doesn't work at times :) )
If it still doesn't work, create a file sapmsg.ini in
c:\windows or c:\winnt for the presentation machine and add the following entry
[Message Server]
SID= I.P address of message server
======================
You need to define the sapms
under "C:\Windows\System32" or "C:\Windows\System32\drivers\etc" (WinXP)
Add the line at the end of the file
sapmsSID port number of the message server/tcp
Example
sapmsPRD 3602/tcp
===========================