Kill that Target Server!
Introduction
A few weeks ago I was asked to change the maintenance plan on one of our new servers to meet the production standards. This server had recently moved into production after having been configured by a developer (usually a bad idea IMHO).
So I connected to the server and edited the maintenance plan. When I went to save it, I received the following message:
Error 14274: Cannot add, update, or delete a job (or its steps or schedules) that originated from an MSX Server
Hmmmm. This threw me for a loop and I decided to dig into why this was the case.
What I did
A few of you might wonder why this bothered me. After all, if a master server (MSX) is sending jobs to its targets (TSX servers), then it's unlikely you want to start creating exceptions.
However, if I told you that I don't use master and target servers, then you might be more interested to read on.
Indeed this is the case. I don't have a master server installed because I am always running into exceptions and prefer the ability to manage items like backup jobs from each server. I think it is easier to administratively ensure the jobs are correct.
So imagine my surprise when I saw the message.
And annoyed. So I started at TechNet. A quick search of the error number revealed three results, one of which is BUG #: 351576. As you read the article, it appears that this is a renaming problem.
Aha!
This makes sense to me. We often name replacement servers or non production servers with an "a" at the end of the name. Then when we move it into production, we rename it. The article mentions that the workaround it renaming the server, then altering or deleting the job and then renaming the server again.
Too much work.
At least for me. The article does mention that sysjobs.originating_server is place where the data is stored. Simple enough for me. Open the msdb database in Enterprise Manager, click "tables", right click the sysjobs table and select Open, return all rows.
And there is the old server name. I edit each row and change the name to the new server name and close the table. A double check and I can now edit the maintenance plans and alter the jobs.
Conclusions
Now I don't recommend editing system tables. Do that at your own risk, but this seems like a pretty simple edit to me. Be sure that you do have your db backup up, however, something I didn't mention above because we snag msdb every night and this one hadn't changed other than the backup history. Also this was a non production server.
One other thing I can recommend. Search TechNet first. It's amazing how much information you can get from there. Sometimes you get deluged, however, and our forums are quicker, but give it a shot.
As always I welcome feedback on this article using the "Your Opinion" button below. Please also
rate this article.
Steve Jones
©dkRanch.net September 2002