May 22, 2006 at 2:04 pm
I just installed SP4 in our sql server and xp_sendmail stopped working. We have Exchange Server 2003 and all our jobs were working fine until this weekend when applied SP4.
I've googled the error (Error 18025) xp_sendmail: failed with mail error 0x80004005 and found a lot of solutions but none of them solved the problem. We think it might have something to do with our exchange user/profile but have too many jobs not working to keep researching, so I am thinking on going back to before applying SP4.
Will this create more problems? If I just uninstall and reinstall sql server? Were the user databases modified when SP4 was applied?
Can't change to xp_smtp_sendmail because most of my jobs that use xp_sendmail also have querys.
Need advise urgent!!!
May 22, 2006 at 9:37 pm
Are you able to log on as the service account and send email normally (though Outlook, not SQL Server)? If so, are you able to do so through Outlook on the SQL Server?
K. Brian Kelley
@kbriankelley
May 23, 2006 at 7:35 am
Yes to both questions. Actually we had no problems sending any emails previously, up until we applied SP4. Every job was running smoothy, every xp_sendmail was sending emails.
May 23, 2006 at 10:59 am
Now that's interesting. We've been having SQL mail issues, but our scenario is backward from yours. We've had sp4 on the SQL Servers for some time and SQL mail hasn't had a glitch. We are upgrading to Exchange 2003 and moving mailboxes and SQL mail has broken using one of two NT accounts / mailboxes. The mailbox that still works has the exact same Display name and Alias name. The one that is broken has a Display name that is different, and I'm wondering if it is changed to match the Alias if it will solve the problem. I am currently waiting for one of the server admins to change the mailbox for me, but it's not a top priority at the moment.
I can change a couple of the servers' startup accounts to use the "good" NT account / mailbox, but can't change them all for various reasons. I think you are correct that it has to do with the combination of Exchange 2003 and SQL sp4 though. I am using different versions of Outlook client on the servers and all but one no longer work. The server that still has SQL mail working uses mail heavily and I think maybe that the connection information is being cached somehow--not sure though. Hope this helps some 🙂
May 24, 2006 at 6:54 am
Well, I almost don't believe it myself but my guess was right (on our servers anyway). Once we changed the Display name to exactly what the Alias name was in the Exchange mailbox, SQL mail worked again on the servers using one "broken" NT account--every one. We've been butting our heads against the wall for weeks, and not once did I see any documentation even hinting about this particular "fluke".
Anyway, I hope your resolution is as simple and that you find a fix soon. I am SO glad to have our email case closed 🙂
May 24, 2006 at 8:45 am
I have had situations where the Exchange account name is case sensitive. Normally this case is not an issue, but for some of our mail profiles they only work if the exchange account is entered exactly as defined in Exchange.
Likewise we have had a few situations where a Windows account needed to be defined in a case sensitive manner in SQL. In situations where our AD domain had Windows accounts DEV\SQLservice and TEST\sqlservice, defining the Windows account as DEV\sqlservice in SQL Server did not always work but DEV\SQLservice did. Where the account name was unique within AD, such as DEV\SQLdevAC, defining the account in SQL as DEV\sqldevac or DEV\SQLDEVAC was not a problem.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
May 24, 2006 at 9:42 am
Checking our accounts setup I noticed that we are using different caps on the names. Some are small caps, some not. So we made the adjustments and we will try tonight (We can't stop the server).
I will let you know if this works. I feel confident that this will be the solution. Thanks to Linda and Ed for your posts
May 25, 2006 at 7:48 am
It DIDN'T work. We tried changing to lower case, upper case, even login in with different users with no upper/lower case difference but NONE worked.
So we tried a different approach. We REPLACED the .DLL used by xp_sendmail with the old one and it WORKS at least partially. It works fine as long as you don't send any attachments. But that was my original problem. I needed to execute querys in my emails, so my problem is solved. And whenever I need to send an attachment there is always xp_smtp_sendmail which is a lot faster (10 times) and has no problems sending attachments.
I don't think it will create any conflicts with the server since is an extended stored procedure and apparently only calls the DLL
The file to replace is sqlmap70.dll and is located in BINN folder in you SQL Server installation folder. Generally:
c:/program files/microsoft sql server/mssql/binn
May 25, 2006 at 7:49 am
Just in case you are still having problems:
http://support.microsoft.com/kb/293422
Make sure that the Active Directory account the MSSQLServer service is logging in as has "Send As" rights on the Exchange 2000 mailbox object in the Active Directory, follow these steps:
1. Open the Active Directory Users and Computers Snap-In.
2. Locate the user object directly associated with the Exchange 2000 mailbox and select it.
3. Right-click to get the properties for this account or mailbox object.
4. Click the Security tab. (If the Security tab is not showing, select Advanced Features from the View menu; this will show the Security tab.)
5. In the Security dialog box, click Advanced.
6. In the Access Control Settings for the selected user dialog box, click ADD.
7. Locate, and then select the Active Directory account that the MSSQLServer service is logging in as.
8. Make sure that the Allow Onto list box is set to This object and all child objects.
9. In the Permission Entry for the selected user dialog box, scroll down in the Permission pane, and under the Allow column, select Send As.
10. Press OK three (3) times to apply the change on all the open dialog boxes.
This change may take some time to replicate through the Active Directory.
May 25, 2006 at 7:50 am
Already tried that one. Nothing
May 25, 2006 at 8:49 am
Before going to uninstall route, which will take several hours, have you tried contacting Microsoft Support? If it's a genuine bug, you most likely won't be charged. If it isn't a bug, you'll probably spend less in the support call cost than you would the uninstall/reinstall cost in man hours.
K. Brian Kelley
@kbriankelley
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply