What Are The Permissions For The Purge Process, Prcsyspurge?

Purge process - Required permissions

The PeopleSoft Oprid used to start the Process Scheduler, as defined in the Scheduler's psprcs.cfg file, must have the following permissions to be able to submit the purge process:

1) "ProcessSchedulerAdmin" Role.
2) "ReportDistAdmin" Role.
3) The Oprid must have the "Can start Application Server" permission assigned.

4) The Oprid must have the TLSALL Process Group permission assigned.
5) The Oprid must have a valid Process Profile and Primary Permission List.


NOTE: "Can start Application Server" and TLSALL process group permissions must be part of a Role assigned to the Oprid.

Steps to add the necessary permissions:

1) Navigate to PeopleTools - User Profiles - User Profiles.
2) Bring up the record for the affected Oprid.
3) Navigate to the Roles tab.
a) Select the + button to add a new row.
b) Assign the "ProcessSchedulerAdmin" role.
c) Select the + button to add a new row.
d) Assign the "ReportDistAdmin" role.
e) Select the + button to add a new row.
f) Assign the "PeopleSoft User" role.
g) Select the + button to add a new row.
h) Assign the "PeopleTools" role.
i) Save the record.
4) Navigate to the General tab.
a) Take note of the Process Profile value.
5) Navigate to PeopleTools - User Profiles - Permissions & Roles.
6) Select Permission Lists and search for the Permission List from step 4a.
7) On the General tab, select the "Can Start Application Server?" checkbox.
8) Select the Process tab.
a) Select the "Process Group" link.
b) Enter a new value: "TLSALL".
c) Hit Ok to return to the previous page.
d) Save the record.

Check which user is having access to start an app server or process scheduler.

Below is a SQL statement that will help you find what users already have access to start an app server or process scheduler.

select DISTINCT ROLEUSER from PSROLEUSER where Rolename in (select ROLENAME from PSROLECLASS where CLASSID in (select CLASSID from PSCLASSDEFN where STARTAPPSERVER = '1'))

How to Migrate or Copy Security From One Database to Another

NOTE for PeopleTools 8.4x and 8.5x:

Question in 8.4x/8.5x. In PT 8.1x there were scripts to migrate security called IMPOPR.DMS, EXPOPR.DMS, USERIMPORT.DMS, and USEREXPORT.DMS. Where are these scripts for PT 8.4x/8.5x?

Answer: The USERIMPORT.DMS, and USEREXPORT.DMS scripts are still available but have a few new tables. The scripts used in PT 8.4 for migrating ALL security tables are called SECURITYEXPORT.DMS and SECURITYIMPORT.DMS.

In PeopleTools 8.4x/8.5x you MUST also update the Portal registry in the target database in order for your new security to take affect correctly. You will need to run the Application Engine program PORTAL_CSS. See Document:624004.1 - E-PORTAL: PT 8.4x and 8.5x: How to Run Portal Security Synch PORTAL_CSS Process for how to do this. But there are some known issues with this process when copying security. see the PORTAL_CSS resolution above for more information on that.

Also, you will want to have the Access ID, Access Password and Symbolic ID the same between the source and target databases in order to alleviate confusion after migration.  If you choose not to have this before the migration, then you will have to make manual updates to the PSOPRDEFN, PSACCESSPRFL, and PSSTATUS in order to be able to log in.  If you are on Oracle or DB2 databases, then you need to update the PSDBOWNER. 

These scripts export and import all of the PeopleTools security tables.

Here is a list of the tables. Note: For an up-to-date list of tables, please refer to the scripts themselves, that are delivered for your PeopleTools Release.

-- ACCESS PROFILES
PSACCESSPRFL

-- USERS
PSOPRDEFN
PSOPRALIAS
PSROLEUSER
PSUSERATTR
PSUSEREMAIL
PSUSERPRSNLOPTN
PS_ROLEXLATOPR
PS_RTE_CNTL_RUSER

-- ROLES
PSROLEDEFN
PSROLEDEFNLANG
PSROLECANGRANT
PSROLECLASS

-- PERMISSION LISTS
PSCLASSDEFN
PSAUTHBUSCOMP
PSAUTHCHNLMON
PSAUTHCUBE
PSAUTHITEM
PSAUTHOPTN
PSAUTHPRCS
PSAUTHSIGNON
PSPRCSPRFL
PS_MC_OPR_SECURITY
PS_MC_OPRID
PS_SCRTY_ACC_GRP
PS_SCRTY_QUERY

-- DEFINITION SECURITY

EXPORT PSPTDEFSEC_GRPS;

EXPORT PSPTDEFSEC_GRP;

EXPORT PSPTDEFSECINRL;

EXPORT PS_APP_DES_OBJ_CST;

EXPORT PSOPROBJ;

-- PERSONALIZATIONS
PSUSEROPTNDEFN
PSUSEROPTNLANG
PSOPTNCATGRPLNG
PSOPTNCATGRPTBL
PSOPTNCATTBL
PSOPTNCATLANG

-- SECURITY OPTIONS
PSSECOPTIONS

-- SECURITY LINKS
PSUSEROTHER
PSUSERSELFOTHER
PSROLEOTHER
PSPERMLISTOTHER

-- USER ID TYPES
PSOPRALIASTYPE
PSOPRALIASFIELD

-- DELETE USER BYPASS TABLE
PS_BYPASS_TABLE

-- FORGOT EMAIL TEXT
PSPSWDEMAIL

-- PASSWORD HINTS
PSPSWDHINT

-- SIGNON PEOPLECODE
PSSIGNONPPC

-- DIRECTORY
PSDSDIR
PSDSSRVR
DSCONNECTID
PSDSEXT_INSTALL
PSDSSECMAPMAIN
PSDSSECMAPSRVR
DSUSRPRFLMAP
PSDSUSERPRFL
PSDSSECROLERULE
DSSRCH_SBR
DSSRCHATTR
DSSECFILTER
PT_WF_NOT_DSCFG

Please note, that in PT 8.4x/8.5x, it is NOT recommended to use these scripts (userimport/export and securityimport/export) to migrate users/security between two different Tools versions.  The recommendation to sync up users between databases that are on two different Tools version is as follows:

If customers are to migrate data from a content DB at a lower Tools  release to a Portal DB at a higher Tools release, the recommended procedure is as follows:
a) Make a copy (clone) of the content DB.
b) Run a Tools-only upgrade on that DB copy, in order to bring it up to the same release as the Portal DB (which should never be lower than that of  the content DB).
c) Run the UserExport / UserImport dms scripts to copy the Security data from the upgraded DB to the Portal DB (both at the same Tools release)
d)Discard the cloned (content) DB once the Portal DB has received the desired data.
Please note that the Security tables on the content DB should be locked down until this process is completed to avoid updates which would not get propagated.

PeopleSoft Deployment Package command lines

It is possible to install these domains separately on different machines using a DPKs. The DPK will have to be executed on each server with the proper install command.

the bootstrap has options to specify the domain_type (the default is all). You can execute the following command in PowerShell or Linux Batch process:

1. For App Server domain

--env_type midtier --domain_type appserver

2. For App Batch Domain (for App Server & Process Scheduler on on one machine)

--env_type midtier --domain_type appbatch

3. For PIA Domain

--env_type midtier --domain_type pia

4. For a Process Scheduler Domain

--env_type midtier --domain_type prcs

5. This command setups a fulltier (database and midtier) PeopleSoft environment using the DPK zips from the directory /opt/psft/dpks.

--dpk_src_dir /opt/psft/dpks

7. This command deploys just the PS_HOME. It does not setup any PeopleSoft environment. Just installs PS_HOME and none of the other 3rd party components.

--env_type midtier --deploy_only --deploy_type tools_home

[NOTE] For --deploy only commands, above, the “--deploy_type --deploy_only” option is broken in 8.55.01 which is bundled with PUM –HCM Image 16.

There is no workaround. If a customer is taking PUM image, this deploy-only option is not even valid as they need fulltier components.

The issue has been addressed in the 8.55.03 patch of PeopleTools. The Bug# is 22535736 - SERVER DPK - DEPLOY_ONLY WITH APPS DPKS CREATES PI_HOME.

Bad Request

Post go-live of project, some of the users were facing below issue when they were trying to access the application.

Bad Request

Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.

Authorization

Reason : Request Header size was big for some profiles which server was refusing

Fix: To fix we have make modification in httpd.conf

  LimitRequestFieldSize 16384


we need to add this parameter under virtual host
<VirtualHost *:80>
   ServerName xxxxxxxxx
   LimitRequestFieldSize 16384
   RequestHeader set WL-Proxy-SSL true
   RewriteEngine on



Use below links for more help
https://stackoverflow.com/questions/10309751/bad-request-your-browser-sent-a-request-that-this-server-could-not-understand

https://serverfault.com/questions/413984/increase-the-value-of-limitrequestfieldsize-in-apache