I was introduced to multi-server administration in my first real SQL
admin job, but it’s been a hard sell in subsequent environments. Thanks
for the recommendation of using a local job to run a master job.
Scheduling has sometimes been a headache.

I look forward to your book on multi-server administration! It’s been a well-kept secret for far too long.

Yep. We had to stagger our backup job times as a result of IO pressure as well. I used OpsMgr to keep my job code in synch, too.

If you have an error in a script, it will get deployed to every server. In that, you’re absolutely correct.

The other challenge of the MSX/TSX relationship is that setting a schedule for an IO intensive job can bring your SAN to its knees. For some jobs, we deploy them without a schedule so we get the benefit of keeping the job code consistent, and then we deploy a local job that calls the master job. This gives us the flexibility to schedule that job when we want.

When you manage hundreds of instances, MultiServer Administration can be a huge help by making sure that every server has the same version of your backup script, index maintenance script, etc. If I ever write a book, it will be around this.

Thanks Mike! That’s not how I remember it working. What version of SQL are you using now? I’m wondering if things may have changed.

Part of my “single point of failure” comment was that I was thinking about how an error in one place can end up being deployed in many places, but that’s no different than what we already do daily, right?

I’m going to edit that paragraph from this post for now, and probably use it for a follow up post.

Thanks again! BTW, my daughter is watching me write this and says “hello”.