Update 2012-01-11: There is now a hotfix available for Windows 7 / Server 2008 R2 to address this issue – KB2647169
Update 2012-02-16: The above hotfix has now been extended to cover Windows Vista / Server 2008
A customer had a case recently where a Windows Server 2008 x86 SP2 server had Office 2003 and Internet Explorer 9 installed, and when users in TS sessions try to print HTML format emails from Outlook, the following error is displayed:
Line: 2053 Char: 1 Error: The system cannot find the file specified Code: 0 URL: res://ieframe.dll/preview.js
Plain text, and RTF format emails print just fine – the problem is specifically HTML format (which makes sense as this would invoke the HTML rendering engine shared with the OS and IE).
Others have reported the same issue on Windows Server 2008 R2 in RDS sessions, and only after upgrading from IE8 to IE9 – so on the surface the problem appears to be with an IE component, however that’s actually not the problem here…
First, what file is it that the system cannot find? Here’s how we find out…
First, download Process Monitor.
Next, start Outlook 2003 and open an HTML format email so you are ready to repro the problem.
Now start Process Monitor so we are logging all I/O events.
Now click the Print button on the Outlook toolbar and get the error up. TIP: Don’t clear the error message by clicking OK – this will just generate more activity and we’ve already recorded the problem.
Now switch to Process Monitor and stop it recording, then filter on Process Name = OUTLOOK.EXE.
Filter out all but file I/O events to reduce the list, and use a highlight rule for Result = NAME NOT FOUND.
Scroll down the list and you can get an idea as to what Outlook is doing as it renders the elements of the mail in the Temporary Internet Files folder in the user profile.
The actual files created will vary, as the mail content and name for the cache folders will be unpredictable, but you will see a pattern of checks to see if a file exists (NAME NOT FOUND, highlighted), then afterwards a series of events for the same path where the file is created and written to, then closed.
At some point down the list you will see a NAME NOT FOUND for a path ending with \Windows\Fonts, and there is a series of successful I/Os that follow – the events after here are actually handling the script error.
The problem is that the process is trying to open a folder that does not exist – so the solution is to create this missing path (the folder does not need to contain anything). NOTE: There may be side effects of creating this folder and not having it populated.
The path to the folder is %HOMEDRIVE%%HOMEPATH%\Windows\Fonts, and for most users this translates as C:\Users\%USERNAME%, but if the AD user object has a home folder specified then this will be a UNC path.
So now we know what is missing and how to work around the problem – but why does it happen, and why only when IE9 is installed?
IE9 had a design change in how its invokes printing APIs in the OS – the XPS component is now involved.
IE9 itself does not have a problem printing, so why do applications such as Outlook 2003 suddenly get issues? This is because the application is not “TS aware” and so its API calls are marked as such, leading to an incorrect code path being followed when trying to enumerate the path to the fonts folder. If the application was marked as TS aware then the system fonts folder is used (%SYSTEMROOT%\Fonts) and there would be no problem.
NOTE: This is not the root cause of all scripting errors, or even all errors thrown by preview.js, it is just one specific symptom tied directly to the presence of an IE version after 8.0, and only in TS/RDS scenarios.
Could we use Group Policy Preferences to create the folder?
"Run in logged-on user's security context"
Yes, that should work fine - though I'd be tempated to use Replace mode (so it can be removed when the GPPrefs policy no longer applies to ther user), and create "%HOMEDRIVE%%HOMEPATH%\Windows\Fonts" so it works regardless of local or remote home folder location.
Thank you so much! This helped me immensely!
The hotfix linked here doesn't seem to work for me even though the workaround does. Has anybody else had issues with the hotfix?
I've tried installing it several different ways, but it only ever seems to correct the issue for the user I installed it as. I've tried it as a Domain Admin, Local Admin, and with plain user accounts.
The workaround requires me to put the folder "fonts" into the "WINDOWS" folder on every users local profile. Since we use remote desktop roaming profiles and a server farm of five servers, that is a A LOT of folders. Does anybody know how to get the Hotfix to work?
Is this W2K8R2 RTM or SP1?
What version string do you have for xpsprint.dll?
The RTM LDR version is 6.1.7600.21097
The SP1 LDR version is 6.1.7601.21866
Version is SP1. To confirm I verified that the file xpsprint.dll is version 6.1.7601.21866
Strange, I've not seen any reports of it failing for others.
The bit that concerns me is this: "...it only ever seems to correct the issue for the user I installed it as" - the hotfix is repalcing a DLL, and as such is not user-specific in any way so should either work for all or no users, so long as this is the problem being hit...
I would start by looking at what Process Monitor records for a user who does _not_ have the workaround in place does but does _not_ have the problem - is there any I/O towards the Windows\Fonts folder in the user profile folder?
It seems I've actually given you some false information. Further testing reveals that administrator account can print no matter if the hotfix is installed or not (something I'm almost certain I wasn't able to do before I installed it the first time), and user accounts cannot print regardless if the hotfix is installed or not. I had actually forgotten to delete the "Fonts" folder for the user I was testing the hotfix on, which is why I thought it had worked for that user.
So basically, it hasn't fixed the issue for users. I'm going to try it on a different server today just in case. Any other information I can provide you with?
I'd still be going back to Process Monitor - the symptom described & addressed by the hotfix is not related to permissions or privileges but the presence (or more correctly, absence) of a folder in their profile so should affect standard or administrative users alike.
I would set up a brand new standard user account and repro the problem while recording with ProcMon, then make them a member of Administrators, log off & on again and repeat the test (now successful according to your comments above) and compare the difference.
In particular, the call stack of the event in Process Monitor (with symbols configured) where the access to %HOMEDRIVE%%HOMEPATH%\Windows\Fonts is attempted would be an interesting place to look.
It it worth noting that, at least in my case, the %HOMEDRIVE%%HOMEPATH%\Windows\Fonts needs to exist before the user logs in. I logged in and created the folder, but the fix did not work until I logged out and back in again.
So it seems we have this same issue.
Windows 7, IE9, Outlook 2003.
I our case we were able to get it to work it we select the Printing in plain text only option as a work around.
We also noted that we were able to print to our Konica Copier and can also print to an HP CM1420 using the PCL driver but not the HP4250's.
Seems it may be a driver issues here.
I created the aforementioned folder through policy, and it has corrected the problem. Screenshot in link: http://prntscr.com/h37qh
@DAN k --your picture is missing. Please give us proper snapshot so that we easily correct this problem
I tried installing the hotfix on our 2008 r2 terminal server and it didn't resolve the issues with HP Universal Print drivers and html printing. The fix was to manually create the folder \WINDOWS\Fonts under the user's roaming profile. As mentioned above
user needs to log off and log back in for it to take effect. Works great!