I write a number of VBS scripts to help perform functions on servers. Some of these send me alert emails using CDO.
I have had no issues with VBS files and CDO access however I started compiling to EXE files and everything changed.
The VBS scripts either use:
set objMsg = CreateObject(“CDO.Message”)
.To = “email address”
.From = “email address”
……. etc …………….
Or more chaotically
Set objMsg = CreateObject(“CDO.Message”)
objMsg.From = “email address”
objMsg.To = “email address”
To send me the results of some test.
This has been working for ages, and continues to work however, someone pinched my code. I need to start protecting it. I can’t resort to compiling to vbe (Easily unencrypted) so I instead found a solution to compile to exe files.
The exe files worked for a while (over a year) and suddenly, they started failing.
They brought up “Error”, the line number that broke but no error description. The vbs files still work fine.
I looked at the line that fails.
It is the .To = “email address” or objMsg.From = “email address” in my above samples.
i.e. the line that tries to do the first action with CDO.
I tried all kinds of error trapping/reporting to bring up an error message. Nothing. It is as if CDO is not there.
But only for exe files ?
I tried making the exe file a trusted file. I allowed it through the firewall and tried loads of other actions and tests.
It does not work.
I ran filemon/regmon and process monitor and compared a working and failing server.
I wrote a test script that has about 10 lines and just tries to send an email. As a VBS, it is fine. As an EXE it fails.
These 10 lines created over 30,000 entries in Process Explorer.
Now started the long trawl through the output, comparing each section.
On the machine that works, the exe gets access to the registry, looks for the CDO handler for Win32, finds cdosys.dll and executes.
On the machine that fails, it looks for the win32 dll for CDO, falls back to win16 and then fails.
It seems some key information for CDO is missing in the registry.
I ran the vbs file. It looks for the CDO handler for Win64, finds cdoex.dll. It seems cscript and wscript want to use the Win64 registry key, not the Win32.
Now I see why the exe could potentialy fail and yet the vbs works. They access CDO via 2 different ways.
A little more research and I found that Exchange 2007 SP1 can loose the 32bit CDO reference.
All I needed to do was drop to a cmd prompt.
All fixed !