Thank
remove xxx's to emailYes, just select only the client tools in the setup. Make sure you follow
the license agreement, though ;-=--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Sphynx" <xxxjoseph.dempsey@.xxxmedcath.com> wrote in message
news:26CCDD79-BBEF-4F8C-A156-0C57327A6523@.microsoft.com...
> Thanks
> remove xxx's to email|||Absolutely. Just place the install CD in the drive and de-select the
options you don't want when it comes up.
If you're using the Standard Edition on an XP or 2K Pro box you'll only get
the option to install the tools anyway.
Buck
"Sphynx" <xxxjoseph.dempsey@.xxxmedcath.com> wrote in message
news:26CCDD79-BBEF-4F8C-A156-0C57327A6523@.microsoft.com...
> Thanks
> remove xxx's to email|||Thanks...
Showing posts with label installing. Show all posts
Showing posts with label installing. Show all posts
Wednesday, March 28, 2012
Wednesday, March 7, 2012
Is is it advisable for SQL installation folder to be on the same drive as Windows?
Hey Community,
What are the guidelines for installing the SQL Software? Is it bottleneck if both Windows and SQL software are installed on the same drive ( I have all the database .mdfs and and .ldfs on a seperate RAID array)?
thanks,
Saptagiri Tangudu
PNT Marketing Services
Is Installing SQL05dev and VS05pro on the same machine supported?
When SQL05dev is installed a SQL05 version of Visual Studio (SQL05-VS) is also installed (called the “SQL Server Business Intelligence Development Studio”). The SQL05-VS installs files into a “C:\Program Files\Microsoft SQL Server\90\Tools\binn\VSShell\Common7\IDE” directory (and other directories - not described here).
When the full version VS05pro is installed it installs/uses files in a “C:\Program Files\Microsoft Visual Studio 8\Common7\IDE” directory.
The number of files in these two directories is different – the directory for VS05pro has (of course) many many more files than the directory for SQL05-VS. On the surface this seems ok since the install of VS05pro should supersede the install of the SQL05-VS and when VS05 is started it utilizes the files from the VS05pro directory and picks up the functions from the SQL05-VS (like SSIS, SSAS, SSRS and such).
But what about the SQL05-VS Common7/IDE directory? In this directory are 64 files that exist in both directores (556 files are not found in the VS05pro Common7/IDE directory). Additionally, there are 10 files that have different versions (mostly having to do with SQL-CE) – newer versions are in the SQL05-VS directory.
I’m confused. Is Microsoft going to support revision changes (Service Packs and such) to both directories? I suppose so, but this introduces possible versioning problems when SQL is updated but VS is not or VS is updated but SQL is not.
I guess I do not understand the rational for not maintaining a single VS directory structure and the problems that this creates. Microsoft is utilizing VS as the IDE for SQL but to not have a really good matching installation layout with the full version of VS is wacky – to say the least. Maybe M$ considers maintaing the versions of 64 files to be unimportant for the correct functioning of VS?
Is Installing SQL05dev and VS05pro on the same machine supported?
MikeC
Installing VS 2005 (and flavor) and SQL 2005 on the same machine is supported.
SQL installs what we call the Premier Partner Edition, which is just the basic IDE with no langauges. SQL then installs its own packages on top of the IDE.
The additional files are SQL specific. The Premier Partner Edition and any VS flavor will install to one location. If you install SQL first, when installing VS, VS will "lock" you to install to a specific directory and won't allow you to install anywhere you want.
That way, you only have one version of the file, its serviced in one place, and is properly ref counted.
|||
QuanT,
You said, "Installing VS 2005 (and flavor) and SQL 2005 on the same machine is supported.”
If this is the case, then I would like to see Microsoft fix the problems with SQL05 when VS and SQL05 are installed on the same machine – *but not to the C: volume*. That is - installing full VS05 (without SQL Express) and SQL05 to a non-C: volume on a freshly formatted/installed version of Windows 2003R2.
You said “If you install SQL first, when installing VS, VS will "lock" you to install to a specific directory and won't allow you to install anywhere you want."
It does not matter which you install first, installing VS to a non-C: volume after SQL is installed to a non-C: volume broke SSIS and the copy db wizard (I did not do any checking beyond these show-stoppers…)
Installing VS first (to a non-C: volume) allows the SQL install to install more components to a non-C: volume, but the problems still arise. Installing in this order should also be supported.
Installing VS to C: and SQL to E: works, but then RS has issues...
It appears that very little SQL05 installation testing was done to anything other than a C: volume - when VS05 is also installed on the same machine - as would be the case on development boxes. On a production db server it is unlikly that I would install the full VS, but who knows, it might be necessary, and should be possible without worry that SQL05 will be broken.
MikeC
Error from create SSIS package (save to server):
===================================
No description found (Microsoft Visual Studio)
Program Location: at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package package, IDTSEvents events, String packagePath, String serverName, String serverUserName, String serverPassword) at Microsoft.DataTransformationServices.Controls.PackageLocationControl.SavePackage(Package package) at Microsoft.DataTransformationServices.Design.Controls.PackageSaveCopyForm.PackageSaveCopyForm_FormClosing(Object sender, FormClosingEventArgs e)
===================================
Error from copy db wizard:
===================================
No description found (Copy Database Wizard)
Program Location: at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package package, IDTSEvents events, String packagePath, String serverName, String
serverUserName, String serverPassword) at Microsoft.SqlServer.Management.CopyDatabaseWizard.PackageCreator.SavePackage()
===================================
Thanks for the feedback Mike.
I'm moving this to the SQL Setup alias to get comments from the SQL Team.
|||
Mike,
is your issue resolved? I would like to know what the resolution was if it has been resolved. Iam encountering the same issue now.
My setup is:
1. Installed SQL2000 (default instance)
2. Installed SQL2005 (named instance)
All on C:
I was able to save SSIS packages to the DB until recently using "Save Copy of <pkg> As".
Now I'm encountering the above error (No decription found etc..). I don't even remember anymore if I specified the <machine name> OR <machine name>\<Instance Name> for the "Server" when I had it working.
But I tried with both and I get different errors:
<machine name>\<Instance Name> : No decription found etc.
<machine name> :
======================
The ExistsOnSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement issued has failed.
(Microsoft Visual Studio)
=======================
For "Protection Level", I have tried different options, but it doesn't seem to matter.
Another thing is that I suspect this may have started happening after I was trying to install VS05 (other components) on top of the default version that was installed along with SQL05. I didn't go ahead with the VS install and canceled it half way through the initial install setup.
Any inputs are appreciated.
Thanks.
|||Sql_Rv,
I have an open support call with M$ for the last week or so about the "can't save package" problem. This problem with saving packages absolutely has something to do with installing VS05 on the same machine that has SQL05 installed. Works without VS05, fails with VS05 installed.
To fix your installation (without a complete wipe of the house-of-cards that is Windows ), I suggest installing VS05 all the way! Then run the VS05 uninstall. This is the only way to get the VS05 install/uninstall program to run and remove the all the bits of VS05 that M$ stashes all over the place - especially the registry. I would hope that an aborted VS05 install would back-out any changes, but given the somewhat buggy state of Win03r2, MMCv3, VS05 and SQL05 tools… Really, I don’t think M$ has it altogether any more, the testers likely do not have initiative to try anything slightly out of line…
Lets see - ALL third party and M$ products like ISA04 that use MMC cause the new MMC v3 to crash on WinR2 - really - what kind of testing is M$ doing? I suppose we are doing the testing for them...
It would be nice if M$ (and other M$ app mfg) would wake up and see the simplicity of installing all executables of an application in ONE directory tree, and have a minimal registry footprint. A manifest of files would be nice also - but no, we get this horrific splat of install logs that lists what files were installed - and the number of registry entries that get added by SQL05 is obscene. Really, it is too much to ask for list of files and their versions needed to maintain a SQL05 installation? Tracking revisions must be a fuzzy concept at M$...
Anyway - M$ support is slow on the testing and the wonderfully informative error message "no description found" goes a long way in pointing to the problem - not.
Question: What version of Windows are you running? Is it a domain controller? Are SQL services running with a domain account?
MikeC
|||Mike,
Thanks for taking the time to respond. I appreciate it.
This is on my dev box which is running XP Pro. No, it is not a domain controller. Yes, the services are running with a domain account that has admin privileges on this box.
btw, to get around this problem, I tried saving it from a different machine and it worked. This is what I did:
box1\2K5 - Unable to save the pkg to this DB from box1.
box2 - Has a 2K5 instance too. I used this to save it to box1\2K5 by doing a save as and specifying box1\2K5 as the SQLServer name - and it saved successfully.
Thanks,
RV
|||I have the same problem.
MS WinXP Pro sp2 (latest patches as of 9.26.2006)
SQL Server 2005
VS2005
error:TITLE: SQL Server Import and Export Wizard The operation could not be completed. ADDITIONAL INFORMATION: The ExistsOnSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement issued has failed. BUTTONS: OK
The error is generated when I try to save the SISS package to the SQL server instance mentioned above.
I was able to save the SISS package using the filesystem option.
Is Installing SQL05dev and VS05pro on the same machine supported?
When SQL05dev is installed a SQL05 version of Visual Studio (SQL05-VS) is also installed (called the “SQL Server Business Intelligence Development Studio”). The SQL05-VS installs files into a “C:\Program Files\Microsoft SQL Server\90\Tools\binn\VSShell\Common7\IDE” directory (and other directories - not described here).
When the full version VS05pro is installed it installs/uses files in a “C:\Program Files\Microsoft Visual Studio 8\Common7\IDE” directory.
The number of files in these two directories is different – the directory for VS05pro has (of course) many many more files than the directory for SQL05-VS. On the surface this seems ok since the install of VS05pro should supersede the install of the SQL05-VS and when VS05 is started it utilizes the files from the VS05pro directory and picks up the functions from the SQL05-VS (like SSIS, SSAS, SSRS and such).
But what about the SQL05-VS Common7/IDE directory? In this directory are 64 files that exist in both directores (556 files are not found in the VS05pro Common7/IDE directory). Additionally, there are 10 files that have different versions (mostly having to do with SQL-CE) – newer versions are in the SQL05-VS directory.
I’m confused. Is Microsoft going to support revision changes (Service Packs and such) to both directories? I suppose so, but this introduces possible versioning problems when SQL is updated but VS is not or VS is updated but SQL is not.
I guess I do not understand the rational for not maintaining a single VS directory structure and the problems that this creates. Microsoft is utilizing VS as the IDE for SQL but to not have a really good matching installation layout with the full version of VS is wacky – to say the least. Maybe M$ considers maintaing the versions of 64 files to be unimportant for the correct functioning of VS?
Is Installing SQL05dev and VS05pro on the same machine supported?
MikeC
Installing VS 2005 (and flavor) and SQL 2005 on the same machine is supported.
SQL installs what we call the Premier Partner Edition, which is just the basic IDE with no langauges. SQL then installs its own packages on top of the IDE.
The additional files are SQL specific. The Premier Partner Edition and any VS flavor will install to one location. If you install SQL first, when installing VS, VS will "lock" you to install to a specific directory and won't allow you to install anywhere you want.
That way, you only have one version of the file, its serviced in one place, and is properly ref counted.
|||
QuanT,
You said, "Installing VS 2005 (and flavor) and SQL 2005 on the same machine is supported.”
If this is the case, then I would like to see Microsoft fix the problems with SQL05 when VS and SQL05 are installed on the same machine – *but not to the C: volume*. That is - installing full VS05 (without SQL Express) and SQL05 to a non-C: volume on a freshly formatted/installed version of Windows 2003R2.
You said “If you install SQL first, when installing VS, VS will "lock" you to install to a specific directory and won't allow you to install anywhere you want."
It does not matter which you install first, installing VS to a non-C: volume after SQL is installed to a non-C: volume broke SSIS and the copy db wizard (I did not do any checking beyond these show-stoppers…)
Installing VS first (to a non-C: volume) allows the SQL install to install more components to a non-C: volume, but the problems still arise. Installing in this order should also be supported.
Installing VS to C: and SQL to E: works, but then RS has issues...
It appears that very little SQL05 installation testing was done to anything other than a C: volume - when VS05 is also installed on the same machine - as would be the case on development boxes. On a production db server it is unlikly that I would install the full VS, but who knows, it might be necessary, and should be possible without worry that SQL05 will be broken.
MikeC
Error from create SSIS package (save to server):
===================================
No description found (Microsoft Visual Studio)
Program Location: at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package package, IDTSEvents events, String packagePath, String serverName, String serverUserName, String serverPassword) at Microsoft.DataTransformationServices.Controls.PackageLocationControl.SavePackage(Package package) at Microsoft.DataTransformationServices.Design.Controls.PackageSaveCopyForm.PackageSaveCopyForm_FormClosing(Object sender, FormClosingEventArgs e)
===================================
Error from copy db wizard:
===================================
No description found (Copy Database Wizard)
Program Location: at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package package, IDTSEvents events, String packagePath, String serverName, String
serverUserName, String serverPassword) at Microsoft.SqlServer.Management.CopyDatabaseWizard.PackageCreator.SavePackage()
===================================
Thanks for the feedback Mike.
I'm moving this to the SQL Setup alias to get comments from the SQL Team.
|||
Mike,
is your issue resolved? I would like to know what the resolution was if it has been resolved. Iam encountering the same issue now.
My setup is:
1. Installed SQL2000 (default instance)
2. Installed SQL2005 (named instance)
All on C:
I was able to save SSIS packages to the DB until recently using "Save Copy of <pkg> As".
Now I'm encountering the above error (No decription found etc..). I don't even remember anymore if I specified the <machine name> OR <machine name>\<Instance Name> for the "Server" when I had it working.
But I tried with both and I get different errors:
<machine name>\<Instance Name> : No decription found etc.
<machine name> :
======================
The ExistsOnSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement issued has failed.
(Microsoft Visual Studio)
=======================
For "Protection Level", I have tried different options, but it doesn't seem to matter.
Another thing is that I suspect this may have started happening after I was trying to install VS05 (other components) on top of the default version that was installed along with SQL05. I didn't go ahead with the VS install and canceled it half way through the initial install setup.
Any inputs are appreciated.
Thanks.
|||Sql_Rv,
I have an open support call with M$ for the last week or so about the "can't save package" problem. This problem with saving packages absolutely has something to do with installing VS05 on the same machine that has SQL05 installed. Works without VS05, fails with VS05 installed.
To fix your installation (without a complete wipe of the house-of-cards that is Windows ), I suggest installing VS05 all the way! Then run the VS05 uninstall. This is the only way to get the VS05 install/uninstall program to run and remove the all the bits of VS05 that M$ stashes all over the place - especially the registry. I would hope that an aborted VS05 install would back-out any changes, but given the somewhat buggy state of Win03r2, MMCv3, VS05 and SQL05 tools… Really, I don’t think M$ has it altogether any more, the testers likely do not have initiative to try anything slightly out of line…
Lets see - ALL third party and M$ products like ISA04 that use MMC cause the new MMC v3 to crash on WinR2 - really - what kind of testing is M$ doing? I suppose we are doing the testing for them...
It would be nice if M$ (and other M$ app mfg) would wake up and see the simplicity of installing all executables of an application in ONE directory tree, and have a minimal registry footprint. A manifest of files would be nice also - but no, we get this horrific splat of install logs that lists what files were installed - and the number of registry entries that get added by SQL05 is obscene. Really, it is too much to ask for list of files and their versions needed to maintain a SQL05 installation? Tracking revisions must be a fuzzy concept at M$...
Anyway - M$ support is slow on the testing and the wonderfully informative error message "no description found" goes a long way in pointing to the problem - not.
Question: What version of Windows are you running? Is it a domain controller? Are SQL services running with a domain account?
MikeC
|||Mike,
Thanks for taking the time to respond. I appreciate it.
This is on my dev box which is running XP Pro. No, it is not a domain controller. Yes, the services are running with a domain account that has admin privileges on this box.
btw, to get around this problem, I tried saving it from a different machine and it worked. This is what I did:
box1\2K5 - Unable to save the pkg to this DB from box1.
box2 - Has a 2K5 instance too. I used this to save it to box1\2K5 by doing a save as and specifying box1\2K5 as the SQLServer name - and it saved successfully.
Thanks,
RV
|||I have the same problem.
MS WinXP Pro sp2 (latest patches as of 9.26.2006)
SQL Server 2005
VS2005
error:TITLE: SQL Server Import and Export Wizard The operation could not be completed. ADDITIONAL INFORMATION: The ExistsOnSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement issued has failed. BUTTONS: OK
The error is generated when I try to save the SISS package to the SQL server instance mentioned above.
I was able to save the SISS package using the filesystem option.
Is Installing SQL05dev and VS05pro on the same machine supported?
When SQL05dev is installed a SQL05 version of Visual Studio (SQL05-VS) is also installed (called the “SQL Server Business Intelligence Development Studio”). The SQL05-VS installs files into a “C:\Program Files\Microsoft SQL Server\90\Tools\binn\VSShell\Common7\IDE” directory (and other directories - not described here).
When the full version VS05pro is installed it installs/uses files in a “C:\Program Files\Microsoft Visual Studio 8\Common7\IDE” directory.
The number of files in these two directories is different – the directory for VS05pro has (of course) many many more files than the directory for SQL05-VS. On the surface this seems ok since the install of VS05pro should supersede the install of the SQL05-VS and when VS05 is started it utilizes the files from the VS05pro directory and picks up the functions from the SQL05-VS (like SSIS, SSAS, SSRS and such).
But what about the SQL05-VS Common7/IDE directory? In this directory are 64 files that exist in both directores (556 files are not found in the VS05pro Common7/IDE directory). Additionally, there are 10 files that have different versions (mostly having to do with SQL-CE) – newer versions are in the SQL05-VS directory.
I’m confused. Is Microsoft going to support revision changes (Service Packs and such) to both directories? I suppose so, but this introduces possible versioning problems when SQL is updated but VS is not or VS is updated but SQL is not.
I guess I do not understand the rational for not maintaining a single VS directory structure and the problems that this creates. Microsoft is utilizing VS as the IDE for SQL but to not have a really good matching installation layout with the full version of VS is wacky – to say the least. Maybe M$ considers maintaing the versions of 64 files to be unimportant for the correct functioning of VS?
Is Installing SQL05dev and VS05pro on the same machine supported?
MikeC
Installing VS 2005 (and flavor) and SQL 2005 on the same machine is supported.
SQL installs what we call the Premier Partner Edition, which is just the basic IDE with no langauges. SQL then installs its own packages on top of the IDE.
The additional files are SQL specific. The Premier Partner Edition and any VS flavor will install to one location. If you install SQL first, when installing VS, VS will "lock" you to install to a specific directory and won't allow you to install anywhere you want.
That way, you only have one version of the file, its serviced in one place, and is properly ref counted.
|||
QuanT,
You said, "Installing VS 2005 (and flavor) and SQL 2005 on the same machine is supported.”
If this is the case, then I would like to see Microsoft fix the problems with SQL05 when VS and SQL05 are installed on the same machine – *but not to the C: volume*. That is - installing full VS05 (without SQL Express) and SQL05 to a non-C: volume on a freshly formatted/installed version of Windows 2003R2.
You said “If you install SQL first, when installing VS, VS will "lock" you to install to a specific directory and won't allow you to install anywhere you want."
It does not matter which you install first, installing VS to a non-C: volume after SQL is installed to a non-C: volume broke SSIS and the copy db wizard (I did not do any checking beyond these show-stoppers…)
Installing VS first (to a non-C: volume) allows the SQL install to install more components to a non-C: volume, but the problems still arise. Installing in this order should also be supported.
Installing VS to C: and SQL to E: works, but then RS has issues...
It appears that very little SQL05 installation testing was done to anything other than a C: volume - when VS05 is also installed on the same machine - as would be the case on development boxes. On a production db server it is unlikly that I would install the full VS, but who knows, it might be necessary, and should be possible without worry that SQL05 will be broken.
MikeC
Error from create SSIS package (save to server):
===================================
No description found (Microsoft Visual Studio)
Program Location: at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package package, IDTSEvents events, String packagePath, String serverName, String serverUserName, String serverPassword) at Microsoft.DataTransformationServices.Controls.PackageLocationControl.SavePackage(Package package) at Microsoft.DataTransformationServices.Design.Controls.PackageSaveCopyForm.PackageSaveCopyForm_FormClosing(Object sender, FormClosingEventArgs e)
===================================
Error from copy db wizard:
===================================
No description found (Copy Database Wizard)
Program Location: at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package package, IDTSEvents events, String packagePath, String serverName, String
serverUserName, String serverPassword) at Microsoft.SqlServer.Management.CopyDatabaseWizard.PackageCreator.SavePackage()
===================================
Thanks for the feedback Mike.
I'm moving this to the SQL Setup alias to get comments from the SQL Team.
|||
Mike,
is your issue resolved? I would like to know what the resolution was if it has been resolved. Iam encountering the same issue now.
My setup is:
1. Installed SQL2000 (default instance)
2. Installed SQL2005 (named instance)
All on C:
I was able to save SSIS packages to the DB until recently using "Save Copy of <pkg> As".
Now I'm encountering the above error (No decription found etc..). I don't even remember anymore if I specified the <machine name> OR <machine name>\<Instance Name> for the "Server" when I had it working.
But I tried with both and I get different errors:
<machine name>\<Instance Name> : No decription found etc.
<machine name> :
======================
The ExistsOnSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement issued has failed.
(Microsoft Visual Studio)
=======================
For "Protection Level", I have tried different options, but it doesn't seem to matter.
Another thing is that I suspect this may have started happening after I was trying to install VS05 (other components) on top of the default version that was installed along with SQL05. I didn't go ahead with the VS install and canceled it half way through the initial install setup.
Any inputs are appreciated.
Thanks.
|||Sql_Rv,
I have an open support call with M$ for the last week or so about the "can't save package" problem. This problem with saving packages absolutely has something to do with installing VS05 on the same machine that has SQL05 installed. Works without VS05, fails with VS05 installed.
To fix your installation (without a complete wipe of the house-of-cards that is Windows ), I suggest installing VS05 all the way! Then run the VS05 uninstall. This is the only way to get the VS05 install/uninstall program to run and remove the all the bits of VS05 that M$ stashes all over the place - especially the registry. I would hope that an aborted VS05 install would back-out any changes, but given the somewhat buggy state of Win03r2, MMCv3, VS05 and SQL05 tools… Really, I don’t think M$ has it altogether any more, the testers likely do not have initiative to try anything slightly out of line…
Lets see - ALL third party and M$ products like ISA04 that use MMC cause the new MMC v3 to crash on WinR2 - really - what kind of testing is M$ doing? I suppose we are doing the testing for them...
It would be nice if M$ (and other M$ app mfg) would wake up and see the simplicity of installing all executables of an application in ONE directory tree, and have a minimal registry footprint. A manifest of files would be nice also - but no, we get this horrific splat of install logs that lists what files were installed - and the number of registry entries that get added by SQL05 is obscene. Really, it is too much to ask for list of files and their versions needed to maintain a SQL05 installation? Tracking revisions must be a fuzzy concept at M$...
Anyway - M$ support is slow on the testing and the wonderfully informative error message "no description found" goes a long way in pointing to the problem - not.
Question: What version of Windows are you running? Is it a domain controller? Are SQL services running with a domain account?
MikeC
|||Mike,
Thanks for taking the time to respond. I appreciate it.
This is on my dev box which is running XP Pro. No, it is not a domain controller. Yes, the services are running with a domain account that has admin privileges on this box.
btw, to get around this problem, I tried saving it from a different machine and it worked. This is what I did:
box1\2K5 - Unable to save the pkg to this DB from box1.
box2 - Has a 2K5 instance too. I used this to save it to box1\2K5 by doing a save as and specifying box1\2K5 as the SQLServer name - and it saved successfully.
Thanks,
RV
|||I have the same problem.
MS WinXP Pro sp2 (latest patches as of 9.26.2006)
SQL Server 2005
VS2005
error:TITLE: SQL Server Import and Export Wizard The operation could not be completed. ADDITIONAL INFORMATION: The ExistsOnSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement issued has failed. BUTTONS: OK
The error is generated when I try to save the SISS package to the SQL server instance mentioned above.
I was able to save the SISS package using the filesystem option.
Is installing MS Outlook a security risk?
I just took over a new project and trying to setup the environment up to bes
t
practicing standards. I wanted to install MS Outlook to setup MAPI. My
manager thinks installing outlook on production server is really nuts. He
thinks it's a security risk and overall having MS Outlook on a production
server doesn't seem right. I have never heard of any kind of security risk o
r
any other internal problems MS Outlook can create in a production box with
SQL Server installed on it. Can one of the MVPs please confirm it for me and
if possible give any suggestions or arguments that I can use to convince him
?
Thanks in advance for your support ...
BobBob wrote:
> I just took over a new project and trying to setup the environment up to b
est
> practicing standards. I wanted to install MS Outlook to setup MAPI. My
> manager thinks installing outlook on production server is really nuts. He
> thinks it's a security risk and overall having MS Outlook on a production
> server doesn't seem right. I have never heard of any kind of security risk
or
> any other internal problems MS Outlook can create in a production box with
> SQL Server installed on it. Can one of the MVPs please confirm it for me a
nd
> if possible give any suggestions or arguments that I can use to convince h
im?
> Thanks in advance for your support ...
> Bob
I assume this is a SQL 2000 server? I agree, Outlook has no place on a
server, but if you want to use SQL Mail, you have no choice. You do
have alternatives to SQL Mail, however. I've used a command-line mailer
called "BLAT" for years with great success. There is also an extended
stored procedure available for download called xp_smtp_sendmail, that is
nearly a drop-in replacement for xp_sendmail.
Of course, if you're on SQL 2005, this is all moot...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I don't find Outlook to be a security risk, I find it to be a stability
risk. Outlook is a lot of things, but a stable MAPI service provider isn't
on that list. I prefer to use xp_smtpmail from www.sqldev.net. It isn't a
drop-in replacement for SQLMail or SQLAgentMail, but you can make it do most
of the tasks that xp_sendmail supports. I usually add extra steps for
failure and success notification to my agent jobs, but there are several
ways to implement this code. It is a very stable add-in and has caused me
zero problems, even on large cluster installations.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Bob" <Bob@.discussions.microsoft.com> wrote in message
news:3A2B8DAB-9424-4E86-9C53-C8BD6E0B1206@.microsoft.com...
>I just took over a new project and trying to setup the environment up to
>best
> practicing standards. I wanted to install MS Outlook to setup MAPI. My
> manager thinks installing outlook on production server is really nuts. He
> thinks it's a security risk and overall having MS Outlook on a production
> server doesn't seem right. I have never heard of any kind of security risk
> or
> any other internal problems MS Outlook can create in a production box with
> SQL Server installed on it. Can one of the MVPs please confirm it for me
> and
> if possible give any suggestions or arguments that I can use to convince
> him?
> Thanks in advance for your support ...
> Bob|||Sorry, I forgot to put SQL Server version .. yes it is SQL Server 2000 (SP4)
on Windows 2003 server
That's the confusion .. MS Outlook is also a Microsoft product then why
can't we have that on the server where SQL Server resides?
"Tracy McKibben" wrote:
> Bob wrote:
> I assume this is a SQL 2000 server? I agree, Outlook has no place on a
> server, but if you want to use SQL Mail, you have no choice. You do
> have alternatives to SQL Mail, however. I've used a command-line mailer
> called "BLAT" for years with great success. There is also an extended
> stored procedure available for download called xp_smtp_sendmail, that is
> nearly a drop-in replacement for xp_sendmail.
> Of course, if you're on SQL 2005, this is all moot...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||Bob wrote:
> Sorry, I forgot to put SQL Server version .. yes it is SQL Server 2000 (SP
4)
> on Windows 2003 server
> That's the confusion .. MS Outlook is also a Microsoft product then why
> can't we have that on the server where SQL Server resides?
>
My personal reasons:
1. It's absurd to require a full blown mail client in order to send
SMTP messages from a database server. In the *nix world, there are
hundreds of tiny, dedicated SMTP components available if you need to
send an email message. Why couldn't Microsoft provide something so
simple without requiring their mail client?
2. Outlook is not a stable application, and I don't like having
unstable applications running on my servers, especially when they have
hooks into my database server.
3. Internet Explorer is also a Microsoft product, but I don't trust it,
even on a Microsoft operating system, therefore I don't use it. IE has
some serious flaws, as does Outlook. If something (virus/worm,
whatever) gets loose on my network, I don't want to have to worry about
my databases getting nailed by it.
4. There are simply better options available...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Bob wrote:
> I just took over a new project and trying to setup the environment up to b
est
> practicing standards. I wanted to install MS Outlook to setup MAPI. My
> manager thinks installing outlook on production server is really nuts. He
> thinks it's a security risk and overall having MS Outlook on a production
> server doesn't seem right. I have never heard of any kind of security risk
or
> any other internal problems MS Outlook can create in a production box with
> SQL Server installed on it. Can one of the MVPs please confirm it for me a
nd
> if possible give any suggestions or arguments that I can use to convince h
im?
> Thanks in advance for your support ...
> Bob
MAPI mail support is gone from SQL Server 2005. That's one more reason
why NOT to use it (the main reason has always been "It sucks!"). Think
xp_smtp_sendmailk, Notification Services or some other mail component.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||my confusion has come to an end after reading all these replies ... Thanks s
o
much all for your help
"David Portas" wrote:
> Bob wrote:
> MAPI mail support is gone from SQL Server 2005. That's one more reason
> why NOT to use it (the main reason has always been "It sucks!"). Think
> xp_smtp_sendmailk, Notification Services or some other mail component.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>|||"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:ekTxHeFpGHA.4424@.TK2MSFTNGP05.phx.gbl...
> Bob wrote:
best[vbcol=seagreen]
He[vbcol=seagreen]
production[vbcol=seagreen]
risk or[vbcol=seagreen]
with[vbcol=seagreen]
and[vbcol=seagreen]
him?[vbcol=seagreen]
> I assume this is a SQL 2000 server? I agree, Outlook has no place on a
> server, but if you want to use SQL Mail, you have no choice. You do
> have alternatives to SQL Mail, however. I've used a command-line mailer
> called "BLAT" for years with great success. There is also an extended
> stored procedure available for download called xp_smtp_sendmail, that is
> nearly a drop-in replacement for xp_sendmail.
Except they don't replace the best reason (in my opinion) to use outlook
which is to allow SQL Agent to send alerts, etc.
(I also have used blat btw, decent product.)
I don't think there's a problem with outlook on a SQL Server. Just make sure
it's only sending email and not receiving.
Generally I install the SMTP server that comes with IIS and have my Outlook
install send to this and have it relay to my "real" SMTP server.
This eliminates a lot of issues with Outlook locking up if it can't reach
the mail server.
I don't think the security risk is that large if you understand your goals
and what you're doing.
> Of course, if you're on SQL 2005, this is all moot...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:OH33MhFpGHA.1796@.TK2MSFTNGP03.phx.gbl...
> I don't find Outlook to be a security risk, I find it to be a stability
> risk. Outlook is a lot of things, but a stable MAPI service provider
isn't
> on that list.
Just for the record, while I tend to agree, see my other email.
The BEST thing I ever did for Outlook was to put a local SMTP server on the
SQL box and set it up to relay only from that box to my main SMTP server.
This has GREATLY increased my stability. (to the point I really don't have
to think about SQL Mail at all. It pretty much just works.)
> I prefer to use xp_smtpmail from www.sqldev.net. It isn't a
> drop-in replacement for SQLMail or SQLAgentMail, but you can make it do
most
> of the tasks that xp_sendmail supports. I usually add extra steps for
> failure and success notification to my agent jobs, but there are several
> ways to implement this code. It is a very stable add-in and has caused me
> zero problems, even on large cluster installations.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Bob" <Bob@.discussions.microsoft.com> wrote in message
> news:3A2B8DAB-9424-4E86-9C53-C8BD6E0B1206@.microsoft.com...
He[vbcol=seagreen]
production[vbcol=seagreen]
risk[vbcol=seagreen]
with[vbcol=seagreen]
>
t
practicing standards. I wanted to install MS Outlook to setup MAPI. My
manager thinks installing outlook on production server is really nuts. He
thinks it's a security risk and overall having MS Outlook on a production
server doesn't seem right. I have never heard of any kind of security risk o
r
any other internal problems MS Outlook can create in a production box with
SQL Server installed on it. Can one of the MVPs please confirm it for me and
if possible give any suggestions or arguments that I can use to convince him
?
Thanks in advance for your support ...
BobBob wrote:
> I just took over a new project and trying to setup the environment up to b
est
> practicing standards. I wanted to install MS Outlook to setup MAPI. My
> manager thinks installing outlook on production server is really nuts. He
> thinks it's a security risk and overall having MS Outlook on a production
> server doesn't seem right. I have never heard of any kind of security risk
or
> any other internal problems MS Outlook can create in a production box with
> SQL Server installed on it. Can one of the MVPs please confirm it for me a
nd
> if possible give any suggestions or arguments that I can use to convince h
im?
> Thanks in advance for your support ...
> Bob
I assume this is a SQL 2000 server? I agree, Outlook has no place on a
server, but if you want to use SQL Mail, you have no choice. You do
have alternatives to SQL Mail, however. I've used a command-line mailer
called "BLAT" for years with great success. There is also an extended
stored procedure available for download called xp_smtp_sendmail, that is
nearly a drop-in replacement for xp_sendmail.
Of course, if you're on SQL 2005, this is all moot...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I don't find Outlook to be a security risk, I find it to be a stability
risk. Outlook is a lot of things, but a stable MAPI service provider isn't
on that list. I prefer to use xp_smtpmail from www.sqldev.net. It isn't a
drop-in replacement for SQLMail or SQLAgentMail, but you can make it do most
of the tasks that xp_sendmail supports. I usually add extra steps for
failure and success notification to my agent jobs, but there are several
ways to implement this code. It is a very stable add-in and has caused me
zero problems, even on large cluster installations.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Bob" <Bob@.discussions.microsoft.com> wrote in message
news:3A2B8DAB-9424-4E86-9C53-C8BD6E0B1206@.microsoft.com...
>I just took over a new project and trying to setup the environment up to
>best
> practicing standards. I wanted to install MS Outlook to setup MAPI. My
> manager thinks installing outlook on production server is really nuts. He
> thinks it's a security risk and overall having MS Outlook on a production
> server doesn't seem right. I have never heard of any kind of security risk
> or
> any other internal problems MS Outlook can create in a production box with
> SQL Server installed on it. Can one of the MVPs please confirm it for me
> and
> if possible give any suggestions or arguments that I can use to convince
> him?
> Thanks in advance for your support ...
> Bob|||Sorry, I forgot to put SQL Server version .. yes it is SQL Server 2000 (SP4)
on Windows 2003 server
That's the confusion .. MS Outlook is also a Microsoft product then why
can't we have that on the server where SQL Server resides?
"Tracy McKibben" wrote:
> Bob wrote:
> I assume this is a SQL 2000 server? I agree, Outlook has no place on a
> server, but if you want to use SQL Mail, you have no choice. You do
> have alternatives to SQL Mail, however. I've used a command-line mailer
> called "BLAT" for years with great success. There is also an extended
> stored procedure available for download called xp_smtp_sendmail, that is
> nearly a drop-in replacement for xp_sendmail.
> Of course, if you're on SQL 2005, this is all moot...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||Bob wrote:
> Sorry, I forgot to put SQL Server version .. yes it is SQL Server 2000 (SP
4)
> on Windows 2003 server
> That's the confusion .. MS Outlook is also a Microsoft product then why
> can't we have that on the server where SQL Server resides?
>
My personal reasons:
1. It's absurd to require a full blown mail client in order to send
SMTP messages from a database server. In the *nix world, there are
hundreds of tiny, dedicated SMTP components available if you need to
send an email message. Why couldn't Microsoft provide something so
simple without requiring their mail client?
2. Outlook is not a stable application, and I don't like having
unstable applications running on my servers, especially when they have
hooks into my database server.
3. Internet Explorer is also a Microsoft product, but I don't trust it,
even on a Microsoft operating system, therefore I don't use it. IE has
some serious flaws, as does Outlook. If something (virus/worm,
whatever) gets loose on my network, I don't want to have to worry about
my databases getting nailed by it.
4. There are simply better options available...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Bob wrote:
> I just took over a new project and trying to setup the environment up to b
est
> practicing standards. I wanted to install MS Outlook to setup MAPI. My
> manager thinks installing outlook on production server is really nuts. He
> thinks it's a security risk and overall having MS Outlook on a production
> server doesn't seem right. I have never heard of any kind of security risk
or
> any other internal problems MS Outlook can create in a production box with
> SQL Server installed on it. Can one of the MVPs please confirm it for me a
nd
> if possible give any suggestions or arguments that I can use to convince h
im?
> Thanks in advance for your support ...
> Bob
MAPI mail support is gone from SQL Server 2005. That's one more reason
why NOT to use it (the main reason has always been "It sucks!"). Think
xp_smtp_sendmailk, Notification Services or some other mail component.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||my confusion has come to an end after reading all these replies ... Thanks s
o
much all for your help
"David Portas" wrote:
> Bob wrote:
> MAPI mail support is gone from SQL Server 2005. That's one more reason
> why NOT to use it (the main reason has always been "It sucks!"). Think
> xp_smtp_sendmailk, Notification Services or some other mail component.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>|||"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:ekTxHeFpGHA.4424@.TK2MSFTNGP05.phx.gbl...
> Bob wrote:
best[vbcol=seagreen]
He[vbcol=seagreen]
production[vbcol=seagreen]
risk or[vbcol=seagreen]
with[vbcol=seagreen]
and[vbcol=seagreen]
him?[vbcol=seagreen]
> I assume this is a SQL 2000 server? I agree, Outlook has no place on a
> server, but if you want to use SQL Mail, you have no choice. You do
> have alternatives to SQL Mail, however. I've used a command-line mailer
> called "BLAT" for years with great success. There is also an extended
> stored procedure available for download called xp_smtp_sendmail, that is
> nearly a drop-in replacement for xp_sendmail.
Except they don't replace the best reason (in my opinion) to use outlook
which is to allow SQL Agent to send alerts, etc.
(I also have used blat btw, decent product.)
I don't think there's a problem with outlook on a SQL Server. Just make sure
it's only sending email and not receiving.
Generally I install the SMTP server that comes with IIS and have my Outlook
install send to this and have it relay to my "real" SMTP server.
This eliminates a lot of issues with Outlook locking up if it can't reach
the mail server.
I don't think the security risk is that large if you understand your goals
and what you're doing.
> Of course, if you're on SQL 2005, this is all moot...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:OH33MhFpGHA.1796@.TK2MSFTNGP03.phx.gbl...
> I don't find Outlook to be a security risk, I find it to be a stability
> risk. Outlook is a lot of things, but a stable MAPI service provider
isn't
> on that list.
Just for the record, while I tend to agree, see my other email.
The BEST thing I ever did for Outlook was to put a local SMTP server on the
SQL box and set it up to relay only from that box to my main SMTP server.
This has GREATLY increased my stability. (to the point I really don't have
to think about SQL Mail at all. It pretty much just works.)
> I prefer to use xp_smtpmail from www.sqldev.net. It isn't a
> drop-in replacement for SQLMail or SQLAgentMail, but you can make it do
most
> of the tasks that xp_sendmail supports. I usually add extra steps for
> failure and success notification to my agent jobs, but there are several
> ways to implement this code. It is a very stable add-in and has caused me
> zero problems, even on large cluster installations.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Bob" <Bob@.discussions.microsoft.com> wrote in message
> news:3A2B8DAB-9424-4E86-9C53-C8BD6E0B1206@.microsoft.com...
He[vbcol=seagreen]
production[vbcol=seagreen]
risk[vbcol=seagreen]
with[vbcol=seagreen]
>
Friday, February 24, 2012
Is installing MS Outlook a security risk?
I just took over a new project and trying to setup the environment up to best
practicing standards. I wanted to install MS Outlook to setup MAPI. My
manager thinks installing outlook on production server is really nuts. He
thinks it's a security risk and overall having MS Outlook on a production
server doesn't seem right. I have never heard of any kind of security risk or
any other internal problems MS Outlook can create in a production box with
SQL Server installed on it. Can one of the MVPs please confirm it for me and
if possible give any suggestions or arguments that I can use to convince him?
Thanks in advance for your support ...
BobBob wrote:
> I just took over a new project and trying to setup the environment up to best
> practicing standards. I wanted to install MS Outlook to setup MAPI. My
> manager thinks installing outlook on production server is really nuts. He
> thinks it's a security risk and overall having MS Outlook on a production
> server doesn't seem right. I have never heard of any kind of security risk or
> any other internal problems MS Outlook can create in a production box with
> SQL Server installed on it. Can one of the MVPs please confirm it for me and
> if possible give any suggestions or arguments that I can use to convince him?
> Thanks in advance for your support ...
> Bob
I assume this is a SQL 2000 server? I agree, Outlook has no place on a
server, but if you want to use SQL Mail, you have no choice. You do
have alternatives to SQL Mail, however. I've used a command-line mailer
called "BLAT" for years with great success. There is also an extended
stored procedure available for download called xp_smtp_sendmail, that is
nearly a drop-in replacement for xp_sendmail.
Of course, if you're on SQL 2005, this is all moot...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I don't find Outlook to be a security risk, I find it to be a stability
risk. Outlook is a lot of things, but a stable MAPI service provider isn't
on that list. I prefer to use xp_smtpmail from www.sqldev.net. It isn't a
drop-in replacement for SQLMail or SQLAgentMail, but you can make it do most
of the tasks that xp_sendmail supports. I usually add extra steps for
failure and success notification to my agent jobs, but there are several
ways to implement this code. It is a very stable add-in and has caused me
zero problems, even on large cluster installations.
--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Bob" <Bob@.discussions.microsoft.com> wrote in message
news:3A2B8DAB-9424-4E86-9C53-C8BD6E0B1206@.microsoft.com...
>I just took over a new project and trying to setup the environment up to
>best
> practicing standards. I wanted to install MS Outlook to setup MAPI. My
> manager thinks installing outlook on production server is really nuts. He
> thinks it's a security risk and overall having MS Outlook on a production
> server doesn't seem right. I have never heard of any kind of security risk
> or
> any other internal problems MS Outlook can create in a production box with
> SQL Server installed on it. Can one of the MVPs please confirm it for me
> and
> if possible give any suggestions or arguments that I can use to convince
> him?
> Thanks in advance for your support ...
> Bob|||Sorry, I forgot to put SQL Server version .. yes it is SQL Server 2000 (SP4)
on Windows 2003 server
That's the confusion .. MS Outlook is also a Microsoft product then why
can't we have that on the server where SQL Server resides?
"Tracy McKibben" wrote:
> Bob wrote:
> > I just took over a new project and trying to setup the environment up to best
> > practicing standards. I wanted to install MS Outlook to setup MAPI. My
> > manager thinks installing outlook on production server is really nuts. He
> > thinks it's a security risk and overall having MS Outlook on a production
> > server doesn't seem right. I have never heard of any kind of security risk or
> > any other internal problems MS Outlook can create in a production box with
> > SQL Server installed on it. Can one of the MVPs please confirm it for me and
> > if possible give any suggestions or arguments that I can use to convince him?
> > Thanks in advance for your support ...
> >
> > Bob
> I assume this is a SQL 2000 server? I agree, Outlook has no place on a
> server, but if you want to use SQL Mail, you have no choice. You do
> have alternatives to SQL Mail, however. I've used a command-line mailer
> called "BLAT" for years with great success. There is also an extended
> stored procedure available for download called xp_smtp_sendmail, that is
> nearly a drop-in replacement for xp_sendmail.
> Of course, if you're on SQL 2005, this is all moot...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||Bob wrote:
> Sorry, I forgot to put SQL Server version .. yes it is SQL Server 2000 (SP4)
> on Windows 2003 server
> That's the confusion .. MS Outlook is also a Microsoft product then why
> can't we have that on the server where SQL Server resides?
>
My personal reasons:
1. It's absurd to require a full blown mail client in order to send
SMTP messages from a database server. In the *nix world, there are
hundreds of tiny, dedicated SMTP components available if you need to
send an email message. Why couldn't Microsoft provide something so
simple without requiring their mail client?
2. Outlook is not a stable application, and I don't like having
unstable applications running on my servers, especially when they have
hooks into my database server.
3. Internet Explorer is also a Microsoft product, but I don't trust it,
even on a Microsoft operating system, therefore I don't use it. IE has
some serious flaws, as does Outlook. If something (virus/worm,
whatever) gets loose on my network, I don't want to have to worry about
my databases getting nailed by it.
4. There are simply better options available...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Bob wrote:
> I just took over a new project and trying to setup the environment up to best
> practicing standards. I wanted to install MS Outlook to setup MAPI. My
> manager thinks installing outlook on production server is really nuts. He
> thinks it's a security risk and overall having MS Outlook on a production
> server doesn't seem right. I have never heard of any kind of security risk or
> any other internal problems MS Outlook can create in a production box with
> SQL Server installed on it. Can one of the MVPs please confirm it for me and
> if possible give any suggestions or arguments that I can use to convince him?
> Thanks in advance for your support ...
> Bob
MAPI mail support is gone from SQL Server 2005. That's one more reason
why NOT to use it (the main reason has always been "It sucks!"). Think
xp_smtp_sendmailk, Notification Services or some other mail component.
--
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||my confusion has come to an end after reading all these replies ... Thanks so
much all for your help
"David Portas" wrote:
> Bob wrote:
> > I just took over a new project and trying to setup the environment up to best
> > practicing standards. I wanted to install MS Outlook to setup MAPI. My
> > manager thinks installing outlook on production server is really nuts. He
> > thinks it's a security risk and overall having MS Outlook on a production
> > server doesn't seem right. I have never heard of any kind of security risk or
> > any other internal problems MS Outlook can create in a production box with
> > SQL Server installed on it. Can one of the MVPs please confirm it for me and
> > if possible give any suggestions or arguments that I can use to convince him?
> > Thanks in advance for your support ...
> >
> > Bob
> MAPI mail support is gone from SQL Server 2005. That's one more reason
> why NOT to use it (the main reason has always been "It sucks!"). Think
> xp_smtp_sendmailk, Notification Services or some other mail component.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>|||"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:ekTxHeFpGHA.4424@.TK2MSFTNGP05.phx.gbl...
> Bob wrote:
> > I just took over a new project and trying to setup the environment up to
best
> > practicing standards. I wanted to install MS Outlook to setup MAPI. My
> > manager thinks installing outlook on production server is really nuts.
He
> > thinks it's a security risk and overall having MS Outlook on a
production
> > server doesn't seem right. I have never heard of any kind of security
risk or
> > any other internal problems MS Outlook can create in a production box
with
> > SQL Server installed on it. Can one of the MVPs please confirm it for me
and
> > if possible give any suggestions or arguments that I can use to convince
him?
> > Thanks in advance for your support ...
> >
> > Bob
> I assume this is a SQL 2000 server? I agree, Outlook has no place on a
> server, but if you want to use SQL Mail, you have no choice. You do
> have alternatives to SQL Mail, however. I've used a command-line mailer
> called "BLAT" for years with great success. There is also an extended
> stored procedure available for download called xp_smtp_sendmail, that is
> nearly a drop-in replacement for xp_sendmail.
Except they don't replace the best reason (in my opinion) to use outlook
which is to allow SQL Agent to send alerts, etc.
(I also have used blat btw, decent product.)
I don't think there's a problem with outlook on a SQL Server. Just make sure
it's only sending email and not receiving.
Generally I install the SMTP server that comes with IIS and have my Outlook
install send to this and have it relay to my "real" SMTP server.
This eliminates a lot of issues with Outlook locking up if it can't reach
the mail server.
I don't think the security risk is that large if you understand your goals
and what you're doing.
> Of course, if you're on SQL 2005, this is all moot...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:OH33MhFpGHA.1796@.TK2MSFTNGP03.phx.gbl...
> I don't find Outlook to be a security risk, I find it to be a stability
> risk. Outlook is a lot of things, but a stable MAPI service provider
isn't
> on that list.
Just for the record, while I tend to agree, see my other email.
The BEST thing I ever did for Outlook was to put a local SMTP server on the
SQL box and set it up to relay only from that box to my main SMTP server.
This has GREATLY increased my stability. (to the point I really don't have
to think about SQL Mail at all. It pretty much just works.)
> I prefer to use xp_smtpmail from www.sqldev.net. It isn't a
> drop-in replacement for SQLMail or SQLAgentMail, but you can make it do
most
> of the tasks that xp_sendmail supports. I usually add extra steps for
> failure and success notification to my agent jobs, but there are several
> ways to implement this code. It is a very stable add-in and has caused me
> zero problems, even on large cluster installations.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Bob" <Bob@.discussions.microsoft.com> wrote in message
> news:3A2B8DAB-9424-4E86-9C53-C8BD6E0B1206@.microsoft.com...
> >I just took over a new project and trying to setup the environment up to
> >best
> > practicing standards. I wanted to install MS Outlook to setup MAPI. My
> > manager thinks installing outlook on production server is really nuts.
He
> > thinks it's a security risk and overall having MS Outlook on a
production
> > server doesn't seem right. I have never heard of any kind of security
risk
> > or
> > any other internal problems MS Outlook can create in a production box
with
> > SQL Server installed on it. Can one of the MVPs please confirm it for me
> > and
> > if possible give any suggestions or arguments that I can use to convince
> > him?
> > Thanks in advance for your support ...
> >
> > Bob
>
practicing standards. I wanted to install MS Outlook to setup MAPI. My
manager thinks installing outlook on production server is really nuts. He
thinks it's a security risk and overall having MS Outlook on a production
server doesn't seem right. I have never heard of any kind of security risk or
any other internal problems MS Outlook can create in a production box with
SQL Server installed on it. Can one of the MVPs please confirm it for me and
if possible give any suggestions or arguments that I can use to convince him?
Thanks in advance for your support ...
BobBob wrote:
> I just took over a new project and trying to setup the environment up to best
> practicing standards. I wanted to install MS Outlook to setup MAPI. My
> manager thinks installing outlook on production server is really nuts. He
> thinks it's a security risk and overall having MS Outlook on a production
> server doesn't seem right. I have never heard of any kind of security risk or
> any other internal problems MS Outlook can create in a production box with
> SQL Server installed on it. Can one of the MVPs please confirm it for me and
> if possible give any suggestions or arguments that I can use to convince him?
> Thanks in advance for your support ...
> Bob
I assume this is a SQL 2000 server? I agree, Outlook has no place on a
server, but if you want to use SQL Mail, you have no choice. You do
have alternatives to SQL Mail, however. I've used a command-line mailer
called "BLAT" for years with great success. There is also an extended
stored procedure available for download called xp_smtp_sendmail, that is
nearly a drop-in replacement for xp_sendmail.
Of course, if you're on SQL 2005, this is all moot...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I don't find Outlook to be a security risk, I find it to be a stability
risk. Outlook is a lot of things, but a stable MAPI service provider isn't
on that list. I prefer to use xp_smtpmail from www.sqldev.net. It isn't a
drop-in replacement for SQLMail or SQLAgentMail, but you can make it do most
of the tasks that xp_sendmail supports. I usually add extra steps for
failure and success notification to my agent jobs, but there are several
ways to implement this code. It is a very stable add-in and has caused me
zero problems, even on large cluster installations.
--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Bob" <Bob@.discussions.microsoft.com> wrote in message
news:3A2B8DAB-9424-4E86-9C53-C8BD6E0B1206@.microsoft.com...
>I just took over a new project and trying to setup the environment up to
>best
> practicing standards. I wanted to install MS Outlook to setup MAPI. My
> manager thinks installing outlook on production server is really nuts. He
> thinks it's a security risk and overall having MS Outlook on a production
> server doesn't seem right. I have never heard of any kind of security risk
> or
> any other internal problems MS Outlook can create in a production box with
> SQL Server installed on it. Can one of the MVPs please confirm it for me
> and
> if possible give any suggestions or arguments that I can use to convince
> him?
> Thanks in advance for your support ...
> Bob|||Sorry, I forgot to put SQL Server version .. yes it is SQL Server 2000 (SP4)
on Windows 2003 server
That's the confusion .. MS Outlook is also a Microsoft product then why
can't we have that on the server where SQL Server resides?
"Tracy McKibben" wrote:
> Bob wrote:
> > I just took over a new project and trying to setup the environment up to best
> > practicing standards. I wanted to install MS Outlook to setup MAPI. My
> > manager thinks installing outlook on production server is really nuts. He
> > thinks it's a security risk and overall having MS Outlook on a production
> > server doesn't seem right. I have never heard of any kind of security risk or
> > any other internal problems MS Outlook can create in a production box with
> > SQL Server installed on it. Can one of the MVPs please confirm it for me and
> > if possible give any suggestions or arguments that I can use to convince him?
> > Thanks in advance for your support ...
> >
> > Bob
> I assume this is a SQL 2000 server? I agree, Outlook has no place on a
> server, but if you want to use SQL Mail, you have no choice. You do
> have alternatives to SQL Mail, however. I've used a command-line mailer
> called "BLAT" for years with great success. There is also an extended
> stored procedure available for download called xp_smtp_sendmail, that is
> nearly a drop-in replacement for xp_sendmail.
> Of course, if you're on SQL 2005, this is all moot...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||Bob wrote:
> Sorry, I forgot to put SQL Server version .. yes it is SQL Server 2000 (SP4)
> on Windows 2003 server
> That's the confusion .. MS Outlook is also a Microsoft product then why
> can't we have that on the server where SQL Server resides?
>
My personal reasons:
1. It's absurd to require a full blown mail client in order to send
SMTP messages from a database server. In the *nix world, there are
hundreds of tiny, dedicated SMTP components available if you need to
send an email message. Why couldn't Microsoft provide something so
simple without requiring their mail client?
2. Outlook is not a stable application, and I don't like having
unstable applications running on my servers, especially when they have
hooks into my database server.
3. Internet Explorer is also a Microsoft product, but I don't trust it,
even on a Microsoft operating system, therefore I don't use it. IE has
some serious flaws, as does Outlook. If something (virus/worm,
whatever) gets loose on my network, I don't want to have to worry about
my databases getting nailed by it.
4. There are simply better options available...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Bob wrote:
> I just took over a new project and trying to setup the environment up to best
> practicing standards. I wanted to install MS Outlook to setup MAPI. My
> manager thinks installing outlook on production server is really nuts. He
> thinks it's a security risk and overall having MS Outlook on a production
> server doesn't seem right. I have never heard of any kind of security risk or
> any other internal problems MS Outlook can create in a production box with
> SQL Server installed on it. Can one of the MVPs please confirm it for me and
> if possible give any suggestions or arguments that I can use to convince him?
> Thanks in advance for your support ...
> Bob
MAPI mail support is gone from SQL Server 2005. That's one more reason
why NOT to use it (the main reason has always been "It sucks!"). Think
xp_smtp_sendmailk, Notification Services or some other mail component.
--
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||my confusion has come to an end after reading all these replies ... Thanks so
much all for your help
"David Portas" wrote:
> Bob wrote:
> > I just took over a new project and trying to setup the environment up to best
> > practicing standards. I wanted to install MS Outlook to setup MAPI. My
> > manager thinks installing outlook on production server is really nuts. He
> > thinks it's a security risk and overall having MS Outlook on a production
> > server doesn't seem right. I have never heard of any kind of security risk or
> > any other internal problems MS Outlook can create in a production box with
> > SQL Server installed on it. Can one of the MVPs please confirm it for me and
> > if possible give any suggestions or arguments that I can use to convince him?
> > Thanks in advance for your support ...
> >
> > Bob
> MAPI mail support is gone from SQL Server 2005. That's one more reason
> why NOT to use it (the main reason has always been "It sucks!"). Think
> xp_smtp_sendmailk, Notification Services or some other mail component.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>|||"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:ekTxHeFpGHA.4424@.TK2MSFTNGP05.phx.gbl...
> Bob wrote:
> > I just took over a new project and trying to setup the environment up to
best
> > practicing standards. I wanted to install MS Outlook to setup MAPI. My
> > manager thinks installing outlook on production server is really nuts.
He
> > thinks it's a security risk and overall having MS Outlook on a
production
> > server doesn't seem right. I have never heard of any kind of security
risk or
> > any other internal problems MS Outlook can create in a production box
with
> > SQL Server installed on it. Can one of the MVPs please confirm it for me
and
> > if possible give any suggestions or arguments that I can use to convince
him?
> > Thanks in advance for your support ...
> >
> > Bob
> I assume this is a SQL 2000 server? I agree, Outlook has no place on a
> server, but if you want to use SQL Mail, you have no choice. You do
> have alternatives to SQL Mail, however. I've used a command-line mailer
> called "BLAT" for years with great success. There is also an extended
> stored procedure available for download called xp_smtp_sendmail, that is
> nearly a drop-in replacement for xp_sendmail.
Except they don't replace the best reason (in my opinion) to use outlook
which is to allow SQL Agent to send alerts, etc.
(I also have used blat btw, decent product.)
I don't think there's a problem with outlook on a SQL Server. Just make sure
it's only sending email and not receiving.
Generally I install the SMTP server that comes with IIS and have my Outlook
install send to this and have it relay to my "real" SMTP server.
This eliminates a lot of issues with Outlook locking up if it can't reach
the mail server.
I don't think the security risk is that large if you understand your goals
and what you're doing.
> Of course, if you're on SQL 2005, this is all moot...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:OH33MhFpGHA.1796@.TK2MSFTNGP03.phx.gbl...
> I don't find Outlook to be a security risk, I find it to be a stability
> risk. Outlook is a lot of things, but a stable MAPI service provider
isn't
> on that list.
Just for the record, while I tend to agree, see my other email.
The BEST thing I ever did for Outlook was to put a local SMTP server on the
SQL box and set it up to relay only from that box to my main SMTP server.
This has GREATLY increased my stability. (to the point I really don't have
to think about SQL Mail at all. It pretty much just works.)
> I prefer to use xp_smtpmail from www.sqldev.net. It isn't a
> drop-in replacement for SQLMail or SQLAgentMail, but you can make it do
most
> of the tasks that xp_sendmail supports. I usually add extra steps for
> failure and success notification to my agent jobs, but there are several
> ways to implement this code. It is a very stable add-in and has caused me
> zero problems, even on large cluster installations.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Bob" <Bob@.discussions.microsoft.com> wrote in message
> news:3A2B8DAB-9424-4E86-9C53-C8BD6E0B1206@.microsoft.com...
> >I just took over a new project and trying to setup the environment up to
> >best
> > practicing standards. I wanted to install MS Outlook to setup MAPI. My
> > manager thinks installing outlook on production server is really nuts.
He
> > thinks it's a security risk and overall having MS Outlook on a
production
> > server doesn't seem right. I have never heard of any kind of security
risk
> > or
> > any other internal problems MS Outlook can create in a production box
with
> > SQL Server installed on it. Can one of the MVPs please confirm it for me
> > and
> > if possible give any suggestions or arguments that I can use to convince
> > him?
> > Thanks in advance for your support ...
> >
> > Bob
>
Subscribe to:
Posts (Atom)