Hello AskPerf Readers. My name is Mick Bailey, and I am a Support Escalation Engineer on the Performance team in Texas. Recently I was working with a customer on an issue concerning print notifications for Windows Vista, and I thought that the information might be useful to some other folks out there.
One of the key pieces to remember about Vista print notifications is that regardless of what is configured on the print server, the setting on the Vista client is the one that will be honored. For example, if you have print notifications turned off on the Windows Vista client but enabled on the print server, then you will not receive print notifications. Conversely, if you enable print notifications on the Windows Vista client, but disable them on the server, then you will receive notifications. To change the setting for print notifications, select the Printers applet in Control Panel, select File –> Server Properties and then select the Advanced tab and change the selections in the “Show informational notifications for local printers” or “Show informational notifications for network printers” to suit your needs":
These settings are also controlled via the registry in the following location:
. The two values are:
Neither of the settings exist in the registry by default. When you modify either of the checkboxes above and click on either Apply or OK, the registry values are displayed:
OK, now that we know what we’re setting and where, this is where things get fun. In the specific issue I was working on, the customer was not receiving notifications even though they had the print notification settings listed above enabled. To troubleshoot the problem we captured a Network Monitor trace of the behavior and dug in a little deeper.
Print notifications are found in network traces as RFFPCNEX and NT Create AndX Response traffic. You need to check that this traffic is in the trace and does not have any “Access Denied” errors. RFFPCNEX is related to RpcRemoteFindFirstPrinterChangeNotificationEx for print notification process/communication. This is briefly described in an
MSDN Article on Network Monitor
. The article indicates that if you see the Access Denied errors in the trace that print notifications are disabled. However, this is actually misleading. If print notifications were disabled, you would not see the RFFPCNEX request in the network trace.
The NT Create AndX Response is related to the communications pipe that the notifications use. Below is a sample of what you might see in a network trace:
274 12:54:04.226086 Vista W2K3 SPOOLSS RFFPCNEX request
284 12:54:04.363198 W2K3 Vista SMB NT Create AndX Request, Path: \spoolss
285 12:54:04.365995 Vista W2K3 SMB NT Create AndX Response, FID: 0x0000, Error: STATUS_ACCESS_DENIED
301 12:54:04.441971 W2K3 Vista SPOOLSS RFFPCNEX response, Access denied
We also captured a Process Monitor log on the server and noticed the following:
9:51:07.7798830 AM spoolsv.exe 960 CreateFile \\Vista\pipe\spoolss ACCESS DENIED Desired Access: Generic Read/Write, Disposition: Open, Options:
Non-Directory File, Open No Recall, Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a
What this is telling us is that the print server cannot access the communications pipe for the spooler on the client for some file activity - specifically the print notification. It is important to note, that printing itself was not affected, only the notifications. Once we discovered this information, the fix itself was relatively simple. On the Vista Client, we needed to modify the following Multi-string registry value:
. We double-clicked on the value, and added a new entry as shown below:
When editing Multi-String values it is important to ensure that you do not have any trailing spaces, or additional carriage returns. Once we performed this step on the Windows Vista machine, print notifications worked fine. One thing to note here - this registry modification is not required by default to allow print notifications to work. A number of factors may result in requiring this change on the client - for example, the client and server might be in different domains, or the client may have had extensive security changes applied.
OK, that’s all for this post. Thanks for stopping by and have a great weekend!
- Mick Bailey
Share this post :
1/16: (CC Hameed) The changes were made on the CLIENT (Vista) and not the Print Server. My error in typing it up!
1/19: (CC Hameed) FYI - NullSessionPipes access for the Print Spooler was removed from Vista as part of the security hardening of the overall OS. You should carefully evaluate your system security before making changes to allow NullSession access.