SSIS Issue
Hello,
I am experiencing an issue when running SSIS packages via a Windmill worker.
The package runs perfectly locally on the VM using the account zvmfrtwsp01\claranet.
When I run the exact same package via a Windmill worker (started with the same account), the execution fails with the following error:
Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
This error comes from an SSIS Execute SQL Task that uses ADO (msado15.dll).
I have checked: the DLLs are properly registered, the package is launched in 32-bit mode (dtexec.exe x86), and the environment PATH is the same in both contexts (all Sybase and SQL Server DLLs are accessible).
A PowerShell test with New-Object -ComObject "ADODB.Connection" works correctly via Windmill, so the ADO COM object itself is available.
In summary:
The issue only occurs when the SSIS package is executed by a Windmill worker, while it works locally with the same account and the same dtexec.exe binary.
This strongly suggests that the Windmill worker is running in a context that does not have full access to the COM runtime (for example, a non-interactive service context).
Could you please confirm if Windmill workers run in a restricted environment for COM/DCOM, and if there is an option or configuration to grant them a full execution context (equivalent to an interactive session)?
Thank you for your help.
I am experiencing an issue when running SSIS packages via a Windmill worker.
The package runs perfectly locally on the VM using the account zvmfrtwsp01\claranet.
When I run the exact same package via a Windmill worker (started with the same account), the execution fails with the following error:
Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
This error comes from an SSIS Execute SQL Task that uses ADO (msado15.dll).
I have checked: the DLLs are properly registered, the package is launched in 32-bit mode (dtexec.exe x86), and the environment PATH is the same in both contexts (all Sybase and SQL Server DLLs are accessible).
A PowerShell test with New-Object -ComObject "ADODB.Connection" works correctly via Windmill, so the ADO COM object itself is available.
In summary:
The issue only occurs when the SSIS package is executed by a Windmill worker, while it works locally with the same account and the same dtexec.exe binary. This strongly suggests that the Windmill worker is running in a context that does not have full access to the COM runtime (for example, a non-interactive service context).Could you please confirm if Windmill workers run in a restricted environment for COM/DCOM, and if there is an option or configuration to grant them a full execution context (equivalent to an interactive session)?
Thank you for your help.
