How to retrieve stdout from the WCC Job Runs component when using UNC paths

Document created by hebsh01 Employee on Oct 15, 2014Last modified by Lenn Thompson on Apr 20, 2016
Version 2Show Document
  • View in full screen mode

Issue encountered:  WCC does not display the stdout log or stderr logs when the std_out_file and std_err_file attributes in the job description include a UNC path.


We would prefer that the std_out / std_err files are hosted on the Agent machine so that the below modification to your Agent server will not be necessary, also so that these jobs being processed do not encounter a possible bottle-neck or point of failure accessing the UNC across the network.


The WAAE Agent machine is the server where the job is scheduled to run.

Modify the agent service properties -> Log On account needs to be modified to run as a user with elevated rights by adding the user to "Replace a process level token" in the Local Security Policy.


The job owner must have WAAE and OS level privileges to execute the job on the Agent machine.

The job owner must have read/write access to the UNC share.


By performing the following you will be able to retrieve the std_out/std_err spool files stored on a UNC path via the WCC Quick View - Job Runs component.



1.  Create local user with password for agent to run as - in this case 'WAAgent'

•  This user does not have to be an administrator on the agent server though your Security/Windows teams may appreciate it.

2.  Add 'WAAgent' user to the "Replace a process level token" in the Local Security Policy.

• This allows the Agent to have the necessary rights to be able to perform its Autosys duties, access the UNC path and send the results back to the WCC.

3.  Reboot your Agent server for the above settings to take place.

4.  Set the Workload Automation Agent to run as 'WAAgent' in services properties.

5.  Job owner attribute can be any user who has login privileges to this Agent as well as read/write privileges to the UNC share.

6.  The WCC user will need to have the appropriate privileges to work with the job provided by EEM or it must be a user with the valid default privileges or defined as a Credential User.

Note:   This user does not have to be the job owner.