I'm been trying to get an old 32-bit service (.dll) of ours to run on a Windows 2008 (R1 and R2).
The service accesses a system-DNS for ODBC connection and secondly it performs some statistic HTTP calls with a normal WebClient request (sort of a PING function that reports data back to our service for statistics).
The only interface we have to see if this is running, is to see if the SQL spool/records changes with "LastUpdate" and from this I can conclude that "something" isnt working.
The service has been running smoothly for almost 8 years on Windows 2000 and Windows 2003 servers.
Now, as we are moving old servers into the cloud, I am trying to see if we can get this old friend to work too.
Somehow it doenst work. I've tried to look in windows-logs, checking for any sign of errors. But none found.
My guess would be that it just lacks some "rights" as Windows 2008 is more closed/secured.
Therefore I've also tried to make a "special user account" for this service only, and allowed the service to logon as account with access to desktop.
Currently I dont care how low security we have to make, as NOTHING works for me. I am testing this on a none-production server, so there is no problem with security - yet.
Does anyone have ANY clue of what I need to do?
What type of security rights, settings or policy am I missing?
I've been checking the threads about "32-bit on 64-bit" etc. no luck finding anything so far :-(
I'm lost...
IS the only way to get it running, to install and keep and old windows 2003 server in the cloud.. sigh ???
If it uses an ODBC DSN to connect, did you have to set this up manually?
It's worth noting that there are two versions of the ODBC admin console, one 32-bit and the other 64-bit. Data sources defined in one version do not appear in the other.
The 64-bit one is the default that gets opened via the Administrative Tools folder. The 32-bit one lives in
%SystemRoot%\SysWOW64
. Confusingly enough, both executables are calledodbcad32
.Try running the 32-bit console and defining the System DSN in there. It may be that your DLL is looking in the wrong part of the registry for the data source and not finding anything.