![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(76.8, 99%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBP%3C/text%3E%3C/svg%3E)
SQL Server Integration Services
A Microsoft platform for building enterprise-level data integration and data transformations solutions.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(227.2, 35%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ELN%3C/text%3E%3C/svg%3E)
On the upgraded SQL Server 2022 server, the SSIS package is loading and executing under a newer SSIS runtime, which can silently change behavior for scripts and external components even when the package itself was not modified.
Key points from the provided information that apply to this scenario:
- When a newer SSIS runtime (for example, SQL Server 2019 or later) loads a package created on an older version, it temporarily converts the package in memory to the newer format. If there are issues in this conversion, the package may not behave as expected, even though it reports success.
- This conversion happens when using the newer
dtexecor SQL Server Agent on the upgraded instance.
- This conversion happens when using the newer
- Script Tasks and Script Components are particularly sensitive to version and runtime changes:
- Integration Services assemblies were upgraded to .NET 4.0 and placed in a different GAC path in newer versions.
- Scripts that reference certain assemblies (for example, ADODB.dll or other external components) may not upgrade or run correctly on machines that only have the newer tools/runtime installed.
- In Azure/modern runtimes, validation explicitly warns that Script Tasks/Components may reference unsupported assemblies and can fail at runtime.
- Because Server B (not upgraded) still runs the package correctly, the package itself and its script logic are valid. The difference is the SSIS runtime and underlying assemblies on Server A after the SQL Server upgrade.
Practical steps to resolve on Server A:
- Rebuild and redeploy the package using the newer SSIS designer that targets the upgraded SQL Server version.
- Open the project in SQL Server Data Tools/Visual Studio with the SSIS extension that matches the upgraded SQL Server version.
- Open the Script Task, make a trivial change (for example, add a comment), and rebuild so that the script is recompiled against the newer Integration Services assemblies.
- Deploy the updated ISPAC/package to Server A and test again.
- Check the Script Task for any explicit references to older or unsupported assemblies:
- If the script uses ADODB.dll or other legacy COM/interop components, replace them with ADO.NET where possible, as recommended for newer SSIS versions.
- If Server A is running packages created with older tools without having the corresponding design-time/runtime components fully installed, install or repair the SSIS components for the upgraded SQL Server version so that the Script Task has all required assemblies available.
- If the package is being executed via SQL Server Agent on Server A, test the same package with
dtexecfrom the command line on Server A to see if any warnings or errors are surfaced there that are not obvious in the Agent history.
These steps align the Script Task and its dependencies with the upgraded SSIS runtime on Server A, which should restore the expected behavior of creating the Excel/PDF files while still reporting success.
References: