Hello,
We recently upgraded our VisualCron server installation from 7.7.8 to 8.2.1. We briefly had 8.2.7 installed but that was causing some issues which we resolved by downgrading to 8.2.1. Since that time several (about 10) SSIS 2016 tasks fail at the very end of the task with error of type:
C:\Windows\TEMP\VisualCron\7f93cad9-83ef-400c-b71f-f56215fc10a3' because it is being used by another process…
For certain SSIS tasks this happens sporadically but for one particular task that calls child dtexec packages it happens every time it runs. The tasks can run again but there is a buildup of files in the temp folder and if the task is part of job with subsequent tasks the job fails at that point preventing the subsequent tasks from running. This issue seems to be the same as that mentioned in here:
https://www.visualcron.c....aspx?g=posts&t=7478 
I doubt trying to get 8.2.7 or 8.2.8 up and running will resolve the issue based on that thread. We initially thought that maybe our antivirus was blocking VC from accessing the necessary files at the appropriate time but we disabled the antivirus on those folders and the problem persists.
Any help or advice would be appreciated. We need to get this resolved soon as some these tasks have a significant impact on our business processes.
Regards
Eesha

For more info I have included a process monitor trace of VC temp folder during the error.
Also the task that fails every single time calls child packages both with a native SSIS task and with .NET code. This happens with and without std out capture enabled on those SSIS jobs. The jobs and all child packages run to completion as noted above, the VC failure is at the end.
The file that causes the error is the VisualCron std out capture.  ProcessMonitorTrace_VCTemp.xlsx (16kb) downloaded 44 time(s).

In this case the (2016) SSIS packages are stored on a networked file share, so they can't be run by a local user. Credentials were used to run the SSIS package.

By running the visualcron service with a domain service account (instead of a local account), I was able to run the job with "No Credential". That configuration avoids the problem.
The job failing consistently was using credentials that (only) had impersonation options "Suppress flow" and "Open Desktop" selected. The jobs which occasionally failed had a distinct credential created with options "Duplicate token", "Suppress flow" and "Open desktop" checked.

Does this indicate credentials can not be reliably used with (2016) SSIS packages?

I was hoping this fix might also fix the display of the task log. It didn't. The task log shows all tasks with an hourglass icon (instead of an appropriate success/failure status).

In this case the (2016) SSIS packages are stored on a networked file share, so they can't be run by a local user. Credentials were used to run the SSIS package.

By running the visualcron service with a domain service account (instead of a local account), I was able to run the job with "No Credential". That configuration avoids the problem.
The job failing consistently was using credentials that (only) had impersonation options "Suppress flow" and "Open Desktop" selected. The jobs which occasionally failed had a distinct credential created with options "Duplicate token", "Suppress flow" and "Open desktop" checked.

Does this indicate credentials can not be reliably used with (2016) SSIS packages?

I was hoping this fix might also fix the display of the task log. It didn't. The task log shows all tasks with an hourglass icon (instead of an appropriate success/failure status).

Are you using your Credential both to authenticate against SQL server and accessing the file? Or just for file access?

---

Within SSIS packages we generally will make all SQL connections as trusted connections, so whatever credentials used for running the SSIS job are passed through for the SQL connection (and for any file access).

Enable Extended debugging and edit the Credential. Make sure you have CreateProcessWithLogonW selected and not CreateProcessAsUserW.

---