0

I have a legacy ASP website with COM object running under IIS 7.0 on Windows Server 2008. This generally works great but I ran into a rather strange issue lately for which I'm unable to find a solutions.

There's one page that calls into a custom made COM object (VB6 code, yeah, I know) that calls into a 3rd party graphics rendering COM object. After testing we found that this code works fine under Windows 2003 and IIS 6.0 but it doesn't under Windows Server 2008 and IIS 7.0. The problem is that the 3rd party render engine does not use the proper (custom installed) true-type font and seems to use a default font.

When the code from the ASP page is run as a VBScript file under an Administrator account the rendering does use the correct font. So you might think it's a permission issue. However, when I run the VBScript under the same account that the website and IIS application pool is running under, the correct font is used as well. So only when the code runs under IIS 7.0, it doesn't render with the correct font. If it runs from a CMD box under the same account as IIS is using, it renders correct.

The account that IIS is using is a custom created account (not NETWORK SERVICE) with very little priviledges, however enough to function. The website has been running for years also using 3rd party COM objects. It's the first time an issue like this has come up.

I thought that permissions on the font might be an issue, although that would not explain why it would work outside IIS. To make sure it's not part of the problem I've given the Everyone group read permissions on the specific font. This did not solve the problem.

Taking all of the above into consideration, I think my question comes down to what is IIS doing differently that might cause the code to fail to use the correct font. I know that IIS 7.x is automatically putting the application pool account into the group IIS_IUSRS before it launches the application pool. But I already manually added the account to that group so also when I run the VBScript from a CMD box under that account, the account is also part of the IIS_IUSRS group. So that should be the same.

I'm running out of ideas how to solve this. Any ideas, tips or suggestions are welcome.

2 Answers 2

0

I've managed to solve this issue a couple of weeks ago and will answer my own question for future reference, having just received an e-mail from a fellow Superuser user having similar problems.

The problem seems to be very specific to just Windows Server 2008 possibly due to a bug in this version of Windows. The font was an unknown custom font bought from a small font creation firm. We had already requested a new version of the font and already tried loading it up in a few font editors and re-saving it but to no avail.

Eventually a little freeware font editor called Type Light from CR8 Software Solutions managed to fix the issue. Loading the font in this editor and saving it out again fixed the issue on Windows Server 2008. Since then we can use the font like any other font.

0

I know you found a solution, but I had a very similar issue to yours (running an application through a scheduled task would use the default font but when running locally it would find the custom font I installed) and I found a different solution; On Server 2008, there is an issue where custom fonts are not registered immediately after installing for non-interactive users, whereas regular users (i.e. when running on a user actually logged in to the machine) do have the font registered immediately.

The solution that worked for me was to simply restart the machine the font was installed on and the font started working under the non-interactive accounts, as when the computer is turned on it registers correctly. It appears the font installation has a bug where it doesn't register the font correctly for non-interactive users until a reboot.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .