User ID Deletion

[sunilv_dev]

Hi:

I have a job scheduled by a user USER01. I deleted this user id as user left organization. Will this impact scheduled job??

Will it still run on scheduled time or will it be canceled???

Let me know.

[Former Member]

Hi Tridev,

If you have deleted/locked the User, then the Job scheduled under that particular User ID will be cancelled.

Regards,

Kiran Kandepalli.

[Former Member]

>

> Will this impact scheduled job??

You have already done it, so you tell us what happened...?

If these are only interview questions, then please take note that the purpose of these forums is not to load interview questions into them and expect others to do your investigations and learning for you. Try it yourself, use the search and ask specific questions if you have a problem.

Cheers,

Julius

[sunilv_dev]

This was not an interview question. I just wanted to know as we have not deleted user ID's but have locked them.

[Former Member]

Hi Tridev,

If the user who has scheduled the job is not active in the system then the Job scheduled by him will get cancelled.When the job will begin to run, it will authenticate the user under whose id it was scheduled and not finding the user active in the system it will get aborted.

Thanks,

Saby..

[jurjen_heeck]

> I just wanted to know as we have not deleted user ID's but have locked them.

That's good. There are a number of threads about the disadvantages of deleting users.

Locking will also prevent their jobs form running.

[Former Member]

Okay, sorry about that. For a moment it sounded as if you didn't even have a system, which normally indicates a series of interview questions about to "take off"

>

> I deleted this user id as user left organization.

So you actually meant "locked" and would like to know whether you can "delete" (as well).

Do you think there should be a difference, considering that the user cannot logon (it is locked) so will not pass any authority-checks either...?

I am a bit surprised that you have marked this thread as answered....

Are you referring to:

- the user ID in a job-step (who will need authority to run the step when checks are encountered)? or

- the user who created the job and defined other SYSTEM-type users in the job steps (noting that others who come and go might have done some subsequent maintenance on this job as well)?

- or are these job steps changing existing or scheduling new jobs / job-steps, particularly external commands?

- Or is it just a "vanilla" report scheduled to run in the background by a user (perhaps periodically)?

There are some differences, and it would be usefull to know which release you are on as well.

Cheers,

Julius

[sunilv_dev]

Hi Julius:

Thanks for the replying. My dilemma is we have many users who left organization but there are few daily jobs scheduled under their ID (Dialog users). Auditors asked as why these user still exists.

W explained them that if we delete these IDs, the jobs which they scheduled to run will not be executed.

There re many users who left the organization and we locked their user IDs. Does this impact licensing. Does SAP considers locked users as active users???

I don't know what we should do in this situation.

Lock User IDs or delete them or change job under system user ID??

I am sorry for any confusion that may have caused to you.

Please accept apologies.

[Former Member]

although i am telling you something you could have found by searching this forum, i think it is important enough to answer again:

1st of all one should Never delete any userid in a SAP System reasons:

1 this makes impossible to create an other user with the same userid,

2 by LAW you need to be able to prove who a persone with a certian userid was, dependent on local laws the period can be over 10 years.

3 some open processes in f.i. workmanagement can not be finalised if the userid that started the process is no longer active in the system.

4 background jobs scheduled on the uid's will fail.

best practice for "obsolete" users:

A Lock userid

B take away all roles,

C set end validity date of userid to today.

D move user to a dedicated usergroup (Like Obsolete Users)

E change license type to a NON paying type

Besides that i would suggest to immediately create background userid's and schedule all your background jobs top ONLY run on these uid's

[Former Member]

I agree with Auke.

Make an inventory of the jobs which you have and which steps have dialog users in them (regardless of whether the user is still there or not) and set them up again with dedicated SYSTEM-type users. As these user's are often slaves to some other user or file system, it is advisable to grant them only the authority which they need to run these jobs and isolate access to them (object S_BTCH_NAM). Also take a closer look at object S_BTCH_ADM to deter this in future by having dedicated batch-job administrators who are trained not to enter themselves or other dialog users into those jobs.

Best you speak to the developers and the users who "own" these jobs first.

Good luck,

Julius

[Former Member]

Julius, Can you throw your opinion on following Batch Administration/Usage process:

1. All End Users get :

S_TCODE: SM36 & SM37

S_BTCH_JOB: LIST, PLAN, PROT, RELE, SHOW

User's cannot delete other's jobs !

2. Business Support Users get :

S_TCODE: SM36 & SM37

S_BTCH_JOB: LIST, PLAN, PROT, RELE, SHOW

S_BTCH_NAM: FI_BATCH (OR SD_BATCH, etc)

User's can access FI_BATCH's jobs !

3. Batch Admins get:

S_TCODE: SM36 & SM37

S_BTCH_JOB: *

S_BTCH_NAM: *

S_BTCH_ADM: Y

Let me know if this would be ideal/typical

Thanks

Prashanth

[Former Member]

I don't know how your support and processes are set up, but some suggestions worth considering:

> 1. All End Users get :

>

> S_TCODE: SM36 & SM37

> S_BTCH_JOB: LIST, PLAN, PROT, RELE, SHOW

>

> User's cannot delete other's jobs !

If they need access to their own jobs only to see when reports they have executed in the background are finished, then consider giving them tcode SMX (display only) instead on SM36 & SM37.

> 2. Business Support Users get :

>

> S_TCODE: SM36 & SM37

> S_BTCH_JOB: LIST, PLAN, PROT, RELE, SHOW

> S_BTCH_NAM: FI_BATCH (OR SD_BATCH, etc)

>

> User's can access FI_BATCH's jobs !

This would depend on the authority of the FI_BATCH user ID.

If you want them only to support existing jobs and not be tempted into creating more (new) ones, then reconsider SM36.

> 3. Batch Admins get:

>

> S_TCODE: SM36 & SM37

> S_BTCH_JOB: *

> S_BTCH_NAM: *

> S_BTCH_ADM: Y

What you might want to consider here is exclusing the dialog users and the super users (DDIC, SAP*, etc) from S_BTCH_NAM if you don't want them to be used in periodic jobsteps (see the original problem described above).

From where I am here, it is hard to tell what is most ideal for your system and support where you are, so these are just suggestions to consider.

Cheers,

Julius