Ola.hallengren.com is my go-to solution for MX.
+1 for Ola's solution
FWIW - that solution doesn't even make my top 3. Minion is superior to that solution. My top recommendation would always be to create your own to match your environment. So many more advantages that way. If you don't have time or knowledge and need something quickly, definitely go with Minion.
To each their own. I cannot recommend Minion as a generic solution due to it requiring people to rely on a feature in the database engine that is disabled by default as well as a language runtime that sits outside the database engine. Both of these points present a barrier for adoption to many who are conscious of minimizing admin overhead and attackable surface area on their servers.
I'm not sure I understand what you're saying. You're saying you don't use DBMail, or the SQL Agent, or the Browser? Cause they're all disabled by default too. No wait, Agent is just manual. So I suppose you leave it set at manual because it's too much of a mgmt pain to switch to automatic? As for PS being disabled by default. PS is NOT disabled, only the running of scripts is. And I don't know any shops anymore that don't make turning on PS scripting a standard. It's not any kind of security risk to turn it on. And as for cmdshell being a security risk. Man, I'm getting tired of hearing that. Here's a blog I wrote that proves that having cmdshell on isn't any more dangerous than anything else. And it speaks about it specifically in the case of Ola vs. Minion.
http://www.midnightdba.com/DBARant/security-theater/
I cannot quite connect your response to my original comment so let me clarify.
- DBMail is not a "language runtime" outside the database engine, nor is SQL Agent, nor Browser, so the comparison you're trying to draw with PowerShell is inaccurate.
- I never said PowerShell was disabled by default nor did I say it was a security risk. I said it was a "language runtime" outside the engine.
- I also never explicitly stated xp_cmdshell was a security risk, although I believe it is, because I do not want to get into that. I think there are plenty of materials on the web that draw attention to the fact that great care should be taken when employing xp_cmdshell. For example, this article and the ensuing comments. Let's not rehash it here in terms of Minion, Sean. People can find the material and draw their own conclusions. Vendors that require xp_cmdshell often don't provide, in my opinion, comprehensive information qualifying the security risks associated with employing xp_cmdshell but I cannot control that. All I can do is highlight the situation so people can make informed decisions.
No those items aren't language runtimes. I was giving an example of other things that are off by default, that you still use, so giving that as a reason for not using PS isn't valid.
Sean, please re-read my post. I never said PowerShell being off was a reason to avoid using it.
And I don't honestly believe that most people have the ability to read something and make up their own mind intelligently.
Thanks for sharing. I appreciate you letting us know how you feel about most people.
These are complicated topics and most people don't put enough effort into it to really know what's important.
I tend to agree but that's no reason to withhold important information and stop trying to guide people towards seeing why those things are important. I try to do something every day in that capacity.
I am concerned though that you're still out there preaching against cmdshell even after the long thread in the article you linked to... again, another article by me. And I remember how impossible it was to get an answer out of you and we never did. So I'm asking you again. Get away from what you feel and tell me how cmdshell is a security risk. I don't want to hear about how far behind in the times it is, or how dumb people are for including it in their solutions. I just want a solid case of how it's a security risk, of how it lessens the security of your server. Without you giving me even on example, you have no argument. That's why I called that article 'Security Theater', because disabling cmdshell is just that, it's theater. It has no basis in reality.
Sean, I have explained my thinking numerous times. I would refer you back to the comment thread in the article I linked to. There are lengthy threads here on SSC as well between Jeff and I on this same topic. It's all there and I firmly believe you can extrapolate the security risks from the behavior of the tool and the situations where it can be used, implemented or exploited.
You've never given me anything. Whenever I ask for specifics you give me answers like that... like how it's obvious if I just think about it. We've asked you again and again for a specific example and you fail to give one. It's always with the feelings, and the condescending tone that the rest of us aren't keeping up with you. Like I've said many times, and like Jason said, give us a specific example, or you don't have an argument. We've spent this much time asking for one without getting it because you don't have one. You know we're right but you refuse to admit it.
So let's say that we're beginners. Stop telling us that it's obvious, and tell us in plain english how cmdshell poses a security risk. There are bound to be beginners reading this; take this opportunity to teach them the right way. Don't speak in generalities, give a single example.
Condescending...hmm. That's rich coming from you, Sean, especially after the little gem you dropped earlier regarding "most people."
I'll re-raise one that we have talked in the past. Think about losing track of the caller, i.e. losing look-through auditability, as one place where xp_cmdshell presents a security risk. It allows the caller to obfuscate their identity. That brings another one to mind which is permission elevation. Callers of xp_cmdshell are potentially having their permissions elevated on the network due to the callout happening in the context of the SQL Server service account. Honestly, it's all in the comments of the xp_cmdshell is evil article as well as on this site in many more posts, and on many other sites from people other than myself. I suspect that will not be enough for you now since it has not been enough for you thus far. If I can help refine this further, please let me know.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato