The Complete Windows NT & UNIX System Administration Pack By O'Reilly, et al. 1st Edition August 1998 HPPACK, Order Number: HPPACK

Table of Contents
Filesystem Integration from Windows NT and UNIX Intergration Perspective
Resolution from Understanding Domain Name System (DNS)
Maintaining and Troubleshooting WINS from Using the Windows Internet Naming Service (WINS)
Windows NT Scripting Language from Windows NT Desktop Reference
Using NT as a Multiprotocol Print Server from Windows NT Tips & Tricks
DES from Cryptography from a UNIX Perspective
Security Monitoring from Network Security
Optimizing Network Performance from Monitoring & Optimizing Server Performance
Advantages Offered by the Registry from Windows NT Registry Nuts & Bolts
Planning DHCP for Large Networks from Dynamic Host Configuration Protocol (DHCP)
Restoring Files from Backups from Essential System Administration, 2nd Ed.
Manipulating Print Jobs from Essential Windows NT System Administration

Windows NT and UNIX Intergration Perspective

Filesystem Integration

Because UNIX and Windows NT do not typically come with a compatible network filesystem, you need to add software to one operating system for it to speak the language of the other. Windows NT uses the server message block (SMB) and UNIX uses the network file system (NFS). You can either make UNIX speak SMB or Windows NT speak NFS.

Given an option, people tend to prefer to do something with which they are familiar. There are third-party and public domain software solutions for both situations. These typically fall into one of the categories discussed below.

UNIX SMB Server

A UNIX daemon uses the SMB protocol to share filesystems with Windows NT computers. This is a simple solution because it does not require you to make any modification to existing Windows-based client software or any user training for Windows NT users. Examples include Samba and Syntax TotalNet.

Windows NFS Clients

NFS software can be added to every Windows computer that needs access to the UNIX filesystem. This does not require you to make changes to the existing UNIX installation. Examples include Intergraph IPC-NFS, FTP Software, Beame & Whiteside Connect NFS Client, NetManage, and Chameleon32NFS.

Windows NT NFS Server

This solution enables UNIX NFS clients to access Windows NT filesystems with no changes. Examples include Intergraph DiskShare, Xlink Omni-NFS Server, Beame & Whiteside Connect NFS Server, NetManage, Chameleon32NFS, and Process Software NFSware.

Windows NT NFS Gateway

Installing NFS software on a single Windows NT server does not require you to make changes to either the UNIX server or Windows clients. The gateway software redistributes the NFS to Windows clients using the SMB protocol. Performance is limited by the speed of the gateway. This is very similar to the scheme used by File and Print Services for NetWare (FPNW), where an NT server gateways a NetWare filesystem to Windows clients. Examples include Intergraph AccessNFS Gateway, Omniplex Omni-NFS Gateway, and Databit NFS Gateway.

Potential Problems and Conflicts

Because files created on UNIX do not normally have an extension, or may have an extension that exceeds three characters, this could cause problems for Windows users who wish to double-click files to open them.

To ease integration, you may want to establish some guidelines for the files shared between UNIX and Windows NT. The following are examples of actions that may alleviate the problem:

• Avoid characters that will make life difficult for command-line users. For example, spaces in filenames require placing the filename in quotation marks to prevent it from being interpreted as multiple filenames. Instead, use underscores or hyphens.
• Give a UNIX file containing plain ASCII text an extension such as .TXT. That enables most Windows editors to find and open the file.
• Use compatible file archive utilities. For example, find an archive format that can be supported on both systems, such as zip.

UNIX uses utilities such as tar, cpio, and gzip to store multiple files in a single archive. These typically preserve directory structure, file permissions, and modification dates, or compress the files. Windows NT users use PKZip or WinZip for the most part. Utilities are available for each operating system to read the native archive format of the other. Windows NT comes with the pax utility as part of the base OS. It reads and writes files in a pax, tar, or cpio format that can be used on UNIX.

The following table outlines UNIX and Windows NT filesystem similarities and differences:

Understanding Domain Name System (DNS)

Resolution

Name servers are adept at retrieving data from the domain name space. They have to be, given the limited intelligence of some resolvers. Not only can they give you data about zones for which they're authoritative but they can also search through the domain name space to find data they're not authoritative. This process is called name resolution, or simply resolution.

Because the name space is structured as an inverted tree, a name server needs only one piece of information to find its way to any point in the tree: the names and addresses of the root name servers. A name server can issue a query to a root name server for any name in the domain name space, and the root name server will start the name server on its way.

Root Name Servers

The root name servers know where to find name servers that are authoritative for all the top-level domains. (In fact, most of the root name servers are authoritative for the generic top-level domains.) Given a query about any domain name, the root name servers can at least provide the names and addresses of the name servers that are authoritative for the top-level domain that the domain name is in. And these top-level name servers can provide the list of name servers that are authoritative for the second-level domain that the domain name is in. Each name server queried gives the querier information about how to get closer to the answer it's seeking, or it provides the answer itself.

The root name servers are clearly important to resolution. Because they're so important, DNS provides mechanisms--such as caching, which we'll discuss a little later--to help offload the root name servers. But in the absence of other information, resolution has to start at the root name servers. This makes the root name servers crucial to the operation of DNS; if all the Internet root name servers were unreachable for an extended period, all resolution on the Internet would fail. To protect against this, the Internet has thirteen root name servers (as of this writing) spread across different parts of the network. Two are on the MILNET, the U.S. military's portion of the Internet; one is on SPAN, NASA's internet; two are in Europe; and one is in Japan.

Being the focal point for so many queries keeps the roots busy; even with thirteen, the traffic to each root name server is very high. A recent poll of root name server administrators showed some roots receiving an average of 700 queries per second.

Despite the load placed on root name servers, resolution on the Internet works quite well. Figure 10 shows the resolution process for the address of a real host in a real domain, including how the process corresponds to traversing the domain name space tree.

The local name server queries a root name server for the address of girigiri.gbrmpa.gov.au and is referred to the au name servers. It asks an au name server the same question and is referred to the gov.au name servers. The gov.au name server refers the local name server to the gbrmpa.gov.au name servers. Finally, the local name server asks a gbrmpa.gov.au name server for the address and gets the answer.

Recursion

You may have noticed a big difference in the amount of work done by the name servers in the previous example. Four of the name servers simply returned the best answer they already had--mostly referrals to other name servers--to the queries they received. They didn't have to send their own queries to find the data requested. But one name server-- the one queried by the resolver--had to follow successive referrals until it received an answer.

Why couldn't it simply have referred the resolver to another name server? Because a stub resolver wouldn't have had the intelligence to follow a referral. And how did the name server know not to answer with a referral? Because the resolver issued a recursive query.

Queries come in two flavors, recursive and iterative, also called nonrecursive. Recursive queries place most of the burden of resolution on a single name server. Recursion, or recursive resolution, is just a name for the resolution process used by a name server when it receives recursive queries.

Iteration or iterative resolution, on the other hand, refers to the resolution process used by a name server when it receives iterative queries.

In recursion a resolver sends a recursive query to a name server for information about a particular domain name. The queried name server is then obliged to respond with the requested data or with an error stating that data of the requested type don't exist or that the domain name specified doesn't exist.[7] The name server can't just refer the querier to a different name server, because the query was recursive.

If the queried name server isn't authoritative for the data requested, it will have to query other name servers to find the answer. It could send recursive queries to those name servers, thereby obliging them to find the answer and return it (and passing the buck). Or it could send iterative queries and possibly be referred to other name servers closer to the domain name it's looking for. Current implementations are generally polite and do the latter, following the referrals until an answer is found.[8]

Iteration

Iterative resolution, on the other hand, doesn't require nearly as much work on the part of the queried name server. In iterative resolution, a name server simply gives the best answer it already knows back to the querier. No additional querying is required. The queried name server consults its local data (including its cache, which we're about to talk about), looking for the data requested. If it doesn't find the data there, it makes its best attempt to give the querier data that will help it continue the resolution process. Usually these are the names and addresses of name servers closer to the data it's seeking.

What this amounts to is a resolution process that, taken as a whole, looks like Figure 11.

A resolver queries a local name server, which then queries a number of other name servers in pursuit of an answer for the resolver. Each name server it queries refers it to another name server that is authoritative for a zone further down in the name space and closer to the data sought. Finally, the local name server queries the authoritative name server, which returns an answer.

Mapping Addresses to Names

One major piece of functionality missing from the resolution process as explained so far is how addresses get mapped back to names. Address-to-name mapping is used to produce output that is easier for humans to read and interpret (in log files, for instance). It's also used in some authorization checks. Some hosts map addresses to host names to compare against entries in authorization files, for example. When using host tables, address-to-name mapping is trivial. It requires a straightforward sequential search through the host table for an address. The search returns the official host name listed. In DNS, however, address-to-name mapping isn't so simple. Data, including addresses, in the domain name space are indexed by name. Given a domain name, finding an address is relatively easy. But finding the domain name that maps to a given address would seem to require an exhaustive search of every domain name in the tree.

Actually, there's a better solution that's both clever and effective. Because it's easy to find data once you're given the name that indexes that data, why not create a part of the domain name space that uses addresses as names? In the Internet's domain name space, this portion of the name space is the in-addr.arpa domain.

Nodes in the in-addr.arpa domain are named after the numbers in the dotted-octet representation of IP addresses. (Dotted-octet representation refers to the common method of expressing 32-bit IP addresses as four numbers in the range 0 to 255, separated by dots.) The in-addr.arpa domain, for example, could have up to 256 subdomains, one corresponding to each possible value in the first octet of an IP address. Each of these subdomains could have up to 256 subdomains of its own, corresponding to the possible values of the second octet. Finally, at the fourth level down, there are resource records attached to the final octet giving the full domain name of the host or network at that IP address. That makes for an awfully big domain: in-addr.arpa, shown in Figure 12, is roomy enough for every IP address on the Internet.

Note that when read as a domain name, the IP address appears backward because the name is read leaf to root. For example, if winnie.corp.hp.com has the IP address 15.16.192.152, the corresponding in-addr.arpa subdomain is 152.192.16.15.in-addr.arpa, which maps back to the domain name winnie.corp.hp.com.

IP addresses could have been represented the opposite way in the name space, with the first octet of the IP address at the bottom of the in-addr.arpa domain. That way, the IP address would have read correctly (forward) in the domain name.

IP addresses are hierarchical, however, just like domain names. Network numbers are doled out much as domain names are, and administrators can then subnet their address space and further delegate numbering. The difference is that IP addresses get more specific from left to right, while domain names get less specific from left to right. Figure 13 shows what we mean.

Making the first octets in the IP address appear highest in the tree gives administrators the ability to delegate authority for in-addr.arpa domains along network lines. For example, the 15.in-addr.arpa domain, which contains the reverse mapping information for all hosts whose IP addresses start with 15, can be delegated to the administrators of network 15. This would be impossible if the octets appeared in the opposite order. If the IP addresses were represented the other way around, 15.in-addr.arpa would consist of every host whose IP address ended with 15--not a practical domain to try to delegate.

Inverse Queries

The in-addr.arpa name space is clearly only useful for IP address-to-domain name mapping. Searching for a domain name that indexes an arbitrary piece of data--something besides an address--in the domain name space would require another specialized name space like in-addr.arpa or an exhaustive search.

That exhaustive search is to some extent possible, and it's called an inverse query. An inverse query is a search for the domain name that indexes a given datum. It's processed solely by the name server receiving the query. That name server searches all of its local data for the item sought and returns the domain name that indexes it, if possible. If it can't find the data, it gives up. No attempt is made to forward the query to another name server.

Because any one name server knows only about part of the overall domain name space, an inverse query is never guaranteed to return an answer. For example, if a name server receives an inverse query for an IP address it knows nothing about, it can't return an answer; but it also doesn't know that the IP address doesn't exist, because it only holds part of the DNS database. What's more, the implementation of inverse queries is optional according to the DNS specification. The Microsoft DNS Server doesn't support inverse queries at all. That's fine with us, because very little software (such as archaic versions of nslookup) actually still uses inverse queries.

Footnotes

7. The Microsoft DNS Server gives name server administrators the ability to refuse recursive queries. Why would you want to do this in the first place? If you were setting up a name server solely for the purpose of giving out data about your zone to other name servers and didn't have any resolvers using it, refusing recursive queries would eliminate the possibility that anyone could steal valuable cycles from your name server by pointing their resolvers at it.

8. The exception is a name server configured to use a forwarder.

Using the Windows Internet Naming Service (WINS)

Maintaining and Troubleshooting WINS

Once it has been installed and configured correctly, WINS requires little routine maintenance, and is likely to have few problems. When problems do occur, they are usually minor and affect only one or a few clients. The following list describes four of the most common minor problems that might occur with WINS and how to go about resolving them:

Clients receive "network path not found" messages

This problem may occur in environments with a mix of h-node and b-node hosts, and in those with multiple WINS servers configured as replication partners. If this problem occurs, the first step is to look up the name in question in the WINS database. If the name does not exist, check to see if the destination host uses b-node. If so, you must enter a static mapping for the b-node host in the WINS database. If an entry for the destination host does exist in the local WINS database, but that host is connected to a subnet served by a different WINS server, then the most likely cause is that that host's IP address is no longer the same as the value stored in the local WINS database. To resolve the problem, perform a push replication from the remote WINS server to the local WINS server to replicate the changed information to your local database.

WINS returns "duplicate name" messages

This problem also occurs in environments with multiple WINS servers configured as replication partners. It occurs when a static mapping record exists for a particular name in the local database, and a remote database attempts to replicate that same name to the local database. To resolve the problem, first examine the local WINS database to determine if a static mapping record exists for that name. If so, delete it.

WINS database backup fails

If you receive an error message during backup of the WINS database, the most likely cause is that the backup folder you specified initially in WINS Manager is located on a network drive. WINS requires that its backup folder be located on a local drive. You will also receive a similar message if the drive containing the backup folder has inadequate space to complete the backup.

WINS replication fails

If you receive an error message reporting a replication failure, by far the most likely cause is a simple configuration error. A WINS server can be configured as a push partner, as a pull partner, or as both push and pull. Normally, in an environment with multiple WINS servers configured as replication partners, each WINS server should be configured as both a push partner and a pull partner with each other WINS server. If you receive an error message reporting a replication failure on a newly installed or recently reconfigured WINS server, verify that the partnership settings are configured correctly between the WINS servers. You can do so by using the Registry Editor to examine the values for the Registry subkeys Pull and Push in the key HKLM_SYSTEM\CurrentControlSet\Services\Wins\Partners.

If you haven't made any changes recently to your WINS servers, then an incorrect configuration is unlikely to be the cause of the replication problem. In this case, the most likely cause is a simple network communication problem. The two WINS servers obviously can't replicate if they can't talk to each other. Use the ping utility to verify that IP connectivity exists between the two servers.

NOTE: Performing any of the problem resolution measures described in this section requires that you be logged on to the server with an account that is a member of the Administrators group.

The following two problems (or widespread client problems of the sort described earlier) indicate more severe problems with WINS:

• When you attempt to use WINS Manager to connect to a WINS server, you are unable to do so and receive a warning message.
• When you attempt to start the Windows Internet Name Service service or the WINS client service, you receive a warning message that the service cannot start.

If the first problem occurs, first use ping to verify that IP connectivity exists between the workstation you are using and the WINS server in question. If you can ping the server successfully, next verify that WINS is running on that server by running the Services applet from Control Panel. The Status column should report "Started" for both the Windows Internet Name Service service and the WINS client service. If either or both of these services is not running, first attempt to start the service by highlighting its name and clicking Start. If the service starts successfully, verify that the problems you were experiencing have been resolved.

Don't forget to use Event Viewer to check the log for error messages. To run Event Viewer, from the Start button, choose Programs → Administrative Tools (Common) → Event Viewer.

If the second problem occurs, and you are unable to start the service using the procedure described earlier, the next step is to shut down the server. Before doing so, notify everyone that the server is about to be shut down. If you experiencing severe WINS problems, you may have to notify your users by using some method other than a broadcast to clients. Once all clients have disconnected safely, shut down the server, turn the power off, and allow the server to remain down for at least a minute.

Once your drives have all spun down, turn the power back on, and watch the console for warning messages as the server restarts. Most of the time, you will find that WINS starts normally. If WINS still does not start, from the command prompt, type net start wins, and press Enter. WINS should start normally. If WINS still refuses to start, or if WINS appears to start properly but you still cannot access the WINS database with WINS Manager, there are two alternatives remaining. Before attempting either, back up your existing WINS database. Make sure that you are not backing up bad data over good, and that you have a copy of your last-known good WINS database backup stored in a safe location before proceeding.

Restore the WINS database

The penultimate measure to correcting WINS problems is to revert to an earlier version of the WINS database. You can restore the WINS database using WINS Manager or by manually copying files.

• To restore using WINS Manager, select Restore Local Database option from the Mappings menu, enter the location of the backup WINS database files, and click OK to confirm.
• To restore manually, first stop any running WINS services as described earlier in this section. Next, delete all files in the \%SystemRoot\system32\wins folder, and copy a known-good earlier version of wins.mdb to this folder. Finally, restart WINS using the command-line procedure described earlier.
Reinstall WINS

If you are running a small network with a simple WINS environment--one without replication partners, numerous static mappings, and so on--the quickest and easiest fix is sometimes simply to reinstall WINS. Even if your WINS environment is more complex, you may have no alternative to reinstalling WINS if you find that all of your existing WINS database copies are corrupt.

To reinstall WINS, from Control Panel-Services, shut down any WINS services that are currently running. Next, from the Services page of the Network property sheet, highlight Windows Internet Name Service and click Remove, but don't restart the server just yet. First, delete the \%SystemRoot\system32\wins folder and all of its files and subfolders. Restart the server and install WINS as described earlier in this booklet. Restart the server once more. The WINS database will be rebuilt dynamically as the clients access it. In a small environment, removing and then reinstalling WINS may be quicker and less disruptive than attempting to fix the existing installation.

Windows NT Desktop Reference

The Windows NT Scripting Language

Script-Related Constructs

:label

Named location within script (target of goto or call command).

%m

Argument number m (access arguments above the ninth one via the shift command).

%~cm

Modified argument m, where c can be one or more of the following code letters indicating the parts of the argument to use:

f

Full pathname.

d

Drive letter only.

p

Path only.

n

Filename only.

x

Extension only.

s

Use 8.3 (DOS-style) names (valid with n and x).

$PATH

Examines the search path in the PATH environment variable and returns the fully qualified pathname for the first match for the argument, returning an empty string if the item is not found.

%*

Corresponds to all command parameters.

%var%

Value of variable var (local or environment).

errorlevel

Internal variable set by various commands. Often indicates the contents of user input--see the discussion of the if command.

Commands Useful in Scripts

call file | :label [args ]

Run the specified external script file or labeled subroutine within the current script.

choice [/C:choices ] [/S] [/ T:c,n] prompt-string

Prompt user to select from a list of choices, using the specified string as the prompt text. Sets the errorlevel variable to the selected choice number (starting at 1).

/C:choices

Specify choice letters (the default is YN).

/S

Make choices case-sensitive.

/ T:c,n

Select default choice c after timeout of n seconds.

cls

Clear the screen.

echo message

Display the specified message text on screen. The message may not be null. A string consisting solely of a period at right margin is the conventional way to create a "blank" output line.

echo ON | OFF

Enable or disable command echoing (enabled by default).

