I am trying to send an email via Exchange using PowerShell. Is it possible to specify what version of Exchange to use? I don't know if Send-MailMessage is the correct function to use either.
The server requires username and password, and should use Exchange2007_SP1.
Running the code below returns "Send-MailMessage: Service Not Available. Closing Channel. Server response 4.3.2 Service Not Available".
So it seems that the server gets this, but rejects it.
The secured server that this runs on, has no direct internet connection, but can reach the Exchange server. Hence, I cannot download and install addons to PowerShell, if that is required.
Any ideas out there? Am I attacking this from the wrong angle?
$sendMailParams = #{
From = 'sender#somemailaccount.com'
To = 'johndoe#someexchangeserver.com'
Subject = 'some subject here'
Body = 'some body here'
SMTPServer = 'exchange.server.com'
UseSsl = $true
Credential = $mailCred
}
Send-MailMessage #sendMailParams```
The reason for this not working in the first place is due to PowerShell policies on the terminal servers. For security reasons, sending mail from PowerShell has been disabled, since you can mail to anyone, from anyone. When you log on to the system in the morning, you get a random terminal server. If I'd been logged on to the same one all the time, it might have been an option to enable it on that specific terminal server. But as it is, it is too open to enable it on all servers, so that's why it is restricted.
If things change in the future, it might be an option to do this.
I know this isn't a direct answer to the question, but it is no longer relevant for me. IT says it isn't necessary to specify Exchange version when sending through PowerShell.
Thanks for all your inputs, folks. You are the best.
Related
I have several hundred Perl scripts that send email via gmail SMTP. All are, and have been working fine for a couple of years with the gmail password hard-coded.
To simplify password changes (and for security), I want to move the password to an env var, and pull that into the perl scripts. I am using the code below.
my $smtp = Net::SMTP::SSL->new('smtp.gmail.com', Port => 465);
my $passwd = $ENV{'PASSWD'}; # I added this line
$smtp->auth('email#gmail.com', $passwd); # I replaced 'theHardCodedPassWord' with $passwd
The same method works in a non-smtp scenario -- I pull info from an env var and use it.
What am I doing wrong?
Two obvious debugging approaches:
Print the values of $ENV{PASSWD} and $passwd before the call to auth().
Turn on debug output in the Net::SMTP::SSL object (add Debug => 1 to the call to new()).
A few other points:
The documentation for Net::SMTP::SSL is pretty clear that the module is deprecated and should no longer be used. It says that Net::SMTP now has built-in support for SSL connections.
Net::SMTP seems to be a rather low-level approach to this problem. Have you considered Email::Send::Gmail? I've even had success sending email through GMail with Email::Sender::Simple.
I know that GMail recently hardened their security around using their SMTP servers from external apps. There's more information about this change on the Google support site.
I would like my MacOS "server" (basic mac mini with OS12.1 installed)
to be able to send emails using my current (paid) email provider.
Some theory first.
I am aware about this fine article (http://hints.macworld.com/article.php?story=20081217161612647)
What puzzles me is how on earth will "fresh out of box" mac be able to send even ONE email without being (mail-server) configured first. In other words to what email server will it send my email?
Discovered the very useful command mailq that will show the current status of all current emails being processed.
I understood that the command mail will send an email:
echo "this is the body" | mail -s "this is the subject" "myself#myserver.lu"
I understand, mail is using postfix in the background.
This will show the version of postfix (mine is mail_version = 3.2.2)
postconf mail_version
Is it possible to update postfix on macos?
Did anyone managed to enable the log on mail_version 3.2.2?
I get this warning:
postconf: warning: /etc/postfix/main.cf: unused parameter: maillog_file=/var/log/postfix.log
without the log it is a bit difficult to see what went wrong during email send...
thanks in advance for some MAC related input.
I have a BizTalk 2013r2 Standard Edition application server with CU7 installed. The BizTalk databases are hosted on a separate Sql Server 2014 server. This setup has been working fine for many months - until today! A colleague used the BizTalk admin console to make a change to the address BizTalk uses to the reach the SMTP server, by selecting Platform Settings\Adapters\SMTP\\properties.
After making this change, on attempting to refresh the BizTalk Admin Console, the following error is displayed:
From what I've googled, it seems this may be due to some corruption in the SSO database. I have a backup of the SSO database, and a backup of the SSO key along with the password. Before restoring the backup of the SSO database, I wanted to check that I would be able to restore the key, so I ran ssoconfig -restoreSecret from the command line. I was prompted to enter the password. If I intentionally enter the wrong password then it tells me the password is incorrect. However, if I enter the correct password then it displays the message "BAD DATA".
Although the BizTalk admin console is currently unusable, thankfully the BizTalk host instance continue to run and messages are being processed as expected.
Can anyone please suggest why I'm getting the "BAD DATA" message, or perhaps a work-around in order to solve the problem?
I had this problem again and blogged about it at BizTalk WinMgt error solution. As Colin says the hard part is identifying the corrupt handler. It is probably the SMTP send handler but you should check this using WBEMTEST first. I found this link helpful on using WBEMTest. The parameter is incorrect (WinMgt)" error when refreshing the BizTalk Group in BizTalk Administration Console
In my case a quick fix to bring the BizTalk Administration Console back to life was to hack the database. N.B. This probably won't be supported by MS. In my case it was the FTP send handler that screwed up. So I ran
USE [BizTalkMgmtDb]
GO
DECLARE #return_value int
EXEC #return_value = [dbo].[adm_SendHandler2_Delete]
#AdapterName = N'FTP',
#HostName = N'Sending32'
SELECT 'Return Value' = #return_value
GO
At this point the BizTalk Administration console came back to life. In my case it worked because I was creating a new handler but in your case you just edited it. It will take all your SMTP handling out.
I then fixed the corruption using the BizTalk Administration console.
In my case I had to set every FTP receive and send adapter temporarily to a FILE adapter.
I then deleted the FTP adapter and then re-added it. Finally I reset the all the change receive and send location from FILE back to FTP.
This was all very scary on a live system.
Finally I believe that this is bug in BizTalk 2013 R2 because I've seen it happen on 2 systems and now I have heard that the same thing happened to you.
The WinMgt error happens when one of the Adapters setting has gotten itself corrupted. See WinMgt error when refreshing Group Hub
Removing and re-adding the adapter to the host usually fixes it. The trick of course is identifying which Adapter / Host, I would start with the SMTP adapter in your case.
This might be a tough thing to figure out but i have to give it a try.
With no changes i am aware of, my jenkins just stopped sending out e-mail notifications. I use jenkins 1.609 and email extension plugin 2.40.5. Jenkins runs as a service using a service user who also has the rights on the server to send e-mails. Ports to our smtp-server are unlocked. Used telnet for testing that everything works as expected. SMTP-server works fine, so it has something to do with jenkins and i cant figure out what is going wrong.
For some unknown reason jenkins still fails to send e-mails. When i use the test-feature that jenkins offers i get: javax.mail.AuthenticationFailedException: 535 5.7.3 Authentication unsuccessful which tells me that either user or pw is incorrect, but as mentioned i've checked many times, it's setup correctly. Can anyone help out with this?
UPDATE:
After decrypting the password i can safely say that jenkins does save the password correct. Is there any way i can check that jenkins actually compares the correct encrypted passwords with each other? From my understanding jenkins uses 2 different encrypting techniques, maybe it uses tech1 for stored pw and tech2 for compare pw?
ANOTHER UPDATE:
Just tried adding a new certificate to the keystore, just in case, still no change.
MORE UPDATES:
Tried updating the mailer plugin- no change
Tried different users - all failed with the same error
So no matter what user i try, they all fail, but have jenkins execute a script which sends e-mails using said users it works.
August 18, 2016 - no change
We're using SSRS to generate database reports that publish to an internally hosted webserver. I'm then writing a PowerShell script that periodically runs and downloads the reports as PDFs.
I've gotten it to work running as an admin. But for security purposes, the automated task must run as a generic domain service account.
The code I use to download the PDF using my account is:
$webClient = New-Object System.Net.WebClient
$webClient.UseDefaultCredentials = $TRUE
$webClient.DownloadFile($ssrsURL, $filePath)
When I run this code as the service account, I get an 500 Internal Server error. I've tried replacing the second line of code with:
$webClient.Credentials = New-Object System.Net.NetworkCredential("Username", "Password", "Domain");
When I try this, I get a 401 Unauthorized error. Even though the Username / Password I put in the code is my own, and works when I log in to the webserver via IE.
The answer may be in my code, domain / local security policies, or SSRS security settings...
Some questions that might be in the right direction are:
What other means of authentication could I try in PowerShell
Does anyone know of any IIS / SSRS settings I could try altering?
What domain or local security policies are allowing "UseDefaultCredentials" to work when run under my account, but not the service account set up?
Thanks in advance for any ideas.
Finally figured it out... it had nothing to do with authenticating with SSRS. My first code snippet works fine.
The issue was in the permissions of the underlying databases. We have five reports, I suddenly noticed that the PowerShell script could download 4 of the 5 reports using the service account. Never noticed because I was always testing on the same report...
Went to the SSRS log file to see why the last one wasn't working - the service account didn't have access to the database that specific report is pulling data from. Hence the 500 error instead of a 401 error.