In-Depth

Printer Magic

You can do a lot with printers in Windows 2000. All it takes is a little sleight of hand.

• By Jeremy Moskowitz
• October 01, 2002

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:

1. Define your “location hint” strategy.
2. Define AD sites and ensure each site has two or more subnets.
3. Set a “location hint” for each subnet.
4. Set a “location hint” for each printer.
5. 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.