Integration Services Evaluation Period Has Expired: Maintenance Plan Fails

The Integration Services evaluation period can expire while the Database Engine keeps running, and the maintenance plan fails. In this 2018 client case, the failed package meant scheduled backups stopped completing. Checking that SQL Server was running missed the real failure.

Read the Package Error in Job History

The job history named the 64-bit Execute Package Utility, version 12.0.5000.0. The decisive messages were these:

Code: 0xC0000033
Source: Backup
Description: Integration Services evaluation period has expired.
Could not execute package because of error 0xC0000033.
The step failed.

Earlier logs warned that ten evaluation days remained. Nobody acted on the warning before the package failed. The final command line message did not make this a package syntax problem.

This query lists failed job steps that mention the evaluation period. Run it on the instance that hosts the maintenance plan. It needs permission to read msdb. SQL Server Agent was stopped on my test instance, so my copy returned no rows.

SELECT TOP (20) j.name AS job_name, h.step_id, h.step_name,
       msdb.dbo.agent_datetime(h.run_date, h.run_time) AS run_time, h.message
FROM msdb.dbo.sysjobhistory AS h
JOIN msdb.dbo.sysjobs AS j ON j.job_id = h.job_id
WHERE h.run_status = 0 AND h.step_id > 0 AND h.message LIKE N'%evaluation period%'
ORDER BY h.run_date DESC, h.run_time DESC;

Other failures read differently. A login failure names the login. A path failure names the file. If the step output lacks code 0xC0000033 and the evaluation text, look for another cause before you plan an upgrade. Keep the full step output with your notes. The first line can hide the useful one.

Protect the Backups First

When I asked about recent backups, the client said the failing package had left them without any. The Database Engine was still available, so I took database backups directly with SQL commands. Then we fixed the installation.

In your environment, find the last successful backups before you do anything else. This query shows the last full and log backup of every database. NULL means msdb has no record of one.

SELECT d.name, MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END) AS last_full_backup,
       MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END) AS last_log_backup
FROM sys.databases AS d
LEFT JOIN msdb.dbo.backupset AS b ON b.database_name = d.name
WHERE d.database_id <> 2
GROUP BY d.name
ORDER BY last_full_backup;

If the Engine is up, take a direct backup with the approved procedure while you repair the package runtime. Then prove the file reads back. An old successful job entry proves nothing about today.

BACKUP DATABASE SalesDemo TO DISK = N'D:\SQLBackups\SalesDemo_full.bak' WITH INIT, CHECKSUM, STATS = 10;
RESTORE VERIFYONLY FROM DISK = N'D:\SQLBackups\SalesDemo_full.bak' WITH CHECKSUM;

Identify the Component That Is Expiring

The Database Engine and Integration Services are separate components. The engine query below reports only the edition and build of the connected engine. It does not report the evaluation state of an installed SSIS runtime.

SELECT SERVERPROPERTY('ProductVersion') AS EngineVersion,
       SERVERPROPERTY('Edition') AS EngineEdition,
       SERVERPROPERTY('ProductLevel') AS EngineProductLevel,
       SERVERPROPERTY('ProductUpdateLevel') AS EngineUpdateLevel;

Next, list the package runtimes on the machine that runs the job. Different versions of Integration Services can sit side by side, and the job runs one specific executable. On my PC the script found one dtexec.exe, from the SQL Server 2025 folder.

Get-ChildItem "$env:ProgramFiles\Microsoft SQL Server\*\DTS\Binn\dtexec.exe", "${env:ProgramFiles(x86)}\Microsoft SQL Server\*\DTS\Binn\dtexec.exe" -ErrorAction SilentlyContinue |
    Select-Object FullName, @{ n = 'FileVersion'; e = { $_.VersionInfo.FileVersion } }

Compare the file version with the utility version in the failed job. The original article blamed the running Engine on a missing restart. That was the observation in this case, not a rule. Engine availability tells you nothing about the license state of a separate component.

Use the Supported Edition Upgrade

The environment recovered after its edition upgrade, and the package ran again. Use installation media and a license that fit the real version and the supported target edition. Confirm that the SSIS features are part of the target edition. Take a backup of msdb first, so the job definitions are safe. Plan a maintenance window, because an edition change can need a restart.

Do not change the system clock or reset evaluation data. Do not assume a free development edition is allowed in production. Confirm the licensing with the responsible owner.

My earlier posts cover an expired SQL Server evaluation and an Evaluation to Enterprise Core upgrade warning. Their version details are historical, so check them against your installation.

Verify the Whole Job

Run the affected job after the upgrade. Check the package result and the new backup files, then test a restore. Add an alert for failed jobs and for evaluation warnings, so the gap does not return quietly. Record the upgrade date and the new runtime version next to the job. The next person then knows what changed and when.

A running Database Engine is not proof of a working backup plan, it is one component of that plan.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.