Have you ever had the feeling that SQL Server was playing a trick on you? I had those moments. I was updating a database maintenance plan and ran the corresponding job associated with it. I got an error saying that the job owner did not have permissions to execute the task. So I did what I would do as part of my testing procedure- change the job owner to sa and re-ran. And so it completed successfully until I realized I need to change some parameters in the database maintenance plan. After updating the maintenance plan, I again re-ran the same job and unexpectedly, it failed throwing the same error. When I checked the job owner, it reverted back to the original login prior to me changing it to sa. This login happens to be the user account that created the database maintenance plan. The worse part is, the maintenance plan has like 20+ subplans, each creating a SQL Server job. Now, you wouldn’t want to change the job owner for each job associated with the maintenance job every time you change something, would you? Well, there’s just no way you can do it directly. But there’s always a workaround. This blog post provided a workaround for this case. You just modify the sysdtspackages90 table in the msdb database

UPDATE
msdb.dbo.sysdtspackages90
SET
OWNERSID = SUSER_SID(‘DOMAINnew_user’)
WHERE
OWNERSID = SUSER_SID(‘DOMAINold_user’)

For SQL Server 2008, this query should do the trick

UPDATE msdb.dbo.sysssispackages
SET OWNERSID = SUSER_SID(‘DOMAINnew_user’)
WHERE name = ‘MaintenancePlan’ AND OWNERSID = SUSER_SID(‘DOMAINold_user’)

There’s currently a Microsoft Connect item for this case so feel free to vote on it if you think it’s worth having a solution that just a workaround