opus:interactive | If These Servers Could Talk

Thursday, August 30, 2007 at 3:02 pm by Eric Hulbert

COM Object Issues on Windows 2003 (URLFetch)

With the passage of time, there is always technological challenges that crop up for existing clients, which is why as a managed service provider we step in to eagerly correct issues so our clients need not (after all, this is what they are paying us for.) These challenges manifest themselves either through user growth, hardware limitations or in worse case scenarios: hardware failures. Recently our monitors noticed that a five year old Windows 2000 Server was about to start digging a little virtual six-foot-deep grave and this is where we stepped into the challenge.

I quickly stabilized their old server allowing it to keep running while we worked on a migration to a new solution. While this was happening, Jeremy (our beef-jerky-loving sales representative) sold the client one of our new dedicated managed HP c-Class BladeSystem servers. The web server will be migrated to Windows 2003 and the SQL server migrated to SQL 2005 on Windows 2003 as well. Additionally, I replaced their old Cisco PIX 501 firewall.

After the migration of content, I began setting things up, including the VPN tunnels to the third party development company and the integration with the billing system. Once this was completed, I began full regression Quality Assurance.

After testing, it was quickly discovered that the integration with the billing engine was not working. The reason was the rather old code (Active Server Pages, ASP, version 3.0) which had been written by a third-party development company back in 1999. The code they produced relied on a component called URLFetch, which didn’t work inside of the new operating system environment.

Here is the particular code call:

This component is a COM Wrapper for a few lines of Java code that allow you to, basically, screen scrape sites and return them for use in the code. Since the billing system is on an internal network behind firewalls and a VPN, it can’t be served up direct to the end-user, so it has to be done from the code on the web server. Since this was an old component it was pretty much assumed that it wouldn’t work on Windows Server 2003 and IIS 6.

The research began about this component and the specific error that was being thrown by the code, which was:

I quickly found this Microsoft Knowledge base (KB) article and grabbed filemon from sysinternals to check it out.

Using depends.exe (from Dependency Walker) I looked into finding the missing .dll that I figured was trying to be loaded behind the scenes. This was confirmed and the missing dependent file was DWMAPI.dll.

From there a little more research uncovered another team having difficulty with the same situation. From this information the .dll was found and downloaded.

However, this new .dll didn’t produce results and I had to start again, from ground-zero.

It was at this point that I began to deduct that this old component would not work on the Windows 2003 and IIS6. We then contacted the client and gave them the harrowing news that the possibility that they may need to re-write their code existed. Even in the face of this possibility, we wanted to assure that all avenues had been explored and I continued researching. Next was to review the component itself and how it was written - to define what dependencies it required. This additional digging uncovered the following information:

This was the final ‘a-ha!’ moment. I then quickly downloaded the Microsoft Virtual Machine and voilà, it worked! (The new SUN Java SDK was already tried before this and it didn’t work.)

The end result: The client’s code now works great, on the new environment, with no need to update the code-base and I got to celebrate the moment with a Dr. Pepper.

Post Comment (1)