Big Scripts

While working on a MOM 2005 system all the servers running DFS went red. This organisation had set these up but had then disabled them all temporarily for security reasons and have not re-enabled them.

Looking at the cause there is one big script that runs every 15 minutes. This is the “DFS root, link, and target availability health check” script. There is no comments in the script to help. As I am not a script specialist it is hard to work out what to do to remove the bits that cause the alerts that are not needed while still providing monitoring of the other bits. In the end, due to time constraints, I disabled the whole script from running and the organisation will switch it back on when they enable their DFS shares.

There are other big scripts that I have come across in the past that are similar. So why do the product groups feel the need to write these huge multi function scripts? Because they are clever? They want to show off? Or they feel they can reuse code better?

I would prefer to have those scripts broken down into smaller bits that do just one thing. That way it would be easier to just switch that bit off. Tuning is a crucial part of a MOM or SCOM installation. Operators will get blase if the console is full of false alerts and the tool will fall into disuse. This end game needs to be in mind when the product groups are creating their MPs. And with the difficulty of applying overrides in some areas of SCOM 2007 it does not look like that message has got through. If they need help they just have to hire me.  🙂

Advertisements

Comments are closed.

%d bloggers like this: