Working with Server Domain Configurations

This chapter provides an overview and discusses how to:

• Work with the default PS_CFG_HOME.

• Work with alternate PS_CFG_HOME locations.

• Manage domains.

• Work with PS_APP_HOME.

Understanding PS_HOME and PS_CFG_HOME

On any server that you install the PeopleTools software, the installation program installs the required files for that server into one high-level directory structure, referred to as PS_HOME. After creating a domain, the configuration files associated with that domain reside in a directory structure referred to as "PS_CFG_HOME".

By default, the system separates the binary files (executables and libraries) stored in PS_HOME from the ASCII files (configuration and log files) associated with a domain stored in PS_CFG_HOME. This separation of the binary and ASCII files applies only to these servers:

• PeopleSoft Application Server.

• PeopleSoft Process Scheduler Server.

• PeopleSoft Search Server.

• PeopleSoft Internet Architecture.

Note. Decoupling binary files from ASCII files does not apply to any other PeopleSoft servers, such as file servers or database servers.

The following table describes the two file types and provides examples of these types within the PeopleSoft server.

Note. While some ASCII files are present in PS_HOME, these should be considered non-modifiable. For example, all of the files that are in PS_CFG_HOME when it is initially created, come from the associated PS_HOME.

The decoupling of these file types enables system administrators to:

• Streamline and provide more flexible PeopleSoft server installations.

• Apply unique security restrictions to the binary file and configuration file locations.

Note. Although domains always contain their base template, the CFX and UBX templates (such as small, medium, and large) remain in PS_HOME. This means that when you create a new domain the template that you choose comes from PS_HOME\appserv, not PS_CFG_HOME\appserv.

Implementing Flexible Server Installations

With the binary files separate from the domain configuration, you have the option of installing multiple domains on multiple separate servers all leveraging the binary files of a single PS_HOME.

Multiple PS_CFG_HOME locations, containing multiple domains, all referencing the same PS_HOME installation on a remote server

Creating domains on separate servers enables you to:

• Install the PS_HOME binaries a single time.

• Incorporate additional server machines for additional domains per demand and performance requirements.

• Apply updates and upgrades to a single PS_HOME, reducing the time required for upgrading your system.

Applying Security Restrictions

With the server binary files and configuration files in separate locations, you can now apply uniform restrictions per file type. For example, some sites might prefer to have the binary files under read-only security, while providing write access to the configuration files to specific users for administrative tasks and certain server processes, such as logging.

See Securing PS_HOME and PS_CFG_HOME.

Working with the Default PS_CFG_HOME

This section discusses how to:

• Locate the default PS_CFG_HOME.

• Use PSADMIN with the default PS_CFG_HOME.

Locating the Default PS_CFG_HOME

When you launch PSADMIN, if a PS_CFG_HOME does not exist, the system creates the PS_CFG_HOME directory in the “user” directory of the current user (the owner of the domain). The system assumes the presence of the following environment variables:

For example, depending on the operating system of the server, the system creates PS_CFG_HOME in the following location on the same drive as PS_HOME.

After you create a domain, the domain exists under $PS_CFG_HOME\appserv\<domain>.

With a user of tsawyer, on UNIX/Linux this would appear as:

/home/tsawyer/peopletools/8.52
                     peopletools.properties
                     /appserv
                       /CRM
                       /HR
                       /PRCS
                         /CRM_PRCS
                         /HR_PCRS
                       /Search
											/webserv
                       /ver_dom

With a user of tsawyer, on Windows this would appear as:

C:\Documents and Settings\tsawyer\psft\pt\8.52
				              peopletools.properties
                     \appserv
                        \CRM
                        \HR
                        \PRCS
                           \CRM_PRCS
                           \HR_PCRS
                        \Search
                        \Temp
                        \webserv
                        pswinsrv.cfg

Note. The previous examples show a situation in which CRM, HR, CRM_PRCS, HR_PRCS and ver_dom are all domain directories. They are not in PS_CFG_HOME by default, and appear only after the domains are created.

To display the default PS_CFG_HOME location, you can submit the following command to PSADMIN:

psadmin -defaultPS_CFG_HOME

Note. These commands are not case sensitive.

Using PSADMIN with the Default PS_CFG_HOME

Launching PSADMIN requires no extra steps or variables defined when domains exist on the same machine as PS_HOME in the default PS_CFG_HOME location.

When you launch PSADMIN, it will either create (if one doesn’t exist) PS_CFG_HOME or search for PS_CFG_HOME, based on the current environment settings.

To start PSADMIN, the following conditions need to be fulfilled:

• PS_CFG_HOME must be a valid location. That is, the base directory must exist (UNIX), or the drive must exist (Windows).

• The PS_CFG_HOME must be writeable, and the user running PSADMIN must have write access to the PS_CFG_HOME location.

