Hi Keith. Just want to confirm please, how are you running the sample created? I've created the vbs file and when I double click on it the error "ActiveX component can't create object" is displayed. Script only runs if I run it using C:\Windows\Syswow64\cscript.exe, it doesn't work when run through the System32 version. Just wondering how you ran your script so that I can simulate the same experience.

Thanks.

Hi

Yes, that's correct you have to use the Syswow64 script host to run VBS because Sage is 32-bit.

Best regards

Keith

Thanks Keith. I'll continue to have a look.

Hi

We're being asked by several customers now what the problem is and we haven't got many answers to give them.

We're a Sage ISV, so should I have logged this via the Sage developer's programme email address?

Anyway - I have new information.

I have now reproduced the problem on the one working PC that we have.  I have installed anti-virus protection ESET and now my script fails in the same way.

However, after disabling all protection in ESET anti-virus, the script still failed, which I thought was odd.

On further investigation, ESET has an "Advanced" section where I found something called SSL/TLS Protocol filtering buried deep in there.  Once I disabled that sub-feature (you'd have thought disabling the headline feature would have been enough!), the script worked once again.  It was also possible to change the SSL/TLS Protocol filtering to edit the list of applications being monitored.

I noticed SBDDesktop.exe was already in the list along with c:\windows\syswow64\cscript.exe.  Note that isn't a list of "blocked" applications, but rather a list of those where the SSL/TLS communication is being scanned.

I don't know where that leaves this problem.  Clearly there is something different where the AV software scans the TLS communication/certificate and for Sage desktop concludes the TLS communication/certificate is OK, whereas for SDO the TLS communication/certificate is not.

Please advise.

Best regards

Keith

Hi Keith.

Thanks for the provided info. I have looked further into this following the details you provided by running a VBScript and a .NET/C# app that both use SDO while ESET is running with SSL/TLS filtering turned on. The VBScript fail as you've experienced, however the .NET/C# app does not. This leads me to think the issue is not with SDO, but instead related to ESET and cscript.exe. I haven't been able to figure out why ESET is blocking cscript.exe but not other apps that use SDO.

You can keep the SSL/TLS option in ESET on, and tell ESET to ignore SSL/TLS filtering for the specific certificate that cscript.exe tries to use to communicate with the Sage 50 data service, using the following steps:

• From SSL/TLS section of ESET, change "SSL/TLS protocol filtering mode" from "Automatic mode" to "Interactive mode" (you can change it back to automatic later)
• Run your VBScript. You'll be prompted for few certificates that you can choose the "Scan" option for and leave it to "Ask every time"
• Eventually (or possibly at the start) you'll see a prompt similar to the image below. Choose "Remember action for this certificate" and click "Ignore"
• Turn filtering mode back to "Automatic mode".

When you follow the above steps the VBScript will initially fail with the same error, but subsequent runs will work once the Sage 50 data service certificate is added to the list of known certificates, which you can confirm is there by clicking "Edit" next to "List of known certificates" from ESET.

It's worthwhile contacting our Sage Developer support in case they've come across a similar issue in the past, no harm in doing so.

Hope the information above is useful.

Thanks.

I'm trying to set up a VBS with the same code as yours and test locally.  get-shareit.com  get-vidmateapk.com