exit

Terminate script immediately (or terminate the current command interpreter if executed interactively).

See also goto :EOF.

Loop construct.

for [/D] %%var in ( filelist ) do command

Loop over a list of files. The specified variable is set to each successive item in the file list each time through the loop.

/D says to match directory names only in filelist.

for /L %%var in (m,j,n) do command

Loop from m to n by j, using the specified variable as the loop index.

goto label

Jump to the named location in the script.

goto :EOF

Jump to the end of the current script file.

Conditional command. In all cases, including the not keyword inverts the logical expression.

if [not] errorlevel n command

Execute command if the value of the errorlevel variable is/isn't greater than or equal to n.

if [not] defined variable command

Execute command if the specified variable is/isn't defined.

if [not] exist file command

Execute command if the specified file does/doesn't exist.

if [not] [/I] string1 op string2 command

Execute command if the specified string comparison expression is true/false. The available operators are:

==, EQU

Equal.

NEQ

Not equal.

LSS

Less than.

LEQ

Less than or equal.

GTR

Greater than.

GEQ

Greater than or equal.

All comparison operators are case sensitive. / I says to perform a case-insensitive comparison.

pause

Pause execution until user presses a key.

prompt text

Set the command prompt to text, which can contain the following codes (among others--see prompt /?):

$D, $T

Current date, current time.

$G

Greater than sign (>).

$N

Current drive letter.

$P

Current drive and working directory.

$S

Space.

$_

Carriage return.

rem anything

Comment line, ignored by the command interpreter.

Display/set a variable value.

set [var ]

Display value of the specified variable (or all defined variables).

set var =string

Set the value of a string variable.

set /A var =numeric-expression

Set the variable to the result of the evaluated numeric expression.

setlocal begins a local environment within the script, which is terminated by endlocal.

shift [/n]

Shift script/command arguments down one place, starting at argument n (if specified).

Windows NT Tips & Tricks

Using NT as a Multiprotocol Print Server

The ability of NT to speak multiple network protocols enables it to be used as a sort of protocol converter, where it accepts data using one protocol and sends the data out using another protocol.

Multiprotocol Printing

A good use of this feature is network printing. For example, a Windows 95 computer could print to an NT print queue using the NetBEUI protocol, and then the NT server could send the print job to an Apple LaserWriter using the AppleTalk protocol. The print job has been "converted" from NetBEUI to AppleTalk.

NT Server can accept print jobs via NetBEUI, TCP/IP (LPR/LPD), AppleTalk, and Novell IPX. It can print via NetBEUI, TCP/IP, AppleTalk, IPX, and DLC, in addition to hard-wired serial and parallel ports. NT Workstation can print to the same device as Server, but it can share only via the NetBEUI protocol.

For NT Workstation to print to a printer using IPX, you must install Client Services for NetWare (CSNW). NT Server can act as a gateway between NetWare printers and non-NetWare clients using Gateway Services for NetWare (GSNW). NT Server can act as a NetWare printer using File and Print Services for NetWare (FPNW), which does not come with NT Server, and must be purchased separately.

It also possible to print using TCP/IP via NBT (NetBIOS over TCP/IP), but this is quite different from using the native TCP/IP printing protocol, LPD.

Printing Versus Sharing

It is important to distinguish between the ability of an NT machine to offer a print queue to other machines on the network versus an NT machine printing to a networked printer (or other computer). When you add a service, such as Services for the Macintosh, you are adding the ability for another computer to print to your computer using the AppleTalk protocol. When you add a protocol, such as AppleTalk or DLC, you are adding the ability to print to a network device using that protocol.

Printing via ports

Microsoft calls the network connection between your NT computer and a printer a port. A port can be a protocol and printer name combination, such as:

Port Name			Description:

-------------------------------------------------------------

PC248 HP4M			NetBIOS print queue HP4M on computer PC248

sales:sales			TCP/IP printer sales

ORA_MEDIA:color			AppleTalk printer color in Zone ORA_MEDIA

LPT1				Parallel port

COM2				Serial port

Sharing print queues

Microsoft's name for the ability to accept print jobs from remote computers is sharing a print queue. You will need a monitor for each protocol under which you want to share the print queue.

Installing Printing Protocols

The NT installation process tends to blur the distinction between offering a printing service for a protocol and the ability to print via that protocol. By default, adding one adds both. For example, adding Services for the Macintosh (SFM) adds the Print Server for Macintosh, which enables Macintosh computers to print to the NT server, and the AppleTalk protocol, which enables printing to a AppleTalk printer.

The Network control panel display is very confusing in this regard. In order for NT Workstation to print via AppleTalk, you add the AppleTalk Protocol. AppleTalk then shows up in the Protocols tab of the Network control panel. Once AppleTalk is installed, you can create AppleTalk ports. NT Workstation has only a limited ability to act as a print server, and only for the NetBEUI protocol.

On NT Server, the AppleTalk protocol is installed when you install the Services for the Macintosh service, but it never shows up in the Protocols tab of the Network control panel!

To create a port to a networked printer using the Add Printer Wizard, choose My Computer, and Add Port. If you are adding an AppleTalk port, choose AppleTalk Printing Devices, and select an AppleTalk printer. If you have lots of printers to connect to, it may be quicker to just keep hitting the Add Port button to create all the printer ports at once. When you are setting up the next printer, you can then select from the list of ports you have created.

Installing a protocol under NT Server implies sharing all your existing print queues under that protocol, but you do have some control over what protocols are used for printer sharing. For example, if you do not want the printer queues to be shared under AppleTalk, but want to print via AppleTalk, you can simply stop the Print Server for Macintosh service from running, and none of your computer's print queues will be visible from AppleTalk. To stop or disable the service from running, use the Startup setting in the Services control panel. Set the Startup Type to manual or disabled, and the service will not start at the next reboot.

Centralized Queuing

One problem with having print jobs coming from multiple machines and multiple protocols is queue management and performance.

Centralized management

Using an NT server as a choke point for all print jobs allows the administrator to see every job being sent to a printer, regardless of where the print job originated (PC, Mac, UNIX, or NetWare). If you need to pause or stop a print queue in order to work on a printer, you can do so from a single location. If a print job goes haywire and starts printing out hundreds of pages of garbage, you can find the offending job, cancel it, and determine who sent it--all from the same machine.

For example, the NT server print queue in Figure 4 has four jobs being spooled. The first job was sent from a Macintosh, the second from a Sun (UNIX) computer, the third from a Windows 95 client, and the fourth from the local NT computer itself. All of these print jobs are being sent to the same network printer, but by sending them through the NT server first, the administrator has gained centralized queue control.

Performance

The performance of the computer sending the job is usually improved by spooling it to an NT server instead of directly to a printer. Most printers will occupy some resources on the computer while printing a large job, so sending to a server gets it off your machine quickly and lets you get back to work. Some network printers cannot handle being bombarded by multiple print jobs coming from different computers all at the same time. The NT server will feed jobs to the printer one at a time, keeping the printer happy.

Cryptography from a UNIX Perspective

DES

One of the most widely used encryption systems today is the Data Encryption Standard (DES), developed in the 1970s and patented by researchers at IBM. The DES was an outgrowth of another IBM cipher known as Lucifer. IBM made the DES available for public use, and the federal government issued Federal Information Processing Standard Publication (FIPS PUB) Number 46 in 1977 describing the system. Since that time, the DES has been periodically reviewed and reaffirmed (most recently in December 30, 1993), until 1998 as FIPS PUB 46-2. It has also been adopted as an American National Standard (X3.92-1981/R1987).

The DES performs a series of bit permutation, substitution, and recombination operations on blocks containing 64 bits of data and 56 bits of key (eight 7-bit characters). The 64 bits of input are permuted initially, and are then input to a function using static tables of permutations and substitutions (called S-boxes). The bits are permuted in combination with 48 bits of the key in each round. This process is iterated 16 times (rounds), each time with a different set of tables and different bits from the key. The algorithm then performs a final permutation, and 64 bits of output are provided. The algorithm is structured in such a way that changing any bit in the input has a major effect on almost all of the output bits. Indeed, the output of the DES function appears so unrelated to its input that the function is sometimes used as a random number generator.

Although there is no standard UNIX program that performs encryption using the DES, some vendors' versions of UNIX include a program called des which performs DES encryption. (This command may not be present in international versions of the operating system, as described in the next section.)

Use and export of DES

The DES was mandated as the encryption method to be used by all federal agencies in protecting sensitive but not classified information.[15] The DES is heavily used in many financial and communication exchanges. Many vendors make DES chips that can encode or decode information fast enough to be used in data-encrypting modems or network interfaces. Note that the DES is not (and has never been) certified as an encryption method that can be used with U.S. Department of Defense classified material.

Export control rules restrict the export of hardware or software implementations of the DES, even though the algorithm has been widely published and implemented many times outside the United States. If you have the international version of UNIX, you may find that your system lacks a des command. If you find yourself in this position, don't worry; good implementations of the DES can be obtained via anonymous FTP from almost any archive service, including the Usenet comp.sources archives.

For more information about export of cryptography, see "Encryption and U.S. Law," later in this booklet.

DES modes

FIPS PUB 81 explains how the DES algorithm can be used in four modes:

• Electronic Code Book (ECB)
• Cipher Block Chaining (CBC)
• Cipher Feedback (CFB)
• Output Feedback (OFB)

Each mode has particular advantages in some circumstances, such as when transmitting text over a noisy channel, or when it is necessary to decrypt only a portion of a file. The following provides a brief discussion of these four methods; consult FIPS PUB 81 or a good textbook on cryptography for details.

• ECB Mode. In electronic code book (ECB) mode, each block of the input is encrypted using the same key, and the output is written as a block. This method performs simple encryption of a message, a block at a time. This method may not indicate when portions of a message have been inserted or removed. It works well with noisy transmission channels--alteration of a few bits will corrupt only a single 64-bit block.
• CBC Mode. In cipher block chaining (CBC) mode, the plaintext is first XOR'ed with the encrypted value of the previous block. Some known value (usually referred to as the initialization vector, or IV) is used for the first block. The result is then encrypted using the key. Unlike ECB mode, long runs of repeated characters in the plaintext will be masked in the output. CBC mode is the default mode for Sun Microsystems' des program.
• CFB Mode. In cipher feedback (CFB) mode, the output is fed back into the mechanism. After each block is encrypted, part of it is shifted into a shift register. The contents of this shift register are encrypted with the user's key value using (effectively) ECB mode, and this output is XOR'd with the data stream to produce the encrypted result. This method is self synchronizing, and enables the user to decrypt only a portion of a large database by starting a fixed distance before the start of the desired data.
• OFB Mode. In output feedback (OFB) mode, the output is also fed back into the mechanism. A register is initialized with some known value (again, the IV). This register is then encrypted with (effectively) ECB mode using the user's key. The result of this is used as the key to encrypt the data block (using an XOR operation), and it is also stored back into the register for use on the next block. The algorithm effectively generates a long stream of key bits that can be used to encrypt/decrypt communication streams, with good tolerance for small bit errors in the transmission. This mode is almost never used in UNIX-based systems.

All of these modes require that byte and block boundaries remain synchronized between the sender and recipient. If information is inserted or removed from the encrypted data stream, it is likely that all of the following data from the point of modification can be rendered unintelligible.

DES strength

Ever since DES was first proposed as a national standard, some people have been suspicious of the algorithm. DES was based on a proprietary encryption algorithm developed by IBM called Lucifer, which IBM had submitted to the National Bureau of Standards (NBS)[16] for consideration as a national cryptographic standard. But whereas Lucifer had a key that was 112 bits long, the DES key was shortened to 56 bits at the request of the National Security Agency. The NSA also requested that certain changes be made in the algorithm's S-boxes. Many people suspected that NSA had intentionally weakened the Lucifer algorithm, so the final standard adopted by NBS would not pose a threat to the NSA's ongoing intelligence collection activities. But nobody had any proof.

Today the DES is more than 20 years old, and the algorithm is definitely showing its age. Recently Michael Weiner, a researcher at Bell Northern Research, published a paper detailing how to build a machine capable of decrypting messages encrypted with the DES by conducting an exhaustive key search. Such a machine could be built for a few million dollars, and could break any DES-encrypted message in about a day. We can reasonably assume that such machines have been built by both governments and private industry.

In June 1994, IBM published a paper describing the design criteria of the DES. The paper claims that the choices of the DES key size, S-boxes, and number of rounds were a direct result of the conflicting goals of making the DES simple enough to fit onto a single chip with 1972 chip-making technology, and the desire to make it resistant to differential cryptanalysis.

These two papers, coupled with many previously published analyses, appear to have finally settled a long-running controversy as to whether or not NSA had intentionally built in weaknesses to the DES. The NSA didn't build a back door into DES that would have allowed it to forcibly decrypt any DES-encrypted transmission: it didn't need to. Messages encrypted with DES can be forcibly decrypted simply by trying every possible key, given the appropriate hardware.

Improving the Security of DES

You can improve the security of DES by performing multiple encryptions, known as superencryption. The two most common ways of doing this are with double encryption (Double DES) and with triple encryption (Triple DES).

While double DES appears to add significant security, research has found some points of attack, and therefore experts recommend Triple DES for applications where single DES is not adequate.

Double DES

In Double DES, each 64-bit block of data is encrypted twice with the DES algorithm, first with one key, then with another:

1. 1. Encrypt with (key 1)
2. 2. Encrypt with (key 2)

Plaintext → (key1) → (key2) → ciphertext

Double DES is not significantly more secure than single DES. In 1981, Ralph Merkle and Martin Hellman published an article[17] in which they outlined a so-called "meet-in-the-middle attack."

The meet-in-the-middle attack is a known plaintext attack which requires that an attacker have both a known piece of plaintext and a block of that same text that has been encrypted. (These pieces are surprisingly easily to get.) The attack requires storing 256 intermediate results when trying to crack a message that has been encrypted with DES (a total of 259 bytes), but it reduces the number of different keys you need to check from 2112 to 257. "This is still considerably more memory storage than one could comfortably comprehend, but it's enough to convince the most paranoid of cryptographers that double encryption is not worth anything," writes Bruce Schneier in his landmark volume, Applied Cryptography.

In other words, because a message encrypted with DES can be forcibly decrypted by an attacker performing an exhaustive key search today, an attacker might also be able to forcibly decrypt a message encrypted with Double DES using a meet-in-the-middle attack at some point in the future.

Triple DES

The dangers of the Merkle-Hellman meet-in-the-middle attack can be circumvented by performing three block encryption operations. This method is called Triple DES.

In practice, the most common way to perform Triple DES is:

1. 1. Encrypt with (key1)
2. 2. Decrypt with (key2)
3. 3. Encrypt with (key3)

The advantage of this technique is that it can be backward compatible with single DES, simply by setting all three keys to be the same value.

To decrypt, reverse the steps:

1. 1. Decrypt with (key3)
2. 2. Encrypt with (key2)
3. 3. Decrypt with (key1)

For many applications, you can use the same key for both key1 and key3 without creating a significant vulnerability.

Triple DES appears to be roughly as secure as single DES would be if it had a 112-bit key. How secure is this really? Suppose you had an integrated circuit which could perform one million Triple DES encryptions per second, and you built a massive computer containing one million of these chips to forcibly try all Triple DES keys. This computer, capable of testing 1012 encryptions per second, would require:

This is more than 16,453 times older than the currently estimated age of the universe (approximately 1010 years).

Apparently, barring new discoveries uncovering fundamental flaws or weaknesses with the DES algorithm, or new breakthroughs in the field of cryptanalysis, Triple DES is the most secure private key encryption algorithm that humanity will ever need (although niche opportunities may exist for faster algorithms).

Footnotes

15. NBS later became the National Institute of Standards and Technology.

Network Security

Security Monitoring

A key element of effective network security is security monitoring. Good security is an ongoing process. Following the security guidelines discussed above is just the start. You must also monitor the systems to detect unauthorized user activity, and to locate and close security holes. You need to known the system in order to detect and fix these problems as they arise.

Windows NT provides system monitoring through the Event Viewer. Most Windows NT administrators are familiar with the Event Viewer from debugging problems that occur during system startup or from fixing problems with newly installed hardware. An equally important function for the Event Viewer is security monitoring. To perform this important task you must first define the audit policy for your system. Open the User Manager for Domains and select Audit from the Policies menu. This opens the Audit Policy window shown in Figure 2. Use this window to define your security monitoring policy.

Network security is monitored by examining the event logs of individual systems on the network. To detect unusual activity on a system, you must know what activity is normal. You need to know this in order to develop a "feel" for how things should be. Through the Audit Policy window you can enable the following audits that give you insight into the normal activity of your system:

• Logon and Logoff tracks the local and network logons to this system, which is important for learning who is usually logged in and who commonly logs in after hours. You need to know this to help you detect when improper logins are taking place.
• File and Object Access enables logging of access to files and directories, and the submission of print jobs. See the NTFS Auditing section of this booklet for information on how to monitor file and directory access.
• Use of User Rights audits every time a user uses a right, other than logon, that has been granted to that user. This is useful for checking who uses special rights and can alert you to a problem if a user uses a right that you did not intentionally grant him.
• User and Group Management audits all changes to accounts and groups, including password changes. This audit is useful for detecting any changes to the groups to which a user belongs. An intruder who gains access to the administrative account may change groups or even create new accounts in order to exploit your system.
• Security Policy Changes logs changes to user rights, to domain trust relationships and to the audit policy itself. If any of these things have changed, and they have not been changed by you, you have a major problem. This audit should always be selected.
• Restart, Shutdown, and System tracks system-level events such as reboots. This should always be selected. Even if an intruder does not cause the reboot, you should have a record of when your system unexpectedly restarts.
• Process Tracking enables logging of events relating to the executable processes that run on the system. Some applications allow you to specify event logging within the application itself. See the example of Registry monitoring later in this booklet.

If the event logs give you reason to suspect a security problem, examine them in detail for modified security policies, for modified user or group rights, and for unusual login activity. This close examination also can be made using the Event Viewer. The next section shows an example of examining login activity.

Checking Login Activity

Strange login activity, at odd times of the day or from unfamiliar locations, can indicate attempts by intruders to gain access to your system. Use the Event Viewer to check who has logged into the system in the past.

Figure 3 shows the summary lines displayed by the Event Viewer for each user login. Use each day's summary to learn normal login patterns in order to detect abnormal login activity. The Event Viewer provides a record of who logged into the system, when they logged in, and when they logged out.

Figure 4 shows the detail of a single login record from the Event Viewer. To view this level of detail simply double-click on an individual summary line in the main Event Viewer window to open the Event Detail box. The Event Detail contains fields that show the user who logged in, the workstation from which the login originated, the date, the time logged in, and the Windows NT domain.

If you find any problems, even if you suspect any problems, follow your reporting procedure and let people know about the problem. This is particularly important if you are connected to a local area network. A problem on your system could spread to other systems on the network.

Registry Monitoring

As every Windows NT administrator knows, the Registry is vital to the operation of the system. The Registry holds configuration values that are used by the applications that run on a Windows NT system and by the operating system itself. If the Registry is corrupted, applications do not run correctly, the system is exposed to potential security problems, and it may not boot correctly. If an intruder can corrupt the Registry, he can severely damage your system.

To help prevent this problem, monitor who is accessing and changing the Registry. To do so, use the Audit Policy window discussed in the previous section to enable auditing. Once auditing is enabled, run regedt32.exe. From the Security menu in the registry editor select Audit. This opens the window shown in Figure 5.

In the Registry Key Auditing window select Audit Permission on Existing Subkeys. Then select the individual events that you want to audit. At a minimum you should audit when values are set (Set Value), when new keys are created (Create Subkey) and when keys are deleted (Delete). Auditing everything can produce a large amount of data, but you may want to start by monitoring failures on every event to track how often there are failed attempts to access or change keys.

Monitoring, including Registry monitoring, is an important part of keeping your system and network secure. Windows NT provides excellent system monitoring tools. Learn about them and use them.

Monitoring & Optimizing Server Performance

Optimizing Server Performance

After reading the preceding section, you might reasonably wonder exactly how to go about using the information you discover with Performance Monitor to improve the performance of your server. Which objects and counters should you look at, and how can you tell if one is too high or too low? Well, as usual, the frustrating answer is, "it depends."

The primary purpose of Performance Monitor is to uncover bottlenecks in your server environment. A bottleneck is simply a single choke point that by itself restricts the performance potential of your server. For example, if your processor utilization routinely borders on 100%, it doesn't matter that the server has the fastest disk drives available and plenty of memory. Your server can't go any faster because the processor is already pedaling as fast as it can.

If you eliminate a bottleneck, the overall performance of the server takes a substantial quantum jump. If you replace that processor with a faster one--or add another processor--the other system components will no longer be held back by the slow processor, and can achieve the higher performance that was always their potential.

When you locate a bottleneck, you might therefore expect that the next step is always to eliminate it. Not true. The next step is to determine what is causing it to be a bottleneck. Simply throwing hardware at a problem isn't always the best or most cost-effective solution.

For example, while writing this Job Aid, I noticed that my processor utilization was typically ranging from the mid-80s to the high 90s. Now, this is a small server on a small network, and it seemed that a 133 MHz Pentium and 64 MB of RAM ought to be enough to handle things. But, in thinking about it, I realized that I had more services and applications loaded on this box than any real production server would be expected to handle, so perhaps I really was processor bound. I might easily have decided that the quick fix was to replace my 133 MHz Pentium with a faster Pentium or a Pentium Pro, or to add a second processor.

As it turns out, that wouldn't have done anything to solve the problem. The real problem was that an RPC bug was causing the processor to sit there looping on a zombie process, eating CPU ticks in the process. I went to the Microsoft web site and found that they had posted a fix for that exact problem earlier that same day--talk about a timely solution. When I applied the hot fix, processor utilization dropped into the 2% to 5% range immediately and stayed there. If I had simply upgraded the processor, my server would have been looping much faster, but it would still have been sitting at 97% processor utilization.

The point is this. When you find a bottleneck, try to figure out what is causing it before you try to fix it. Otherwise, you'll spend a lot of time and money fixing things that aren't really broken.

Optimizing Memory Performance

Inadequate RAM is by far the most common reason for server performance problems, with Windows NT Server or any other network operating system. Windows NT Server 4.0 requires 16 MB of RAM. It says so right on the box. In fact, of course, 16 MB is a ridiculously low amount for a serious server. Although Windows NT Server will load in 16 MB, it won't actually do much afterwards.

Consider 24 MB--or, better, 32 MB--as a bare-bones minimum on a small production file and print server. If you are using the server as an application server, consider 64 MB to be the starting point, and install 128 MB or more if you possibly can. If your server RAM doesn't meet these realistic minimums, don't bother wasting your time using Performance Monitor to locate bottlenecks. It's pretty obvious where the bottleneck is. Add more RAM.

When you install Windows NT Server, a page file is created. The page file is an area of your hard disk that the system treats as virtual memory. When the physical memory (RAM) is inadequate to meet the demands of all of the processes running on the server, memory pages are swapped to and from the page file. The page file operates at hard disk speeds (~10 ms read times) rather than at memory speed (~100 ns read times). This disparity of 100,000 times means that every time the page file is used, the server takes a performance hit. In essence, virtual memory is nice to have as an emergency fallback, but you want to use it as little as possible.

If you think your server is equipped with a reasonable amount of memory, but you are still having performance problems that may be memory related, chances are that the problem is due to overuse of the page file. Check the following items to decide whether paging is slowing down your server:

• Examine the Pages/sec counter in the Memory object (subsequently referred to in the form Memory ➝ Pages/sec). If this value has a sustained average of 10 or more, your server may not have enough physical RAM. If this value reaches an average of 20, server performance will be significantly degraded because of the continuous swapping that is occurring. Before you decide to add RAM, check Memory ➝ Available Bytes. If this value is not shrinking when the Pages/sec counter is growing, the problem may not actually be a shortage of physical RAM. You may have an application that is doing a great deal of random disk I/O. For an example of this type of behavior, watch these counters while using Start ➝ F ind to locate all files on your drive that contain the string "the." If you find that the problem is not due to excessive random I/O, the only solution is to increase the amount of physical RAM in your server.
• Examine Memory ➝ Available Bytes, which displays the amount of free physical memory. A consistent value below 4 MB indicates that substantial paging activity is occurring. Add RAM.
• Examine Memory ➝ Committed Bytes, which displays the amount of virtual memory that has been committed, as opposed to simply reserved. If this counter is greater than the amount of physical memory in the server, then the amount of physical memory may be inadequate to meet the demands of all processes that are currently active. Before you conclude that this is true, examine Memory ➝ Pages/sec and Memory ➝ Page Faults/sec. If the former is greater than 10 or so, and the latter is greater than Memory ➝ Cache Faults/sec, excessive paging is occurring.

As Memory ➝ Committed Bytes nears the value for Memory ➝ Commit Limit, and the page file is at or near its allowable maximum size, your server is headed for serious memory problems. The Commit Limit counter specifies how much virtual memory can be committed without increasing the size of the page file. If both are maxed out, you're about to run out of both physical and virtual memory. This situation usually arises because a poorly written application is leaking memory. To determine the process that is causing the problem, use Process ➝ Page File Bytes or Process ➝ Working Set to examine each process that is a likely candidate. You can also use the Process Monitor utility, PMON.EXE, included on the Resource Kit CD.

• Examine your page file. If its current size is larger than its initial size (ordinarily the amount of installed RAM plus 12 MB), this means that Windows NT Server has found it necessary to expand the page file size during operations. This reduces server performance because it introduces page file fragmentation, which slows paging performance even more.

The best solution to this problem is to never allow it to occur in the first place. Specify a very large page file when you install Windows NT Server--at least twice the size of the amount of physical RAM installed, and preferably three times the size. The initial page file is created in a single contiguous block of disk space, which avoids the fragmentation issue. If you're trying to fix this problem after the fact, the solution is a bit more involved, because disk defragmenting utilities currently available for Windows NT won't touch the page file.

To fix the problem, first create a new, temporary page file of the appropriate size on another volume. Then, reduce the size of the current page file to zero and reboot the server, causing it to use the new page file. Delete the old page file, and then run a defragmenting utility on the original volume. Most defragmenters for Windows NT defragment only, however, and do not relocate files to eliminate gaps, and the whole point is to create a new page file that is contiguous. Accordingly, you may find yourself needing to do a full backup, format, and restore to fix the problem. It's much easier to do things right in the first place.

If your testing indicates that the server is memory-bound, there are a few things that you can do. First, you can relocate memory-hungry applications to another, more lightly loader server. Second, if the application in question can be run after hours, you can use the scheduler service and the AT command to do so. Realistically, however, the usual answer is simply to add memory to the server.

To determine how much memory to add, examine the Paging File ➝ % Usage Peak counter, and multiply that number by the size of the paging file. If you have more than one paging file, do so for each paging file and total the results. If, for example, your server has a single 100 MB paging file, and the % Usage Peak counter indicates that at most 30% of the paging file was in use, multiply 30% (0.3) times 100 MB to arrive at a total of 30 MB. That means that if your system had had 30 MB more physical RAM, minimal paging would have occurred. Round up to the next increment, and add 32 MB of RAM.

If you add memory to your server, you may also need to upgrade the secondary processor cache. Otherwise, you may find that the resulting reduced cache hit rates turn your memory-bound server into a processor-bound server. Some caching methods link required cache size relatively loosely to the main memory size, whereas others tie the required cache size closely to the main memory size. I recall one old Everex server that gave you no option. You had to upgrade cache when you added RAM, or the thing just didn't work.

If your server has a utility that allows you to monitor cache hit rate, use it. A value under 90% means that you probably need a larger cache, or one of a more efficient type. A value of 95% or more means that your cache is performing effectively, and that adding cache will yield only rapidly diminishing returns.

Optimizing Processor Performance

Processor utilization is unlikely to be a bottleneck on a file and print server. Even a relatively slow processor--like the 486/66 on my test bed server--can serve a reasonably large number of clients if all it has to do is share files and printers. On an application server, however, the story is different. Because an application server is actually executing programs on behalf of clients, it needs all the processor (and memory) you can give it. If your server is primarily providing file and print services and is running a fast Pentium or better, it's probably a waste of time to look at processor performance. If it's also providing application server functions, however, check the following items:

• Examine the Processor ➝ % Processor Time counter. If this value has a sustained average of 90% or more, your server may need a faster processor (or more processors), or it may not. You may have a poorly written client application or a system service that is consuming excessive processor ticks.

To find out if this is the case, examine the Process ➝ % Processor Time counter for each instance of all likely processes, or use the PMON.EXE utility provided with the Resource Kit to view this data. Another quick way to get an idea of processor utilization is to use the Task Manager. To do so, press Ctrl-Alt-Del to bring up the Windows NT Security dialog, click Task Manager, and then the Processes tab. The resulting display shows each active process, the amount of memory it is using, its current CPU utilization, and the total CPU time it has consumed. You can sort on any of these values by clicking the column header.

