Why does the Print Management MMC snap-in report different printers when run from a workstation versus a server?

Greetings -

I'm having some inconsistency issues with the Print Management MMC snap-in that you can use to manage printers in a Server 2003 R2 environment.

When I run the utility from a workstation on my network with all the proper print servers added to the list, I see a certain number of printers.  However, when I run it from a server, under the same Domain Admin credentials, I see way more printers - and yes, the server list is the same inside the utility.

Why can I see some printers when running it from a server but not when I run it from a workstation?  Any ideas?

One piece of interesting data - when running the utility from a workstation, some of my print servers show NO printers at all.  I can't peg any consistency in OS level to this issue either.  One of my Server 2003 R2 SP2 boxes shows all its printers fine, another one shows none.  Again, this only happens when running from a workstation.  All of my printers always show up when running from a server.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

This sounds like a master browser problem.

The default configuration of the master browser is when the client sends a Netbios broadcast on UDP port 137 that says "I am here"  If there is any type of port blockage (Like different subnets, firewalls software/hardware, NAT, ect...), you will not get a full list of computers or printers in my network places. The domain master may be running wins or have access to all of these computers.

One thing that could happen is a client can do its broadcast and not see the domain master browser. Then, an election can be forced by that client. That elected computer could also not have a completely populated network browse list.

One thing you can do to overcome this problem is elect to use WINS instead of netbios broadcast to populate the domain master browser list. Each subdomain should, (to include workgroups), should have its own master browser that reports its section to the domain master. So, your clients may be seeing only certain section of the full browse list.

You might wint to disable port 137 firewall blocks and see if that helps. If you have domains on different subnets or ip spaces, you will have to use WIN to overcome a shortened browse list.
amendalaAuthor Commented:
ChiefIT - Thanks for the insight and I did a bunch of research and it doesn't appear that what I'm running into is a master browser or networking issue.

Let me explain what I've done and let me know what you think.  I appreciate the help.

I've been under the assumption for a while that this is an operating system specific issue.  The Print Management MMC snap-in works fine on Server 2003 R2 but when I put it on an XP Professional workstation, I can't see the complete printer list.

So I placed a brand new fresh-image XP Pro workstation on the exact same subnet with the same IP as the Server 2003 R2 box I was using for test.  I shut down the Server box to avoid an IP conflict, installed the Print Management snap-in on the workstation and launched it.  So what I have is an XP workstation that has the same IP, same Group Policy settings, same everything really as the server.

Low and behold when I launch the snap-in, same results.  I can only see about half the printers in my organization.  This leads me to believe it is not a network/WINS/NetBIOS issue.  The workstation is using the same cable through the same network path with identical IP settings and it can't pull the complete list.  And I'm using the exact same Domain Admin account.

Any further ideas?  Or am I off base on my thinking here?  Thoughts?  Thanks!
amendalaAuthor Commented:
One additional piece of information... there are certain servers in my list inside the snap-in that simply show NO printers at all.  The ones that do this are the same every single time one every XP workstation that I've run the snap-in from.

So there's consistency regarding which ones don't show printers.  But I'm having trouble pointing my finger at those servers because their printers appear just fine when I run the snap-in from a Server 2003 OS.  Just thought I'd point out that it's the same ones every time.
Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

amendalaAuthor Commented:
Okay, ignore that last comment.  Now one of the servers that never anything listed spontaneously populated.  So it appears moderately inconsistent.
My first guess:
I really want to say this sounds like a domain master browser conflict. When you took one server off line, it seems to have elected the other server as the domain master browser. It may have been a backup browser at the time of removing the other server.

I don't know how you are trying to connect to the printers. Are you using the netbios printer name? You could use a "local IP" port to manually populate the printer list and forgo any netbios translation.

The master browser has a separate nebios translation then DNS. Many feel DNS populates the browse list. It doesn't. If the domain master browser picks that up, it will be included that device in the browse list. If not, the client will elect a master browser. So, you may have a partial list of computers and printers if an election was forced and conflicting with the real domain master.

You should see event viewer, on the 2003 server, errors saying something like, "XXX computer thinks it is the master browser, an election has been forced and YYY computer browser has shut itself down the browser service."

Computers popping in and out of the browse list means a domain master has been elected and is interfering with the real domain master browser. Sometimes, this can be a mass storage device some node you wouldn't suspect. By default the domain master should be DC1, (with the FSMO roles).

