Step by Step Procedure to copy a Client to the Remote SAP Server.

•Logon to destination SAP server
•Use Transaction Code SCC4
•Go to change mode
•Create a new client, assign client number & description as per request
•Logoff from current client.
•Login to newly created client in destination SAP server using the following credentials :

i. Client Number : Newly created one
ii. User Id : SAP*
iii. Password : PASS

•Use Transaction Code SM59 to create a RFC Connection for client copy if does not exist already.
•RFC Connection should have Target Server as Destination and the test results should say “Connection test OK”
•Use SCC9 Transaction code to go to client copy screen.
•Give profile as per the request.
•Select RFC destination created for the purpose for the source client to client copy
•Use Transaction code SCC3 for monitoring the progress of client copy
___________________________________________________________________

Golden rules for CLIENT Copies

1. Master data can not be copied without copying transactional data and transactional data can not be copied without copying master data.

2. Application data (transactional and master) should not be copied without copying configuration data.

3. Client copy requires a valid client as the destination client. Make sure that the client exists in T000 table and you can logon to that client.

4. The transport system and the transport management system of 4.0 are the only proper tool to be use to keep multiple systems in sync by transporting development and customizing changes to another instance.

5. When you copy a client from one system to another, client-independent tables should only be copied if they are not yet modified in the target system.

6. We recommend the users to read all the OSS notes regarding client copy that applies to their SAP release. It is always better to schedule the client copy job in the background for the night run when normal work is not taking place.

7. Always check the database space before performing a client copy.

8. To avoid data inconsistencies all the users working in the source and target clients should logoff from the system.

9. RSCLICHK program should be run in the target system remotely before doing a client export. This program will give information about the missing definitions from the data dictionary in the target. After executing this program and getting successful results you can ensure that the client copy will have no problems. In case some tables are different; you can use SE11 to compare and adjust the table structure in both the system before the client copy. A remote test client copy also can be executed to know the differences between source client and target client.

10. If you are not in release 2.2 then do not use R3trans to copy a client.

Kernel Upgrade

Summary:
Can someone please give me the steps for upgrading the kernel on my system to the latest patch level?

I. Download files to local directory from Sapnet (Sapserv4).

1) Review OSS note 19466 for basic information.

2) Go to http://www.saplabs.com/ and log into "SAP Service Marketplace." You will need your OSS ID and password. Next, click on "System Admin," and go to "SAP online Corrections." Finally, navigate to "Download Kernel/Frontend Patches."

3) Enter the correct "Product data" " (SAP R/3, 4.5B, Kernel Patches), and click on "next page."

4) Enter the correct "System data" (i.e. SAP Kernel 4.5B, Solaris, Oracle), and click on "next page".

5) Select all files to download. At this point you can click on "Mark for Download." Note: You must have SAP Download Manager installed on your workstation. If you do not have this, you will need to load it first.

6) If the status indicates the data is flagged for download, click on "Close."

7) Click on "Maintain download basket."

8) Click on "Start Download." This will move the downloaded file to your local drive.

II. Applying the kernel patches.

1) You now need to FTP the downloaded files to the Unix server. Go to Start --> programs --> reflection --> FTP client and connect to the server. Navigate to /sapsource/downloads and create a new folder as Updates
(i.e.: JulUpdates2001). FTP all of the kernel patches to this folder.

2) Telnet into the server as adm. Navigate to /sapsource/downloads and remove all update folders except the 2 most recent ones.

3) Copy the CAR executable file to the new update folder.
(i.e.: Cp/usr/sap//SYS/exe/run/CAR /sapsource/download/JulUpdates2001

4) The saposcol file for 4.5B and 4.6C must be a 64bit version since our OS level is 64bit. (get this from 64bit Solaris under 5.6D) - see OSS note
19227

5) Navigate to the update folder and uncar the files. (i.e.: CAR -xvf
BRARCHIVE.CAR).

6) You can then delete all of the .car files (i.e.: rm *.CAR and rm *.car)

7) Back up the exe/run directory by running
/sapsource/scripts/bkup_files.sh.
Source: /sapsource/downloads/Updates
Target: /usr/sap//SYS/exe/run
This backup script will copy the files from exe/run and put a current date extension on them (i.e.: brarchive.07022001). Verify that all the files you downloaded were backed up in the exe/run directory.

8) Notify users that you will be bringing the system down for approx. 1/2 hour.

9) Stop R/3 and the database: /export/home/adm.
Stopsap_

The Difference Between ITS and WAS

Summary:
What is the difference between ITS and WAS?

ITS : Internet Transaction Server

WAS : Web App Server

Once, there was "BASIS", which described the technical layer of the SAP system. The technical layer provides services to the application layer. Later, the SAP marketing guys decided that the new and improved version of BASIS was so fantastically terrific that it should get a new name, and so they changed the name of it to WAS (or Web App Server).

