0

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 ???

BerggreenDK
  • 188
  • 9
  • 2
    My first step would be to try on Windows Server 2008 x86 and see if it works there. If it **doesn't** work, then you know the problems are necessarily related to the architecture. – Dan Apr 30 '12 at 11:22

1 Answers1

3

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 called odbcad32.

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.

Chris McKeown
  • 7,168
  • 1
  • 18
  • 26
  • I did set it up manually, but I didnt know about the two versions. I'll have to check upon that. Great advice. – BerggreenDK Apr 30 '12 at 11:57
  • Btw. since my intial post I've been able to see the custom logfile (from the service) is actually working (I am logged in as the user account I've created for the service). I've also tried to have a look on the SQL database as its moved from an old SQL 2000 to a SQL 2008 express (the database is only around 10 mb) – BerggreenDK Apr 30 '12 at 11:58
  • aaah, the first R2 server (64-bit) didnt have this configured, but now it says: "TESTS COMPLETED SUCCESSFULLY!" in the ODBC in Wow64... good! The other one, which I posted above is a 32-bit server (win2008 data center) to see if 32-bit OS would make any difference. – BerggreenDK Apr 30 '12 at 12:06
  • Thanks for your help man! I found the reason. I tried to make a "user" account with the name of the service + using Windows authentication for the SQL-connection in the ODBC - and using the WoW64 version ... NOW it works HURRAY!!! – BerggreenDK May 02 '12 at 17:42