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

[ChristianB]

Hi all,

our setup includes a few OCR-fonts which are copied to the %FONTSDIR% directory. The code generated in the script for each ocr font file is:

Install File "R:\OurPath\OCRB.ttf" to "%FONTSDIR%\OCRB.ttf" (Always install)

On the "ordinary" versions of Windows (XP, Vista, 7) this works very well, but when running the installation on Windows Server 2008, the setup stops and prompts the following error message (seems to be the xxxx_ERR_DIR_NOTWRITABLE): "The target directory %s is not writable or accessible. The installation cannot continue". Note also that the "%s" expression isn't replaced by anything so we can only see two spaces between "directory" and "is not". Behind this messagebox the "file copy progress" is shown and the file name being copied at the moment this fails is the OCRB.ttf font.

PS:
- This fails instantly on the first of the three font files in our script
- The %FONTSDIR% directory is certainly not read-only - e.g we are allowed to use a DOS-box and create/delete folders in the %FONTSDIR%.
- The user logged into our server running the installation is the administrator and the setup is also "run as administrator".

Would really appreciate some input on this matter! :-)

[linder]

Hello,

That means that for whatever reason, the value for the %FONTSDIR% variable cannot be set at runtime in your case. The installer retrieves the fontsdir value by calling the SHGetSpecialFolderLocation API (CSIDL_FONTS).

HTH,
Friedrich

[linder]

By the way, I have created a small test script and tested it on our Server 2008 (see attached screenshots).

It correctly displayed C:\Windows\Fonts as writable.

Friedrich

[linder]

What you can try is to run the setup.exe in event logging mode (e.g. setup.exe /E) and then check the c:\sbevents.txt log. If the SHGetSpecialFolderLocation API fails then you should see "empty" {FONTSDIR} and %FONTSDIR% items.

|01/31/2012|11:42:12.554|Set Variable {WINVER} to 2048
|01/31/2012|11:42:12.554|Set Variable %WINVER% to 2048
|01/31/2012|11:42:12.554|Set Variable {CURLNG} to 1033
|01/31/2012|11:42:12.554|Set Variable %CURLNG% to 1033
|01/31/2012|11:42:12.554|Set Variable {WINDIR} to C:\Windows
|01/31/2012|11:42:12.554|Set Variable %WINDIR% to C:\Windows
|01/31/2012|11:42:12.554|Set Variable {SYSDIR} to %WINDIR%\System
|01/31/2012|11:42:12.554|Set Variable %SYSDIR% to %WINDIR%\System
|01/31/2012|11:42:12.554|Set Variable {SYS32DIR} to C:\Windows\SysWOW64
|01/31/2012|11:42:12.554|Set Variable %SYS32DIR% to C:\Windows\SysWOW64
|01/31/2012|11:42:12.569|Set Variable {FONTSDIR} to C:\Windows\Fonts
|01/31/2012|11:42:12.569|Set Variable %FONTSDIR% to C:\Windows\Fonts

Friedrich

[ChristianB]

Ok, here's the output from sbevents.txt in my case. As you wrote the value for the fonts directory isn't retrieved:

|01/31/2012|12:41:02.993|Set Variable {FONTSDIR} to
|01/31/2012|12:41:02.993|Set Variable %FONTSDIR% to

...so, what does this mean? :) ...i guess i can manually test for server OS and eventually set the %FONTSDIR% by myself?

[linder]

The one million dollar question is, why does it fail on your machine ;)

IMO, it does not make sense to test for the Server OS because it works without any problem on Server ;) We have four Server 2008 machines here in-house and of course, it works without any problem. And most of our Script Writing Consulting projects install fonts on Server 2008/R2 and it never failed (with tens of thousands installations). I checked our bug reporting system and not a single report. So I "think" it's specific to your machine. But the question is why does the standard SHGetSpecialFolderLocation API (CSIDL_FONTS) fail for you.

Friedrich

[linder]

What you can try is to check if %FONTSDIR% is empty. If this is the case, retrieve the value of the virtual fonts folder. I can't say for sure if this will work as expected because I have never seen an empty %FONTSDIR% variable.

Friedrich

[ChristianB]

The one million dollar question is, why does it fail on your machine ;)

IMO, it does not make sense to test for the Server OS because it works without any problem on Server ;) We have four Server 2008 machines here in-house and of course, it works without any problem. And most of our Script Writing Consulting projects install fonts on Server 2008/R2 and it never failed (with tens of thousands installations). I checked our bug reporting system and not a single report. So I "think" it's specific to your machine. But the question is why does the standard SHGetSpecialFolderLocation API (CSIDL_FONTS) fail for you.

Friedrich


Hehe, the problem is reported from some of our customers installing on their servers but we weren't aware of the problem until we tested it on our server earlier today. :)

[linder]

Hi Christian,

;)

So the attached test application does not display a valid fonts folder on your machine, correct?

Friedrich

[linder]

And if it does not display a valid fonts folder, what Fonts value entry do you see in your Shell Folders registry key?

Friedrich

[ChristianB]

OK...this is embarrasing! :o ...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! :D

[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