Thoughts from the EPS Windows Server Performance Team
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:
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
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...
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!
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.
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?
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.
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.