What Are The User Groups and How Can We Use Them?: Transport Tables Between Clients
What Are The User Groups and How Can We Use Them?: Transport Tables Between Clients
What Are The User Groups and How Can We Use Them?: Transport Tables Between Clients
Transaction SUGR - have a look. Purpose for example is to give certain system admin rights to unlock /
change password only to a given user group. You assign user group to an user id via SU01.
User group can be used for different reasons and in different way.
In the latest versions of SAP, actually two types of usergroup exist, the authorization user group and the
general user groups.
Naturally the main reason of user groups is to categorize user into a common denominator.
The authorization user group is used in conjunction with S_USER_GROUPauthorization object. It allows
to create security management authorization by user group. e.g. you can have a local security
administrator only able to manage users in his groups, Help-Desk to reset password for all users except
users in group SUPER, etc...
The general user group can be used in conjunction with SUIM and SU10, to select all the users in a
specific group. User can only be member of one authorization user group but several general user group.
One of the Primary uses of user groups is to sort users into logical groups.
This allows users to be categorised in a method that is not dependent on
roles/AG's/Responsibilities/Profiles etc.
User Groups also allow segregation of user maintenance, this is especially useful in a large organisation
as you can control who your user admin team can maintain - an example would be giving a team leader
the authority to change passwords for users in their team.
The most important factor identified is that the lack of user groups is an indication that there may be
problems with the user build process. This is very "fuzzy" but is a bit of a warning flag.
The Auditors job is to provide assurance that SAP is set up and administered in a way that minimises
risks to the financial data produced. If the only thing they have picked up on is the lack of usergroups then
you will be fine.
If you are in any doubt whatsoever ASK THE AUDITOR. They would have produced a report listing why
they feel there is a risk by not having User Groups implemented. If you feel that the risk is mitigated by
other measures then let them know. It works best as a 2 way process and both parties can learn
something.
Start RSCLCCOP from the target client which the users and authorizations should be copied.
Do not use this report if the target client contains some users and authorizations you want to preserve.
You are trying to change the password for sap* user, however when you go into su01 and enter sap* as
the user name, the following message is displayed, user sap* does not exist.
You can delete the SAP* user using ABAP code :-
Delete from usr02 where bname = 'SAP*' and mandt = '***';
Where '***' means your client no.
Then login to your client using password SAP* and password PASS
However, if you delete it, then it will automatically created once again with password PASS
The userid, SAP*, is delivered with SAP and is available in clients 000 and 001 after the initial installation.
In these 2 clients, the default password is 07061992 (which is, by the way, the initial date when R/3 came
into being...). It is given the SAP_ALL user profile and is assigned to the Super user group. When I say it
is "delivered" with SAP, I mean that the userid resides in the SAP database; there are actually rows in the
user tables used to define userids.
If you delete the userid, SAP*, from the database, SAP has this userid defined in its kernel (the SAP
executable code that sits at the operating system level, i.e., disp+work). When this situation exists, the
password defined in the SAP code for SAP* is PASS. This is necessary when you are performing client
copies for example, as the user information is copied at the end of the process. You can sign into the
client you are creating while a client copy is processing using SAP* with password PASS (but you should
have a good reason to do this - don't change anything while it's running).
Anyway, if the SAP* userid is missing, you can sign in to the client you want and simply define it using
transaction SU01 and, as I stated above, assign it to the SUPER user group and give it the SAP_ALL
profile. You define its initial password at this point. If you've forgotten its password and don't have a userid
with sufficient authorization to create/change/delete userid,
then you can use the SQL statements to delete it from the database and then you can use SAP* with
PASS to sign back into the client you want to define it in and recreate it.
There is also a profile parameter which can override the use of SAP* with PASS to close this security hole
in SAP (login/no_automatic_user_sapstar). When this parameter is defined either in your DEFAULT.PFL
profile or the instance-specific profile and is set to a value of '1', then the automatic use of SAP* is
deactivated. The only way to reactivate the kernel-defined SAP* userid at this point would be to stop SAP,
change this parameter to a value of 0 (zero), and then
restart SAP.
The default password for SAP* is 06071992. (DDIC has 19920706)
If master data exists in the child system for the user sent, it is overwritten.
Procedure...
1. Start report RSCCUSND (for example, using transaction SA38).
2. In the Receiving System field, specify the child system to which you want to send the user data.
3. You can use the fields User and User Group to restrict the number of users.
4. Specify the data that you want to distribute under Distribution Options.
5. Choose Execute.
What a interesting piece of information now you can run os commands from SAP GUI.
Here I am sharing the procedure more-over its a trick to get all the t-codes from a Role.
To find all tcode for role along with the tcode that are present in the tcd field..
goto se16 enter agr_1251 and click on data browser button enter the role name in agr_name field and
enter tcd in FIELD field
Then click on execute button or press F8 to execute and you will see the list of tcodes for that role.
SAP T-Codes
Here I am sharing List of T-codes that can help you lot in case you are facing some Problems.
1) SWU3:RFC destination warning in workflow custom. check Automatic Work Flow Customizing 2)
SUCOMP : User Company Address Maintain
3) STZAC: Customizing Time-Zones
4) SWF_XI_CUSTOMIZING:Automatic Work Flow Customizing For XI
5) SXMB_ADM:Integration Engine Administration
6) SOST :SAPConnect Transmission Request Overview With Log
7) SMSY: In Solution Manager To Define System
8) DSWP:In solution Manager To Check EWA / MOPz
press Enter
Click Execute
Click Save
Click Create
Transfer button.
If successful, your logo will be shown in the Binary data for WebRFC.
Click Maintain
START_IMAGE zlogo.gif
RESIZE_IMAGE NO
BW Client Activation
teps for activating newly created client in BI 7.0:
Step 1, execute function module RS_MANDT_UNIQUE_SET / (Transaction SE37).Enter the new client
(300) as value for parameter i_mandt.
Step 2, enter default client (300) in the field BWMANDT of the tableRSADMINA (Transaction SE16).
Step 3, change the profile parameter login/system_client to 300(Transaction RZ10 > Default profile).
Sometimes, you may need to change the Title of the SAP Transaction code to a more meaningful one.
The steps are as follows:
Goto tcode SE63 ,On the top left Menu of the screen – Click Translation —> Short texts – –> Transactions
For example, assuming you want to change the title of the t-code su10 from user maintenance: Mass changes
Initial Screen to Mass User changes . On the first screen, fill in the following information:
To change the Title, click the Edit button. On the second line (the one in dark yellow), type in the Title (For
e.g. Mass User changes) you want for the transaction code. Click the Save button
Now, call up the transaction code /nSU10 again and you should be able to view the new Title.
Some-time its needed to reset some buffers in SAP For performance issues So here iam sharing the differnt
But Keep n mind Resetting of the buffers could change the performance of the entire system
Here i am sharing the experience of installing two oracle database on same host.
After installing new database my first database won’t come up.there are some problems with listener.ora and
Changes in listener.ora
################
# Name……….:
# Date……….:
################
LISTENER =
(ADDRESS_LIST =
(ADDRESS=
(PROTOCOL=IPC)
(KEY= dbsid1.WORLD)
(ADDRESS=
(PROTOCOL=IPC)
(KEY= dbsid1)
(ADDRESS=
(PROTOCOL=IPC)
(KEY= dbsid2.WORLD)
(ADDRESS=
(PROTOCOL=IPC)
(KEY= dbsid2)
(ADDRESS =
(COMMUNITY = SAP.WORLD)
(PROTOCOL = TCP)
(HOST = DBHOSTNAME)
(PORT = 1527)
STARTUP_WAIT_TIME_LISTENER = 0
CONNECT_TIMEOUT_LISTENER = 10
TRACE_LEVEL_LISTENER = OFF
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SDU = 32768)
(SID_NAME = dbsid1)
(ORACLE_HOME = ORACLE_HOME_dbsid1)
(PRESPAWN_MAX = 10)
(SID_DESC =
(SDU = 32768)
(SID_NAME = dbsid2)
(ORACLE_HOME = ORACLE_HOME_dbsid2)
(PRESPAWN_MAX = 10)
################
# Filename……: tnsnames.ora
# Name……….: LOCAL_REGION.world
# Date……….:
################
dbsid1.world =
(DESCRIPTION =
(SDU = 4096)
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = sap.world)
(PROTOCOL = TCP)
(HOST = DBHOSTNAME)
(PORT = 1527)
(CONNECT_DATA =
(SID = dbsid1)
(GLOBAL_NAME = dbsid1.world)
dbsid2.world =
(DESCRIPTION =
(SDU = 4096)
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = sap.world)
(PROTOCOL = TCP)
(HOST = DBHOSTNAME)
(PORT = 1527)
(CONNECT_DATA =
(SID = dbsid2)
(GLOBAL_NAME = dbsid2.world)
Do not check CL_FORCE and UP_FORCE because they are reserved for SAP internal services.
LOG IN TO BR*TOOL STUDIO
Hi ALL,
2) To Access it go to url;
Https:hostname:port/studio
Database user (Please note that password of DB user should not be contain’@’ in password string)
Oraclehome/database/init.sap
You can use it to view space, check status ,control files,backup,restore and you now more thing……..
So, (in opinion only) you should start with a buffer hit ratio analysis / DB table & index access analysis (by user group) to see
where you would get the best benefit from this kind of setup. If you don't have this kind of info, then creating logon groups by
line-of-business may have no benefit (or worst case, may make performance degrade for the group with the highest load %). You
need some historical information to base your decision on, for how to best split the users up.
You may find that 50% of the load is from the SD users and so you may need one group for them (with 3 App servers in it) and
one other group for everyone else (with the other 3).
The logon group(s) will have to be referenced by SAP GUI, so SAP GUI (or saplogon.ini + maybe the services file, only) will
have to change to accomodate any new groups you create in SMLG. Also consider that there's variables for time-of-day (load
varies by time-of-day) and op-mode switches (resources vary by op-mode).
Are all the work processes (dia,btc,enq,upd,up2,spo) running or just all the dialog work processes?
If all the work processes are running, then you may want to look at SM12 (or is SM13?) and see if updates are disabled. If they
are, look at the alert log (if it's an Oracle database) and see if you have any space related errors (e.g. ORA-01653 or ORA-
01654). If you do, add a datafile or raw device file to the applicable tablespace and then, re-enable updates in SM12.
If only all the dialog work processes are running, there are several possible causes. First, look to see if there's a number in the
Semaphore column in SM50 or dpmon. If there is, click once on one of the numbers in the Semaphore column to select it and
then, press F1 (help) to get a list of Semaphores. Then, search OSS notes and, hopefully, you'll find a note that will tell you how
to fix the problem.
If it's not a semaphore (or sometimes if it is), use vmstat on UNIX or task manager on Windows to see if the operating system is
running short on memory which would cause it to swap. In vmstat, the free column (which is in 4k pages on most UNIX
derivatives) will be consistently 5MB or so and the pi and/or po columns will have a non- zero value. The %idle column in the
cpu or proc section will be 0 or a very low single digit while the sys column will be a very high double-digit number because the
operating system is having to swap programs out to disk and in from disk before it can execute them.
In task manager, look at free memory in the physical memory section under the performance tab. If it's 10MB or 15MB (I think),
then the operating system will be swapping.
Usually, when all the dialog work processes are running, you won't be able to log in via SAPgui and will need to execute the
dpmon utility at the commandline level. The procedure is basically the same on UNIX and Windows.
On UNIX:
On Windows:
On both operating systems, you'll see a screen that looks like what you see in SM50. Depending on what you see here, will
depend on what you do next, but checking the developer trace files (e.g. dev_disp) in the work directory (e.g.
/usr/sap/SID/DVEGMS00/work) is never a bad idea.