This article was previously published under Q281642
This article has been archived. It is offered "as is" and will no longer be updated.
After the Windows server name been changed, when trying to update or delete the jobs previously created in a SQL Server 2000 instance, you may receive the following error message:
Error 14274: Cannot add, update, or delete a job (or its steps or schedules) that originated from an MSX server. The job was not saved.
This problem does not occur for Microsoft SQL Server 7.0; however, you might receive this error message when you upgrade a SQL Server 7.0 virtual server to a SQL Server 2000 virtual server even though you keep the same virtual server name. During the upgrade process, you have to uncluster the SQL Server 7.0 virtual server. When you uncluster the virtual server, it becomes a stand-alone instance of SQL Server and it takes the node name, and you may receive the error message when you change the name.
SQL Server 7.0 does not exhibit this problem because in the msdb..sysjobs table, the field originating_server stores the value '(local)' referencing the local server. Therefore, no matter how the server name is modified, the change does not affect the local server jobs.
Because SQL Server 2000 supports multi-instances, the originating_server field contains the instance name in the format 'server\instance'. Even for the default instance of the server, the actual server name is used instead of '(local)'. Therefore, after the Windows server is renamed, these jobs still reference the original server name and may not be updated or deleted by the process from the new server name.
After an upgrade from SQL Server 7.0 to SQL Server 2000, the originating_server column is also updated for all existing jobs and the value '(local)' is no longer used.
The best way to handle this problem after the rename process is to follow these steps:
Rename the server back to the original name.
Script out all of the jobs and then delete them.
Rename the server to the new name.
Add back the jobs by running the script generated from step 2.
For additional information, see the "Multiserver Administration" article in SQL Server Books Online.
Microsoft has confirmed this to be a problem in SQL Server 2000.