Issues copying fonts to the %FONTSDIR% on Windows Server 2008

[ChristianB]

OK...this is embarrasing! ...I started to go through the script line by line and guess what! ...the %FONTSDIR% has never been assigned any value at all! At least not now. In addition all the ocr files have been copied twice; both to the %SB_INSTALLDIR% and to the %FONTSDIR%. So to conclude: I assigned %FONTSDIR% = [FONTS] and "problem" solved!

The only remaining question is why the messagebox hasn't been shown when, for instance, installing on a regular Windows 7 machine. Life is a mystery!

[linder]

Hi Christian,

Don't use %FONTSDIR% = [FONTS] in your script. [FONTS] is a compiler variable that holds the name of the fonts folder from YOUR machine!!! But it's possible that your customers have another fonts location!!!

In fact, %FONTSDIR% is automatically defined by the runtime. See my previous screenshot. I did not assign any value in the script that generates the "fontsdir.exe" test application. And your event log clearly tells us that the runtime was unable to retrieve the fonts dir on your machine.

What do you see when you run my "fontsdir.exe" test app and what Fonts value entry do you see in your Shell Folders registry key?

Friedrich

[linder]

Hi Christian,

BTW, once I know your Fonts value entry from your Shell Folders registry key, I can tell you how to work-around this problem. Instead of using your %FONTSDIR% = [FONTS] "solution", you can simply read the fonts folder value from the registry. But before we do this, we have to make sure that the value is correct on those machines where the SHGetSpecialFolderLocation API (CSIDL_FONTS) fail.

Friedrich

[ChristianB]

Ok...well, I've attached the output from the fixdir.exe. As you see it doesn't work...regarding the Shell Folders registry key...seems it contains this:
#SYS:Microsoft\Windows NT\CurrentVersion\Fonts

[ChristianB]

Aaargh, a little too fast there! I guess this is the key you asked for:
HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\Shell Folders\Fonts

The value is: C:\Windows\Fonts

[linder]

Christian,

I Googled and found similar Server 2008 problems reported in our competitors online forums. If you are interested, I can send you such a link via private email. I don't want to post it here

To cut a long story short, it seems to be caused by a Windows bug because the SHGetSpecialFolderLocation API (CSIDL_FONTS) fails.

Two possible workarounds (see attached screenshots):

1. Check if %FONTSDIR% is empty and if this is the case, read the Fonts folder from the registry.

-or-

2. Check if %FONTSDIR% is empty and if this is the case, set the value to %WINDIR%\Fonts

Does this help?

Friedrich

[ChristianB]

Good morning Linder,

Ok, getting the registry key will work. I also tested the %WINDIR%\Fonts, and I must admit I haven't emphasized it, but this is on a Terminal Server (running on Windows 2008 server) so this last approach won't do it as this returns, for instance, c:\users\administrator\windows...

[linder]

Hello Christian,

Yes, absolutely. And that's why the correct way to retrieve the folder is via CSIDL_FONTS. The registry key is "suboptimal" because it might not even exist.

Taken from the TechNet Magazine "The Sad Story of the Shell Folders Key":

"...did you know that if you never open your Fonts folder, and if SHGetSpecialFolderLocation(CSIDL_FONTS) is never called, then there won’t be a Fonts entry in the Shell Folders key? Those entries are created only if somebody asks for them. No point setting up a compatibility hack until it is needed..."

BTW, to create Terminal server-aware installs, it's also a good idea to make use of the "TERMINAL_SERVER_AWARE" #pragma in SetupBuilder.

Friedrich

[ChristianB]

Looks like we have a stable and well-working setup on all platforms here now. Thanks for excellent support!


--
best regards,
Christian

[linder]

Perfect!!! Thank YOU, Christian

Friedrich