BASIS was written in ABAP/4 (SAP's own programming language). BASIS did not speak HTTP. SAP Customers (the largest ones) wanted thin clients (browser access). ITS was created to bridge that gap, and is the translator engine that sits between the BASIS/ABAP/RFC backend and the Web/HTTP frontend.

New WAS systems are dual-personality and can talk ABAP/RFC to the fat clients or HTTP to the thin clients.

New implementations will likely not use ITS, it is now legacy technology.

Applying a Hot Patch - Step by Step

Summary:
I would like to know how to apply a hot patch step by step.

Follow these procedures if using NT/2000:

- Download the support packs from service.sap.com (provided you have a login ID) to the usr\sap\trans directory.
- Open a command prompt and change the directory to usr\sap\trans
- Unpack the support packs using the following command:
car -xvf .CAR
This command unpacks the files that need to be imported into your SAP instance into the usr\sap\trans\eps\in directory.
- Log into client 000 as user DDIC
- Call transaction SPAM
- Once in transaction SPAM, go to menu option Support Package->Load Packages->From Application Server. It will ask you if you want to upload the files - click the green check mark on the box that appears to upload the files.
- Another screen will appear listing the files that you uploaded successfully - just click on the Back arrow to get back to the SPAM screen.
- On the SPAM screen, click on the Display/Define button.
- A box will appear with the Support Package categories (Basis, ABA, etc.)
- Click on the category for the support packages that you uploaded and it will list them in order.
- You can apply them individually or the whole list at one time.
- To apply individually, select the first one in the list and then hit the green check mark at the bottom left of the box. Then on the SPAM screen, go to menu Support Package->Import Queue.
- Confirm that you want to import the support package.
- Once it is done importing, you have to confirm the queue by clicking on the
Confirm Queue button - this will turn the yellow light in the Status area to green.

*Always check your logs after applying support packages by clicking on the Logs button in the SPAM screen.

2) Adapted from response by Jair on Thu,
step by step (HP)

1. Load the CD containing the patches.

2. Log on to the operating system as:
NT: adm
UNIX: adm

3. Change to the transport directory.
NT: :\usr\sap\trans
UNIX: /usr/sap/trans

4. Unpack the patch archive.
NT: CAR -xvf :\\.CAR
UNIX: CAR -xvf ///.CAR

The next step is to upload the patch from the operating system into R/3.
1. Log on to client 000, under any user that has SAP*-equivalent authorizations.
2. In the Command field, enter transaction SPAM and choose Enter
(or from the SAP standard menu, choose Tools ABAP Workbench Utilities Maintenance SPAM-Patches).
3. From the menu bar, choose Patch Upload.
4. Choose.
5. Check that the Support Packages have successfully uploaded.
6. Choose Back.
7. Select all patches.
8. Choose Display.
9. The patch is under new patches.

Audit Log

Summary:
Is there a way to trace people's activity back to when the server was put into production? Does anyone know what transactions I can use for this?

1) Adapted from response by Dondi

I know of two, TC STAD and TC STAT.

2) Adapted from response by Dan

R/3 does not log the history of users activity. Given the size of R/3 you should increase drastically the hardware resources for that to be a defa. Instead you can simply trace them; to trace you have to put (activate) a trace on what you want to trace.(ST01)

And/or you can set the audit profile accordingly to your needs(SM19and SM20). Be careful on the size of the log! (SM18)

On the other hand there are some logs that can show you users specific intervention on the system including their own status and change on that, but not as a "film."

To give an example: the report RSUSR200 will show the list of users according to their logon date and password change. But unless you put a trace on a user you will not find a log showing you exactly what it was doing between, for example, Monday 10:00 a.m. and Friday 15:00 p.m.

I would like to know which users have access to particular transactions. Is this possible?

Yes. There are several ways.

I think the easiest one is for you to run transaction /nSUIM. In this transaction (User Information System), drill down to:

Infosystem authorization -User -Users by complex selection criteria -By transaction authorizations

Finally, enter the transaction in question and execute.

If you are running R/3 4.7, you can also run transaction /nPFCG.

I am a new Basis administrator, and our systems are:
* SAP R/3 4.6C ( support patch: KA47, KB47, KH47 and KE84)
* Kernel 4.6D (Support Patch Level: 988)
* Solaris operating system is 64-bit, and Oracle database is 32-bit.
My questions:

1. How can I find out if our SAP kernel is 32-bit or 64-bit? I found only saposcol file is 64-bit, most of the files are 32-bit.
2. Do I have to download both DB-independent and DB-dependent files in order to upgrade our SAP kernel?
3. Do I have to download all files in DB-independent and DB-dependent into our system? Or just some files:
DB-independent: dw 1969, R3trans 1953, SAPEXE 1747, SAPEXE 1805, SAPEXE 1883, SAPEXE1913 and tp 1967. DB-dependent: SAPEXEDB, SAPEXEDB 1805, SAPEXEDB 1883, and SAPEXEDB 1913).

