[Solved] Working exe throws comerror on a different pc

[Dionysis]

tldr: I have a compiled AutoIt exe which uses Jos' _INetSmtpMailCom() UDF. It works as expected in 5 PCs with Windows 10 for about a year, now I set it up on a laptop with a fresh Install of Windows 10 and all the needed programs and it throws a com error 0x8002009 with description "The transport failed to connect to the server.". Everything works up until the point where the e-mail is to be sent ($objemail.Send ), with this I mean that the e-mail is composed correctly and saved in a file.

The application reads a tab separated text file that is provided by the user, connects to a database to get additional info and composes a plain-text e-mail that is sent using _INetSmtpMailCom UDF.

The _INetSmtpMailCom is slightly modified to support STARTTLS as it's used with a microsoft account. I just added this line:

$objEmail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/sendtls") = True

 

In this post for the same error number it was suggested to check the TLS version supported in internet properties, in my case this was correct.

I found that com error 0x8002009 is just a generic error in windows: DISP_E_EXCEPTION - "Exception occurred".

Overall, every solution I found either addresses a server-side problem, is specific to a different language e.g. "include typelib in VBS" or addresses problems in a code that is not working. Also, most of them are at least eight years old.

 

I didn't include any code in the post as I think that the problem is in the configuration of the laptop, not in my code, because it is used everyday for about a year and it works as expected on the other PCs.

Did something like this happened to you? Do you have any ideas what else should I check?

 

Some history:
The error 0x8002009 "The transport failed to connect to the server." is the second error in line, I ended up here after fixing the previous error 0x8002009 "The requested body part was not found in this message." that was due to the region language being "English (Europe)", a format that older windows editions didn't have so CDO.Message didn't take it very well. Now the laptop has the same region language as the other 5 PCs.

Edited March 27, 2020 by Dionysis

[Danp2]

Are these machines in the same network? If not, then maybe the laptop is behind a firewall or there is some other ISP-related restriction preventing the connection from occurring.

Have you tried using telnet to connect to the remote server?

[Dionysis]

@Danp2 The 5 desktops are in the company LAN and active directory, the laptop is connected to the company LAN through VPN and also connected to active directory.

Can I telnet smtp.office365.com? I'm not familiar with telnet.

I installed telnet from windows features and tried

telnet smtp.office365.com 25

telnet smtp.office365.com 587

and

telnet -l username@customdomain.com smtp.office365.com 25

where "username@customdomain.com" is the mail address that the _INetSmtpMailCom() uses to log into the smtp.office365.com server, I used port 25 as this is what works in the function. I also tried port 587.

All returned "Could not connect to smtp.office365.com server".

I don't have access to the other PCs at the moment to check if those can access smtp.office365.com through telnet.

[Danp2]

Check out this guide from MS -- https://docs.microsoft.com/en-us/exchange/mail-flow/test-smtp-with-telnet?view=exchserver-2019

[Dionysis]

I got access to one of the other PCs.

It turns out that

telnet smtp.office365.com 25

should work...

I'm looking into it...

[Dionysis]

Finally, it was a problem with the VPN, it blocked port 25.