I've installed Server Configuration Monitor (SCM) a few weeks ago. I have enough licenese to run it on every Windows-based server in our environment; however I'm holding off on deploying it beyond the two dozen or so servers I have it on now because I'm struggling with what is the best method to update the baselines following our monthly patching cycle.
For example, we normally patch 2 times a month. This means that there are some changes in the SW inventory of SCM. This results in me going machine by machine to accept the changes and re-baseline the servers. Not a huge task until you stop and look at how you will do this when it's pushed to around 1000 machines. So here is my question, is there a faster way to re-baseline servers following patching cycles?
This would save me a lot of time and clicks so if anyone knows of any good practices, I am all ears.
If you're interested, you may try the new SCM RC. Based on the feedback collected, SCM now allows to redefine baselines in bulk.
Go to Server Configuration Monitor (SCM) RC and click join group.
Please let us know how do you like it.
Thanks martin.filip I just rolled out the RC on my DEV side. I'm trying to get the final approval to roll it out on the PRODUCTION side of things now. The bulk update to the baseline and the "Who Is" information is really nice in the RC!
i think in the current state of SCM you have to use PowerShell (or any else Script based solution) to help you out.
i could imagine to make it quite easy to maintain. With the SCM we can also create alerts/triggers based on violated baselines. So if we use this in combination with a condition for a specific software - lets say antivirus - we could make an alert that triggers on a baseline violation ONLY for the antivirus software. So if this software gets updated, the alert triggers and will execute a powershell script that sets the new software version for the antivirus as baseline.
Because we forward the NodeID of the affected server to the powershell script, it will be executed only against the specific servers where the software got updated. You could create this alert for every piece of software you have frequently updated and those updates are approved and you are aware of.
I will try this solution myself, but as its end of year i do not really have much time for this unfortunately. But i could post my results as soon as i get my hands on it.
That's a great idea, although this automated mass rebaseline approach comes with it's dangers. Because baseline can only be defined on the level of nodes, not profiles or individual elements, you could accidentally make baseline some configuration changes, that you really did not want, becuase they just coincided with for example software update.
If you decide to go with this approach, It would be great if you could later share, who it worked out for you.
That was the concern I shared with the UX team as well. We would have to be careful with this "mass baselining" idea because as you pointed out, we don't want to accept a change and make it part of the baseline if it shouldn't be there.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.