Sage 100

• Use PowerShell to run the Set-TransportConfig cmdlet in the Exchange Online management module:
• Set-TransportConfig -AllowLegacyTLSClients $True
• Configure clients to use a new endpoint: smtp-legacy.office365.com.

There are no instructions in the file though it is named TLS_2018_8_ProgramFix.Zip

Unfortunately I update this customer to 2018.10 and then tried the install which produced the error.

I tried copying the program file to the local Sage folder but was waiting until everyone is done emailing to test.

Looks like maybe we will have to use an SMTP relay ( which I have not yet found a great source of instructions for IT on how to create  - though I did think this looked comprehensive - https://adamtheautomator.com/office-365-smtp-relay ) 

I wish Sage was more proactive on this and created an actual knowledgebase article 

There are no instructions in the file though it is named TLS_2018_8_ProgramFix.Zip

Unfortunately I update this customer to 2018.10 and then tried the install which produced the error.

I tried copying the program file to the local Sage folder but was waiting until everyone is done emailing to test.

Looks like maybe we will have to use an SMTP relay ( which I have not yet found a great source of instructions for IT on how to create  - though I did think this looked comprehensive - https://adamtheautomator.com/office-365-smtp-relay ) 

I wish Sage was more proactive on this and created an actual knowledgebase article 

There are no instructions in the file though it is named TLS_2018_8_ProgramFix.Zip

Unfortunately I update this customer to 2018.10 and then tried the install which produced the error.

I tried copying the program file to the local Sage folder but was waiting until everyone is done emailing to test.

Looks like maybe we will have to use an SMTP relay ( which I have not yet found a great source of instructions for IT on how to create  - though I did think this looked comprehensive - https://adamtheautomator.com/office-365-smtp-relay ) 

I wish Sage was more proactive on this and created an actual knowledgebase article 

------------------------------
Wayne Schulz
Schulz Consulting
860-516-8990


Original Message:
Sent: 10-28-2021 12:01
From: Jim Steele
Subject: Sage 100 2018 email smtp error

Sorry Folks, I'm chasing the same thing, was told yesterday by Sage Support that the original post about 2018.8, 9 or 10 is incorrect.  That it only applies to 2018.8, any other will throw the error 65.  They said that 2018.9 came out the same time as the other 2019 and 2020 updates, so they changed the email engine file on 2018.9 which caused problems with the patch and the .9 and .10 updates.  I'm still waiting for the patch hotfix for 2 of my end-users, the others are in limbo until I can figure this out.

Jim Steele
Orion Business & Accounting Solutions

------------------------------
Jim Steele
Orion Business & Accounting Solutions


Original Message:
Sent: 10-28-2021 11:44
From: Wayne Schulz
Subject: Sage 100 2018 email smtp error

I applied the supplied patch to a 2018.10 system and receive this ( image below )  when I test the email  ( just an FYI in case someone else tries this as well )

So far two customers setup SMTP relays and did not install the patch.

The relay seems to be working for them.

Sage provides two files as part of their 2018 secret patch/hot fix:

Copy the ChilkatDotNet47.dll to the Sage 100 Server's ..\mas90\home folder. This is a new component.
Copy the SY_EmailEngine.pvc to the Sage 100 Server's ..\mas90\SY folder, after renaming the original file.

I'm unsure if the ChilkatDotNet47.DLL has to be registered somehow. The above two lines are the only instructions supplied.
I did not register the ChilkatDotNet47.dll which might have been part of the problem





------------------------------
Wayne Schulz
Schulz Consulting
860-516-8990

There are no instructions in the file though it is named TLS_2018_8_ProgramFix.Zip

Unfortunately I update this customer to 2018.10 and then tried the install which produced the error.

I tried copying the program file to the local Sage folder but was waiting until everyone is done emailing to test.

Looks like maybe we will have to use an SMTP relay ( which I have not yet found a great source of instructions for IT on how to create  - though I did think this looked comprehensive - https://adamtheautomator.com/office-365-smtp-relay ) 

I wish Sage was more proactive on this and created an actual knowledgebase article 

There are no instructions in the file though it is named TLS_2018_8_ProgramFix.Zip

Unfortunately I update this customer to 2018.10 and then tried the install which produced the error.

I tried copying the program file to the local Sage folder but was waiting until everyone is done emailing to test.

Looks like maybe we will have to use an SMTP relay ( which I have not yet found a great source of instructions for IT on how to create  - though I did think this looked comprehensive - https://adamtheautomator.com/office-365-smtp-relay ) 

I wish Sage was more proactive on this and created an actual knowledgebase article 

There are no instructions in the file though it is named TLS_2018_8_ProgramFix.Zip

Unfortunately I update this customer to 2018.10 and then tried the install which produced the error.

I tried copying the program file to the local Sage folder but was waiting until everyone is done emailing to test.

Looks like maybe we will have to use an SMTP relay ( which I have not yet found a great source of instructions for IT on how to create  - though I did think this looked comprehensive - https://adamtheautomator.com/office-365-smtp-relay ) 

I wish Sage was more proactive on this and created an actual knowledgebase article 

There are no instructions in the file though it is named TLS_2018_8_ProgramFix.Zip

Unfortunately I update this customer to 2018.10 and then tried the install which produced the error.

I tried copying the program file to the local Sage folder but was waiting until everyone is done emailing to test.

Looks like maybe we will have to use an SMTP relay ( which I have not yet found a great source of instructions for IT on how to create  - though I did think this looked comprehensive - https://adamtheautomator.com/office-365-smtp-relay ) 

I wish Sage was more proactive on this and created an actual knowledgebase article 

Sage needs to get into this decade and support OAuth 2.0.   It makes emails sending way more secure and much faster and is super simple to setup for us IF, sage does the necessary API work on their end in the software.

This has been a general nightmare if any of you support things like multi-function office machines that let users send themselves or others scans by email.

SMTP is almost dead with M365 and as you can see is a real hassle to get working due to all the security up grades that have occured.

When proper developers support OAuth 2.0, things go so much smoother

Sage needs to get into this decade and support OAuth 2.0.   It makes emails sending way more secure and much faster and is super simple to setup for us IF, sage does the necessary API work on their end in the software.

This has been a general nightmare if any of you support things like multi-function office machines that let users send themselves or others scans by email.

SMTP is almost dead with M365 and as you can see is a real hassle to get working due to all the security up grades that have occured.

When proper developers support OAuth 2.0, things go so much smoother

Any thoughts on whether this v2018-specific fix can be tried on v2017 or v2016?  Easy-enough to first make a manual bkup of the 'mas90' folder, but who knows what gets touched outside of Sage 100 by running that .bat?  I'm just afraid we may not be able to simply revert back.

Sage needs to get into this decade and support OAuth 2.0.   It makes emails sending way more secure and much faster and is super simple to setup for us IF, sage does the necessary API work on their end in the software.

This has been a general nightmare if any of you support things like multi-function office machines that let users send themselves or others scans by email.

SMTP is almost dead with M365 and as you can see is a real hassle to get working due to all the security up grades that have occured.

When proper developers support OAuth 2.0, things go so much smoother

The only actions in the BAT (outside of privilege checks) are:

regsvr32 /u /s ChilkatCert.dll
regsvr32 /u /s ChilkatMail2.dll
regsvr32 /u /s ChilkatUtil.dll
regsvr32 /s ChilkatAx-9.5.0-win32.dll

So it's just the last file that is unique to the patch.  If things go sideways, to undo it, you can just:
regsvr32 /u /s ChilkatAx-9.5.0-win32.dll
regsvr32 /s ChilkatCert.dll
regsvr32 /s ChilkatMail2.dll
regsvr32 /s ChilkatUtil.dll

My uneducated gut reaction is to be more worried about the PVC than that DLL.

Any thoughts on whether this v2018-specific fix can be tried on v2017 or v2016?  Easy-enough to first make a manual bkup of the 'mas90' folder, but who knows what gets touched outside of Sage 100 by running that .bat?  I'm just afraid we may not be able to simply revert back.

Sage needs to get into this decade and support OAuth 2.0.   It makes emails sending way more secure and much faster and is super simple to setup for us IF, sage does the necessary API work on their end in the software.

This has been a general nightmare if any of you support things like multi-function office machines that let users send themselves or others scans by email.

SMTP is almost dead with M365 and as you can see is a real hassle to get working due to all the security up grades that have occured.

When proper developers support OAuth 2.0, things go so much smoother