It is pretty simple. Just run transaction STZAC and change the System Time Zone and the User Default Time Zone to the correct 3-digit code. You will ave to do the User Default Time Zone in each client. Then just save it.
By the way, the client has to be set to Modifiable in order to make the change.
Saturday, May 31, 2008
Friday, May 30, 2008
SAP User Administration
I just thought I'd share an entry from my personal collection for those new to SAP User Administration...
SAP User Administration
This document is intended to help with basic SAP user administration functions (creating, copying, changing and dropping users). Keep in mind that all user changes are client-dependent, meaning that the changes made to users in one client on a system will not be reflected in the other clients on that system.
Create a User
Before you create a new user, you will have to decide on a User ID for that user. The user name should follow whatever naming convention in place at your company, but it is most commonly a combination of the user’s first initial and last name or first name and last initial. Remember that it is a violation of the SAP license to create generic users, or user ID’s that more than 1 person has access to login as. The steps for creating a user are as follows:
1. In transaction SU01, enter the user ID in the user field that you wish to create.
2. Hit the Create button (F8).
3. Enter the user information in each tab.
4. Save
There are nine information tabs that you can enter information about the user in. The only requirements to create a user are an entry in the Last Name field on the Address tab, and a Password on the Logon Data tab. You can choose to have these users as detailed or basic as you like.
The tabs in the Maintain User screen are as follows:
Address: Personal, Communication, and Company information about the user.
Logon Data: Alias information, User type, Password, Groups, Validity period, and cost center information.
Default Data: Start menu, Language, decimal/date formats, default printing device, time zone.
Parameters: Certain fields in SAP transactions can have a default value set for a user, this is tracked here.
Roles: Authorization roles assigned to this user will populate here, but this is not the correct place to add a user to a role.
Profiles: Authorization profiles assigned directly to this user. An authorization role is made up of one or more authorization profiles.
Groups: All groups, if any, that this user is assigned to will show up here.
Personalization: Advanced settings for user personalization.
License Data: Contractual user type is set here, but is not necessary.
Copy a User
If you have a new user to create, but you want to make him a copy of an existing user, you have the capability to do just that. When copying a new user you can choose to copy as much or little data as you wish, depending on which tabs you want to copy. The steps are as follows:
1. In transaction SU01, enter the user ID in the user field that you wish to create.
2. Hit the Copy button (Shift + F5).
3. Enter the user you wish to copy from and to.
4. Select the tabs that you wish to copy.
5. Enter, set the Last Name and Password
6. Save
Change a User
Making a change to a user is simple after you know how to create and copy users. The steps are as follows:
1. In transaction SU01, enter the user ID in the user field that you wish to create.
2. Hit the Change button (Shift + F6).
3. Make the desired user information changes in each tab.
4. Save
Drop a User
When somebody leaves the company or no longer needs access to SAP, there are several ways you may lock access to the user:
Lock the user: In transaction SU01, enter the user name and hit the lock/unlock button (Ctrl + F5)
Set an expired validity date: In the Logon Data tab under transaction SU01, there is a field called Validity Date. In here you can assign a date in the past that invalidates the user and prevents him from logging in.
Delete the user: In transaction SU01, enter the user name and hit the delete button (Shift + F2)
Typically when a user leaves a position or no longer needs access to SAP, somebody else needs an equivalent level of access to fill that position. If this is the case, you do not want to delete the current user account; otherwise you will have to create the new user from scratch rather than copying the old user. It is recommended that you use one of the first two options to deny login rights to the existing user, but keep the user account in the system in case you want to copy it. After an acceptable period of time has passed and the position has been filled, then you can clean up the system and delete out old user accounts.
This document is intended to help with basic SAP user administration functions (creating, copying, changing and dropping users). Keep in mind that all user changes are client-dependent, meaning that the changes made to users in one client on a system will not be reflected in the other clients on that system.
Create a User
Before you create a new user, you will have to decide on a User ID for that user. The user name should follow whatever naming convention in place at your company, but it is most commonly a combination of the user’s first initial and last name or first name and last initial. Remember that it is a violation of the SAP license to create generic users, or user ID’s that more than 1 person has access to login as. The steps for creating a user are as follows:
1. In transaction SU01, enter the user ID in the user field that you wish to create.
2. Hit the Create button (F8).
3. Enter the user information in each tab.
4. Save
There are nine information tabs that you can enter information about the user in. The only requirements to create a user are an entry in the Last Name field on the Address tab, and a Password on the Logon Data tab. You can choose to have these users as detailed or basic as you like.
The tabs in the Maintain User screen are as follows:
Address: Personal, Communication, and Company information about the user.
Logon Data: Alias information, User type, Password, Groups, Validity period, and cost center information.
Default Data: Start menu, Language, decimal/date formats, default printing device, time zone.
Parameters: Certain fields in SAP transactions can have a default value set for a user, this is tracked here.
Roles: Authorization roles assigned to this user will populate here, but this is not the correct place to add a user to a role.
Profiles: Authorization profiles assigned directly to this user. An authorization role is made up of one or more authorization profiles.
Groups: All groups, if any, that this user is assigned to will show up here.
Personalization: Advanced settings for user personalization.
License Data: Contractual user type is set here, but is not necessary.
Copy a User
If you have a new user to create, but you want to make him a copy of an existing user, you have the capability to do just that. When copying a new user you can choose to copy as much or little data as you wish, depending on which tabs you want to copy. The steps are as follows:
1. In transaction SU01, enter the user ID in the user field that you wish to create.
2. Hit the Copy button (Shift + F5).
3. Enter the user you wish to copy from and to.
4. Select the tabs that you wish to copy.
5. Enter, set the Last Name and Password
6. Save
Change a User
Making a change to a user is simple after you know how to create and copy users. The steps are as follows:
1. In transaction SU01, enter the user ID in the user field that you wish to create.
2. Hit the Change button (Shift + F6).
3. Make the desired user information changes in each tab.
4. Save
Drop a User
When somebody leaves the company or no longer needs access to SAP, there are several ways you may lock access to the user:
Lock the user: In transaction SU01, enter the user name and hit the lock/unlock button (Ctrl + F5)
Set an expired validity date: In the Logon Data tab under transaction SU01, there is a field called Validity Date. In here you can assign a date in the past that invalidates the user and prevents him from logging in.
Delete the user: In transaction SU01, enter the user name and hit the delete button (Shift + F2)
Typically when a user leaves a position or no longer needs access to SAP, somebody else needs an equivalent level of access to fill that position. If this is the case, you do not want to delete the current user account; otherwise you will have to create the new user from scratch rather than copying the old user. It is recommended that you use one of the first two options to deny login rights to the existing user, but keep the user account in the system in case you want to copy it. After an acceptable period of time has passed and the position has been filled, then you can clean up the system and delete out old user accounts.
Thursday, May 8, 2008
SAP Adobe Document Services (ADS) Issues...
For the past several days, I have been struggling with an issue at a client site with configuring Adobe Document Services (ADS). After following all the configuration guide steps meticulously, I was still unable to get the thing to work correctly.
To make a really really long story short: always verify the Java support pack level is appropriate and that the ADS version is current. After pulling much of my increasingly-gray hair out, it was suggested by a colleague that I verify the SP levels on the Java AS. Okay! Kudos to her. That fixed it!
So, if you ever find you are having trouble with ADS, make sure to check the Java SP and ADS version first, and save yourself the headache of fruitless troubleshooting...
Hope this helps someone out there.
To make a really really long story short: always verify the Java support pack level is appropriate and that the ADS version is current. After pulling much of my increasingly-gray hair out, it was suggested by a colleague that I verify the SP levels on the Java AS. Okay! Kudos to her. That fixed it!
So, if you ever find you are having trouble with ADS, make sure to check the Java SP and ADS version first, and save yourself the headache of fruitless troubleshooting...
Hope this helps someone out there.
Tuesday, April 29, 2008
SAP Backup/Recovery Planning...
SAP Backup/Recovery Planning
In order to protect your SAP systems, it is recommended that full and transactional backups be created regularly and kept separate from the system hardware, preferably in a remote location.
Full Backups
A full backup contains the entirety of the database at a given point in time. In the event of a hardware failure or data corruption, it is necessary to have a full backup of the database to restore. The main benefit of having a full backup available for restore is obvious: your company does not have to lose critical business data in the event of a failure. It is recommended that a full backup be taken at least once daily.
Transactional Backups
Full backups alone are not sufficient for most businesses. If a failure occurs just before or during a full backup, then data created or altered since the prior backup will be lost. Transactional backups are designed to save the changes made to a database after full backups are taken, that way those changes are protected. If your backups are setup to run daily at 12:00 AM, and you have transactional backups every hour, then if a failure occurs at 11:59 PM, you potentially would only lose 59 minutes worth of productive changes. Depending on your business requirements, transactional backups can be taken as frequently as you need. It is recommended that transactional backups be taken every 15 minutes for a production system.
Multiple Points of Failure
Taking full and transactional backups, however, does not mean that your data is sufficiently protected. If your backups are stored on the same physical device that houses the database, they can be subject to the same hardware failure that can corrupt or destroy the database. If your backups are on the same array as the data, and the array is lost, then you have lost both your live data and your backups, making your data unrecoverable. If your backups are on a different array, but still attached to the same server as the database, a server loss will potentially make your system unrecoverable. This is where the concept of multiple points of failure comes into play. You do not want any single event to be able to make your SAP system unrecoverable. The ideal scenario is for your database backups (both full and transactional) to be written to tape and taken to a secure remote location so that the live data and the backups are less likely to be destroyed in a single event, like a power surge or even acts of nature such as a flood or tornado.
Recovery Planning
No matter how extensive your backup scenario is, it is useless if there is not a recovery plan in place. Your company needs to have a recovery plan in place and periodic recovery tests need to be performed so that documentation is kept updated and the validity of the backup/recovery scenario is verified. It is recommended that recovery scenarios be tested and updated at least once annually.
Hope this helps...
In order to protect your SAP systems, it is recommended that full and transactional backups be created regularly and kept separate from the system hardware, preferably in a remote location.
Full Backups
A full backup contains the entirety of the database at a given point in time. In the event of a hardware failure or data corruption, it is necessary to have a full backup of the database to restore. The main benefit of having a full backup available for restore is obvious: your company does not have to lose critical business data in the event of a failure. It is recommended that a full backup be taken at least once daily.
Transactional Backups
Full backups alone are not sufficient for most businesses. If a failure occurs just before or during a full backup, then data created or altered since the prior backup will be lost. Transactional backups are designed to save the changes made to a database after full backups are taken, that way those changes are protected. If your backups are setup to run daily at 12:00 AM, and you have transactional backups every hour, then if a failure occurs at 11:59 PM, you potentially would only lose 59 minutes worth of productive changes. Depending on your business requirements, transactional backups can be taken as frequently as you need. It is recommended that transactional backups be taken every 15 minutes for a production system.
Multiple Points of Failure
Taking full and transactional backups, however, does not mean that your data is sufficiently protected. If your backups are stored on the same physical device that houses the database, they can be subject to the same hardware failure that can corrupt or destroy the database. If your backups are on the same array as the data, and the array is lost, then you have lost both your live data and your backups, making your data unrecoverable. If your backups are on a different array, but still attached to the same server as the database, a server loss will potentially make your system unrecoverable. This is where the concept of multiple points of failure comes into play. You do not want any single event to be able to make your SAP system unrecoverable. The ideal scenario is for your database backups (both full and transactional) to be written to tape and taken to a secure remote location so that the live data and the backups are less likely to be destroyed in a single event, like a power surge or even acts of nature such as a flood or tornado.
Recovery Planning
No matter how extensive your backup scenario is, it is useless if there is not a recovery plan in place. Your company needs to have a recovery plan in place and periodic recovery tests need to be performed so that documentation is kept updated and the validity of the backup/recovery scenario is verified. It is recommended that recovery scenarios be tested and updated at least once annually.
Hope this helps...
Monday, April 28, 2008
SAP Java ConfigTool...
Since most of you know my experience with Java is very limited, it shouldn't surprise you that I was just recently introduced to the Java ConfigTool for SAP.
A client was having issues with some of the Java process dropping off while SAP was running, so I opened a customer message for them.
The solution was to change the Global Server Config -> Managers-> ClusterManager-> ms.confirmation.timeout parameter inside the ConfigTool.
The ConfigTool can be found here:
usr\sap\\\j2ee\configtool\configtool.bat
Hope this helps.
A client was having issues with some of the Java process dropping off while SAP was running, so I opened a customer message for them.
The solution was to change the Global Server Config -> Managers-> ClusterManager-> ms.confirmation.timeout parameter inside the ConfigTool.
The ConfigTool can be found here:
usr\sap\
Hope this helps.
Thursday, April 24, 2008
SAPGUI Logon Screen Message...
You want to display a customer-specific text on the SAPGui logon screen?
Go to Transaction SE61and select the document class General Text (selection using F4 help), and create a text with the name ZLOGIN_SCREEN_INFO in the system language determined with the profile parameter zcsa/system_language. If the text does not exist in the system language, no output is made. Note that there is space on the logon screen for 16 lines for every 45 fixed-font characters or for approximately 60 proportional font characters. Title lines (can be recognized by format keys starting with a 'U') are highlighted in the display. You may also output icons at the beginning of lines by using an icon code (for example, @1D@ for the STOP icon). You can get a list of icon codes from Report RSTXICON. Pay attention to the codes with two '@' symbols displayed by the report. You cannot include text symbols. The function 'include character' cannot be used.
Creating/changing this text requires a changeable system. Therefore, for production systems, SAP recommends maintaining the text in the upstream system and then transporting it. To do this, select a transportable (customer) development class when you create the text and save the active version prior to the export.The transport is done via the transport object R3TR DOCT ZLOGIN_SCREEN_INFO The text can be changed in the original system only (see TADIR entry R3TR DOCT ZLOGIN_SCREEN_INFO). When making a change in a non-original system, a modified text would be generated which cannot be represented sensefully on the initial screen.
Try this example text on for size:
Client 100: Development/Customizing
Client 200: Unit Test
Client 900: Sandbox
@1A@ Warning.
You are about to logon to the Development System for
COMPANY NAME
Unauthorized Access is Prohibited.
If you encounter any problems, please
contact your System Administrator.
Go to Transaction SE61and select the document class General Text (selection using F4 help), and create a text with the name ZLOGIN_SCREEN_INFO in the system language determined with the profile parameter zcsa/system_language. If the text does not exist in the system language, no output is made. Note that there is space on the logon screen for 16 lines for every 45 fixed-font characters or for approximately 60 proportional font characters. Title lines (can be recognized by format keys starting with a 'U') are highlighted in the display. You may also output icons at the beginning of lines by using an icon code (for example, @1D@ for the STOP icon). You can get a list of icon codes from Report RSTXICON. Pay attention to the codes with two '@' symbols displayed by the report. You cannot include text symbols. The function 'include character' cannot be used.
Creating/changing this text requires a changeable system. Therefore, for production systems, SAP recommends maintaining the text in the upstream system and then transporting it. To do this, select a transportable (customer) development class when you create the text and save the active version prior to the export.The transport is done via the transport object R3TR DOCT ZLOGIN_SCREEN_INFO The text can be changed in the original system only (see TADIR entry R3TR DOCT ZLOGIN_SCREEN_INFO). When making a change in a non-original system, a modified text would be generated which cannot be represented sensefully on the initial screen.
Try this example text on for size:
Client 100: Development/Customizing
Client 200: Unit Test
Client 900: Sandbox
@1A@ Warning.
You are about to logon to the Development System for
COMPANY NAME
Unauthorized Access is Prohibited.
If you encounter any problems, please
contact your System Administrator.
Thursday, March 20, 2008
TP.exe (or STMS) Hangs While Importing or Adding Transports to the Buffer...
There are many reasons why TP.exe (the underlying executable that STMS calls on the OS) may hang while trying to make changes to one of the system transport buffers. The reason we came across yesterday was this: there was something corrupt inside the usr/sap/trans/tmp directory. Now, the tmp directory contains a lot of really important stuff for TP.exe, and then again it also can contain a lot of unnecessary junk. I DO NOT recommend deleting this directory. In fact, the best way to fix this is to simply rename that directory and create a new, empty tmp directory, then attempt to manipulate the buffer again with the TP.exe commands or transaction STMS. The tools will work fine with an empty tmp directory, but if you are interested in finding out what file caused this problem you can always copy the files from the original directory one-by-one and run test commands each time to single out which file is the culprit. But I don't have time for any of that. I just left the old tmp directory (now name tmp_old) in place and went about my busy little life.
Hope this helps...
Hope this helps...
Subscribe to:
Posts (Atom)