October 2, 2008 at 2:29 pm
A job failed for the first time today on our SQL 2005 instance, running an SSIS package, that to my knowledge, has not been changed for about a month.
When looking at the job step properties, I found out that the location of the .config file was wrong, so I have the strong suspicion that the job/package has been tampered with.
Is there a way changes to SSIS packages can be audited somehow?
The package has been deployed in the File System.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
October 2, 2008 at 2:50 pm
If the config file path was wrong in the job step, wouldn't that indicate that the job was changed rather than the package?
Unfortunately, I don't think a modification history of jobs is kept, except for the date_modified column in msdb.dbo.sysjobs.
Greg
October 2, 2008 at 3:05 pm
Greg Charles (10/2/2008)
If the config file path was wrong in the job step, wouldn't that indicate that the job was changed rather than the package?Unfortunately, I don't think a modification history of jobs is kept, except for the date_modified column in msdb.dbo.sysjobs.
thank you, you gave me an idea.
I will look at a recent backup of the msdb database to see if that job has been changed in the last couple of days.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply