• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    Printer Sharing

    There's a high level of "print rage" among users. I think this is because users think that printing is a trivial thing that any numbskull should be able to get working. They don't realize that network printing involves a complicated set of technologies with devices and drivers and interface boxes from a myriad of vendors.

    In this section, we'll take a look at how to configure network printing in Windows Server 2003 and how to avoid as much user wrath as possible by anticipating potential difficulties.

    Functional Description of Network Printing

    Figure 16.19 shows a diagram of a typical printing system layout. The fact that it resembles a game of Mousetrap is not coincidental. Rube Goldberg would have been astonished at the complexity of the transactions involved in turning a word on a screen to a word on a piece of paper.

    Figure 16.19. Block diagram of typical printing system arrangement.


    Here is the sequence of events when a user sends a print job to a Windows print server:

    • The user's application calls on Win32 to take the on-screen document and deliver it to the appropriate services for print rendering.

    • Win32 works with the Graphics Rendering Engine to turn the document into an intermediate format called a metafile that can be transported quickly across the network. The job is spooled both before and after this rendering.

    • The spooler hands the metafile to a network print provider, which then delivers it to the print processor service on a Windows print server.

    • The print processor service renders the metafile into a set of printer commands and saves that to a file, which is spooled to disk.

    • The spooler hands the file to a Printer Monitor service that delivers it to the print device.

    • The print device applies toner/laser/sublimated dye to paper/emulsion/coffee mugs and, like an egotistical actor, takes credit for all the work done by the rest of the system.

    Initial Job Rendering

    The transactions in a network print job are set in motion when a user clicks the Print button inside an application. What happens at that point depends on the platform and the type of application:

    • Native 32-bit Windows applications use Win32 API calls to render the page on-screen into a form that can be processed by a printer.

    • 16-bit Windows applications use Win16 API calls that are interpreted by the Windows16-on-Windows32 subsystem, or WOW, that converts them into the equivalent Win32 API calls.

      When Is a Printer Not a Printer?

      If you are unfamiliar with Windows parlance, the term printer can trip you up. A physical printer is called a print device. In Windows, a "printer" is a logical object, not a physical one. You create a printer by configuring a set of drivers at a server or workstation. You would say, "I created a printer on this server using the HPLJ8000 driver."

      The nomenclature becomes even more convoluted when you talk about devices such as the HP JetDirect or the Intel NetPro. These are often called "print servers," but in Windows, a print server is a Windows server that hosts a printer. Microsoft does not have a consistent term for a JetDirect or NetPro card. I will call them network printer interfaces.

    • DOS applications issue raw print commands. These are converted to Win32 API calls by the Virtual DOS Machine (NTVDM) driver.

    • UNIX/POSIX applications running under Interix in Windows Server 2003 issue shell commands that are converted into Win32 API calls.

    Itanium machines use Win64 API calls and have an additional emulator layer, Win32-on-Win64, or WOW64, that handles native 32-bit Windows applications. WOW16 and the NTVDM run inside WOW64.

    Because most of the system filenames were not changed when Microsoft wrote the IA64 version of Windows, it was necessary to put the 32-bit versions of the files in their own directory. WOW64 hides this directory using a file system redirector. When a 32-bit application accesses a system file, it is redirected to \Windows\SysWOW64.

    The Win32 API calls initiate a set of routines inside the Windows Executive that call on the services of the Graphic Device Interface, or GDI. As you'd expect from its name, GDI controls all things graphical in Windows Server 2003, both on the screen and for printing. It is one of the three key components of the Win32 subsystem. User and kernel are the other two.

    WOW64 maps the 8K memory pages used in the IA64 version of Windows Server 2003 to the 4K memory pages used by the IA32 version. This permits Win32 applications that do direct memory access to operate without compatibility issues. On multiprocessor servers with more than 32 processors, WOW64 also maps processor affinity for 32-bit application to maintain compatibility with the 32-processor limit of IA32 versions of Windows.

    The printing engine wants to give control of the application back to the user as quickly as possible, so instead of taking the time to completely render the job into printer control commands, it renders the job into an intermediate format called an Enhanced Metafile, or EMF. Each new version of Windows has its own metafile format revision. Windows Server 2003 and XP are up to version 1.008.

    Enhanced Metafiles

    When GDI receives a print job, it renders the job into an EMF file. By first building an EMF file, the system can quickly return control of the system back to the user.

    The EMF file is stored by the spooler while it waits for further processing. If the printer is located on a remote print server, the EMF file is sent across the network, not the fully rendered printer file. This conserves cycles at the client and bandwidth on the network.

    The EMF file does not contain actual print commands. Instead, it consists of a series of native GDI commands that fully describes the printed page. Some printers are built to understand this native GDI language, but most have their own language so that vendors can add value and differentiate their products.

    The EMF file is not completely independent of the printer driver. GDI needs general information about the printer so that it can design the page to match the printer's capabilities and specifications. For example, it would do no good to build a metafile with 1200dpi color output on an 11x17 page just to feed to a dot-matrix printer.

    Microsoft Printer Drivers

    A printer driver is required to convert an EMF file, which contains only raw GDI commands, into a print job containing printer control commands.

    GDI resides in kernel space. Starting with NT4, print drivers were required to live in kernel space as well so GDI could access them directly. This made NT-style printer drivers highly privileged, something many administrators found to their dismay as they tried to implement cantankerous drivers and suffered through blue screen stops, erratic performance, and data corruption.

    Windows Server 2003, XP, and 2000 finesse this problem by permitting a device driver to run in user space rather than kernel space. It took a long time for developers to learn the ins and outs of kernel mode writing, so they have not shown any particular eagerness to go back to user mode drivers. Microsoft dangles a carrot by offering more stack space, access to other device drivers, easier debugging, and better floating point performance in user space. It also wields a stick, warning that it may eventually stop supporting kernel-mode drivers.

    You could potentially encounter a problem when connecting to printers hosted by the IA64 version of Windows Server 2003. The IA64 printer drivers will work on IA32 versions of Windows Server 2003 and XP but not with Windows 2000. You will need to configure Windows 2000 printer drivers at shared printers on IA64 servers.

    Print Driver Group Policies

    You can get a head start on Microsoft by implementing a group policy in Windows Server 2003 and XP called Disallow Installation of Printers Using Kernel-Mode Drivers. The policy is located under Computer Configuration | Administrative Templates | Printers. If you set this policy, users and administrators will be blocked from installing printer drivers that contain kernel-mode DLLs. The error will state this clearly and prompt the user to contact an administrator to get approved drivers.

    Most printer drivers written by Microsoft and supplied with Windows Server 2003 have user-mode DLLs. The drivers are also digitally signed, indicating that they have been through logo certification. You can set a group policy to block drivers that do not have a digital signature. This also prevents Trojan horse programs from entering a system disguised as printer drivers. The policy is called Code Signing For Device Drivers. It is located in User Configuration | System. Enabling the policy blocks unsigned drivers.

    Master Printer Drivers

    The print driver design in Windows Server 2003 and Windows 2000 relieves a vendor of the majority of the coding work. Microsoft provides three master printer drivers:

    • "Universal" printer driver, Unidrv.dll. This driver handles raster printers that use some derivation of the HP Printer Control Language (PCL).

    • Postscript printer driver, Pscript.dll. This driver handles Postscript printers up to and including Postscript version 3 and Document Structuring Convention 3.1.

    • Plotter driver, Msplot.dll. This driver handles pen plotters and plotter equivalent printers using inks or electrostatics.

    These drivers are capable of handling just about any printer on the market. Vendors need only provide user interface plug-ins, rendering plug-ins, and one of the following types of printer data files:

    • Generic Printer Description (GPD) files. These are text-based files that deliver configuration information to the Unidrv raster image processor.

    • Postscript Printer Description (PPD) files. These are text-based files that deliver configuration information to the Pscript processor.

    • Plotter Characterization Data (PCD) files. These are DLLs that deliver configuration information to the Msplot driver.

    When you install a printer, the drivers are stored in the \Windows\System32\ Spool\Drivers folder. This folder is shared so network clients can download their drivers directly from the print server.

    Viewing Driver Details

    You cannot look at the driver files and tell the drivers associated with each printer on a server. You also cannot determine the driver versions, which is important to know if you have a driver that is known to cause problems. You can view details about the suite of drivers loaded for a particular printer as shown in Procedure 16.10.

    Procedure 16.10 Viewing Printer Driver Details

    1. From the Printers and Faxes menu, select FILE | SERVER PROPERTIES.

    2. Select the Drivers tab (see Figure 16.20).

      Figure 16.20. Drivers tab in print server Properties window showing the list of printers loaded on a print server.


    3. Highlight a printer and click Properties to open the Driver Properties window (see Figure 16.21).

      Figure 16.21. Printer Driver Properties window showing details about the drivers that are installed for a particular printer.


    4. To see the version of a DLL, highlight it and then click Properties and select the Version tab.

    You can also use this interface to remove a printer or change the driver.


    The Spooler service behaves like a school crossing guard watching over the hustle and bustle of print jobs going to and from the rendering engine, the disk, and the printer monitors on their way to the print devices.

    Spooler is a client/server system. The client portion, Winspool.drv, takes a print job from an application and delivers it to the server portion of the spooler, Spoolsv.exe, which contains the core spooler code. Spooler also accepts jobs submitted across the network via Win32spl.dll.

    You can stop and start this executable with the NET command. The syntax is net stop spooler and net start spooler.

    Spooler stores pending jobs in the \Windows\System32\Spool\Printers folder. It saves two files for each print job:

    • Spool file. These files have an .spl extension. They contain the contents of the print job itself, either the initial EMF file or the fully rendered job.

    • Shadow file. These files have an .shd extension. They contain information and instructions concerning the job, such as the destination print device, print priority, and originating user.

    Changing Spool File Location

    You can change the location of the default spool directory by following Procedure 16.11.

    Procedure 16.11 Relocating the Default Spool Directory

    1. Open the Printers window using START | SETTINGS | PRINTERS AND FAXES.

    2. From the menu, select FILE | SERVER PROPERTIES.

    3. Select the Advanced tab (see Figure 16.22).

      Figure 16.22. Print Server Properties window Advanced tab showing spool location.


    4. Under Spool Folder, enter the local path to the new spool directory. Ensure that proper access rights have been granted so that authenticated users can print.

    5. Click OK to save the change.

    6. Stop and start the Spooler service using net stop spooler then net start spooler.

    Print Processor

    Responsibility for generating a final print job based on the contents of the EMF file falls to the Local Print Provider, Localspl.dll. This driver combines the functions formerly performed by Winprint.dll, the print processor, and Localmon.dll, the local print monitor. (This change to the print architecture was made in Windows 2000 along with other changes designed to speed up booting.)

    One of the key functions of Localspl is to assign a data type to a job. This defines how the job will be handled as it is converted into printer commands. Ordinarily, you never need to worry about the data types. They are handled in the background and that's that. But one day you will try to print to a print server running Windows Server 2003 using a non-Windows client and if you run into formatting problems, you'll need to know how the data types are assigned so you can change them, if necessary. Here are the data types:

    • Raw. The print job has been fully rendered into native printer commands and requires no further processing.

    • Raw (FF appended). A form-feed command is appended to the end of the rendered print job. This is useful for DOS applications that don't kick out the final page after they finish printing.

    • Raw (FF auto). A form feed is appended to the rendered print job if one is not already present. Use this option if you get two blank pages at the end of every job. (The Help Desk call typically goes something like this: "We're printing a 300-page report and getting two blank pages at the end. We're tired of you IT people wasting paper.")

    • NT EMF 1.003, 1.006, 1.007, and 1.008 (Enhanced Metafile). These are EMF versions for Windows Server 2003/Windows 2000, NT4 through several service packs, and Windows 98. Earlier versions of Windows and NT 3.5x use Journal files, which cannot be sent across the network.

    • Text. This indicates a pure ANSI-compliant text job that contains no control codes. This data type should be assigned to Postscript jobs coming from UNIX clients.

    Localspl assigns data types to the incoming byte stream based on the criteria in Table 16.1.

    Print Providers

    Spooler also contains a router component, Spoolss.dll. The router decides which print provider to use for communicating with the printer service that eventually prints the job. Local print jobsЧthat is, jobs destined for locally-attached printersЧare handled by the Local Print Provider, Localspl.dll. This provider also handles print jobs destined for network print devices such as JetDirect and NetPro and Castelle boxes and cards.

    Print jobs destined for network print servers are handed over to network print providers, which are as follows:

    • Windows (SMB) Network Print Provider (Win32spl.dll). This provider handles print jobs destined for Windows-based print servers. For print servers running Windows Server 2003, XP, Windows 2000, or NT4, Win32spl sends the EMF file directly. Otherwise, it works with Localspl to fully render the job into printer commands prior to sending it to the server.

    • Internet Print Provider (Inetpp.dll). This provider handles print jobs destined for Internet Printing Protocol (IPP) print servers.

    • NetWare Network Print Provider (Nwprovau.dll). This provider gets jobs destined for NetWare print servers. The jobs get a RAW data type, meaning that the final rendering is done at the client.

    • UNIX print jobs. Jobs intended for UNIX hosts are handled by the Line Printer Protocol (LPR) provider.

    You can see both of these providers in the ADVANCED | ADVANCED SETTINGS properties window of the Network Connections window. Select the Provider Order tab.

    Table 16.1. Print Processor Data Type Assignments

    Job Source

    Assigned Data Type

    Windows Server 2003, XP, 2000, NT4, and Windows 98

    Data type NT_EMF of the applicable revision.

    NT 3.51, Windows 95, and Windows 3.1x


    DOS applications printing locally or across the network


    Macintosh clients printing to a Postscript printer on a server running Windows Server 2003


    Macintosh clients printing to a non-Postscript printer on a server running Windows Server 2003

    PSCRIPT1. This calls up a second-level print processor to render the Postscript job for a non-Postscript device.

    UNIX clients using l (as in Lima) parameter

    RAW. The l parameter indicates job contains printer control codes.

    UNIX clients using f parameter

    TEXT. The f parameter indicates non-printing control characters have beenfiltered out. This includes the ESC character, which causes incorrect printing by PCL printers.

    Port Monitors

    After a job has been rendered into native printer commands, Spooler hands it over to a port monitor. This is a user-mode driver that communicates with the print device via a paired kernel-mode device driver.

    For example, print jobs destined for a locally-attached printer on a parallel or serial port are sent to Localspl, which does double duty as a port monitor and the local print provider. If a job uses Printer Control Language (PCL), it is also sent through a Language Monitor, Pjlmon, for additional bidirectional print control. (PJL stands for Printer Job Language.)

    NetWare CAPTURE Command

    DOS applications often send print jobs that make certain formatting assumptions about tab length and end-of-page markers. In a Windows 9x environment when printing to a NetWare print server, these assumptions are handled by special options of the NetWare CAPTURE command.

    Windows NT and later do not support NetWare CAPTURE. If you have legacy DOS applications that do gymnastics with graphics that ordinarily require CAPTURE settings on a Win9x machine, test them thoroughly on Windows Server 2003 or XP to make sure you can get them to work before deployment. Your only option if they don't is to leave the client on the older Windows platform or retire the application.

    Print monitors are exposed to the UI as ports. For example, when you install a Universal Serial Bus (USB) printer, the Usbmon port monitor is activated and a virtual printer port is created at the USB interface.

    There are print monitors for network print devices, as well. For example, the Tcpmon print monitor controls jobs destined for TCP/IP-based network print devices. This is the default printer monitor for network printing. (The older Hpmon interface for DLC printing has been eliminated. DLC is no longer supported in Windows Server 2003.) The Lprmon print monitor handles print jobs destined for the LPD service on a UNIX host. There are also print monitors for fax printers, Internet printing, and for bus interfaces such as IrDA and FireWire.

    Final Print Job Delivery

    After the print monitor finishes delivering a print job, Spooler deletes the .shl and .spd files from the spool folder unless the printer has been configured to retain print jobs.

    During despool, Spooler keeps the SPL file locked but not the SHD file. If you kill a print job while it is printing, the SHD file may get deleted while the SPL file goes into limbo. From the printer window, you cannot delete the print job no matter how many times you click the Cancel option.

    If this happens, stop the Spooler service (net stop spooler), delete the SPL file manually, then start Spooler again. Pending print jobs are not lost if you stop the spooler. Jobs that are actively despooling will be interrupted. They will restart from the beginning after you restart the spooler. This might irritate a user who was three pages away from finishing a 500-page end-of-year financial report, so check the status of the queues before stopping the spooler.

      Previous Section Next Section