4

I am using Multi-Server Administration to execute jobs on multiple targets. This works well, but I am not able to enlist the master as a target. I receive the following error when attempting to enlist the MSX as a TSX:

Server 'XXXXX' is an MSX. Cannot enlist one MSX into another MSX. (Microsoft SQL Server, Error: 14299)

I would think that running these same jobs on the master would not require managing a local job as well as the multi-server jobs.

Any help is appreciated.

Improve this question

2 Answers 2

Reset to default
2

Based on my understanding, the master server (MSX) cannot be a target server (TSX) that receives jobs from another master server i.e You cannot list one MSX server into another MSX, you have to defect it and make sure it is not enlisted with any other master server.

Its a simple two-level hierarchy: a server is a master server, a target server, or neither. Cannot be both at the same time.

FROM BOL :

When creating a multiserver environment, consider the following:

  • Each target server reports to only one master server. You must defect a target server from one master before you can enlist it into a different one.
  • The master and target servers must be running on the Windows NT 4.0 or Windows 2000 operating system.
  • When changing the name of a target server, you must defect it before changing the name and reenlist it after the change.
  • If you want to dismantle a multiserver configuration, you must defect all the target servers from the master server.

You may also want to read up : SQL Server Multiserver Administration: Master and Target Servers

Improve this answer
2

We just finished setting up a MSX/TSX environment.

You cannot target your MSX. The MSX will technically have 2 copies of a job. One under "Local" in the Agent, and one under "Multi"

Easiest way to manage it is to set the multiserver job to target the local, right click and select 

Script... | Create to

Once you have it scripted, modify the job back to target the TSX servers

In the script, look for the job name and change it.

I tend to just add "(local)" to the end of the job name.

Run the script to create the second copy, and that should be good.

Bit of a hassle, but the absolute best way is to use a machine that you wont need to have the central jobs run against, like a "dba" server. Because as the MSX, its not "hosting" the jobs itself, its just replicating the jobs and the commands out to the TSX servers, then they run it locally. So the MSX doesn't really need to be a hardcore production machine.

That's my 2 cents on it

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.