Case of “catastrophic failure” and error 0x8000ffff with Group Policy Preferences mapping printers

Mapping printers using Group Policy Preferences is a really nice feature and it is supposed to be working much better than using traditional scripting technologies. Let me tell you about an interesting day troubleshooting why printers didn’t want to map using Group Policy Preferences. In the logs it just stated “catastrophic failure” which does not sound good at all nor makes much sense.

Log Name: Application
Source: Group Policy Printers
Event ID: 4098
Description: The user 'X' preference item in the 'Y {3EE4E80F-17CB-4E56-9237-4FC8B9FA090A}' Group Policy object did not apply because it failed with error code '0x8000ffff Catastrophic failure' This error was suppressed.

Logging in as the user on another machine did not produce the same problem and the mapping of printers work fine, as did mapping the printers when logging in using an administrator account.

This got me thinking that I should try mapping a printer manually as the standard user so I did. It got me a “You do not have permission to use the selected printer” which made me turn to the classic tool Process Monitor and to start a trace. It didn’t take long to see that after filtering all logs for a result of “denied” resulted in the following line:

Operation: CreateFile
Result: ACCESS DENIED
Path: \\printserver\print$\w32x86\3\OPLO_UM.dll
Desired access: Generic Read

Note that CreateFile does not necessarily mean to create a file, it can mean “read file” as documented by Microsoft for the CreateFile function. 

So the conclusion was that after investigating with the printer department the printer share “print$” security permissions did not match the user and the user actually did not have read permissions to read the driver which is an absolute requirement for the printer to be mapped (as the print driver is actually installed when the printer is mapped).

Also one setting that affected the behavior was that one have to set “Run in logged-on user’s security context” in the Common tab of the printer mapping Properties. This is an essential part of the solution…

Case closed!

Split services for troubleshooting purposes

In Windows you might know that a lot of services do not run as separate processes, instead many of them are actually run within the famous svchost.exe processes. To see this in action just go to a cmd.exe and type “tasklist /svc” and it will list all processes and subprocesses. It might look like:

svchost.exe    AeLookupSvc, Appinfo, AppMgmt, BITS,
               Browser, CertPropSvc, gpsvc, IKEEXT,
               iphlpsvc, LanmanServer, MMCSS, ProfSvc,
               Schedule, SENS, SessionEnv,
               ShellHWDetection, Themes, Winmgmt, wuauserv

If you need to do some troubleshooting or investigate something related to a certain process that is running with other services you can split this service to make in run in its own process. This is done by using the command:

sc.exe config servicename wuauserv type= own

Which in this case makes sure that the Windows Update service (wuauserv) will be run in its own process, for you to troubleshoot. Set it back to its original setting by changing “own” to “share” in the above command. You can find more information about this in KB934650.

Case of the CHM files which give you “Navigation to the webpage was canceled”

Opening CHM (Windows Help Files) downloaded from the internet or from a network location will most likely give you “Navigation to the webpage was canceled” and it will refuse to display the contents of the help file. This is due to changes that were introduced some years ago by a security update, and this is the default behavior in Windows Vista and 7 (and their Windows server equivalents).

I experienced this case at a customer site and to resolve the problem you can follow the steps in MS KB article KB896054. However adding the trusted UNC path caused some problems in this case, as the UNC path was sort of hidden because the CHM file was opened from an embedded link within an application.

So to find the UNC path from where the CHM file was opened I had two choices, either to use the famous Sysinternals tool Process Monitor to trace the open file action, but I chose a quicker way. Opened CHM files are logged in a file called hh.dat which can be found at C:\users\\AppData\Roaming\Microsoft\HTML Help. This file, when opened with WordPad contains the path to the opened CHM file, which lead me to the key which was an important part of this solution.