Office 365 and FMS

[geosharp]

Hey there,

Apologies if this the wrong part of the forum for this, but as the problem seems to be Office 365 config I figured here.

We've had email PO's and BACS remittances set up for a while in SIMS FMS and it's worked fine. However, it suddenly stopped working last Thursday, then very briefly worked Friday and now has stopped it seems entirely.

I've been mucking around trying to get it working for most of yesterday but i'm stumped.

 

We've got Google for Education so I bought a domain, verified it with google and created a google account there and that works, so it's not entirely an FMS thing.

The settings i've got in FMS are:

Mail Server smtp.office365.com

Port: 587

Use STARTTLS Encryption: Yes

Authentication Required: Yes

 

Followed be an email and password that I know is correct as i've logged into it - i've also tried sending and receiving email on that account.

 

The error i'm seeing from FMS is 'Failed to read beginning of SSL/TLS record. Client handshake failed. Failed to establish TLS connection.' Now, I remembered that office was depreciating TLS 1.0 & 1.1 so I hunted round on Microsoft's site and i've made sure SMTP AUTH is still on and legacy TLS and tried using the legacy SMTP address, as I strongly suspect that despite ESS suggesting otherwise FMS doesn't support TLS 1.2.

 

Anyone any thoughts? Any help appreciated :-)

[DEllinor]

Unfortunately, we are experiencing the same issue that also occurred on Thursday.

 

A team member has been trying to find a solution since Monday to no avail!

Really hope someone finds a solution soon... our finance team hates change

[3s-gtech]

Could it be a basic auth issue?

 

https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online

[geosharp]

Hey,

I knew there was something i'd done Thursday that seemed to make it work - i'd ended up at the same article you linked, I recognised it when I opened it up. I've ran the diag again to check but it does seem i've re-enabled basic auth for POP3, i'm assuming that's what it uses. I'll try EWS as well and see if that does anything.

Cheers :-)

[DEllinor]

I have enabled basic auth completely but the dialogue box says it could take up to an hour so here to hoping!

[DEllinor]

Hey,

I knew there was something i'd done Thursday that seemed to make it work - i'd ended up at the same article you linked, I recognised it when I opened it up. I've ran the diag again to check but it does seem i've re-enabled basic auth for POP3, i'm assuming that's what it uses. I'll try EWS as well and see if that does anything.

Cheers :-)

 

We have tried this but still getting the same error!

[geosharp]

Hey there,

Yeah, ours still isn't playing ball. I've found out since that we pay for FMS support from the local council, i've been in touch with them and the lady I got freely admitted she wasn't technical enough to really be able to help but would get back to me, and to be fair she has. Important bit copied below:

 

"I logged a call with ESS and they have got back to me today.

 

They are aware of an issue with sending emails from FMS, where Office365 (Microsoft365) is the mailserver provider being used by the school to send emails.

They believe this to be related to a change made by Microsoft, investigation is still ongoing.

 

However, they have had a setting within O365 suggested as a possible fix for the email issue:

In the properties for the mail box user can you please go to Mail > Manage email apps and check the option "Turn on use of legacy TLS clients" "

 

I'd already tried what she suggested at the end earlier in week and it hadn't worked, but worth a pop, may work for you! :-)

[DEllinor]

My colleague said he had a similar response regarding the issue. He said he has tried the "Turn on use of legacy TLS clients" but still no change!

 

Looks like the ball is firmly in ESS' court!

[Anonymous2000]

We are seeing several schools reporting this. Even with all the things above added we are still seeing failures.

If I send an SMTP message using Powershell from the same computer that is running FMS it goes fine - just not via FMS.

I turned off TLS 1.2 in IE and it worked so thought I had cracked it but it only worked once! Subsequent tests just fail.

Tried it with a Yahoo account too and got the same results.

Ran wireshark and as someone mentioned it seems unable to handshake properly and falls over using FMS.

 

I have a remote session with ESS tomorrow so will we see what that brings but not hopeful.

 

I did find an old article on their website that seemed to use a workstation patch to fettle it but that is now obsolete.

 

Strange thing is we are seeing it across many versions of FMS client - 6.202, 204, 206 and 208 so it doesn't appear to be upgrade related.

 

If anything remotely interesting happens I will post it on here.

[mukz]

They already remoted into our FMS setup and was told not an issue with us. its your Firewall.

Noone else has logged this bla bla bla.

 

We have spoken to LGFL and Ports are definitely open.

Microsoft have confirmed that there is nothing wrong on their end as i can manually connect via powershell using those same settings and it works fine!

 

There is a TLS issue with updates but if you are on the latest update then it should be applied - This is for server 2022.

https://support.microsoft.com/en-us/topic/october-17-2022-kb5020436-os-build-20348-1131-out-of-band-18baa25a-5fc0-4118-9b89-ddbe9819e578

Edited December 1, 2022 by mukz
Updated

[TDO2022]

Looks like this is happening quite widely now. Suggest everyone logs with ESS, focus their minds a bit!

[DEllinor]

Our Head of Finance has had a call with ESS and managed to get more information than we could...

 

They are aware of the issue and have started conversations with Microsoft to try and resolve the issue.

She isn't very technical so she didn't say much more than ESS is on the case and that they will endeavour to give her an update by next Thursday...

 

So if you want results... get your Head of Finance on it.

[Michael]

Afternoon all,

 

Here's my working FMS bodge, based on the same principle as I posted here for HP iLO4.

 

 

This is going to need quite a fix from ESS to work properly on Microsoft relays.

[Strawdog]

