Trouble with ESP getting correct status in spool file after windows server upgrade to 2022

[Keith Grizzell]

Upgrading one of our model servers and was wondering if anyone else was experiencing any issues withe ESP getting the correct return from a PowerShell script. Trying to figure out if this an ESP Agent issue or on the job owners side. We are using  workload automation system agent 12..0. and windows server was recently upgrade to windows server 2022 and we are seeing some interesting spool files. The jobs are submitting but in the spool file you can see a couple of access denied messages followed by a couple of job already running messages then more access denied messages and finally a successful execution. Has anyone else encountered this issues with agent 12.0 and windows server 2022? Worked just fine before upgrade. When working with job owner they state job starts executes and shows completion on their side. Any ideas or thoughts would be appreciated. What is really weird is that we would get an access error and then the job would run, I would think an access error would be fatal. Example below

----------------------------------------------------------------

 Output of messages for workload object OSMCCCFD/MDLCOR05.290532/MAIN

 Start date 06/10/2025 10:26:05.432-0400

 ----------------------------------------------------------------

 Batch name: CatastropheClaimFinder

 URL: https://sit-ws-claimcenter.gmcc.grange.local/cc/ws/gw/webservice/cc/MaintenanceToolsAPI

 Starting batch job: CatastropheClaimFinder

 Calling CC to start batch job: CatastropheClaimFinder

 @[91mInvoke-WebRequest: @[0mD:\CYB_jobs\esp_powershell_batch_scripts\CC_Powershell_Call_BatchWithStatus.ps1:69

 @[96mLine |

 @[96m  69 | @[0m . l]$result = @[96mInvoke-WebRequest -Uri $url -Headers $Headers  -Body $Bod@[0m .

 @[96m     | @[91m               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 @[91m@[96m     | @[91mWin32 internal error "Access is denied." 0x5 occurred while reading the console output buffer. Contact

 @[96m     | @[91mMicrosoft Customer Support Services.

 @[0m

 Sleeping for 30 and then attempting ping batch process CatastropheClaimFinder again. 

 Calling CC to start batch job: CatastropheClaimFinder

 @[91mInvoke-WebRequest: @[0mD:\CYB_jobs\esp_powershell_batch_scripts\CC_Powershell_Call_BatchWithStatus.ps1:69

 @[96mLine |

 @[96m  69 | @[0m . l]$result = @[96mInvoke-WebRequest -Uri $url -Headers $Headers  -Body $Bod@[0m .

 @[96m     | @[91m               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 @[91m@[96m     | @[91m

         soap12:Receiver   

         java.lang.RuntimeException:

 @[96m     | @[91mcom.guidewire.pl.system.exception.AlreadyRunningException: Batch process 'CatastropheClaimFinder' is

 @[96m     | @[91malready running

 @[0m

 Sleeping for 60 and then attempting ping batch process CatastropheClaimFinder again. 

 Calling CC to start batch job: CatastropheClaimFinder

 @[91mInvoke-WebRequest: @[0mD:\CYB_jobs\esp_powershell_batch_scripts\CC_Powershell_Call_BatchWithStatus.ps1:69

 @[96mLine |

 @[96m  69 | @[0m . l]$result = @[96mInvoke-WebRequest -Uri $url -Headers $Headers  -Body $Bod@[0m .

 @[96m     | @[91m               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 @[91m@[96m     | @[91m

         soap12:Receiver

         java.lang.RuntimeException:

 @[96m     | @[91mcom.guidewire.pl.system.exception.AlreadyRunningException: Batch process 'CatastropheClaimFinder' is

 @[96m     | @[91malready running

 @[0m

 Sleeping for 90 and then attempting ping batch process CatastropheClaimFinder again. 

 Calling CC to start batch job: CatastropheClaimFinder

 @[91mInvoke-WebRequest: @[0mD:\CYB_jobs\esp_powershell_batch_scripts\CC_Powershell_Call_BatchWithStatus.ps1:69

 @[96mLine |

 @[96m  69 | @[0m . l]$result = @[96mInvoke-WebRequest -Uri $url -Headers $Headers  -Body $Bod@[0m .

 @[96m     | @[91m               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 @[91m@[96m     | @[91m

         soap12:Receiver   

         java.lang.RuntimeException:

 @[96m     | @[91mcom.guidewire.pl.system.exception.AlreadyRunningException: Batch process 'CatastropheClaimFinder' is

 @[96m     | @[91malready running

 @[0m

 Sleeping for 120 and then attempting ping batch process CatastropheClaimFinder again.

 

 Calling CC to start batch job: CatastropheClaimFinder

 @[91mInvoke-WebRequest: @[0mD:\CYB_jobs\esp_powershell_batch_scripts\CC_Powershell_Call_BatchWithStatus.ps1:69

 @[96mLine |

 @[96m  69 | @[0m . l]$result = @[96mInvoke-WebRequest -Uri $url -Headers $Headers  -Body $Bod@[0m .

 @[96m     | @[91m               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 @[91m@[96m     | @[91mWin32 internal error "Access is denied." 0x5 occurred while reading the console output buffer. Contact

 @[96m     | @[91mMicrosoft Customer Support Services.

 @[0m

 Sleeping for 150 and then attempting ping batch process CatastropheClaimFinder again. 

 Calling CC to start batch job: CatastropheClaimFinder

 @[91mInvoke-WebRequest: @[0mD:\CYB_jobs\esp_powershell_batch_scripts\CC_Powershell_Call_BatchWithStatus.ps1:69

 @[96mLine |

 @[96m  69 | @[0m . l]$result = @[96mInvoke-WebRequest -Uri $url -Headers $Headers  -Body $Bod@[0m .

 @[96m     | @[91m               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 @[91m@[96m     | @[91mWin32 internal error "Access is denied." 0x5 occurred while reading the console output buffer. Contact

 @[96m     | @[91mMicrosoft Customer Support Services.

 @[0m

 Sleeping for 180 and then attempting ping batch process CatastropheClaimFinder again. 

 Calling CC to start batch job: CatastropheClaimFinder

 @[91mInvoke-WebRequest: @[0mD:\CYB_jobs\esp_powershell_batch_scripts\CC_Powershell_Call_BatchWithStatus.ps1:69

 @[96mLine |

 @[96m  69 | @[0m . l]$result = @[96mInvoke-WebRequest -Uri $url -Headers $Headers  -Body $Bod@[0m .

 @[96m     | @[91m               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 @[91m@[96m     | @[91mWin32 internal error "Access is denied." 0x5 occurred while reading the console output buffer. Contact

 @[96m     | @[91mMicrosoft Customer Support Services.

 @[0m

 Sleeping for 210 and then attempting ping batch process CatastropheClaimFinder again. 

 Calling CC to start batch job: CatastropheClaimFinder

 @[91mInvoke-WebRequest: @[0mD:\CYB_jobs\esp_powershell_batch_scripts\CC_Powershell_Call_BatchWithStatus.ps1:69

 @[96mLine |

 @[96m  69 | @[0m . l]$result = @[96mInvoke-WebRequest -Uri $url -Headers $Headers  -Body $Bod@[0m .

 @[96m     | @[91m               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 @[91m@[96m     | @[91mWin32 internal error "Access is denied." 0x5 occurred while reading the console output buffer. Contact

 @[96m     | @[91mMicrosoft Customer Support Services.

 @[0m

 Sleeping for 240 and then attempting ping batch process CatastropheClaimFinder again. 

 Calling CC to start batch job: CatastropheClaimFinder

 Successfully started batch job: CatastropheClaimFinder

 Pausing before retrieving status of batch job: CatastropheClaimFinder for 60 seconds. 

 Continuing process

 Calling CC for status of batch job: CatastropheClaimFinder

 Attempt: 1

 Batch status is completed

 pogo                : http://guidewire.com/gw/api/webservice/maintenanceTools

 Complete            : true

 DateCompleted       : 2025-06-10T10:44:20.937-04:00

 DateCreated         : 2025-06-10T10:44:08.685-04:00

 Executing           : false

 FailedOps           : 0

 OpsCompleted        : 0

 ServerId            : ualwapt02

 StartDate           : 2025-06-10T10:44:11.483-04:00

 Starting            : false

 StartingOrExecuting : false

 Success             : true

 Type                : CatastropheClaimFinder

Successful production version spool file of this job below

 ----------------------------------------------------------------
 Output of messages for workload object OSPCCCFD/PRDCOR05.299582/MAIN
 Start date 06/10/2025 14:41:05.610-0400
 ----------------------------------------------------------------
 Batch name: CatastropheClaimFinder
 URL: https://ws-claimcenter.gmcc.grange.local/cc/ws/gw/webservice/cc/MaintenanceToolsAPI
 Starting batch job: CatastropheClaimFinder
 Calling CC to start batch job: CatastropheClaimFinder
 Successfully started batch job: CatastropheClaimFinder
 Pausing before retrieving status of batch job: CatastropheClaimFinder for 120 seconds. 
 
 Continuing process
 Calling CC for status of batch job: CatastropheClaimFinder
 Attempt: 1
 Batch status is completed
 
 pogo                : http://guidewire.com/gw/api/webservice/maintenanceTools
 Complete            : true
 DateCompleted       : 2025-06-10T14:41:36.834-04:00
 DateCreated         : 2025-06-10T14:41:07.653-04:00
 Executing           : false
 FailedOps           : 0
 OpsCompleted        : 0
 ServerId            : ualwapp01
 StartDate           : 2025-06-10T14:41:11.476-04:00
 Starting            : false
 StartingOrExecuting : false
 Success             : true
 Type                : CatastropheClaimFinder
 
 
 

------------------------------
[Keith Grizzell]
[Infrastructure Specialist]
[Grange Insurance]
[Columbus] [Ohio]
------------------------------

[Venkateswarlu Dondapati]

Hi Keith,
We haven't found any open issues with System Agent 12.0 on Windows Server 2022.
The System Agent only writes the header information to the spool file. For your job run, the header portion is as follows:

----------------------------------------------------------------
Output of messages for workload object OSMCCCFD/MDLCOR05.290532/MAIN

Start date 06/10/2025 10:26:05.432-0400

----------------------------------------------------------------

The remaining messages in the spool file are generated by the PowerShell script used in the job definition. 

This indicates that the Agent itself is not accessing any files related to the "Access denied" errors in the spool file.

The reason the job is completing with a "success" status, despite the access denied errors, is because the PowerShell script is returning a success code, as shown below:

Batch status is completed
Success : true

We recommend checking with the owner of the PowerShell script, D:\CYB_jobs\esp_powershell_batch_scripts\CC_Powershell_Call_BatchWithStatus.ps1, to identify what resources it is accessing that are causing the "access denied" errors.

Thanks,
Venkat D (System Agent Team)

[Keith Grizzell]

Hi Venkat, thanks for the information I have reached out to the owner of the PowerShell and asked them to review their script

------------------------------
[Keith Grizzell]
[Infrastructure Specialist]
[Grange Insurance]
[Columbus] [Ohio]
------------------------------

[Keith Grizzell]

Just wanted to post an update. We worked with the app team on their PowerShell script. Turns out even though the spool file was showing the access denied error the job was actually being kicked off on the API side by the PowerShell script. Because ESP was retrying every 30 seconds due to the access denied error the jobs on the API side were being run multiple times until the successfully started message was finally returned to the spool file. APP team reviewed their PowerShell and found no issues. We opened a case with Microsoft per the error message and they found no issues. I finally opened a case with Broadcom support (Case #: 36601462) and we were instructed to add oscomponent.su.newconsole=true to the agent parm file and this fixed the issue and we no longer saw the access denied errors in the spool file. Still not sure of root cause but jobs are working correctly now

------------------------------
[Keith Grizzell]
[Infrastructure Specialist]
[Grange Insurance]
[Columbus] [Ohio]
------------------------------

[Lucy Zhang]

Thank you Keith for sharing the result!

-------------------------------------------