Understanding Print Notifications in Windows Vista

Understanding Print Notifications in Windows Vista

  • Comments 6
  • Likes

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: HKEY_CURRENT_USER\Printers\Settings.  The two values are:

  • EnableBalloonNotificationsLocal
  • EnableBalloonNotificationsRemote

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: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionPipes.  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.
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Interesting post, Mick, but...  I'm a bit confused - perhaps you can clarify?

    >> What this is telling us is that the Vista client cannot access the communications pipe for the spooler for some file activity <<

    If Process Monitor was running on the server, I would interpret the log entry to mean that the spooler running on the server was not able to open the communications pipe \\vista\pipe\spoolss, on the Vista client.  This makes sense, since the registry modification to allow the access apparently took place on the Vista client.

    There also appears to be some discrepancy WRT the system the NullSessionPipes registry change was made on - first, the statement is made that "On the print server, we needed to modify the following Multi-string registry value", then another statement is made indicating the modification was made on the Vista client - "Once we performed this step on the Windows Vista machine,  print notifications worked fine."

    CC Hameed's EDIT attempts to clarify this ("The changes were made on the CLIENT (Vista) and not the Print Server."), but I think it would be desirable to edit the article to reflect the actual scenario...

  • Molotov -

    The edit error is my fault.  I missed one spot when I edited the article.  I've corrected the oversight.

    Thanks for pointing it out!

    - CC

  • Thanks, CC.

    However, I'm still a bit confused about the interpretation of the Procmon log entry, as noted in my initial comment...  Any clarification would be welcome.

  • hello,

    I would like to add myself to the procmon entry question.

    Why should I change the null-session settings on the Vista client? Is the connection done locally?

  • Molotov -

    The Procmon which was taken on the print server shows that it can't perform an activity on the Windows Vista spooler (\\Vista\pipe\spoolss) - that is why the change has to be made on the client side - to allow the print server to send the notification back to the client's spooler.

    - CC

  • Thanks for clarifying, CC - it appears somewhere along the way I missed an edit - "What this is telling us is that the Vista client cannot access the communications pipe for the spooler for some file activity" changed to "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", which makes more sense in the given scenario.