We got hit by it yesterday, my immediate thought was MS discontinuing support for basic auth - given the age of the underlying software I can't see ESS being able to easily shoehorn modern auth support into FMS.

 

They could setup their own basic auth capable mail relay for schools to use but I can see a number of reasons they'd not want to go down that path (support, cost, security, liability, etc.).

 

If it is basic auth ESS have only had 12+ months to put a fix in place... :\

[chazzy2501]

Yes, I thought it was just me! Just a waiting game then. Edited December 2, 2022 by chazzy2501

[Boredguy]

Afternoon all,

 

Here's my working FMS bodge, based on the same principle as I posted here for HP iLO4.

 

[ATTACH=CONFIG]67334[/ATTACH]

 

This is going to need quite a fix from ESS to work properly on Microsoft relays.

 

Just remember if using this method that if you have not updated the DNS records it can end up marking the messages as potential spam when the message runs through the spf checks.

 

Other option (which seems to be working fine for us with Legacy Disabled in 365 and should work with FMS even though we've not used it for 5 years) is to setup an on site Mail relay that has a valid 365 account it is authenticating with, that has Send As rights to the mailbox your e-mails are going out from.

 

So far all our Powershell/Photocopiers/SCCM etc is still happily sending the messages out via this route without any errors so knowing how long it takes EES to fix stuff it might be a better option

[chazzy2501]

so is this not valid? https://www.sims-partners.com/GeneralDocuments/Announcements/FMS/TLS1.2

[Anonymous2000]

Had a call with ESS yesterday and the only outcome was they have it logged as a major case and their devs are looking at it.

[CharlieKES]

I've had a reply from EES today to say they think its a DLL file issue -

 

"Following further investigation into this issue we believe we have identified the cause of this issue as being down to a fault with a 3rd party .DLL file utilised by FMS for email handling."

 

I've replied asking if they even read the link I send them (from Microsoft) explaining that they've turned off the ability to sign into SMTP using basic authentication. I've also told them that I have since bought a new domain, assigned it to our Googe Workspace account service (verifying the MX records etc), and got the system working again. Google still allow basic authentication for their Workspace customers (not the free google service - just workspace).

[Strawdog]

"Following further investigation into this issue we believe we have identified the cause of this issue as being down to a fault with a 3rd party .DLL file utilised by FMS for email handling."

 

Weak sauce, someone needs to send them a copy of the BOFH Excuse Board.

[CharlieKES]

Here's what I did to bypass the issue, basically switching from Office365 to Google Workspace for this one account :

 

1. Go to 123-reg.co.uk and buy a cheap domain for the school, no hosting is required. Costs about £15.

2. Sign into Google Workspace (sign up if you haven't already, it's free for education).

3. Assign the domain, and verify, updating the MX records on the reg-123.co.uk site from the information on the Google admin page.

 

4. In the Google admin page for the domain, create a new user with an email address ending in the new domain. You also have to give them superuser privileges - I know annoying, but for us it's the only way to get past the SSO setup we have for our school - you might not need to.

5. Under Security on the admin.google.com page, turn on "Less secure apps".

6. Sign in with the new account and turn on IMAP via the gmail settings cog. Go to the accounts page for the account, then security. Turn on "2 Step Verification", with this on, you can now create an "App Password".

7. With the app password, I head over to FMS, and enter:

 

Mail Server: smtp.gmail.com

Port Number: 587

Use STARTTLS: YES

REQUIRES AUTHENTICATION: YES

USERNAME:

PASSWORD:

 

All sorted.

 

Issues:

The annoying thing with all of this is it means suppliers are going to get emails from a new/different email address than the one they're used to.

I've set up a forwarding rule so any messages that do come in via the new account, automatically get forwarded to the old finance email account.

[Strawdog]

Here's what I did to bypass the issue: -

 

Told the affected admin staff to print their invoices/remittance to PDF and email them as attachments

 

(I'm only here for another month so I'd rather not leave some convoluted workaround or potential security hole for whoever picks up the reins once I've left)

[andy_b]

Here's what I did to bypass the issue, basically switching from Office365 to Google Workspace for this one account :

 

1. Go to 123-reg.co.uk and buy a cheap domain for the school, no hosting is required. Costs about £15.

2. Sign into Google Workspace (sign up if you haven't already, it's free for education).

3. Assign the domain, and verify, updating the MX records on the reg-123.co.uk site from the information on the Google admin page.

 

4. In the Google admin page for the domain, create a new user with an email address ending in the new domain. You also have to give them superuser privileges - I know annoying, but for us it's the only way to get past the SSO setup we have for our school - you might not need to.

5. Under Security on the admin.google.com page, turn on "Less secure apps".

6. Sign in with the new account and turn on IMAP via the gmail settings cog. Go to the accounts page for the account, then security. Turn on "2 Step Verification", with this on, you can now create an "App Password".

7. With the app password, I head over to FMS, and enter:

 

Mail Server: smtp.gmail.com

Port Number: 587

Use STARTTLS: YES

REQUIRES AUTHENTICATION: YES

USERNAME:

PASSWORD:

 

All sorted.

 

Issues:

The annoying thing with all of this is it means suppliers are going to get emails from a new/different email address than the one they're used to.

I've set up a forwarding rule so any messages that do come in via the new account, automatically get forwarded to the old finance email account.

 

Isn't this going to complicate matters - will look like a dodgy impersonation email?

[Strawdog]

 

Latest update from ESS via the LA.

[mukz]

I dont think this allows you to email externally? But i could be wrong!