Monthly Archives: September 2013

Group Policy Printers #4098 on SBS2008 Machines

I’ve encountered this Group Policy Printers #4098 message numerous times in my career – they’ve been an annoyance to figure out. I like my event logs clean with as few errors as possible. It lets me focus on more important things – let’s face it, we all hate milling through event logs.

The error message in reference is:

Evt-GPOPrinter-4098For reference, the error message roughly states:

The user ‘NAME OF PRINTER’ preference item in the ‘GPO Object NAME {GUID}’ Group Policy object did not apply because it failed with error code ‘0x8007007b The filename, directory name, or volume label syntax is incorrect.’ This error was suppressed.

If I go into the GPO object, I indeed see the name of the printer and if I copy/paste the UNC of the printer into Start->Run, I can open the printer. I should mention that this is a local printer to the server – it’s being shared with the network. And against best practices, SBS throws all users into the same GPO, so my customer created a GPO Object for all of them – including the local administrator account.

Ultimately, what fixed this for me was changing the Action field for each printer from Create to Update. Underneith the scenes, it’s trying to modify a printer that’s being locally shared on this machine already, so it’s failing with Create – but it works perfectly upon every login when set to Update. After forcing a GPUPDATE on the machine, logging off/back on, and even rebooting, I do not see the message recurring (with the administrative account in that OU, or out).


PERFLIB #2003 Errors

I see a lot of customer servers sporting PerfLib #2003 messages in their event logs:

What happens here seems to be updates (or reloads, or phase-changes of the moon) cause the following message:

EVT-Perflib-2003This means that the referenced DLL file sqlctr90.dll is not marked as trusted in the registry for the service named MSSQL$SBSMONITORING. This happens a lot on SBS boxes and is quite annoying.

The solution to this is to set the library to trusted using the lodctr.exe command. However, you’ll need to do this for the 32- and 64-bit subsystems as applicable:

c:\windows\system32\lodctr.exe /t:MSSQL$SBSMONITORING
c:\windows\syswow64\lodctr.exe /t:MSSQL$SBSMONITORING

Unfortunately, I can’t tell you how the 32- and 64-bit performance counter libraries work together, but I have noticed that for certain counter libraries, you need to set it as trusted using both 32/64-but versions of LODCTR.