The updated Print Server MP has been released, update version is 6.0.6392.0
The monitors are loaded under the following classes:
Windows 2008 Print Services Role
The rules are loaded under the following classes:
Microsoft Windows 2000 Print Servers Installation
Microsoft Windows 2003 Print Servers Installation
Windows 2008 Print Services Role
Some initial musings:
1. This updated MP can *UPDATE* the previous conversion Print MP for 2000 and 2003. You don’t technically have to delete your old Print MP’s first – as the 2000/2003 components are still a conversion MP with a dependence on the MOM 2005 Backwards compatibility, and will upgrade your existing MP. HOWEVER…. there is an issue when upgrading the MP… if you do choose to upgrade, the print server views are not nested all under a single view tree, there will be a tree for 2000/2003, and then a tree which has 2008 under it. If you delete the old MP first, then import the new MP’s, all will be under a single view tree. This will be better if you scope views for specific operators, so I have to recommend skipping the upgrade, deleting your previous version MP, and importing these as new.
2. This updated MP still collects a LOT of Performance data out of the box, per printer. See Print Server management pack fills the Operational DB with TONS of perf data for ideas on turning this off out of the box unless you really need it – or consider overriding the collection to not be so frequent. If you have a lot of print servers with large numbers of queues, this could be more perf data than you really want to deal with. The cool thing is – the 2008 MP’s have resolved this, by disabling some of the perf collection rules by default, letting you enable them if you want, and the remaining enabled rules are set to "optimized" which will result in much less data insertions into the databases.
3. It does appear that while we have classes that discover all servers with the Spooler service running, we only apply rules to Windows 2000 and Windows 2003 server instances that have at least 1 *shared* printer. For instance – we don’t populate the "Microsoft Windows 2003 Print Servers Installation" or "Print Server" class unless the discovered instance have one or more shared printers. This is good and will limit the noise from the MP, as only shared printer queues would be typical for a print server.
4. The State View under 2000 and 2003 Print servers is not so good. It is targeting a class that doesn’t have any state… as there are no monitors targeting this class, so nothing would ever populate this view… and the default fields listed are not useful at all. I would be inclined to recommend ignoring this view, and creating a new one, targeting "Print Server" class – which actually has monitors targeting it – so it will show state.
Here is the default state view…. very strange:
This view doesn’t really tell us anything…. and while we could customize/personalize it to "clean it up" a bit…. it is still targeted to a class that does not contain any monitors, so it would never show state.
Instead – I decided to create my own view for 2000 and 2003 printers – and target the "Print Server" class. However – this failed with an error…. due to the "Print Server" class being flagged as "internal" only for some reason in the XML. The "Internal" or "Public" flag is a setting on a class that allows you to use that class outside of the MP it came from. A quick check using MPViewer shows us that it is indeed Internal. Since this is the only class that has monitors underneath it for 2000/2003 print servers, I don’t believe we will be able to create a simple State view here… we can use the Windows Computer Class and scope it to a group, however, this will include state from all kinds of monitors, and not just the print service. Best I can think of if you really need a state view for legacy print servers, and this is exactly how it worked in the previous MP. The 2008 specific state view is good and works well.
5. My Server 2008 Print server did not discover anything…. even after installing a local printer and sharing it. This is because the MP discovers the "Print Services" role in 2008, which I had not added. I think this is good – as only dedicated 2008 print servers would have this role added. Once I added this, and bounced the healthservice to speed up discovery on the agent, it popped right in.
6. The Legacy alert, event, and performance views for 2000 and 2003 aren’t working out of the box – probably because they are scoped to a class that the collection rules are not targeting. You can easily work around this by creating new views in your own MP – and scope the view to the "Microsoft Windows 2003 Print Servers Installation" class, or create a perf view that is un-scoped by class, but uses logic like "Object = Print Queue". You can do this for alert, event, and perf views.
A coworker here recommended a good workaround… to the Windows 2000 and 2003 Print server state view, that doesn’t work.
As I said previously – the problem is – the "Print Server" class has been flagged as "Internal" which means we cannot utilize it in other unsealed MP’s…. which is typically where we would place views. However – we CAN create custom views based on internal classes in "My Workspace"…. this will not throw the error about the internal class.
Therefore – browse to My Workspace, create a state view – target "Print Server" class with this view. Now – you will have a working state view for Print Servers:
Here is the list of monitors working under that class:
Honestly – this view isn’t super complex – because all that really affects this state view is the service monitor for print spooler.
You could potentially do the same thing – and actually have a working view in the console for everyone – by doing the following:
1. Create a new custom MP for custom print server rules/monitors/views.
2. Create two new State views, and target "Microsoft Windows 2003 Print Servers Installation" and "Microsoft Windows 2000 Print Servers Installation"
3. Create two new unit monitors, for the spooler service, and target "Microsoft Windows 2003 Print Servers Installation" and "Microsoft Windows 2000 Print Servers Installation"
That should produce pretty much the same result, and have a view for everyone. You could even continue to add more monitors under those same classes – to make the state more meaningful, if you knew some good performance metrics that described a print server that wasn’t healthy. This will create some duplicate alerts – so just turn off alerting on the new monitors – so they only affect state.