You can change this setting by using the followin FM:

PRGN_SET_BROWSER_OPTIONS_USER

UNAME – User name
FLAG4 is responsible for this checkbox

You would like to make a system refresh from production to a quality assurance system. But after this refresh, you will have to reconfigure some things back. For example, the state of SLICENSE, SM59, WE20, WE21, BD64 transactions.

Here is an example of how to put SM59 data into a transport request and import it after the system refresh is finished.

Here is a catalog structure:

export_sm59.sh:
R3trans -w /usr/sap/trans/EXPORT/SM59/LOG/EXPORT_SM59.log /usr/sap/trans/EXPORT/SM59/R3T/export_sm59.r3t

export_sm59.r3t:

import_sm59.sh:

R3trans -w /usr/sap/trans/EXPORT/SM59/LOG/IMPORT_SM59.log /usr/sap/trans/EXPORT/SM59/R3T/import_sm59.r3t

import_sm59.r3t:

import file = '/usr/sap/trans/EXPORT/SM59/DUMP/SM59.DMP'

So you need to run :

1. export_sm59.sh before system refresh begins. It triggers the script export_sm59.r3t to export SM59 data to a transport request
2. import_sm59.sh after system refresh ends. It triggers the script import_sm59.r3t to import SM59 data from the transport request
   

Please note that in this case SM59 data will be rewritten, but not added.
In addition, this command doesn’t mean that it will remove any data from the tables, it’s related to the created transport request:
delete from rfcattrib
select * from rfcattrib

It was tested with all mentioned transactions above, the main question is which tables should be used? =)

Transactions:
To Upload files from Presentation Server to Application Server:
CG3Y

To Download files from Application Server to Presentation Server:
CG3Z

There is an analogue in the form of FM:
To Upload files from Presentation Server to Application Server:
ARCHIVFILE_CLIENT_TO_SERVER

To Download files from Application Server to Presentation Server:
ARCHIVFILE_SERVER_TO_CLIENT

You can change the starting transaction for everyone/certain users with a report:
ADMIN_SET_START_TRANSACTION_FO

Example for a system named S4D:

1. Extract kernel OS-dependent and independent parts into the same directory:
   SAPCAR -xvf "./SAPEXE.SAR" -R /mnt/DISTR/SAP_KERNEL/777.500/EXTRACTED/ SAPCAR -xvf "./SAPEXEDB.SAR" -R /mnt/DISTR/SAP_KERNEL/777.500/EXTRACTED/
2. Copy kernel to UC directory (if it’s unicode):
   root>
