The exact symptoms you will experience depend on how the time windows in your jobs are configured - I am however slightly surprised that you did not experience it in 12.0 as a related issue has been present since at least 9.x. Althouh not reproduced by Symantec (me in fact) until more recently.

The issue is caused because Backup Exec schedules the job start time for the next running of the job is set at the end of the previous job (without any DST offset), but by the time the job starts the window for the job now has the DST offset applied which causes the next start time to be outside of the window - hence the error. Although this explanation makes the issue sound very simple, apparently a permanent solution would be very complex hence it has not yet been resolved on a permanent basis.

It should be noted that it should not happen if your backup Window is set to 24hours (the default) and is (usually) easily resolved by a service restart and allowing the job to run as normal.

The continued existence of this issue is an example of laziness and R&D margining on Symantec's part. Someone has decided that the repair/redesign effort to make this work right isn't worth the time or profit margin loss that would have to be absorbed to fix it for existing customers and keep it fixed.

We all as VAR's or end users then have to eat crow when our customers want to know why this expensive and complicatedly designed product can't get this one thing right permanently so that twice a year we don't have to make these service/job schedule restart adjustments.

Just plain stupid.

They could simply get rid of the 'Job Window' time selection for a 'Job Start' time selection and then deal with multiple job runs via queuing or something such as this.

If there were hotfixes for this issue for v11 and v11d then why are we still dealing with this problem in v12.5.  Or maybe those hotfixes did not fix the problem.  

Running backups during prime time is never very popular.  Skipping a day when a backup fails is not an option here.  I used to do that until we lost a SCSI backplane within a day of a failed backup on a raid 5 array which put us back 2 days instead of one day.

 Regardless the problem should not be still with us.  

I don't mean to revive an older thread, but did not want to start another for the same issue.

We have encountered the issue as well, but I could not help but wonder:  If the backup window had been longer than an hour (not necessarily the 24hr default, but simply more than an hour, would the issue have been avoided?

Even with the one hour offset, the adjusted start time would then still fall within the acceptable period.

Any window that is less than 23 hours will cause the problem (assuming your DST only changes by 1 hour)

Also in answer to the comment posted by someone about if it was fixed in 11x why is it not fixed now - it was NOT fixed in 11x

I don't know if the problem was fixed in 11x or not.  I do know that I didn't have this problem with 11x but I have it with both 12 and 12.5 and I assume I'll have it again with 2010.