In-Depth
Printer Magic
You can do a lot with printers in Windows 2000. All it takes is a little sleight of hand.
YOU KNOW THE SCORE: Every time a new printer comes online, or a new user
walks into the office, it’s the same thing: You, the tech on the beat,
need to get that user connected to that printer. If the user moves from
one division to another or even from one floor to the next, it’s another
trip (or two) to the desktop.
Historically, to connect a user with a printer, you would walk up to
the user’s desktop, manually find the printer in Network Neighborhood
(or My Network Places) and make a semipermanent connection to the printer.
The good news is that if you use Roaming Profiles, this connection (theoretically)
will stay with the user when he or she hops from machine to machine.
The problems, however, are obvious. First, you should never, ever have
to trot over to the desktop unless absolutely necessary. Doing so the
first time may show off your magical abilities to your users, but repeating
tricks over and over for an audience diminishes the magic. Besides, making
a printer connection is simply not worthy of a “cube call.”
Can it be done? Let’s conjure up a couple different spells, er, ways
to get your printers and your users more in touch with each other.
Magic Trick 1: With a Little Help from AD
You can leverage Active Directory for the first piece of magic.
The main goal here is to make your users’ printers “self-sufficient.”
This will require a little work on your part and a little work on their
part.
For starters, you should get chummy with the concept of “publishing”
printers in AD. Publishing means that the printer’s attributes become
searchable in AD. Windows 2000 and Windows XP Professional users simply
do a Start | Search | For Printers to find all the published printers
in AD.
Printers attached to Win2K servers are automatically published because
they have the “List in the Directory” checkbox automatically checked,
as in Figure 1. Those attached to Win2K Professional clients are not automatically
published by default. In either case, it takes Server Operator rights
(on servers) or Power User rights (on Professional) to change the Published
status.
 |
| Figure 1. “List in the Directory” means to publish
printers in Active Directory. |
The best part about leveraging this new publishing ability is that Win2K
does some of the work for you. Specifically, when you load Win2K printer
drivers on your servers, some special attributes may already be filled
in for you. For instance, loading an HP color inkjet printer will automatically
mark the “Color” attribute set so users can search on it. The same goes
for printers it knows can staple or do double-sided (duplex) printing.
Now that your printers are set up, your Win2K and XP Pro folks can start
searching in AD. Simply perform a search via Start | Search | Printers
and click the Features tab, which exposes the special attributes. Click
“Find Now,” and you’re off to the races. But are you going to leave your
down-level clients behind?
You can help empower your Windows 9x and NT users to be printer self-sufficient
by installing the AD client, available at http://microsoft.com/windows2000/
server/evaluation/news/bulletins/adextension.asp. It has several benefits,
but we’ll just focus on the printer aspects. Specifically, it adds a feature
that allows users to use the new “Find Printers” dialog. Your Win2K clients
could do this all along. Adding the AD client to your down-level machines
puts them on an even plane, printing-wise.
Once loaded, the original user interface is changed so clients can search
for published printers in AD.
| More
Printer Magic |
| In "What's
the Problem?" in the July 2002 issue, Jeremy
shows a group policy loopback processing mode that can
be used to force all users on computers in an OU to use
a specific printer. |
|
|
Hinting at the Answer
Now your users can search for all printers in AD that meet certain
criteria—name, color and duplex to name a few. What if you have 15,000
printers scattered across your 200-building, multisite complex?
Yikes. You might have a problem—especially with the way most printers
are named. Sure, your IT department came up with a great naming convention,
but PRTHPLJ403 likely doesn’t mean much to Sally at the front desk.
All she knows is that she’s on the fourth floor of building 16 on the
East campus right here in Delaware and wants to print to the nearest printer.
You can enable Sally (and all your other users) to more quickly locate
the printers they likely care about—the ones right next to them!
Users are able to locate printers with this magic when:
- The user’s computer has a “location hint.”
- The computer’s subnet has a “location hint.”
- Each printer in the subnet that the user wants to print to has a
“location hint.”
If all the location hints line up, it’s printer magic!
To perform this trick, you’ll need to tell AD objects the location hints.
In order to do this, we’ll perform several steps as follows:
- Define your “location hint” strategy.
- Define AD sites and ensure each site has two or more subnets.
- Set a “location hint” for each subnet.
- Set a “location hint” for each printer.
- Set a “location hint” for each computer.
1. Defining the Location
Hint Strategy
The hints will come from you in the form of a naming convention.
Take the previous example for Sally. She’s on the fourth floor of building
16 on the East campus in Delaware. Working backward, this example could
use the following fields for your naming convention. Perhaps the fields
of {State}, {Campus}, {Building} and {Floor} are appropriate. Perhaps
your fields might be different. Think {Country}, {Province}, {Ship number}
or other physically separating boundaries. You can have hints up to 256
characters in a name, with 32 levels where the entire length of the hint
can’t be more than 260 characters. Simply concatenate the hints, in descending
order, with slashes between them, and you’ve got it! For Sally’s location,
her hint would be Delaware/East/16/4.
2. Make Site Definitions
You’ll need to ensure that you have AD site definitions for all
your physical locations. Recall that a site definition is a collection
of IP subnets defined with AD Sites and Services. Usually, you would only
need to have site definitions for your locations with domain controllers;
but if you’re going to do this trick, you’ll need to have a site definition
for every location with a networked printer and at least two subnets defined
for each site. Note that if you only have one subnet defined for a site,
this trick doesn’t work. The system thinks all the printers are local.
If all the printers are local, the system doesn’t bother to allow this
feature to become active.
3. Set a “Location Hint” for Each Subnet
Each subnet needs to correspond, roughly, to where these computers and
printers will find each other, as shown in Figure 2. In this example,
the 192.168.0.0/24 subnet corresponds to the fourth floor of building
16 on the East campus in Delaware. The 10.0.0.0/8 subnet here may correspond
to another floor in another building in the same campus.
 |