Working with Alternate PS_CFG_HOME Locations

Domains can exist on the same physical machine or a different physical machine than where the PS_HOME directory resides. That is, multiple domains on different machines can leverage a single installation of the PeopleSoft binary files (PS_HOME) installed on a location accessible through your network.

This section discusses how to:

• Specify alternate PS_CFG_HOME locations.

• Configure domains in alternate locations of PS_CFG_HOME.

Specifying Alternate PS_CFG_HOME Locations

The value of the PS_CFG_HOME environment variable determines where PSADMIN installs a domain. If you accept the default location of PS_CFG_HOME, this environment variable does not need to be specified. However, if you intend to install your domains in a different location, you need to override the default by setting the PS_CFG_HOME environment variable prior to launching PSADMIN.

For UNIX and Linux, you can:

• Set the PS_CFG_HOME environment variable in the psconfig.sh file. However, if you hard code the PS_CFG_HOME environment variable in psconfig.sh other users will not be able to use the same PS_HOME for different PS_CFG_HOMEs. All users of the same PS_HOME would invoke the same psconfig.sh, and therefore see their domains in the same PS_CFG_HOME.

• Set PS_CFG_HOME in the startup script for the platform/shell, resulting in the automatic inheritance of the environment variable when a user signs on.

For Windows, you can set PS_CFG_HOME through the Control Panel in the user variables interface, or issue a SET command prior to starting PSADMIN. For example,

C:\>SET PS_CFG_HOME=n:\psftdomains
C:\>cd pt850\appserv
C:\pt850\appserv>psadmin

In this case, any domains created during this PSADMIN session would be created in n:\psftdomains\appserv.

Note. If you elect to operate in the same fashion as previous PeopleTools releases (where the configuration files and the binary files exist within the same directory structure) set PS_CFG_HOME = PS_HOME.

Using the %V and %K Meta Variable

Use the %V meta variable if you wish to keep all of your PS_CFG_HOMEs together without needing to set PS_CFG_HOME each time you install a new PeopleTools version.

For example, you could set the PS_CFG_HOME environment variable as follows:

PS_CFG_HOME=C:\PeopleTools\installs\%V

If using the %V meta variable, assume you have installed two versions of PeopleTools: PT8.50 and PT8.51. In this case, PSADMIN automatically maps the %V to the PeopleTools version, creating the following PS_CFG_HOME locations:

C:\PT\installs
          \8.50-00
          \8.51-00

Use the %K variable if you wish to store PS_CFG_HOMEs by patch level. That is, while %V stores the files by version (8.50–00, 8.51–00), %K stores files down to the patch level. For example, using %K, a PS_CFG_HOME may look similar to:

C:\PT\installs
          \8.52
               \8.52-01
               \8.52-03
   

Configuring Domains in Alternate Locations of PS_CFG_HOME

When using PSADMIN with alternate locations of PS_CFG_HOME, make note of the requirements discussed in this section.

Working with Remote PS_HOME Locations

If you intend to install your domains on a separate machine from where PS_HOME resides, keep these items in mind:

• The network location to where PS_HOME resides must be mapped to from the machine where PS_CFG_HOME resides.

• If a domain references a PS_HOME on a mapped drive, problems may arise if the drive letter or path is changed after initially creating the domain. If a drive mapping changes, the domain definitions may reference invalid path information. In the event of mapped drive changes, shut down the existing domains and reconfigure (or recreate) the domains.

• If PS_HOME resides on a remote server, the operating system of the PS_HOME server and the PS_CFG_HOME server must match. PeopleTools binaries are native to a platform.

Installing Necessary Components

While you can leverage a single, remote installation of PeopleTools, the server on which PS_CFG_HOME resides must have any additional components installed locally, such as Tuxedo, database drivers, ODBC connectivity information, and so on, depending on your implementation.

Ensuring that PS_CFG_HOME is Set Appropriately

Only domains installed within the current PS_CFG_HOME directory can be administered by PSADMIN. That is, the list of domains to administer that PSADMIN displays depends on the value of the PS_CFG_HOME variable. PSADMIN does not aggregate a domain list across multiple locations.

Assume that you have domains installed under these two PS_CFG_HOME directories:

• N:\psftdomains\appserv

• M:\psftfomains\appserv

Assume also that on server N domain 1 and domain 2 are installed, and on server M domain 3 and domain 4 are installed.

If you launch PSADMIN from server N, where PS_CFG_HOME, by default, is set to N:\psftdomains\appserv, you will only be able to view and administer domain 1 and domain 2.

Domains created on machine N, can only be configured on machine N. There are settings in the domain PSTUXCFG file that bind a domain to its host. You can not boot or configure a domain from a different machine.

Note. The user creating and configuring domains in PSADMIN must have write access to the PS_CFG_HOME location.