On the computers with a partial list, you might want to check BROWSTAT and see who they are going to for a browse list.
My second guess:
With that said, there may be other things that are providing intermittant communications between the clients/printers and server. If you have dual nics or are running SP1 on the server, there are known issues that can flood NICs and give you intermittant communications with the server. The known issue with SP1 seems to be a common problem that many administrators don't suspect or are unaware of. However, problems of this nature would cause multiple issues, not just printer issues on the network.
Just thinking aloud:
I know this seems redundant. I just can't understand why printers, once configured, would pop out of the printer list. They should remain. When off line, they should grey out. You have me scratching my head on that one.

It also appears like you imaged machines. Did you sysprep them to provide a different SID than other the other clones? Duplicate SIDs can really hose things up.  
amendalaAuthor Commented:
Chief -

I just don't think I've provided you enough detail on how everything is setup.  Regarding the DMB, it hasn't changed.  The DC housing the PDC emulator role has remained the DMB throughout all this.

Printers themselves are not entering and leaving the directory.  The servers that they are hosted on sometimes show them in the Print Management MMC and sometimes not.  The printers themselves are never offline and have remained functional the entire time.  It's really an issue with the utility.

A Microsoft engineer that I spoke with in Redmond this morning confirmed the issue for me.  He said that they are aware of the inconsistent population issues that occur.

As well, I've learned that the snap-in does not manage printers that use kernel-mode drivers properly either.  Therefore, this thing really won't fit my business needs anyway... :)

Thanks for all the info.
amendalaAuthor Commented:
A Microsoft engineer has confirmed the issue to be one inherent in the utility's behavior.  It is a known issue.

The troubleshooting information provided here was very good, I would like to award some points for that but unfortunately I don't know how to do that without marking any of the responses as a "solution".
No need. I actually prefer you don't award points. I like to keep the EE database full of correct answers.

News on this discrepancy is what I look for. I like to be aware of signifigant issues with MS.

You said: "As well, I've learned that the snap-in does not manage printers that use kernel-mode drivers properly either.  Therefore, this thing really won't fit my business needs anyway... :)". Maybe there is some other print manager that will work for you.

I am suprised kernel mode drivers won't work with MMC. This is something new to me. Is Microsoft saying this floods the page pool or non page pool virtual memory and therefore floods the kernel with print traffic it can't deal with? Maybe going into a raw data mode will resolve this issue.

My reward is knowledge.
amendalaAuthor Commented:
I should clarify in that it isn't the MMC specifically that can't handle kernel-mode code interfaces, it's the Print Management snap-in specifically.  The issue related to kernel-mode instability is only in the localized state.  So when a user attempts to "manage" a kernel-mode print driver that is hosted on the same server, the GUI and management interface will come up fine.  In other words, you right-click on a printer installed on the same server on which you're on using the Print Management snap-in and everything will come up just fine.

However, when you attempt to manage a printer that uses a kernel-mode driver on a remote server (one of the core duties this snap-in was designed for), the Print Spooler service may crash unexpectedly due to a buffer overflow and in some cases, page out of bounds and thow either a KMODE_EXCEPTION or IRQL bugcheck.  The reason for this is in the packaged driver replication that Windows does when you select the remote printer.  The "core pieces" if you will of the driver are copied to the local machine where the snap-in is running, instantiated, and displayed to the user so he/she can manage the device.

The sad part is, it is well-documented by Microsoft in the WDM specs that print drivers, and these days, very very few drivers in general should have any kernel-mode code at all - everything should be user-mode if possible.  The performance and development overhead this implies is minimal compared to the massive increase in reliability and security.  That being said, manufacturers such as HP (whom I love), Canon, and others still continue to produce a portion of their print drivers that run have a strong base in the kernel-mode environment.  Not good.

So it isn't every driver from HP or Canon that'll do it, but it's enough of them that we're seeing here.  Some detailed use of Process Monitor reveals this situation...  <shrug>

The engineer in Redmond that I spoke with informed that these issues are remedied in Server 2008's version of this interface.

Everything above only covers the issue I ran into when running the snap-in from a member server.  When running it from a workstation, I still have issues seeing everything - I'm going to let that one go as it too is supposedly a "known" issue - though like you, I can't figure out what it's doing.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
amendalaAuthor Commented:
CORRECTION: The issue related to kernel-mode instability is only in the localized state.

SHOULD READ: The issue related to kernel-mode instability is only in the remote state.
Closed, 500 points refunded.
Community Support Moderator
Can this Print Management application be run as a service?  Can the application be exported to be used as a service on another W2K3 SP2 server :  Presently only I can see the filters that I have created and my coworker can not see them.  Additionally, if this were to run as a service, then I wouldn't have to be concerned about leaving a server console open so that the application could properly report changes.


Jay K.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2003

From novice to tech pro — start learning today.