| Figure 2. Insert the “location hint” that corresponds
to each subnet. |
4. Set a “Location Hint” for Each Printer
Next, populate the printers in AD with “hints” about their location. To
populate the printers with the location hints, simply get the properties
of the shared printer and type the hint into the location field, as Figure
3 shows.
 |
| Figure 3. Insert the same location hint for the
printers on the subnet. |
5. Set a “Location Hint”
for Each Computer
Last on the agenda is to provide the same location hints to your
client workstations. You do this with Win2K Group Policy. First, round
up your workstations into logical groupings with Organizational Units,
say an OU called “Computers on the Fourth Floor of Building 16.” Then,
create a new Group Policy object there and call it whatever you like,
perhaps, “Enable Printer Hints.” Then, edit the Group Policy object and
drill down to Computer | Administrative Templates | Printers. You need
to enable two policies. First, enable “Pre-populate printer search location
text.” Then, Enable the “Computer Location” policy and type in the hint.
Voila!
Now, all computer users in this OU affected by this Group Policy object
will be sent the “hint” when performing a search on Printers, as seen
in Figure 4.
 |
| Figure 4. The dialog for “find printers” changes,
allowing users to browse by “location hint.” |
Users may even choose to click the new Browse button (which gets enabled
with this magic) to search for printers anywhere in the organization based
on the “location hint” mechanism.
Magic Trick 2: Batch File Wizardry
So far, all this magic is to ensure your users can be self-sufficient
and find printers near them. But what about ensuring that members of specific
security groups use the same printers? This way, if a user changes jobs,
and an administrator moves a user from one group to another, that person
gets the same printers as everyone else in the group.
To do this, you need two tools from the Win2K Resource Kit. One is called
IFMEMBER and the other is called CON2PRT. IFMEMBER can determine if the
user who calls the script is a member of a specific security group. Once
determined, you use GOTO statements in a batch file and call CON2PRT,
which will connect to the printer or printers that you want for the group.
CON2PRT is essentially a command-line version of the “Add/ Remove Printer”
wizard.
| Batch
File To Tie A Security Group Member to a Printer |
|
—-ITGROUP_PRINTER.BAT—-
\\dc1\netlogon\ifmember DOMAIN\ITGROUP
if not errorlevel 1 goto NOT_ITGROUP
\\dc1\netlogon\Con2prt /c \\w2kserver1\IT_PRINTER
EXIT
:NOT_ITGROUP
\\dc1\netlogon\Con2prt /c \\w2kserver1\normalprinter
EXIT
Note that, unfortunately, this trick won’t work
for your Windows 9x machines.
|
|
|
In this example, when people join the ITGROUP security group, they’ll
automatically get connected to \\w2kserver1\IT_PRINTER via the tools placed
in \\dc1\netlogon share. If they’re not a member of the ITGROUP, they
get attached to \\w2kserver1\normalprinter. Note, if dc1 goes down, this
process will fail. Consider copying the utilities local to the systems
and using local paths to execute the utilities.
Create Your Own Magic Kingdom
These tips should help eliminate most house calls you make for
printers. Use the “location hint” mechanism to help users manually locate
printers near them. Use the IFMEMBER/CON2PRT batch file trick to force
everyone in a security group to use a specific printer. Now get on out
there and make some “cube calls.” Maybe if you wave your magic wand, the
rest of your users’ problems will go away.