I've seen this happen a few times before and here are the causes I have seen. Keep in mind these have only been seen in a large environment. If you are in a single dc, single exchange server environment these will not apply.
First off here is the MS article on this: http://support.microsoft.com/kb/895853. Under the possible cuases you can see there are a lot of things at play.
One of your exchange servers relay permissions are not setup correctly.
This is most likley the cause. The mail may be taking a different route on the first and second try, while this might sound silly run message tracking on both messages, see if they go through the same server. If you see different paths check the settings on the bad one, could be a simple allow relay for authenticated users isnt checked.
AD permissions are wrong
You must have Send As permissions on the account that has the from address from your email. If it is working sometimes, but not others then it may be different pathings on mail routing, with different permissions between them.
Authentication isn't working correctly.
In the first instance of the script it may be that authentication fails, and in this instance the mail is denied as you do not have permission. In the second run of the script authentication is successfull. Unfortunately I do not know ASP well enough to understand the code above or advise on how to fix it. smtpClient.UseDefaultCredentials may not be the correct code for your environment. This will only authenticate if requested by the server and will use the credentials of the locally logged on user. If the server isn't asking for authentication the first time around then you wont be authed and may not have permission to send. Try changing it to some code that always authenticates.
One of your DCs or global catalogs is out of date or has bad information.
This is rare but it is possible that your domain controllers have out of sync information. Double check the server information on the from and to accounts via ldap or adsi edit and ensure they are identical across all dcs.
In all instances check the logs on the exchange server and ensure SMTP logging is enabled with all fields. Use message tracking to see exactly which servers this message is hitting.
The solution is quite simple, having a password for ExchangeServiceAccount as SecureString $ExchangeServicePassword variable:
# Mail server
$SmtpServer = "mail.company.com"
# .NET object MailMessage
$Msg = New-Object Net.Mail.MailMessage
# .NET object SMTP server and SMTP authentication parameters
$Smtp = New-Object Net.Mail.SmtpClient($SmtpServer, 587)
$Smtp.Credentials = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "ExchangeServiceAccount", $ExchangeServicePassword
$Smtp.EnableSsl = $true
# Email structure
$Msg.From = "exchangeserviceaccount@company.com"
$Msg.ReplyTo = "alerts@company.com"
$Msg.To.Add("alerts@company.com")
$Msg.Subject = "Subject"
$Msg.Body = "Some text"
$Msg.SubjectEncoding = [System.Text.Encoding]::UTF8
$Msg.BodyEncoding = [System.Text.Encoding]::UTF8
# Send email
$Smtp.Send($Msg)
Best Answer
No offense meant, I know you were simply trying to answer your own question and post for the SF community, but I would say you are doing it wrong.
You should setup your Receive connector as a proper relay, with the permissions tab set to
Exchange Server
notAnonymous
and your Authentication Tab set toExternally Secured
. Then lock the Receiver down to only accept messages from the WSUS server's IP address.Using
Anonymous
permissions isn't the right way to handle it in general...EDIT: in order to clarify and answer some questions in the comments, see this Technet article: http://technet.microsoft.com/en-us/library/bb232021%28v=exchg.141%29.aspx even though it isn't exactly the easiest to follow.
You have 2 roads to go down...if you choose to go with "Anonymous" then you have to run a shell command to allow anonymous connections the proper ADPermission, something that can't be done in the EMC. This in effect will be the same as the way I'm stating, however some apps will still act like they have to send a username/pwd, so in the past my results have been mixed using this.
So...I stick with the 2nd option they give of "Externally Secured". However, that requires (as mentioned in the article) that the permissions be set to
Exchange Servers
. What happens is mentioned in this article: http://technet.microsoft.com/en-us/library/bb690954%28v=exchg.141%29.aspx -- stating:So in essence you are saying with that Receive Connector "trust anything that comes from this set of inbound IPs I'm allowing", no auth, no prompts, no nothing, just take the email and send it out.
Hope that helps.