We are unable to get SMTP emails working with Office 365. I've tried to setup using the settings found here with no luck:
Using the same settings on our MFDs are other devices are able to send emails by SMTP. Is there something I could be missing? I am using gmail's SMTP for now but I would much prefer to using Office 365.
To confirm, are both the test email and notifications failing with Office 365 - or just one or the other?
If test email fails, what does "Last Server Response" field show after the failure?
The only thing I know about with Office 365 is that I found they required TLS 1.2 for SMTP authentication. We recently introduced that in a new revision of firmware that is not yet available but is in testing. I was under the impression though some people were able to work around it.
Depending on what Last Server Response says in the test email screen, it may confirm/deny an issue with the SMTP authentication protocol. Or, it could be something else.
Both the test option and the notifications were failing.
The Last Server Response is "220 2.0.0 SMTP server ready".
From what I am reading here Office 365 supports TLS 1.0 and 1.1 as well:
Thanks for that article! Looks relatively recent as when I originally researched the issue, I could only find forum posts saying TLS 1.1 and 1.2. We have a knowledge base article on this and I will see about getting it updated.
One possible problem we could have is the cipher support for this function. I will have to check on the supported ciphers so I've put in a request for that.
Another thought - do you know with your Office 365 configuration if there are any settings relating to this feature? Like for example with Gmail, people need to allow less secure apps to connect usually and then it works. I am wondering with Office 365 if you have to specifically allow TLS 1.0, as an example, and the default is TLS 1.2. (We have Office 365 here but I am not an admin so I don't know if such a thing exists.)
Since I have Office 365, I am going to try this tonight with an NMC on my own personal network and a few different firmware versions. I am not having success reaching the email server within our internal lab network. I'll report back with my findings hopefully tomorrow to see if I can figure out if this works some which way.
We do not have any options for managing what version of TLS it uses. As far as I know these things are handled automatically when the SMTP request goes through. Let me know how your tests go. We are getting notified, I would just rather move it off from a gmail account.
So, I went home early. The fact it was a very nice day outside only helped
I tested this with my O365 account and replicated the issue and also same Last Server Response you got. This was on our latest "released" AOS v6.4.6 in a Smart-UPS.
Next, I upgraded to the next rev of AOS where this SMTP authentication enhancement/better support is implemented that I thought may make a difference - AOS v6.4.8 - and it worked!
Let me find out the plan of when this new firmware will be released because I think it will be the answer to your problem Depending on when that is coming out, we'll discuss options. I need to know what firmware applications you're using though - like Smart-UPS, Symmetra, Rack PDU, etc.
That is great news. Thank you very much for looking into this.
We are using Smart-UPS and Rack PDU.
OK, Smart-UPS with AP9630/31/35 NMC will be releasing tentatively towards the end of June with this fix.
Which model of Rack PDU you have? The AP8XXX series models that support secure SMTP authentication and are on v6.X.X? They are tentatively scheduled to release in August as they are adding some new features.
If this timeline does not work for you or will be a major problem to continue to use Gmail in the meantime, let me know.
We actually only use the SMTP on the SmartUPS sorry. But yes if Gmail is the only option for that until June that is all we can do. Thank you very much for the update on this timeframe!
I know this is an older thread but I am having the exact same issue.
I am head of IT at our company and we recently switched our email from offsite exchange to Office 365. SMTP notifications had been working fine before the switch.
I upgraded firmware to 6.5.0 to be compatible with 365's new TLS 1.2 requirement, but I'm still getting the error.
Can you share a copy of your config.ini file? If you dont want to post it here, you can email it to my Box folder so only I'll be able to see. The email to send to is: Office_.email@example.com if you want to go that route.
I am interested in the specifics of the settings - authentication, ports, etc. I have gotten O365 working very recently on this so we should be able to figure out a way to get it going.
*Edit* forgot to add if you need help downloading logs, check here-> http://www.apc.com/us/en/faqs/FA156131
Entire .tar file is fine as well but the minimum will be the config.ini file for now.
Thank you Angela. I just exported the log file and sent it to you.
It's very strange though - when I generated the log file I received an email from the NMC "Debug file generation successful". But I went in right afterward and tried to send a test email and that one failed. Also, we had a brief power outage yesterday and the alerts did not get delivered, which I confirmed in the logs. So it seems that the settings are correct but it's not going through most of the time...
Thanks for your help.
Got the files, thanks. I will look at them shortly in detail and reply back.
OK, I just looked.
I sort of expected the mail server to be using outlook.office365.com or smtp.office365.com. Is what you have programmed in supposed to also work or is there a reason why you're not using similar settings to below? I am not super familiar with Office 365 and all of the different options or possible configs/environments.
We have Office 365 here and what I used was the following and I am receiving emails normally:
I understand you're saying the settings at least work sometimes since you got an email just now when generating the .tar.. but wondering if you have the option to try similar settings to what I did or why you are unable to to see if these work any better.
I am also considering the Last Server Response you mentioned to. Do you by chance have access to the mail server and any logs (not sure how that works with Office 365 since I don't have any access to ours.. Normally I'd also be interested in a packet capture to catch the SMTP conversation and commands back and forth too but since we cannot do this from the NMC side, not sure if it is possible here either with Office 365 vs. a traditional on premise mail server.
The settings I have are based on this article by Microsoft: https://support.office.com/en-us/article/How-to-set-up-a-multifunction-device-or-application-to-send-email-using-Office-365-69f58e99-c550-4274-ad18-c805d654b4c4
I am using "Option 2" in that article, and already set up a number of other devices this way. The settings there are also why I used Port 25 instead of 587.
I don't want to use Authentication (Option 1 in that article) because then the emails will come from me. I would like the sender to be a more obvious name such as what I have now (PowerAlert@mydomain.com) so that when we have an issue with power the notification will be more noticeable.
As far as logs, the closest thing I know of on Office 365 is what they call Message Trace, which I tried but it only showed the messages that went through. I can also connect via PowerShell but I'm not familiar enough with PowerShell to know how to access anything useful.
Thanks again for all your help with this.
Hmm, OK. This is new to me - these options I mean.
I see this note with Option 2 - Note that there is a risk of your email being marked as spam by Office 365.
I was thinking that it is possible some of these messages are getting stopped, which could explain what you saw - most messages not making it through but some do, like yesterday.
Do you just have one of these you're checking with? Curious if you had any more NMCs to observe their behavior and if it's the same. Do you have an idea of how many emails make it through, like 1 out of 5 or something?
I was thinking to try the DNS test function to see if the NMC can resolve your mail server (which you can still do a few times or couple of times after trying to send a test email or generate a "real" notification and see if it fails) but if we go back to the "last server response" after the test failed, it seems like it is making it as far as the server. Could go back to something at the server side that is getting snagged if we don't think there is a DNS problem. DNS is especially doubtful if you're other devices are not having a problem with these settings. Just trying to think what could be different. I am not aware of any recent cases trying this specific option so I don't have any specific experience with this method. I've seen people using smtp.office365.com mostly.
So for option 1 to work for you, you'd need to make PowerAlerts@mydomain.com an actual account in O365, right? Else, it'd have to look like the email was coming from you (which is what I did in my settings), knowing it has to be a valid account for the email to be sent.
OK so re spam, if that was the issue I would receive it to Quarantine and Message Trace would find the message with status listed as Quarantined. Also, NMC would report the email as sent, because it has no idea how our spam filter treated it. In our case the message is not being found at all, and NMC is reporting an error sending.
Also, to prevent the spam issue in the note you quoted, I modified our SPF entry in DNS so that all messages sent from our static IP would be allowed. I did this last week when setting up the other devices I mentioned.
Unfortunately we only have one NMC so can't test another one. But before we switched to O365 it was working flawlessly with a similar setup.
I agree with you that both the reported server response and the fact that other devices are working with the same configuration rules out a DNS issue.
I will try option 1 just to test it, to see if that is the issue or if there is some other problem. If it works I can always set up an account with that name as a shared mailbox. EDIT: Just realized a shared mailbox probably won't work because login is disabled. It would need to be a licensed mailbox.
OK, good idea. I'll wait to hear your results. Once we have as much info from your side that we can get, I can inquire with our team if they would be able to try this. Since our O365 is controlled by internal IT, I am not sure what the process will be for QA (or me) to get what they need to test this and then check into it. Of course we also have no control over DNS configurations either.
Edit - I also need to check if we have O365 somehow in a test environment vs. just corporate environment to work with. That way we can do what we need to if we need to look into this further internally on our side.
Choose a location
There are no forums in this space.