Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
DB Engine
SQL ServerMSDESQL Server CE
Services
Analysis (Data Mining)Analysis (OLAP)DTSIntegration ServicesNotification ServicesReporting Services
Programming
CLRConnectivitySQLXML
Other Technologies
ClusteringEnglish QueryFull-Text SearchReplicationService Broker
General
Data WarehousingPerformanceSecuritySetupSQL Server ToolsOther SQL Server Topics
DirectoryUser Groups
Related Topics
MS AccessOther DB ProductsMS Server Products.NET DevelopmentVB DevelopmentJava DevelopmentMore Topics ...

SQL Server Forum / General / Other SQL Server Topics / February 2007

Tip: Looking for answers? Try searching our database.

SQL mail work around

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
jlaustill@gmail.com - 27 Feb 2007 15:40 GMT
Hey yall,

I have a problem, I'm a DBA for about 250 databases.  I currently have
ZERO means of notification on them.  I put together an entire plan for
using SQL mail, got a pop3 account set up and all that jazz, but when
I put the request into my company to get outlook installed on my sql
servers they shut me down.  The security guys said no email on servers
period even if it's outgoing only because someone might hack it.  As
far as I know that's really the only way to shoot information about my
maintenance plans and other notifications I need.

So with out being allowed to use mail, can anyone suggest any means of
getting this information?  I looked for a central control panel or
dashboard for sql server and couldn't find anything.  It would be
really nice to have a program that could connect to all my sql servers
and just pop up an alert if something goes wrong.  What I'm down to
now is just connecting to all these servers through enterprise manager
and clicking down to the jobs and checking last run status' and
checking stuff out that way, which is REALLY time consuming.

Any suggestions would be so greatly appreciated here!!!

Joshua
Greg D. Moore (Strider) - 27 Feb 2007 16:07 GMT
> Hey yall,
>
[quoted text clipped - 4 lines]
> servers they shut me down.  The security guys said no email on servers
> period even if it's outgoing only because someone might hack it.

No, what they're saying is, "we're so incompetent, we can't secure against
this."

Sorry, but I'd be FAR more concerned about SQL injection attacks.

It's very easy to firewall off the SQL Servers, make sure they can't accept
SMTP/POP3 connections and can only SEND email.

It's pretty easy to do.

But, I wouldn't fight them.  I'd go a different route.  How much is downtime
worth your company?

If backups fail and then a server crashes and you're not notified, what
happens then?

Go to the person who controls the pursestrings.

> As
> far as I know that's really the only way to shoot information about my
> maintenance plans and other notifications I need.

Pretty much

> So with out being allowed to use mail, can anyone suggest any means of
> getting this information?  I looked for a central control panel or
> dashboard for sql server and couldn't find anything.

You can try using NET SEND, but I don't find that very useful.

You can bypass them and use something like BLAT, a command line mail program
to send stuff.

> It would be
> really nice to have a program that could connect to all my sql servers
> and just pop up an alert if something goes wrong.  What I'm down to
> now is just connecting to all these servers through enterprise manager
> and clicking down to the jobs and checking last run status' and
> checking stuff out that way, which is REALLY time consuming.

You can also forward event log events to a centralized server and monitor
that.

I've used ServersAlive for a number of things and it can be scripted to do a
bunch of stuff.

Might be able to do something like a select against the jobshistory table to
get a status and make a web page out of that.

But, I find using SQLMail so jobs can send email immediately very powerful.
I'd continue to work on that.

> Any suggestions would be so greatly appreciated here!!!
>
> Joshua

Signature

Greg Moore
SQL Server DBA Consulting
sql  (at)  greenms.com          http://www.greenms.com

AlterEgo - 27 Feb 2007 17:27 GMT
Joshua,

It sounds to me like the network Nazis just don't want to take the time to
add another security layer which should be in place anyway. I agree
wholeheartedly with Strider. Work with your boss to build a case.

1. Your security layer should already be blocking incoming and outgoing port
25 for all servers and workstations except your mail server. If not, there
is already a significant security issue. If you have local admin rights to
your workstation, set up a local SMTP server and send a few emails through
the firewall. If they make it through, then you've exposed a security hole
far greater than just email on servers.

2. Determine what the ongoing costs (your time) are to continue doing things
this way. Compare it to the one-time cost (network admin to configure the
firewall) to protect the servers. Come up with a break-even analysis, which
may be be a couple of months. Show how much money it will cost over the next
two years if the status quo is maintained.

Good luck,

-- Bill

> Hey yall,
>
[quoted text clipped - 19 lines]
>
> Joshua
jlaustill@gmail.com - 27 Feb 2007 19:11 GMT
> Joshua,
>
[quoted text clipped - 46 lines]
>
> > Joshua

After reading your responses I realize that you are right.  Downtime
in my business is in the millions per hour potentially.  I will have
to put together the analysis of time vs cost, that would certainly be
helpful.  I work for a bank, so money numbers work well.  Certainly
not the answers I was expecting/hoping for, but extremely helpful non
the less, thanks guys!!!

Joshua
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.