This is the slide deck for the New England SQL Server User Group and SQL Saturday Madison.

1. Do More With Less:
Inside SQL Central Management Server and Multi-Server
Administration

2. Mike Hillwig
 SQL Server DBA
 Working with SQL Server since SQL 7
 Resume includes Acme Packet Oracle, Shawmut Design and Construction,
Equitable Resources, Weirton Steel

4. Mike Hillwig
 Owned by Two Pugs
 Avid Cook
 Lover of Blue Cheese
 And Bacon
 Geek at Heart

5. Obligatory Social Networking Slide
 mikehillwig.com
 sqlserverpedia.com
 twitter.com/mikehillwig
 anysocialnetworkingsite/mikehillwig

6. Housekeeping
 Don’t let me talk too fast.
 Blog post at mikehillwig.com/go/domore
 Please send feedback to mike@mikehillwig.com

7. April 18, 2015
Microsoft, Cambridge, MA

8. Beware of the Blogs
 There is some amazing advice out
there. But…
 Anybody can put bad advice on the
internet
 Trust people you know
 Assume I’m an idiot
 I don’t trust people who say
“ALWAYS” or “NEVER”
 Test everything in your own test
environment first.

9. Before I start…
 This crowd scares the crap out of me.
 Seriously.
 You’re one of the most technical user groups I’ve ever seen.

10. With that said…
 This is a new topic for me.
 Your feedback is incredibly important
 mike@mikehillwig.com

11. Slides and Blog Post
 mikehillwig.com/go/domore

12. Tonight’s Topics
 Central Management Server
 SQL Agent Multi Server Administration

13. Central Management Server
 Catalog of Servers
 Allows you to synchronously query multiple servers

14. SQL Agent Multi Server
 Centralize your SQL Agent Jobs
 It’s a Master/Target relationship for the SQL Agent

15. LET’S DIG IN

16. About My Infrastructure
 Using a single VM named SLATE with seven instances
 You wouldn’t do that. These tools require AD authentication.
 I’m too lazy to configure a domain controller

17. Seven Instances
 Fred
 Wilma
 Barney
 Betty
 Pebbles
 BamBam
 Bedrock

18. Central Management Server
 It’s a catalog of servers
 Allows you to break your servers into categories
 There is nothing fancy about this technology
 Yet it’s a great time saver
 The tool you won’t appreciate until you really need it
 Allows you to query multiple servers synchronously at once…
without PowerShell.

19. Why would I Use this?
 Audits (Getting lists of things on multiple servers)
 Deployments
 Security functions
 Creating logins
 Disabling logins
 Anything that you need to run on multiple servers

20. Demo

21. Important Tables
 sysmanagement_shared_server_groups
 Contains the groups/folders
 sysmanagement_shared_registered_servers
 Contains the servers we’ve registered.

22. Important Procedures
 sp_sysmanagement_add_shared_server_group
 Adds a new group/folder
 sp_sysmanagement_add_shared_registered_server
 Adds a new server to a group

23. A Note on Connectivity
 The Central Management Server is just the catalog.
 The machine where you’re running SSMS makes the
connections to each server.
 If your machine can’t see a server, your connection will fail.

24. A Note on Security
 Unless you specifically configure it to use SQL authentication,
AD authentication will use YOUR login and not the server’s
service account.

25. One more thing…
 Your statements and scripts will run synchronously
 Do NOT expect your results to come back in a specific order
 The order of results appears to be the order of completion

26. Multi-Server Administration
 Incredibly cool
 Incredibly powerful
 The most unsexy technology to come out of Redmond since
Microsoft Bob
 Has a few quirks
 Does have a few serious caveats
 Caveats do have workarounds

27. Benefits
 Allows you to keep consistency with SQL Agent jobs across
multiple servers
 It’s a huge time saver when you need to change a script that
you regularly run in your environment, such as backup scripts
or index/statistics maintenance
 When a job is deployed from the master server to targets,
they are locked on the target. This enforces consistency.

28. Pitfalls
 It can be quirky
 Be careful with security
 It’s a complete culture shift
 When you push a job to target servers, it pushes all of the
properties, including the schedules.
 Be careful with IO-intensive jobs!

29. Turning That Around
 You can still deploy the job without a schedule
 Then create a job that uses msdb.dbo.sp_start_job
 This allows you to leverage the benefits of a centrally
managed server while using the schedule of a local job

30. Demo

31. Notable Tables
 sysjobs – All of the jobs you have defined, both local and
Multi-Server Jobs
 systargetservers – Shows all of your target servers
 sysjobservers – Shows what jobs are deployed to what
servers

32. Notable Procedures
 sp_help_targetserver – Run from the master, shows all of
your target servers
 Status of 5 means you have a process that is preventing you from
downloading instructions
 Shows much of the data in systargetservers

33. A Note on Connectivity
 This uses the connectivity between servers, not your
machine’s connectivity
 The pushing of SQL Agent job updates is done on a regularly
scheduled polling process

34. A Note on Security
 Be very careful with security on this
 If you do this wrong, you could set yourself up for issues
 If users can manage SQL Agent jobs on your master servers,
they can deploy jobs to your target server, even if they don’t
have access to that server
 Jobs on the target run in the context of the target server’s
service account
 If you have segregation of duty issues, be very careful who
you give access to your master server

35. Wrapping Up
 CMS and MSX are very different technologies
 Different capabilities
 Different use cases
 Combining the two gives you a great set of tools

36. One more thing…
 Neither CMS and MSX allow the main server to manage
themselves
 Put both of these tools on an independent box