yes | cp -rfp /mnt/DISTR/SAP_KERNEL/777.500/EXTRACTED/* /usr/sap/S4D/SYS/exe/uc/linuxx86_64/
3. Run file permission script:
   /usr/sap/S4D/D00/exe/saproot.sh S4D
4. Restart system and check:
   su - s4dadm -c "sapcontrol -nr 00 -function RestartSystem"
su - s4dadm -c "sapcontrol -nr 00 -function GetVersionInfo"

SELECT LAST_INVALID_CONNECT_ATTEMPT, INVALID_CONNECT_ATTEMPTS, USER_DEACTIVATED, LAST_PASSWORD_CHANGE_TIME,PASSWORD_CHANGE_NEEDED, VALID_FROM, VALID_UNTIL FROM USERS WHERE USER_NAME = 'MY_USER';

Ok, you are a newcomer SAP BASIS administrator, but you didn’t get any passwords from the previous SAP guy. Your target is to get access to SAP* in a certain client, but you only have access to the application and database server’s OS. The algorithm of overtaking is:
OS > SYSTEM@SYSTEMDB >SYSTEM@TENANTDB > SAPHANADB@TENANTDB > SAP*

1. Taking over SYSTEM user of HANA SYSTEM DB:
   su – <hanadb user>
   HDB stop
hdbenv.sh
hdbnameserver -resetUserSystem
sapcontrol -nr $TINSTANCE -function StartSystem HDB
   
2. Taking over SYSTEM user of HANA TENANT DB:
   As SYSTEM@SYSTEMDB:
   ALTER SYSTEM STOP DATABASE <TENANTDB>
ALTER DATABASE <TENANTDB> SYSTEM USER PASSWORD "MY_NEW_PASSWORD";
ALTER SYSTEM START DATABASE <TENANTDB>
   
3. Taking over SAPHANADB user in HANA TENANT DB:
   As SYSTEM@TENANTDB:
   ALTER USER SAPHANADB password "MY_NEW_PASSWORD" NO FORCE_FIRST_PASSWORD_CHANGE;
   
   Changing the password in hdbuserstore of application server:
   su – <application server user>
   hdbuserstore -i SET DEFAULT <sap-hanadb-hostname>:3<instance>13@<TENANTDB> SAPHANADB
   
   Unlock and reset connect attempts count:
   As SYSTEM@TENANTDB:
   ALTER USER SAPHANADB1 RESET CONNECT ATTEMPTS;
ALTER USER SAPHANADB1 ACTIVATE USER NOW;
   
   Checking:
   su – <application server user>
   hdbsql -U DEFAULT
   
   SQL>
   SELECT * FROM T000;
   
   
   
4. Taking over SAP* in the client:
   su – <application server user>
   Check for the parameter login/no_automatic_user_sapstar = 0 in the SAP application server’s profiles.
   
   As SAPHANADB@TENANTDB:
   Check and remove the created SAP* user to remove its override:
   select * from USR02 where MANDT = <MANDT> and BNAME=’SAP*’;
   delete from USR02 where MANDT = <MANDT> and BNAME=’SAP*’;
   
   Login with SAP* user and default password “pass”.
   Do not forget to bring it all back!
   
   

I encountered strange behavior of the database (or maybe I just need to know how to prepare them), so I migrated to HANA. 

Baseline:

• Create a tenant in the database (example HBQ)
• Find out the tenant’s SQL port. To do this, log in to some HANA STUDIO in this tenant and execute the query: 
  SELECT SERVICE_NAME, PORT, SQL_PORT, (PORT + 2) HTTP_PORT FROM SYS.M_SERVICES WHERE (SERVICE_NAME=’indexserver’ and COORDINATOR_TYPE= ‘MASTER’)
  
• Create an entry in your ODBC.INI:
  vi /home/boqadm/.odbc.ini
  And also on:
  vi /usr/sap/BO/sap_bobj/enterprise_xi40/odbc.ini
  
  Why is this so? Good question, it turned out that for some reason it doesn’t work without .odbc.ini in the user’s home folder, perhaps environment variables or something else, in general, in your odbc.ini.
  
  An example entry, here we use the port obtained from the sql query:
  [HBQ] driver=/home/boqadm/sap/hdbclient/libodbcHDB.so servernode=sap-qas-db:30144 databasename=HBQ description=HBQ
  
• Check connection:
  isql -v HBQ SYSTEM mypass
• Find out and write down your Data Source name in a notepad from CMC> Settings:
  
• Find out and write down the Node Name in a notebook:
  cat /usr/sap/BO/sap_bobj/ccm.config | grep SIANODENAME
• Find out or remember your CLUSTER KEY
• Run cmsdbsetup.sh from /sap_bobj
• Enter the node name
• Enter YES to continue
• Enter COPY
• We are asked if the current base is a receiver, we say no
• Select the receiver type (HANA database)
• Enter the DSN of the receiver (HANA database), HBQ in our case
• Enter the user and password (HANA database)
• Select the source database type (SQL Anywhere)
• Enter the DSN of the source database (SQL Anywhere)
• Enter the user and password (SQL Anywhere). LOGIN WILL BE **DBA** big!
• Enter CLUSTER KEY
• Copying will begin. The switch to the new base will happen automatically. You can check that the tables have appeared in the tenant. After this, for the sake of completeness of the experiment, I comment out the old DSNs in odbc.ini and reboot the system. Next, by going back to CMC> Settings, we will see that the database has become HANA. Note 1768842 will help.