Run "disp+work -version". If you do NOT see anything saying, "compiled with 64-bit libraries," then your system is running the 32-bit R/3 kernel version.
Also, I encourage you to take a look at SAP Note 192822 titled, "FAQ: 32-bit/64-bit R/3-Oracle."
I am going to quote a section of this note for you:

"For all current releases, the patches are stored in the SAP service marketplace http://service.sap.com/swcenter_3pmain . After choosing Oracle, you have the option to go down the oracle 32-bit or oracle 64-bit path. Please note that in order to decide which of the two to choose the only thing tht matters is what bit version your Oracle software is. No matter whether your OS is 64-bit; as long as your Oracle is still 32-bit you would go down the Oracle 32-bit path."

2. Yes. You need both. Otherwise, the system will not work properly or won't even start at all.

I'm confused about what Basis administration entails. Does it involve the J2EE and ABAP engines? Please help me sort out my confusion.

Yes, Basis administration does involve the J2EE and ABAP engines, but not necessarily both at once. The most common is the administration of the Web Application Server (Web AS ABAP system). The J2EE applies to environments where Web development takes place.

As the Basis (technical) administrator you need to install, configure and maintain just about every aspect of the system architecture. For information about J2EE please visit this link: http://help.sap.com/saphelp_47x200/helpdata/en/13/a3bb3eff62847ae10000000a114084/frameset.htm

I'm updating my users with their correct User Type for the User Audit. Is there any listing that identifies which tcodes are for which User Type? (Example: MM03-Informational, MM02-Operational)

As you know everything is in R/3 tables.

So, you can get a list of "users by type" by querying

table USR02.

The field 'USTYP' indicates the type of user

(Dialog, Background, CPIC).

Once you get a list of users by type, you can use

transaction SUIM to get the list of transactions

assigned to users.

After running SUIM, select Transactions->Transaction Lists

According to Selection With User, Profile or Object->Executable

for user.

You can create your own SQL script to get everything in a

pretty automated way.

Tip: declare cursors

To help you out, see the following SQL queries

(which you can then improve by declaring cursors).

-- This query lists all user accounts that are type Background

in client 400 select * from USR02 where USTYP='B' and MANDT='400'

-- This query lists all activity groups in client 400 assigned

to the user

JOHND

select * from AGR_USERS where MANDT='400' AND UNAME='JOHND'

-- This query lists all transactions assigned to

activity group 'AP_CLERK' in client 400

select TCODE from AGR_TCODES where MANDT='400' and AGR_NAME='AP_CLERK

How do I split Basis authorization responsibilities?

Can you please give your views on the following:

The structure of SAP is such that the privilege to create a user and to allocate the role/activity to perform any function is given through a single transaction code.

The inability to allocate roles and create users or resetting their passwords through two different channels (transaction codes) is a structural weakness within SAP which can only be addressed by the technical people of SAP AG.

An ideal segregation would require these complementary functions to be performed by two different users. That is, the person who has the ability to create a user should not be allowed to assign the roles at the same time. Moreover, the fact that the structure of SAP enables any user to individually assign the roles without any other users interference does increase a inherent risk in SAP.

Moreover, based on the ideal security level the ability to allocate roles/transaction codes in SAP should not be such that it is executable by a user individually on his own.

A person who has SU01 or PFCG is, in reality, a super user. Can you suggest how to reduce the ability of the super user and especially the ability to individually assign roles to anyone, along with himself?

I'm not an authorizations expert, but I assume that it should be possible to split authorization responsibilities. The same is possible with development and customizing. In most organizations, developers and customizers are allowed to do whatever they want in the development and acceptance system. The usage of the transport system is however limited and monitored by the approval concept. In such a setup, the SAP Basis administrator is responsible for transport management.

Security and Data Protection with SAP Systems, published by SAP-PRESS in 2001, has an interesting chapter on distribution of roles and authorization maintenance. Unfortunately, the authors limit themselves to the an explanation of the concept. The technical implementation is not discussed. The chapter more or less discusses the issue you are describing and a possible solution.

SAP BASIS

Monday, March 14, 2011

SAP GUI Auto logout

Maximum No. Of SAP Session Per User

Friday, October 29, 2010

Proper way to delete a SAP client!!!

Wednesday, October 27, 2010

Changing the SAPGUI Logo on the Right Hand Side

Step by Step Procedure to copy a Client to the Remote SAP Server.

Tuesday, September 14, 2010

Add information to your logon screen

Friday, October 12, 2007

Some IQs