Let me provide the complete solution that worked for our IS 2022.2 environment. The issue stems from three interrelated permission layers that all need proper configuration:
Windows Task Scheduler Permissions:
The service account needs ‘Log on as a batch job’ rights (you’ve verified this) and the task must run with ‘Run whether user is logged on or not’ enabled. However, the critical piece is ensuring the task runs under the service account’s full credentials, not just the security context.
NTFS and Share Access:
As Carlos mentioned, there are TWO permission layers on network shares. The share-level permissions often default to ‘Everyone: Read’ which blocks write operations even when NTFS permissions are correct. Verify the service account has ‘Change’ or ‘Full Control’ at the share level (\fileserver\scm_exports properties > Sharing tab > Advanced Sharing > Permissions). The NTFS permissions (Security tab) should also grant Full Control.
UNC Path vs Mapped Drive Handling:
Mapped drives (Z:, Y:, etc.) are user-session specific and don’t exist in the Task Scheduler’s system context. Always use UNC paths. However, the export utility configuration file might need explicit credential storage. Here’s the solution approach:
# Create wrapper script: DemandPlanningExport.ps1
net use \\fileserver\scm_exports /user:DOMAIN\serviceaccount *
Start-Process "C:\Infor\SCM\bin\DemandPlanExport.exe" -ArgumentList "/config:C:\Infor\SCM\config\export_config.xml" -Wait
net use \\fileserver\scm_exports /delete
Alternatively, use the two-stage approach:
- Configure export utility to write to local directory: C:\Temp\SCM_Exports
- Create second scheduled task (5 minutes after export) to copy files:
robocopy C:\Temp\SCM_Exports \\fileserver\scm_exports /MOV /R:3 /W:10 /LOG:C:\Logs\scm_copy.log
The /MOV flag moves files (deletes source after successful copy), /R:3 retries 3 times, /W:10 waits 10 seconds between retries.
We went with the two-stage approach because it isolated the authentication issues and made troubleshooting much simpler. The export utility no longer needs network access, and robocopy handles the network transfer with proper retry logic. This also improved reliability - if the network share is temporarily unavailable, the export still completes and files get transferred on the next robocopy run.
One final tip: Enable detailed logging in the export utility configuration and in Task Scheduler (History tab) to capture the exact point of failure. This helped us identify that the failure was happening during file write, not during the export processing itself.