"Best Practices" aren't always the best answer
Best practices are recipes designed to achieve a goal in a specific way. It's possible there may be other ways to achieve that same goal that are better for your environment.
"What is Microsoft's 'best practice'?"
I've heard this question so, so many times. As a Premier Field Engineer for Microsoft, with the logo above my head talking to a customer, this was always the question. I'd tell them the answer, and then try to provide context for that answer and how it might or might not apply to them.
That's right… I said, "might not apply".
"But best practices should always be followed! That's why they're called 'Best Practices'. They're the best way to do things. Microsoft says so!"
Of course, the real answer is the infamous (and generally true) "It depends".
Best practices are real. They're accurate. They're great. They work. They are well developed recommendations created through years of experience by brilliant minds who know Microsoft products inside and out. They're available (if not always fully understandable) easily, and they cover almost every Microsoft product.
There's one catch: You have to follow all of them. To the letter. Across all products you use. Without exception. Every single button must be clicked, every single entry must be right. Every single thing has to be exactly as written in the best practice.
"But we can't do this one because of our environment."
This is the problem. The best practice for Microsoft may not be the best answer for you. They are written and intended to be applied in a specific context and with specific assumptions. Those assumptions, and therefore that context, may not apply to you. Your environment is different. Your scale is different. Your needs are different. Your network, your exposure, your budget, your equipment, different, different, different.
Best practices are not gospel. They're designed to solve a specific problem or need in a specific way in alignment with other best practices. If that problem doesn't apply to you (are you sure?) or if your environment is different, the best solution to that problem may be different.
What exactly is the goal of this best practice?
What secondary problems might this best practice solve?
Does or do these issues exist in my environment?
Can the recommended best practice even happen within my environment?
Would this best practice open me up to other risks that would also need to be addressed?
Do I have existing means or methods of accomplishing the goal of the best practice?
What gaps, issues, or risks are created within my environment by not following the best practice?
What are the relationships between this best practice and other products, practices, or integrations with other components in my environment?
You can think of a best practice as a recipe. It's a starting point and changing one thing implies changing another. For example, pie dough can be very particular, and the recipes can be rather precise. If the recipe calls for butter but you want to use something like shortening, you also need to know that butter is frequently ~20% water while shortening is not. In order for the recipe to work as written, you somehow have to recognize that you might need to use a little less shortening and a little more water to get the same result. However, while shortening can create a more flakey crust, butter is delicious, so how are you going to compensate for that, or are you going to simply give that up?
A best practice, just like a recipe, is something you have to adjust for your environment and needs. If you take away something here, you need to adjust for it somewhere else in order for things to work out the way you expect. Not adjusting for the change in water can result in a dry, flavorless pie dough… not the result you were hoping for. Not adjusting for your environment, where you're going to skip an element of a best practice, will leave a gap in your infrastructure that should be recognized and dealt with.
Instead, consider asking "What is the goal of this best practice?" This is an infinitely more valuable question. It presents you with the possibility of recognizing whether and how the best practice applies to you. It also gives you the opportunity to see where you might need to fill in gaps if you don't follow the best practice as written.
For example, Microsoft best practices (and is default in today's Windows versions) indicate that the local Administrator should be/stay disabled. This is solid advice. However, I have seen applications that absolutely demand to run as the actual local Administrator (this is a terrible, horrible, unacceptable pattern, by the way), which means you now have to violate Microsoft's best practice of ensuring the Administrator account is disabled. If you have such a situation in your organization and have no alternative other than to use that application, then you have no choice but to enable the Administrator account (Note that domain controllers have special implications here and should require an exceptionally high level of scrutiny for this situation). This also means you need to consider an alternative way of a meeting the goal of the best practice you are now violating.
Best practices are not an excuse to not think.
Best practices are just the starting point that demonstrate specific ways to achieve specific goals. It's the goals that matter, not the letters, words, buttons, checkboxes, etc. It's up to you adjust the best practices to meet your needs while also achieving the goal of the best practice… if it even applies to you.