A blog with focus on experiences with the Windows Client operating systems…
RSS icon Email icon Home icon

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

    Posted on April 7th, 2011 By Andreas Stenhall + No comments

    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!