Note. You can have multiple PS_CFG_HOME locations on the same host server, but you will need to make sure the PS_CFG_HOME is set appropriately prior to starting PSADMIN, or my using the Switch Config Home PSADMIN option.

Managing Domains

When working with decoupled PS_HOME and PS_CFG_HOME directory structures, keep these recommendations in mind:

• Use distinct PS_CFG_HOME locations for each PS_HOME. When a PS_CFG_HOME is created, PSADMIN brings content from the current PS_HOME into the PS_CFG_HOME, which effectively binds that PS_CFG_HOME to that PS_HOME. That is, all domains within a given PS_CFG_HOME should reference the same PS_HOME. Domains in the same PS_CFG_HOME that reference different PS_HOMEs can encounter unpredictable behavior, especially when applying updates to the system.

• Install as few PS_HOMEs as possible. Ideally, each PS_CFG_HOME requiring the same PeopleTools release level points to the same PS_HOME. This approach helps reduce the number of locations that require patches to be applied.

• After applying updates (patches) to the PS_HOME, recreate domains associated with that PS_HOME.

• A domain configured on one machine cannot be copied manually and run on another machine. Use the Replicate Config Home PSADMIN option to perform this task.

• The Windows service configuration file (PSWINSRV.CFG) will be invalid if it is shared between multiple PS_CFG_HOMEs on different network drives.

• As you maintain your system and upgrade domains, keep in mind that dormant domains will consume disk space. Make sure to keep track of where your retired domains reside and take action to remove them when no longer required. It is generally recommended to remove old log files and trace files for both efficiency and security purposes.

Working with PS_APP_HOME

This section contains an overview and discusses how to manage environments where PS_APP_HOME has been implemented.

Understanding PS_APP_HOME

The PS_APP_HOME environment variable refers to the location where you have installed the contents of your PeopleSoft application. In all previous PeopleSoft releases, you installed PeopleTools into a high-level directory referred to as PS_HOME, and then you installed your PeopleSoft application into the existing PS_HOME location such that PeopleTools and your PeopleSoft application co-exist within the same directory structure.

In the current release, PeopleTools provides the option of installing your PeopleSoft application into a separate directory, outside of the PS_HOME location. The location where you install your PeopleSoft application files is represented by the PS_APP_HOME environment variable. For example, an environment where PS_APP_HOME is implemented may have the following environment variables set.

PS_CFG_HOME=D:\pt_852_server

PS_APP_HOME=N:\HCM_920

Important! Deciding whether to install your PeopleSoft application into a separate PS_APP_HOME should be considered while planning your installation.

See PeopleTools 8.52 Installation for <your platform> and your PeopleSoft application installation guide.

Installing your applications into PS_HOME is still assumed to be the default approach, and, if you elect to stay with this model, there is no change to your existing PeopleSoft system management experience. However, sites that take advantage of the PS_APP_HOME option can expect a variety of benefits, including:

• PeopleTools patches and updates can be applied knowing that no application content has been disturbed. Likewise, PS_APP_HOME application updates can be applied independently.

• Increased flexibility and modularity in that a single PS_HOME can be associated with multiple PS_APP_HOME locations.

• Disk space savings, due to shared PS_HOME amongst multiple PS_APP_HOME locations. Using the traditional method, each application installation requires its own PeopleTools installation.

• When troubleshooting it will be easier to isolate application and PeopleTools issues.

Managing Environments with PS_APP_HOME

If you elect to install your PeopleSoft application outside of PS_HOME, then you need to make sure to set the PS_APP_HOME environment variable prior to running PSADMIN, which can be done manually or by using a.BAT or shell script. Also, as you configure your system, you need to be mindful of the PS_APP_HOME location.

Note. If you do not set the PS_APP_HOME environment variable explicitly, PeopleSoft runtime retrieves all runtime content from PS_HOME. That is, unless you set PS_APP_HOME to a value different than PS_HOME, the system assumes PS_APP_HOME=PS_HOME.

In many of the configuration settings where PS_APP_HOME might be involved, PeopleTools includes both PS_APP_HOME and PS_HOME references. For example,

RCCBL PRDBIN=%PS_APP_HOME%/cblbin:%PS_HOME%/cblbin

In environments where PS_APP_HOME has been implemented, system elements, such as server domains have access to content supplied by both PS_HOME and PS_APP_HOME, but files added by the PeopleSoft application installation (those residing in PS_APP_HOME) that have the same name as those in the PeopleTools PS_HOME take preference.

The following table outlines key areas in the PeopleSoft system, where you need to consider the PS_APP_HOME variable if you have installed your PeopleSoft applications into a location outside of PS_APP_HOME. When you are installing, configuring, and maintaining your system, make sure to keep these items in mind and review the documentation associated with these areas.