SSIS Script Task – The Script Task is corrupted

Having moved an SSIS package to a new server it was failing to run with the errors below.

%Script Task Name%:Error: There were errors during task validation.

%Script Task Name%:Error: The Script Task is corrupted.

%Script Task Name%:Error: There was an exception while loading Script Task from XML: System.Exception: The Script Task “ST_…” uses version 15.0 script that is not supported in this release of Integration Services. To run the package, use the Script Task to create a new VSTA script. In most cases, scripts are converted automatically to use a supported version, when you open a SQL Server Integration Services package in %SQL_PRODUCT_SHORT_NAME% Integration Services. at Microsoft.SqlServer.Dts.Tasks.ScriptTask.ScriptTask.LoadFromXML(XmlElement elemProj, IDTSInfoEvents events)

The resolution is to change the SSIS project TargetServerVersion property.  Right-click on the project an choose Properties.

ssis error 1

On the screen that loads change the TargetServerVersion value to the version of SQL Server you’re using.  Save and build your project, then re-deploy.

SSIS Error 2.png

A significant part of sql server process memory has been paged out.

Looking through the SQL Server log shortly after the server started I saw:

A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 128084, committed (KB): 423936, memory utilization: 30%.

This is on a Windows Server 2012 R2 VM with SQL Server 2008 R2, 8GB RAM and a maximum server memory configuration of 6144MB.  Lock pages in memory is enabled for the SQL Server service account.  There are many reports of this error from the Windows Server 2003 x64 and SQL Server 2005 era, but little information from more recent times. 

The message is saying that a large amount of the memory allocated to the SQL Server process, sqlservr.exe, has been moved from RAM to the page file as the process’ working set has been trimmed.  In the case of  the message above the SQL Server process has a working set of 128084KB of memory allocated in RAM and a total memory allocation which could be in RAM or on disk of 423936KB.  The memory utilisation value of 30% is showing that ~30% of the SQL Server process’ total memory allocation is in RAM, which is the working set value.  This warning message is raised when the memory allocation in RAM (working set) is 50% or below the committed memory value.

In the case of this server the working set and committed values are low compared to the maximum server memory setting and Task Manager was showing ~2.5GB of the server’s 8GB RAM in use.  Following research I found this MSDN blog article which discusses working set trim warning messages early in the SQL Server startup phase, or shortly after the server is ready for user connections.  Based on this article it appears that in my case I can ignore the warning as the message values are low compared to the server max memory setting and there is little activity on the server.



Azure Backup File – iSCSI Error

When using the file recovery feature of Azure Backup I encountered an error when trying to mount the recovery point.  I ran the exe from the Azure Portal using an elevated command prompt, but received the error “Exception caught while connecting to Target.  Please retry after some time.”


It turns out that the error is caused by the use of the elevated command prompt.  When right-clicking on the exe and choosing “Run as administrator” the error doesn’t occur.


Azure N-series VM BSOD

When creating an Azure NV6 VM with Windows 10 the VM blue screened when installing the NVIDIA GRID drivers (411.81) either through the Azure extension, or manually as per the guidance here.  The blue screen error was System Service Exception for nvlddmkm.sys.

I discovered that the issue was specific to Windows 10 1809 as when I installed the drivers on Windows 1803 the error didn’t occur.  It’s likely that 1809 will be supported in a newer driver.

SSIS Package Incompatible in SSDT and Visual Studio 2017

Having installed Visual Studio 2017 Professional with the SQL Data Tools component I tried to open a SSIS package.  This failed to load and was listed as incompatible and that the application wasn’t installed.

I ran the SQL Server Data Tools (SSDT) install and added the SQL Server Integration Services component to my existing Visual Studio installation.  Unfortunately, it was still showing as incompatible and that the application wasn’t installed.

The resolution was to right click on the project and click reload.  This reloaded the project files from disk and I was able to edit the package.

SQL Server log truncation fails with Veeam Backup & Replication

When using Veeam Backup & Replication 9.5 to backup SQL Server 2012 databases the transaction log was failing to be truncated for one database.  The database was using the full recovery model and the user account specified in Veeam’s Application Aware Processing had the required permissions and was successfully truncating the log of other databases on the same SQL instance.  The warning is displayed in Veeam as below.


Veeam logs additional information in the VeeamGuestHelper log in C:\ProgramData\Veeam\Backup\VeeamGuestHelper_DATE.log.


To resolve the error I added the following registry keys in the two locations below.  In my case the full registry path didn’t exist under Wow6432Node so I had to create it manually.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VeeaM\Veeam Backup and Replication\

HKEY_LOCAL_MACHINE\SOFTWARE\VeeaM\Veeam Backup and Replication\

Name: SqlExecTimeout
Value: 600

Name: SqlLogBackupTimeout
Value: 3600

Name: SqlConnectionTimeout
Value: 300

If you’re encountering this error it my be due to a large number of SQL Server virtual log files (VLFs).  See these blog posts for more information on the issue and how to resolve it.

A Busy/Accidental DBA’s Guide to Managing VLFs

Transaction Log VLFs – too many or too few?

SharePoint Service Pack 1 – Installation of this package failed

When installing SharePoint 2013 service pack 1 on a SharePoint farm, the extraction of the service pack kept failing on one web front end.

When clicking on the officeserversp2013-kb2880552-fullfile-x64-en-us.exe file, the User Account Control dialog appeared, then when I continued to extract the files, the process failed with “The installation of this package failed”.


Looking the service pack log file showed that some files were successfully extracted before the error.


In order to work around the error on this server I found I needed to open an administrative command prompt and then run the service pack.