On a normal server, the System Idle Process will be at or near the top of the list in CPU utilization. If you find another process that is either consuming a large percentage of the CPU or has a high value for CPU Time, that process is a candidate for the culprit. You may find that you have a rogue process that is apparently running normally, but is consuming nearly all of the CPU. You may also find that you have a zombie process--one that you quit but it failed to go away.

For example, while writing this booklet, I exited Word one evening and went to bed. When I started work the following morning, I noticed that the system seemed to be responding very slowly. I used Task Manager to examine the running processes. I found that Word was still active, although the Applications tab showed it as "Not Responding." It was, however, taking 99% of the processor. Granted, Word is not the most usual application to be running on a server, but the concept remains the same. Any application or service may have a bug that causes the process to run out of control and consume processor resources.

• Examine the Processor ➝ Interrupts/sec counter to determine whether excessive processor utilization is due to a hardware device generating excessive hardware interrupts. On a normal server, this counter may have a value of 100 at idle, and perhaps 200 to 300 under load. If this value has a sustained average of 500 or more, you may have a hardware device--typically a network interface card or a disk host adapter--that is spewing spurious interrupts. If this value exceeds 1,000, you almost certainly have a hardware problem. To verify this, examine the System ➝ System Calls/sec counter, which measures the frequency of calls to Windows NT system service routines. If the Interrupts/sec counter value greatly exceeds the System Calls/sec counter, a malfunctioning hardware device is almost a certainty.

If your testing indicates that the server is processor-bound, there are several possible solutions:

• Relocate processor-hungry applications to another, more lightly loader server, or, if the application can be run after hours, use the scheduler service and the AT command to run it. If the application was written in-house, rewrite it to be more efficient in processor utilization.
• Use Task Manager to alter the priority of applications and services, or you can start them with a command-line switch to set their priority. By default, most applications and services run at Normal priority. You can right-click an image name in Task Manager and set the priority to Low, Normal, High, or Realtime. Whatever you do, don't run a processor-bound application at Realtime priority. You'll never get your server back.
• Upgrade the I/O controller drivers, or replace the controllers with better models. In particular, inexpensive or older SCSI host adapters and network interface cards often place a large load on the processor. Early 100 Mbps network adapters were notorious for generating excessive processor loads. I recall seeing one model that, on its own and at idle, consumed more than 50% of a Pentium processor.
• Upgrade to a faster processor, or add additional processors. In a resource sharing environment, e.g., a file server, a faster processor will often provide more benefit than an additional processor. In a client/server environment that uses multiple threading, e.g., Microsoft BackOffice, multiple, slower processors will usually outperform a single faster processor.

Optimizing Disk Performance

Disk performance is critical to any server, both directly and indirectly. In a direct sense, high disk performance provides better response to users and applications by delivering data faster. Program load times are shorter, database files are searched faster, and so forth. In an indirect sense, high disk performance benefits paging file operations, and so benefits the overall performance level of any server that uses paging--which is to say, nearly any server.

If you think your server is disk bound, the first thing to do is check memory, as described in the preceding section. Disk bottlenecks are usually due to memory bottlenecks, and until you eliminate the memory bottleneck, it's almost impossible to resolve disk performance problems.

NOTE: At this point in every Windows NT book I've seen, the author feels obligated to warn the reader that, to run Performance Monitor disk analyses, he must first load special drivers, and that these drivers shouldn't be left loaded because they adversely impact disk performance. Wrong.

Well, the part about the special drivers is right. You need to run diskperf-y from a command prompt and then restart the server before you can monitor Disk object counters. The part about them adversely impacting disk performance is a holdover from olden times, however. On a slow 486 server, these drivers cost you a performance hit in the 0.25% to 0.50% range. On anything faster, the theoretical performance hit is lost in the noise.

If you've eliminated memory bottlenecks on your server, it's worthwhile checking for disk bottlenecks, whether your server is primarily providing file and print services or is an application server. Check the following items:

• Examine the Physical Disk ➝ % Disk Time counter. This counter indicates the percentage of elapsed time that a disk drive is busy reading and writing. If this value has a sustained average of 70% or more, that physical disk is a bottleneck.
• Examine the Physical Disk ➝ Current Disk Queue Length counter. This instantaneous counter indicates the number of disk requests outstanding when the sample was taken. If this counter has a sustained value of two or more, that physical disk is a bottleneck.

If your testing indicates that the server is disk-bound, there are several possible solutions:

• Use the most efficient bus type available on your server for the host adapter. If you have ISA and EISA slots, put the host adapter in an EISA slot. If you have EISA and PCI slots, use a PCI host adapter. If you have ISA and VLB slots, use a VLB slot for the host adapter (but you really need a better server).
• Install a better host adapter. Inexpensive host adapters are often slow and inefficient, and place a significant burden on the processor. Better (and more expensive) host adapters transfer data faster, with less overhead, and do not load the processor. As a rule of thumb, if the SCSI host adapter you are using sells for less than $300, it may be causing a bottleneck.
• Move to a better drive technology. If you're using EIDE now, move to some form of SCSI. If you're running an older, slower, narrower type of SCSI, move to the latest, greatest, fastest, widest, highest numbered SCSI. When you choose drives, give greater weight to the seek time than to the transfer rate. Fast seeking, particularly on a server, is much more important than data transfer rate.
• Install more RAM in the server. Even if you are not memory-bound, Windows NT will devote additional RAM primarily to caching, improving the performance of the disk subsystem.
• Use RAID: RAID 0 striping and RAID 1 mirroring/duplexing can greatly improve disk subsystem performance by distributing activity among multiple spindles. RAID 5 striping with parity can achieve similar improvements at low cost, while protecting your data against drive failures.
• If your server has multiple disk drives, consider what data is stored on each. In my consulting practice, I often find a server that has multiple disk drives, but with 90% or more of the activity being serviced by only one of the drives. Distribute data across the drives to take advantage of having multiple spindles.
• Make sure that your disk drives do not become too full. Consider two disk drives whose specifications are identical except that one is 2 GB and the other 4 GB. If you store 1.9 GB of data on each drive, the larger drive will outperform the smaller drive every time, and by a significant margin. If both drives have a 9 ms average seek time, the smaller drive will in fact require nearly 9 ms for the average seek because its heads may have to move anywhere on the disk surface. The larger drive, however, seeks much faster, because the drive heads spend all of their time on the half of the drive than contains data, giving the 4 GB drive an effective seek time of about 4.5 ms. Note that severe fragmentation can reduce the advantage of the larger drive.
• Use the NTFS filesystem on any but the smallest of disk drives. If you use the FAT filesystem on any drive larger than about 500 MB, performance suffers relative to NTFS.

Optimizing Network Performance

Here's a topic that's difficult to cover in any reasonable amount of space. Even scratching the surface would require an entire book, and treating this subject in depth would require a complete library. Still, there are some items that have a major effect on the efficiency of the network and that are easily checked. For more detailed information, see the Windows NT Server 4.0 Resource Kit.

Server optimization level

Windows NT Server has four preconfigured server optimization levels. These levels determine how various server resources (e.g., file cache) are allocated within the Server service, and what priority is assigned to various processes. Choosing the appropriate level for your server, depending on its usage pattern, is a very important factor in ensuring responsiveness.

To configure server optimization level, right-click the Network Neighborhood icon to display the Network dialog. Click the Services tab to display the Network Services page, and highlight the Server service. Click Properties to display the Server dialog. Choose one of the following option buttons:

Minimize Memory Used

Choose this option button for a small server that supports 10 or fewer clients.

Balance

Choose this option button for a general-purpose server in a medium environment--64 or fewer clients.

Maximize Throughput for File Sharing

Choose this option button for a server on a large network that is providing primarily file and print sharing services. Setting this option enables LargeSystemCache in the Registry, giving file cache access priority over user application access to memory.

Maximize Throughput for Network Applications

Choose this option button for a server on a large network that is configured as an application server. Setting this option disables LargeSystemCache in the Registry, giving user application access priority over file cache access to memory.

Note that this setting benefits an application server only if it is running client/server applications that do not do their own caching. If you are running client/server applications, like Microsoft BackOffice, that do their own caching, choosing the Balance server optimization level will yield better overall network performance.

After you have set the appropriate server optimization level, close the Network dialog and restart the server so that the change will take effect. Examine the Server ➝ Pool Nonpaged Failures, the Server ➝ Pool Paged Failures, and the Server ➝ Work Item Shortages counters. If these counters are increasing, or if Server ➝ Context Blocks Queued/sec has a value greater than 20, the Server service is incapable of keeping up with I/O requests from clients. If the proper server optimization level is in effect, this may be caused by the server being overloaded due to inadequate processor, memory, or disk resources.

Workstation service (redirector object)

When users or applications access a redirected drive, the request is processed by the appropriate redirector. For example, the Windows NT Server Workstation service processes Windows Networking redirection requests, and the Gateway Service for NetWare processes NetWare redirection requests. The redirector forwards the request to the appropriate transport protocol, e.g., TCP/IP or NWLink, which places it on the network for transmission to the appropriate server. In general, the performance of the redirectors is strongly dependent upon the performance of the server. However, there are some issues specific to the redirectors to be considered.

• Examine the Redirector ➝ Current Commands counter. This counter indicates the numbers of redirection requests that are currently queued and awaiting service. If this value consistently exceeds the number of network interface cards installed in the server, a serious bottleneck exists.
• Examine the Redirector ➝ Network Errors/sec counter. Any nonzero value for this counter indicates that serious network communications problems exist. When a network error occurs, SMB requests are timing out, which requires the redirector to drop the connection, reconnect, and attempt to recover.

