Script not sending email

Hi everyone, I created a simple script to pull a product key and then send me the email with the output. On the script output screen it shows me the Product Key and below it says “Call-SyncroApi: success” but I never get the email.

The script itself looks like this:

Import-Module $env:SyncroModule
(Get-WmiObject -query ‘select * from SoftwareLicensingService’).OA3xOriginalProductKey
Send-Email -To “” -Subject “Product Key” -Body “”

Also I checked the email logs and they’re not even hitting my server.

In Syncro’s Quick Help section it says:

#This will send you an email, no SMTP server required.
Send-Email -To “” -Subject “Test Subject” -Body “This is the body”

…so I’m not sure what I’m missing.

Any ideas?


I know the forum messes with the quotes… So, check that those are right.

This works for me:

Send-Email -To "$($targetEmail)" -Subject "Computer $($cName) is now online" -Body "This alert was sent from Synco."

1 Like

Thanks! I will give that a shot. May have to send an email to Syncro to update their documentation as well.

Hello All, I am having this issue as well @jeremy I tried your line but no luck. I am using Office 365 as SMTP server, does this have to do something with the issue?

This would be sending via Syncro so SMTP doesn’t matter. We use this in our online alert script and as of this morning, it was working fine.

Send-Email -To “your@email” -Subject “$assetname ($customername) is online” -Body “$assetname ($customername) is online”

Like Jimmie said, I don’t know why your SMTP settings/method would matter…

Try running a version as a test with no variable replacement and see if it runs. (Perhaps from more than one PC?)

Something like:

Send-Email -To "" -Subject "Computer DESKTOP-DKH397K is now online" -Body "This alert was sent from Synco."

Checked the SMTP Status with the above command and I am getting the following error.

SMTP Delivery Error: Net::ReadTimeout with #TCPSocket:(closed) Your SMTP server did not respond soon enough. Occasional longer running connections are tolerated in normal usage.

Hopefully you didn’t actually use

Not sure, I’m not using BYOSTMP, so something there perhaps?

:grinning: I was tempted to send an email to bill but no. I think BYO SMTP is the issue here since I am using BYO SMTP.

I have logged a request with support in the past but no response on this matter.

BYO shouldn’t matter. It’s not sending via your SMTP settings. All internal stuff like this gets sent out using Syncro’s servers. Ideally you’d think that Syncro would loop all internal stuff like this, but it’s actually running on the endpoint, so one can infer that the endpoint would have to be able to communicate back to Syncro/Syncro’s email server, not 100% sure how they designed it. You could try whitelisting to see, or run some internal test on different networks and see if the email fires off.

Looks like internal emails are coming from servers, so might be something to check into to see if something is blocked somewhere.

Thanks, I will look into this and update.

There is a very good chance that BYO SMTP could matter - because if you are sending out from your company domain, then it may be (correctly!) identified as Spoofing your domain, unless you have at minimum SPF set up properly.

Syncro’s Module function Send-Email still uses a Syncro API on the backend (“/api/syncro_device/emails/send_adhoc_email”) to send the email, which then would potentially use BYO SMTP if you have that set up.

Now, you could have the wrong type of SMTP connection set up - look through the different types of connections here How to set up a multifunction device or application to send email using Microsoft 365 or Office 365 | Microsoft Docs.

For example, if you had set up Option #2 - Direct Send then you would likely have problems with sending to people outside your O365 organization.

It is also possible that Syncro is not using the latest variety of TLS Settings - Office 365 changed their settings fairly recently, so that only TLS 1.2 or better is supported, and certain Cipher Suites have been removed to improve security. You can read more here TLS 1.0 and 1.1 Deprecation and here Preparing for TLS 1.2 in Office 365 .

If this issue is related to the TLS transition - then it is expected to have this fail most of the time and work on rare occasions. I can’t find my link to it, but Office 365 will be accepting a small percentage of these deprecated messages for delivery and increasing the amount of them it rejects over time, until all messages below TLS 1.2 are rejected.

This would not show up in your Exchange Transport or Message Trace Logs anywhere - because the message was never even accepted by Office 365.

Personally, I have looked at the SMTP Conversations that one app we support (Sage 100) has with Office 365 when it was hitting these issues, and it goes something like this

  • Hi I am Server “syncro”
  • Hi I am Office 365
  • I want to establish TLS (starttls),
  • Sound good
  • I support these TLS Suites and Ciphers
  • Office 365 dropped Connection

I could easily see that resulting in the error ReadTimeout with #TCPSocket:(closed) type message.
If this is what you are running into - support would need to be involved in fixing what TLS their sending servers support.

You could do some manual tests with Windows PowerShell’s Send-MailMessage to essentially replicate the BYO SMTP setup on the local machine and using IISCrypto to try various setups of enabled Client Protocols to see if it works.

And - it never hurts to make sure you have SPF, DKIM, and DMARC enabled and configured correctly! MxToolbox is my favorite way to test all of those in one place.