hardware, registry changes. Also be nice if I could tell when someone
loads new software or unistalls old, by I guess I would see that in
registry changes? I would settle for any of the above...the situation
is we have some network engineers who tend to fart around a little to
much on our production MS-SQL servers and I need to know when they
make a change because they wont own up to it when things go wrong.
Can someone help? I realize this would likely be a wmi/wsh/vbs
scripting solution, but I also posting this here becasue I figure at
least one shop out there has the same issue I am having with loose
cannon admin types."sumGirl" <emebohw@.netscape.net> wrote in message
news:a5e13cff.0409010507.104fbdf3@.posting.google.c om...
> Hi all. I am looking for a script that I might use to spot OS,
> hardware, registry changes. Also be nice if I could tell when someone
> loads new software or unistalls old, by I guess I would see that in
> registry changes? I would settle for any of the above...the situation
> is we have some network engineers who tend to fart around a little to
> much on our production MS-SQL servers and I need to know when they
> make a change because they wont own up to it when things go wrong.
> Can someone help? I realize this would likely be a wmi/wsh/vbs
> scripting solution, but I also posting this here becasue I figure at
> least one shop out there has the same issue I am having with loose
> cannon admin types.
I don't have any script for this, but I would suggest that trying to solve
an issue like this via technical means is probably not the best approach.
It's always a good idea to enable OS-level auditing so you have a record of
who accessed the servers and when, but ultimately you cannot stop people
doing things they shouldn't, except by getting your management to make it
clear that unauthorized system changes are unacceptable. I'm assuming of
course that the network guys have valid reasons for being able to access the
MSSQL boxes, so you can't just revoke their permissions.
I suspect the real issue is that you have no change/configuration management
process in place - while this isn't always exciting stuff, it is very
useful. You might want to have a look at the MSSQL Operations Guide to get
some ideas:
http://www.microsoft.com/technet/pr...in/sqlops0.mspx
In the short term, I would suggest documenting one or two incidents in
detail, showing that a) a change was made which caused a real issue, and b)
the change could only have been made by a small number of individuals, none
of whom will admit to making it. Depending on what was changed, it may well
be audited in the system event logs anyway.
If you can show that uncontrolled changes are affecting your company's
business by diverting resources into unnecessary work, or by making
applications unavailable to end users, management will probably take the
issue seriously.
Simon
No comments:
Post a Comment