If you run multiple redirectors on the server, one of the most important things you can do to improve performance is select the proper provider order. When a network call occurs, Windows NT Server routes the call to the first provider listed, and awaits a response from this provider. If that provider responds that it is unable to service the call, Windows NT attempts the next provider, and so forth. For example, if NetWare or Compatible Network is the first Network Provider listed, and Microsoft Windows Network is the second, all network calls are routed to the NetWare or Compatible Network Network Provider before being routed to the Microsoft Windows Network Network Provider. If most network calls in fact need to be serviced by the Microsoft Windows Network Network Provider, using this Network Provider order slows performance needlessly by introducing an extra step for most network calls.

Because Windows NT Server uses providers in the order specified, and because the order that it selects itself may not be the most appropriate for your environment, you should examine provider order and configure it manually to match your environment. To do so, right-click the Network Neighborhood icon on the desktop, and select Properties to display the Network dialog. Click the Services tab to display the Services page, and then click Network Access Order to display the Network Access Order dialog. Expand the tree as necessary, highlight a service provider, and use Move Up and Move Down to rearrange the order in which providers are accessed.

Transport protocols

Transport protocols move data between stations on the network. Windows NT Server includes three major transport protocols--NBF (NetBEUI frame), TCP/IP, and NWLink. It also includes two minor transport protocols--DLC and AppleTalk. When Windows NT Server is operating in a NetWare environment, there are almost always at least two major transport protocols in use--TCP/IP and NWLink--and often all three are being used. If you have two or more transport protocols installed on your server, a potential bottleneck exists.

Network bindings describe the connection relationships between transport protocols, network interface cards, and system services. For example, if a network interface card is to be used to communicate IP packets and IPX packets, both the TCP/IP protocol and the NWLink protocol must be bound to that network interface card. Similarly, if the DHCP Server service is to communicate with TCP/IP on a particular network interface card, that service must be bound to the protocol and the card.

The first rule to follow to eliminate unnecessary transport protocol overhead is to bind only the transport protocols that are needed. For example, if you have a dial-up adapter that will be used only to provide a TCP/IP connection to a remote office, make sure that you don't have NWLink or NetBEUI bound to that adapter.

The second rule to follow is to arrange the order of the bindings to suit your own environment. When a connection to a shared resource is requested, the redirector simultaneously submits the request to all of the installed transport protocols. When it receives a response, it does not act upon it immediately, but instead waits until all higher priority transport protocols return a response. The location of a particular transport protocol on the bindings list determines its priority. Placing the transport protocol that will be used by most stations first on the bindings list decreases the average connection time.

To remove unneeded bindings, or to alter the order of necessary bindings, right-click the Network Neighborhood icon on the desktop, and select Properties to display the Network dialog. Click the Bindings tab to display the Bindings page. Use the Show Bindings for drop-down list to specify how you want the bindings displayed, and then expand the display as necessary to show the individual bindings you are interested in. Use Enable and Disable to set the correct bindings as active, and then use Move Up and Move Down to rearrange the access order.

Network Interface Card

The Network Interface Card (NIC) itself is a bottleneck on many servers. To determine if this is the case on your server, first calculate the throughput that your media access method provides. If you are running 10 Mbps Ethernet, for example, your total theoretical throughput is (10,000,000 bits/second) / 8 bits/byte, or 1.25 million bytes per second. Network overhead, collisions, and so forth, realistically limit actual Ethernet throughput to perhaps 80% or less of nominal--something less than 1 Mbps. Similarly, 16 Mbps Token Ring provides theoretical throughput of 2 million bytes per second, with actual throughput approaching that figure.

Next, examine the Server ➝ Bytes Total/sec counter. This counter measures the actual number of bytes per second that are sent by and received by the NIC. If this counter has a sustained value at or near the actual throughput of your NIC, then the NIC is a bottleneck. If the server itself is capable of substantially higher throughput (as is any modern server), this potential is wasted because the NIC is unable to transfer data any faster than it is already doing.

There are several possible solutions to this problem, but all of them require substantial changes to the network. You might segment the network into subnetworks; replace the existing media access method with a faster one (like 100BaseT, 100VG-AnyLAN, or FDDI); install a high-speed backbone to link servers; or install switching.

Windows NT Registry Nuts & Bolts

Advantages Offered by the Registry

The Registry offers a number of significant benefits to programmers, users, and administrators. These benefits stem from the characteristics I just described.

It Keeps Everything Tidy

Instead of the dozens (or even hundreds) of separate INI files typically found on a Windows 3.1 machine, NT machines usually only have a few--and those typically belong to 16-bit legacy applications that can't use the Registry. NT itself uses the Registry for its configuration data, as do almost all 32-bit applications for Win95 and NT. There's more to tidiness than just the reduction in clutter that comes from eliminating INI files, though. Centralizing where configuration information is stored makes it easier for administrators to back up, restore, and secure the data.

It Provides Security

Access control for the Registry comes in two sizes. First, you can set individual workstations or servers to disallow any remote Registry connections at all. While this is secure, it also makes it impossible to use the System Policy Editor to set and inspect policies on that machine. A better and more fine-grained solution is to use NT's built-in access control lists. As I mentioned earlier, each Registry key, from the root keys on down, can have its own individual set of access permissions in the form of ACLs that apply to the keys.

Each entry in an ACL actually has two parts: a permission (as shown in Table 1) and the account or group name that holds the permission. ACL permissions are usually written like this, with the holder first and the permission following:

Any account or group that is listed in the ACL will have the matching permission; any group or account that's not in the ACL will have no access. This gives you precise control over Registry access, since anyone you don't explicitly include in an ACL won't have any access.

In addition to whatever accounts you've got defined on your workstation or domain, you can use the built-in NT accounts and groups. In particular, you'll see the Everyone account[6] used to grant read access to most keys in the Registry, while the Administrators and Domain Admins groups usually have Full Control access to all keys. Since many NT software installers require write access to the HKEY_LOCAL_MACHINE\Software and HKEY_CURRENT_USER\SOFTWARE subkeys, you'll often see them tagged with Everyone:Full Control. It's also worth mentioning the SYSTEM account name; SYSTEM refers to processes and services owned by the kernel, so it's usually used to grant Full Control access to many of the keys in HKEY_LOCAL_MACHINE.

Besides their access controls, Registry keys also have owners; for example, the Administrators group owns the HKEY_LOCAL_MACHINE\HARDWARE subkey. You can restrict access to parts of the Registry by changing their ownership to a single account to which you control access; since any account that's not in an ACL won't have any access, everyone except the owner will be locked out.

As an additional security feature, NT allows you to create an audit trail of access to, and operations on, the Registry. When you enable auditing for a key, you specify two things:

What actions you want audited

You can create an audit trail of the success or failure (or both) of all of the permissions in Table 1 except Read, Full Control, and Write Owner.

Which accounts will be audited

The accounts you specify will generate audit trail entries when they attempt one of the actions you specify.

The auditing data is written to NT's system event log, where you can view it with the Event Viewer application or parse it with programs or scripts you've written.

It Allows Remote Management

Every computer running NT has a Registry. If you're supporting more than one NT machine on a network, you'll be happy to know that the Registry supports network inspection and modification. This capability, which is built into RegEdit and RegEdt32, allows you to troubleshoot and fix some types of Registry problems on network machines from your desktop. In addition, network Registry access makes it possible to automatically inspect the Registry of every machine on your network--a valuable way to gather statistical ("how many of our machines are still running Netscape Navigator 2.x?") or configuration ("what machines have impala.oreilly.com as one of their DNS servers?") data.

NT's system policies require network access to the Registry; there are also a number of useful administrative tools and utilities that build on network Registry access. For example, the ERDisk product from MWC (http://www.ntsecurity.com/ ) allows you to build an Emergency Repair Disk (ERD) for a machine across the network; in fact, you can automatically build updated ERDs for all the machines on your network every night if you like. Microsoft's System Management Server (SMS) product makes heavy use of network Registry access, as does NT 5's Microsoft Management Console.

Footnotes

6. Everyone's not really an account; it's a special token that matches any account in the SAM database, but you can use it anywhere in NT that you could specify a "real" account. NT 4.0 SP3 also includes the new Authenticated Users token, which is similar.

Dynamic Host Configuration Protocol (DHCP)

Planning DHCP for Large Networks

Planning DHCP for a large, complex network (or internetwork) is considerably more involved than doing so for a simple network. Although there is essentially no theoretical upper limit to the number of clients that a single DHCP server can support, practical limits appear on real-world networks because of issues like IP address classes, subnet topologies, redundancy needs, and server bottlenecks.

If such a thing exists as a "typical" arrangement for a complex network, it might look something like this:

• The network is arranged in logical subnets that match the physical structure of the internetwork.
• One IP subnet serves as the backbone, with physical subnets branching from this backbone, each of which is defined as a separate IP subnet.
• Each subnet contains a single Windows NT Server computer that is configured as both a DHCP server and a WINS server. Each of these servers administers a defined range of IP addresses with a specific subnet mask, and is defined as the default gateway for its subnet. Because this server is also a WINS server, it can provide NetBIOS name resolution services to all hosts on its subnet.
• These DHCP and WINS servers can each serve as a backup for the other servers. The administrator partitions the address pool and allocates it among the servers, allowing each server to provide addresses to remote clients.

Beyond this one-size-fits-all generic approach, when you implement DHCP on a routed internetwork, your planning should encompass the issues described in the following sections.

Routing issues

The defining characteristic of a complex network is that it uses routers to connect subnets via LAN or WAN links. Therein lies a difficulty, because DHCP is a broadcast protocol, and some routers simply discard DHCP broadcast packets instead of forwarding them.

Routers that implement the DHCP/BOOTP relay agent (as defined by RFC 1542) forward DHCP broadcast packets properly, and are referred to as RFC 1542-compliant. Many routers, particularly those that are intended primarily as IPX routers and route IP only as an adjunct, are not RFC 1542-compliant. On RFC 1542-compliant routers, the relay agent intercepts DHCP broadcast requests from clients on its local subnet and forwards those packets to a DHCP server on a remote subnet. When the DHCP server responds, the router forwards the response to the local client.

Even if your routers are RFC 1542-compliant, your goal should be to minimize b-node broadcasts across the routers, particularly on slow WAN links. Accordingly, your existing subnet topology and the types of routers you have installed will have a distinct impact on how many DHCP servers you need and where they must be placed. If all or some of your routers are not RFC 1542-compliant and cannot be upgraded to become so, you have two alternatives:

• Install additional DHCP servers--Install one or more DHCP servers on each subnet that connects to your network with a non-compliant router.
• Use the Windows NT DHCP Relay Agent--If your routers can't pass DHCP broadcast packets, and you don't want to place DHCP servers on each subnet, the final alternative is to install the Windows NT DHCP Relay Agent. A relay agent is a program used to pass specific types of IP packets between subnets. The DHCP Relay Agent performs this function for DHCP and BOOTP packets according to the RFC 1542 specification.

Having the ability to move DHCP broadcast packets across a router--either via compliant router hardware or the DHCP Relay Agent--is probably the single most important component in planning and implementing DHCP in a large-scale environment. Being able to cross routers gives you flexibility. For example, if a DHCP server on one subnet goes down, clients on that subnet will still be able to use a DHCP server on another subnet. If your network is not configured to allow DHCP broadcast packets to cross routers, all of your troubles are amplified. Not only must you provide a DHCP server for each subnet, but you have to worry about what happens when that DHCP server fails.

Redundancy issues

Once implemented, DHCP becomes a critical part of your network. If no DHCP server is available, clients cannot initialize TCP/IP. The reasons to establish redundancy and the methods for doing so are similar to those in a simple network, but are complicated by the presence of multiple subnets and routers.

If, for one reason or another, you are unable to provide redundancy on a particular subnet--perhaps one located at a small branch office--consider not using DHCP at all for that subnet. Instead, configure static IP addresses and other TCP/IP parameters for hosts on that subnet, and exclude those addresses elsewhere on your network.

Traffic issues

Although DHCP is a broadcast protocol, DHCP normally has little effect on network traffic. DHCP traffic occurs on the network in the following situations:

• IP address lease--The initial discovery and lease process generates only four packets (plus an additional packet for the second and subsequent DCHP servers that respond). The entire exchange totals either 1,368 bytes (4*342) or 1,864 bytes (2*342 + 2*590), and takes only a fraction of a second on a lightly loaded Ethernet. The same process occurs if a client is moved to a different subnet, or if the network adapter in the client is replaced.
• Automatic renewal--This process requires only two packets (Dhcprequest and Dhcpack) and requires even less time than the IP address lease process. If the lease duration remains at the default of three days, the automatic renewal process occurs only once every 36 hours.
• Ipconfig--If a client uses the ipconfig utility to manually refresh or release its address. It takes only a fraction of a second to transmit the data over an Ethernet and this process occurs only when invoked by a user.

In the ordinary course of events, therefore, DHCP traffic can usually be safely ignored for planning purposes. At least one exception exists, however. Some networks have many clients that are started almost at the same time--usually at starting time and right after lunch. When this occurs, the network may be very heavily loaded, particularly if clients are configured to download profiles or start applications from a network drive.

We have seen Ethernet utilization climb above 95% in situations like this, which means that almost no traffic is getting through due to all the collisions. In such a situation, not only may DHCP be unable to function, it may actually add to the problem because of re-broadcasts by DHCP clients that are unable to obtain a response. In the worst-case scenario on a very heavily loaded network, a DHCP client may require literally minutes to boot (in approximately 5 minute increments because of the 5 minute timeout retry period).

Of course, this is not really a DHCP traffic issue so much as it is a philosophical one. The solution is to either leave your client computers running all the time (which is probably a good idea anyway), or to subnet the network and install as many additional DHCP servers as are necessary to ensure acceptable response time to DHCP client requests. Using either solution also makes the DHCP boot-time problem go away.

DHCP scope issues

The Microsoft DHCP server allows you to define DHCP options globally, for a specified scope, or for an individual client. DHCP option values defined specifically for a client override values for the same option defined at the scope level, and values defined at the scope level override those defined at the global level.

Defining DHCP options in a complex network requires some thought. Defining the scope for a DHCP server on a local subnet defines the required DHCP options--IP address range and subnet mask--for hosts on that subnet. If hosts on that subnet are to be able to communicate outside the subnet, you must also define a default gateway with the 003-Router DHCP option.

Beyond this, things get a little hazy. If that DHCP server is supporting only clients on its local subnet using a single scope, it makes little difference whether you define DHCP options at the scope level or the global level. If that DHCP server is also supporting clients on other subnets--either as the primary or backup DHCP server--you have to consider which options need to be defined globally and which for the local subnet only.

For example, if your company has only one DNS domain name, you might define 015-Domain Name globally, because clients on all subnets that use this DHCP server will use the same domain name, so all scopes should inherit it from Global DHCP options. Conversely, if the DHCP server supports multiple scopes that map to different subnets, you would have to define the value for 003-Router at the scope level.

In conjunction with this, you must coordinate scopes between the subnets. For example, assume that you have two DHCP servers, A and B. Each is the primary DHCP server for its own subnet. DHCP server A serves subnet 192.168.115 and DHCP server B serves subnet 192.168.116. However, you would also like DHCP servers A and B to back each other up. This means that you need to define two scopes on each server, and that you must reserve a portion of the available IP address range on each subnet to be defined as the secondary scope on the server on the other subnet.

For example, on DHCP server A you might define a primary scope that encompassed 192.168.115.1 through .175, reserving the remaining addresses for DHCP server B. On DHCP server B, you might define a primary scope that encompassed 192.168.116.1 through .175, reserving the remaining addresses for DHCP server A. You would then define the secondary scopes--192.168.116.176 through .254 on DHCP server A and 192.168.115.176 through .254 on DHCP server B.

Dynamic Host Configuration Protocol (DHCP)

# tar -xp /home/chavez/freeway/quake95.data
# cpio -im '*quake95.data$' < /dev/rmt0
# tar -xp /home/harvey
# cpio -imd '/home/harvey*' < /dev/rmt0

$ restore options arguments [ files-and-dirs ]

# cd /home
# restore xf /dev/rmt1 chavez/mystuff others/myprogram

$ restore -x -f /dev/rmt1 chavez/mystuff others/myprogram

$ restore if /dev/rmt1 Initiate restore's interactive mode.
restore > help
Available commands are:
   ls [arg] - list directory
   cd arg - change directory
   add [arg] - add `arg' to list of files to be extracted
   delete [arg] - delete `arg' from list of files to be extracted
   extract - extract requested files
   ...
If no `arg' is supplied, the current directory is used
restore > ls List directory on tape.
 chavez/    harvey/     /ng

restore > cd chavez/vp Change tape directory location.

restore > ls
 v_a.c           v_a1.c          v_b3.c          v_d23.c
 v_early

restore > add v_a1.c Select (mark) files to be restored.
restore > add v_early
restore > ls
 v_a.c          *v_a1.c          v_b3.c          v_d23.c
*v_early
restore > delete v_early Remove a file from the extract list (unmark).
restore > extract Write selected files to the current disk directory.
restore > quit End the restore interactive session.

Footnotes

1. The second cpio command also assumes that there is no file or directory in /home that begins with “harvey” other than user harvey 's home directory.

Essential Windows NT System Administration

Manipulating Print Jobs

The other important aspect of printer administration is monitoring the status of the various print queues and devices on the network and modifying individual jobs within them.

The contents of a print queue can be displayed by double clicking on its icon in the Printers folder, which produces a list of jobs and their current status. Selecting a job and then choosing the Document➤Properties menu path displays the job's properties (Figure 9-11).

Information about the job appears in the upper portion of the dialog box, and users may use the Priority and Schedule areas to modify the job's in-queue priority and time restrictions on when it may print (respectively). In the latter case, the settings you specify must conform to any restrictions currently set for the printer itself.

A selected job may also be paused or canceled using other items on the Document menu (see Figure 9-12). The Resume item is used to continue the printing of a paused job from its current point, and the Restart item will reprint a current print job from the beginning. A job may be removed from the print queue with the Cancel item or by pressing the Delete key.

Similarly, the Printer➤Pause Printing menu item may be used to pause a print queue after the current job completes (a check mark next to the menu item indicates that it has been selected, and selecting it a second time will resume the queue). Use the Printer➤Purge Print Documents menu path to clear out the entire contents of a print queue.

The net print command may be used to perform these same tasks from the command line for any Windows print queue on any network-accessible system. For example, the following command displays the jobs in the queue Picasso on system vala:

C:\> net print \\vala\picasso
Printers at \\vala
 
Name                         Job #      Size            Status
-----------------------------------------------------------------------picasso Queue              3 jobs                      *Printer Active*
     ADMINISTRATOR               8   4596310            Printing
     CHAVEZ                      9     23453            Waiting
     WILL                       10   1264456            Waiting
The command completed successfully.

This print queue is currently printing a job, and there are two others waiting.

The command has the following syntax when used to manipulate a print job:

net print \\host\printer n /cmd

where n is the job number of the job you want to modify, and cmd is hold, delete, or release (all are options preceded by a forward slash).

Finally, the PQCount freeware utility (written by Scott Lemieux) may be used to create a quick status display for a print queue. It takes a hostname as its argument. For example, the following command produces the display for system vala shown in Figure 9-13.

C:\> pqcount \\vala.


Figure 9-13. 
The PQCount utility display 





 

The display is automatically updated periodically. Clicking on the display window provides access to its File menu, from which you may close the display.

This program relies on the Admin$ administrative share for access to print subsystem information. You can create this share if it does not exist via the Server Manager's Computer➤Shared Directories... menu path.