- Shopping Bag ( 0 items )
Ships from: Chatham, NJ
Usually ships in 1-2 business days
Ships from: acton, MA
Usually ships in 1-2 business days
- About This Book
How to Use This Book
Who Are You, Anyway?
How This Book Is Organized
- Part I: Introducing Local Area Networks
Part II: The Wonder of Workgroups
Part III: Networking with Windows NT Server
Part IV: The Part of Tens
- Icons Used in This Book
Where to Go from Here
Chapter 1: A Network Is Just Like Tin Cans and String -- Only Better!
What's a Network?
Making Networks Work
What Do Computers Say to Each Other?
What's Normal? Network Industry Trends
Touring the Facilities
- First stop: Your desktop
Next stop: Servers do the servicing
Final stop: The glue that binds it all together
- How Software Uses the Network
- Asking for services isn't asking for favors
What services are available?
- Sharing Resources Is the Greatest Good
Chapter 2: Making Connections, or Lost in the Wires
Oh, What a Tangled Web We Weave...
What's This Cable Here?
- Twisted-pair cabling: TP or not TP
Watch that wire!
A spec for every spot
- Home of the Brave: Tips for Do-It-Yourselfers
It's a Topology, Not a Wiring Layout
- Now starring...
On or off the bus
Ring around the network
- Brand X Basics
Introducing the Contestants
- Entertaining Ethernet
Strengths and weaknesses
All flavors are available
Getting down to business
Let's talk token ring
Strengths and weaknesses
All flavors are available
Getting down to business
Strengths and weaknesses
All flavors are available
Getting down to business
Proprietary, like ARCnet used to be
Strengths and weaknesses
Getting down to business
What else is there?
- The Polls Are In!
Chapter 3: Message in a Bottle: Mastering the Art of Protocols
How Do Computers Talk to Each Other?
DWIM -- Do what I mean!
- Standardized rules
Why not, indeed?
- According to Protocol
- Suites for the...never mind!
A protocol's work is never done
- The Dance of the Seven Layers
Chapter 4: Rounding Up the Usual Suspects
Warning: Entering the Acronym Zone!
You Can't Tell the Players without a Program
- DLC: Golden oldie
IPX/SPX: The basic NetWare protocols
The government protocols: TCP/IP
Other faces in the gallery
AppleTalk: Making the Mac connection
Keep going -- there's more!
- Mixing Protocols: Hybrids
What's What on Your Desktop?
Chapter 5: NICs and Knocks: Understanding Network Interface Cards
What's in Your NIC?
Catching the Bus: ISA, EISA, VLB, or Micro Channel
- ISA and EISA
The local run: VLB and PCI
Micro Channel: A better idea?
Which bus gets you where you want to go?
- Avoid Trouble: Get Off to a Good Start
- Unplugged -- it's not just for MTV
Getting back to the beginning
Figure out what you're dealing with
Be on the lookout for trouble
Room to maneuver
The lay of your LAN
- Beware the Golden Fingers
How to Read a Manual
- NICcus interruptus
Defaults, dear Brutus...
Any I/O port in a storm
Direct access: Setting the DMA
Running the bases: The MemBase setting
- In the Driver's Seat
Cabling Up to the NIC
Looking for Trouble in All the Right Places
Chapter 6: This LAN Is Your LAN
Time to Make a Map
Formalizing Your Network Map
- Start at the beginning
Put it on the map
- Building a Network Inventory
Keeping Up with Developments
Getting Software to Work for You
Chapter 7: Living Off Your LAN
Paying Now or Praying Later
- Contented users are quiet users
What can you do to make them leave you alone?
Keep the network running at all costs
Schedule downtime and spread the word
Keep an eye out for trouble
Educated users are better than ignoramuses
Keep an eye on growth
Get your report card regularly
- Upgrades, Uprevs, and One-upmanship
Getting Help When You Need It
Building a Routine
Noticing the Obvious
Keeping It Clean
Beyond the Network
Chapter 8: Taking the "WORK" Out of NT Workstation
A Group-er Isn't Just a Big Fish
- Blue velvet workgroups
Group-ers swim peer-to-peer
Isn't size what counts?
Who's in charge?
- Serve It Up Hot and Fresh!
Hard and Soft: These Are the Wares
Get Ready to Rumble!
- Distribute the net, distribute the problems
Chapter 9: Take the Stall Out of the Install
Min to the Max
Making Preinstallation Decisions
- Stiffy or floppy?
Know your network
Gotchas and other flotsam
- Prepare to Start at the Beginning
- Phase one: Getting started
Phase two: GUI and sticky
- Manage the Unmanageable with User Manager
Share and Share Alike
Connect the Dots: Clients Akimbo
Print All Night, Print a Little Longer
Roses Are Red, but What If You're Blue?
It's a Great Big Ol' World
Chapter 10: NT Stands for Network This!
Take Me Away, Protocol: Transports Make It Happen
- NWLink: Your link to NetWare servers
TCP/IP: From Internet to intranet to everynet
NetBEUI: Blast from the past
AppleTalk: Do the Mac thing
DLC: Mainly for mainframes
Mix and match: Stir it up!
- The Control Panel's Network Utility: Get a Grip!
Keep RASing Me: Dial-in and Dial-out
And Now for Something Similar
Chapter 11: NT for Life?
NT Workstation to the Rescue!
Peer, Peer, Pumpkin Eater
Movin' on Up
Living in a Diverse Network World
Make Up Your Mind
Chapter 12: A Road Map to Windows NT Server
What's the First Thing Adam and Eve Wanted to Do? Network!
The Network Speaks: NetBIOS, then NetBEUI, then IPX and IP
- NetBIOS and NetBEUI
IPX and the packets that BURST!
The Internet protocol: TCP/IP
- LAN Man's the Man!
NT Rises from the DEC Ashes
- Taking NT to the nth degree
NT 3.5 is almost there
Look into the crystal ball: The future of NT
- NT on Parade: A Retrospective
Chapter 13: SCSI-Wuzzy Wasn't Fuzzy, Was (S)he?
Plumbing the Hardware Interface
Configuring NT for SCSI Devices
SCSI Configuration Tools and Techniques
Other sources of information and inspiration
- SCSI Devices Unveiled
- SCSI is for hard disks, too
- Avoiding Preinstallation Jitters
When Trouble Comes, Ask Questions First, Shoot Second
Doing the Update-Upgrade Shuffle: Dealing with Devices
Chapter 14: Connecting Your NT Network
Examining Client-Side Differences
Lower than a Snake's Belly: Bringing the Server Down
Lightning Can Be a Real Charge!
Look, Ma -- It Eats Out of My Hand!
Backups, Backups, and More Backups
Documentation, Documentation, Documentation
Did We Mention Backups, Backups, and More Backups?
Meet a Different UPS
Chapter 15: Making NT Server Communicate
Understanding Network Dial-Out and Dial-In
- The server side of RAS
The workstation side of RAS
- What Does RAS-Aware Mean?
Making Good Connections: Handling RAS Hardware
Installing RAS with Class
- Installing RAS on your NT 4.0 server
Installing RAS on your client PCs
Chapter 16: Communicating with NTS
Installing DOS/Windows RAS Clients
Installing Windows for Workgroups RAS Clients
Phone Book Setup
Installing Windows NT Workstation RAS Clients
Installing Windows 95 RAS Clients
The RAS Protocols
- Administrator utility
- Internetworking with RAS
Chapter 17: The Properties of Protocols
IPX/SPX Spells Success
- Stellar lineage
Pluses and minuses
- TCP/IP: The Little Protocol That Could
DLC with Some TLC
What To Do?
Stacking Protocols: A Virtual Smorgasbord
Chapter 18: What's in a Name?
What's So Keen about Naming Services?
- NetBIOS names
Protocol addressing differences
- Understanding WINS
- The desired method: Automated updates
- Doing the DHCP Thing
Serving Up and Replicating Domains
NT's Trust Relationship
Chapter 19: The File System: Center of the NT Universe
The NTFS View on Files, Directories, and More
Navigating the Server
Utilities, Applications, and More
How to Use the File System
Your Server versus Computer Viruses
No Rest for the Weary: Take Care of Business
Chapter 20: Network Security: It's Not a Game!
Keeping Watch: Setting Up the Right Controls
It Ain't Easy Being an NTS Supervisor
If You Want Help, Do This
Using Other Empowered Entities
The Easy Way Out: Tips for Setting Permissions
Stand Up for Your Directory, File, and Object Rights
- Setting shares
Who may access what?
Individual file and directory permissions
Standard file and directory permissions
- Permission to Assign Permissions
Examining and Changing Access Rights and Permissions
File and Directory Attributes
Chapter 21: Keeper of the Keys: Managing NTS Security
The Ins and Outs of Logging On and Off!
Passwords: How to Build 'Em, Use 'Em, and Keep 'Em Fresh
Security Begins at Home, but It Doesn't End There
And at Your Neighbor's, Too!
Now for Some Audit Checks
Say It Loud and Clear: Intruders Aren't Welcome Here
For Peace of Mind, Keep Servers under Lock and Key
Chapter 22: Hard Copies: Printing in the NT Environment
It's a Small (Printing) World after All
- Born to serve: Print server to the masses
So many printers, so many print queues
Line up and sound off: Print queues
Network print users: The bane of your existence or misunderstood?
- The Romaine Domain: Lettuce Define Printers
Local Yokels: Sharing Local Printers
Cut! It's a Wrap!
Chapter 23: Got Your Backup against the Wall?
Choices, We Hear Choices!
Why Back Up?
Out of Site, but Not Out of Mind
Backup Strategies of the Rich and Famous
Money Talks: On-line, Near-line, and Off-line Backups
- On-line and on time
Near-line: Close, but not quite on-line
Off-line takes time
- Hardware That's Hard to Wear
- Changers and exchangers
CD-ROMs et al.
- Client PC Backups: Can You Afford Not To?
- Standard local directory backups
Full user local hard drive backups
- Disaster Prep: Hope for the Best, but Plan for the Worst
Chapter 24: Mysteries of the Organism: NTS Configuration
An Overview of Installation Basics
- To grow or not to grow?
If it ain't broke, don't fix it
- NT Configuration Utilities
- User Manager
- The NTS Registry Hierarchy
Where to learn more
- Setting Up Groups and Users
Chapter 25: File, Information, and Management Utilities
The NET Word
Common Keyboard Gotchas You Need to Know
A Road Map to the NTS Utilities
- Getting your bearings: File, directory, and disk utilities
Emergency Repair Disk
Windows NT Backup
Windows NT Explorer
Windows NT Diagnostics
Network Client Administrator
Beyond the NTS planet
Chapter 26: Shooting Trouble
Common Troubleshooting for Uncommon Problems
Installation Can Be a Breeze or a Hurricane
Hardware Configuration Problems
Disk Controller Problems
CHKDSK and Check Dat
File System Errors
Poor System Performance
Printing and Not Printing Problems
Troubleshooting RAS Hardware Problems
Chapter 27: Dealing with a Dead Network
Is Anybody Home?
Whoa! "Server Unavailable"
Suddenly, Slow Networking
Can't Get from Point A to Point B
Out of Disk Space
Beating the Blackout Blues
Networks Have Rules for Good Reasons
Correcting Intermittent Problems
Losing Your Log On
Chapter 28: What You Should Know about Your Network
Where's the Wiring?
Where Are Your Connections?
How Long Is Each Cable?
Where's the Gear, and What Do You Have?
Know Your NICs
Your Nodes Know, but Do You?
Dealing with Vendors
The Map's the Thing!
Chapter 29: Ten Things You Must Know Before Anyone Can Help You
Assemble the Facts
Describe the Problem and its Symptoms
What's New or Changed?
What Have You Tried?
Does the Problem Have a History?
Be Clear, Concise, and Polite
Send Information through Other Channels
Can You Do Anything Else?
Chapter 30: Keeping the Peerage Pleased with the Network
Users Must Be Responsible to Each Other
Define a Naming Scheme and Use It Hard!
Dedication Supports Heavy Sharing
Don't Be a File Hog
Common Rules Promote Common Courtesy
Dealing with Error Messages
Back Up Shared Resources!
Smart Users Use Secure Networks
Maintenance Is the Key to Network Salvation
Chapter 31: What You Should Know Before Making Changes to a Windows NT Server
Make Two Complete Backups?
Inspect and Survey the File System
Document the System
Map Network Addresses and Configurations
Master Your Network's Routing
Map Your Print Services
Check the Server Situation
Know Your User Community
Version and Service Pack Check
Chapter 32: The Paths to Print Perfection
You've Gotta Have Drivers
Make Printer Names Self-Documenting
Creating the Right Mix of Logical and Physical
Separating User Communities
The Print Job Must Die!
Chapter 33: Backups Benefit Everybody
Buy Enough Capacity
Automatic Pilot Is the Only Way to Go
If You Miss It, You Lose It!
Store a Backup Off-site
Practice, Practice, Practice!
What about Workstation Backups?
Rotating Media by the Book
Mixing Backup and Routine Maintenance
Choosing a Suitable Backup System
Chapter 34: Success Means Growing Pains Lie Ahead
Flaky Is as Flaky Does
When Delays Become Normal
More Users Than Logons
Chronic Disk Space Shortages
Regular Network Traffic Jams
Dirty Looks in the Hallway
Mystery Guests on Your Network?
Chronic Crashes Signal Imminent Danger
The Backup Won't Fit!
Burned in Effigy
- Build a List and Check It Twice
Write This Down Before Making the Call
Talk the Talk, Walk the Walk
Escalation -- Not Just for Department Stores
One-Stop Shopping: the TSA
Let Your Fingers Do the Walking
Training for the Pros
- Whither the Internet?
- Information please
The best NT mailing list
- Welcome to CompuServe
- Forums for conversation and investigation
Obtaining a CompuServe membership
- What Is the Microsoft Connection?
- Reaping rewards from the Microsoft Connection
Surf the libraries
In This Chapter
Chapter 1 describes the three fundamental components of networking: connections, communications, and services. In this chapter, you leave the wires and interfaces behind and go inside the network to take a look at communications -- how senders and receivers field messages moving across the network.
Communications rely on a shared set of rules for exchanging information and for defining things at the most rudimentary levels, such as how to present digital data -- what's a one and what's a zero? The rules also determine the format and meaning of network addresses and other essential information.
In this chapter, we stick with the plumbing metaphor. You've already looked at the pipes; now it's time to look at what the pipes carry -- messages and data that computers send to each other. This should help you better understand how computers communicate on your network -- and why they occasionally don't.
Table 1-1 compared a computer conversation to a human conversation and showed that any communications between humans or machines have much in common. A trivial difference is that computers use ones and zeroes to communicate and humans use words. There are also some real differences, however. Understanding those will help you understand networking.
In human communication, what's being said is always interpreted and often misunderstood. What one person says is not always what the other person hears. Human communication, like the communication of computers over a network, relies on shared rules and meanings and a common frame of reference.
Computers, however, are linear. They can do only what they're told to do. For computers to exchange information, every piece of that information must be explicitly supplied; computers are not strong on picking up implications and subtlety. To communicate, computers have to begin in complete agreement about the following issues. (The questions are phrased from a computer's point of view.)
These are the fundamentals, but they are only the tip of a large technological iceberg. Before computers can communicate with each other, everything must be completely mapped out and implemented in software that supplies all the answers to these questions in a way that all the computers know and understand. These answers form the basis of a set of rules for computer communications, rules the computers use to handle networking.
Building a complete set of communications rules is time-consuming and picky and would bore most people out of their skulls. In the early days of the computer industry, individual companies or groups put a bunch of programmers to work building programs to do whatever they needed to have accomplished. As time went on, this process resulted in many different ways of doing such things as networking, none of which would work with the way talented programmers over at another company did the same things.
These incompatibilities were not a big deal (or so it seemed) in the beginning. As networks became a more common part of the business landscape, however, it seemed natural for people who bought computers from companies A and Z to wonder, "Well, gee, if my company A computers can talk to each other and my company Z computers can talk to each other, why can't the As talk to the Zs and vice versa?"
Uncle Sam played an important role in bringing order to this potential network chaos. When the government tried to get their A and Z computers to talk to each other, they learned that they had a monster compatibility problem. A consensus emerged that a set of rules was absolutely necessary for networking. The industry also learned that networking was difficult, if not impossible, when everyone didn't share the same set of rules.
If this story had a happy ending, it would be: "Nowadays there's only one set of networking rules, and everyone uses the rules wisely and well." Unfortunately, there's no happy ending. Although the chaos has been reduced, there's still plenty to go around, and vendors trying to stay in the vanguard seem to be inventing more rules as they go.
Just to keep things simple, these "sets of networking rules" are usually called networking protocols -- they're also referred to as networking standards, or even as standard networking protocols. You get the drift.
In diplomacy, protocol is the code of correct procedures and etiquette that representatives from sovereign governments follow to prevent all-out war. For example, protocol is the reason why diplomats refer to screaming matches as "frank and earnest discussions" or to insoluble disagreements as "exploratory dialogue." Political double-talk aside, the word protocol nicely captures the flavor of rules for network communications.
The concept of the networking protocol is based on the premise that any two computers must have an identical protocol in common to communicate; that is, the computers are peers in any communication. The particular protocol defines the language, structure, and rules for that communication.
Although this book is about Windows NT Server and focuses its attention on the Microsoft protocols, you should be aware that these protocols are just one of a large number. Microsoft has become surprisingly catholic in its support for protocols, including support not only for government standards (TCP/IP) but also for the Novell IPX/SPX protocols. That may be because IPX/SPX was built to enable desktop computers, including PCs, to communicate and also because there are more PCs on the nation's desktops than any other kind of computer. And, too, the government's finger is in many pies, and the Internet uses the same protocols, so it is not surprising that NT Server supports today's most popular networking protocols.
Raising the standards
An interesting -- not to say confusing -- thing about networking rules is that both vendors and standards groups call their stuff a "standard." Some vendors expend a lot of hot air talking about the difference between de facto and de jure standards. De facto means "It ain't official, but a lot of people use it, so we can call it a standard if we want." De jure means "It's a standard because XYZ (a standards-setting group) has declared it to be so and has published this foot-high stack of documentation to prove it."
Behind the sometimes heated discussion of what is or is not a standard is a control issue. Purists -- including academicians, researchers, and techno-weenies -- flatly assert that only a standards-setting group can be "objective and fair," and, therefore, only they can adequately handle the job of selecting the very best that technology has to offer by putting it in their standard -- thus making this the best of all possible worlds (and everything in it a necessary evil).
The other heat source comes from vendors' desperate race to keep up with the market and customers' demands by heroically struggling to get their products off the drawing board and out the door. "Of course we have to be in control of our technology," they say. "It's the only way we can keep up!" The objectivity, fairness, and leading-edge characteristics of most standards are not disputed, but establishing standards involves groups of individuals who must agree on them, which takes time. In the meantime, technology continues to evolve, and nothing goes stale faster than leading-edge technology.
Whether networking technologies are standards or not, or de facto or de jure, doesn't matter: The action is where the markets are. Vendors must be involved on both sides of the debate to some extent because they cannot afford to miss any of the technology boats leaving port. Some astute vendors have published their "standards" and given customers and industry people sufficient documentation and input both to keep things working and to keep up with the development of the technology.
Some standards bodies have been wise enough to realize that a standard is a good thing only when it's widely implemented and have given vendors opportunities to deal with the real-world concerns of getting products to market. The winners in both camps are the protocols that are used the most.
One last remark on protocols: They rarely, if ever, occur in the singular. Most networking protocols consist of a named collection of specific message formats and rules for interaction rather than a single set of formats and rules. For that reason, protocols are also called protocol suites, not because they like to lounge around on matched collections of furniture, but because they travel in packs.
So now you know that your computer cannot talk to another computer without sharing a common protocol. Where does this protocol stuff come from? Put differently, who decides which protocols are used?
Protocols cover networking capability from software to hardware. The programs that let your computer access the network must use a protocol. This protocol holds all the way down to the edge of the hardware, where the computer says "send this message" to talk to the network or "give me the message," depending on what the hardware is telling it.
Protocols come a little from here and a little from there. For example, most protocols don't care which kind of network they're talking through; in most cases, they don't even notice if it's an ARCnet, Ethernet, or token-ring network. This is because part of the software that provides network capability comes from a LAN driver and part of it comes from other sources.
The LAN driver on a computer tells it exactly how to talk to the network interface in your machine. If you're lucky, you use a network machine, such as a network-ready PC or a Sun workstation. Otherwise, you have to locate and install a LAN driver on your computer so it can talk to the network.
Some applications may know how to communicate directly with a network through a special kind of software interface. Applications with this kind of savvy used to be scarce, but they're becoming more common as networks become more widespread. Other applications may use standard computer system access and end up talking through the network, totally unaware that the network is being accessed.
The key to network access from applications or from a computer's operating system is a collection of software that implements the protocol suite being used. The operating system, such as DOS or Windows 95 on a PC, is a program that keeps the computer running and capable of doing the jobs you ask it to perform.
If an application or operating system is network-savvy, the vendor may supply all or part of the network access software, including the LAN driver.
For Windows NT Server, for example, Microsoft supplies software for most of its desktop clients: Windows (in all its many flavors), UNIX, OS/2, and Macintosh can make use of their own networking software, whereas DOS uses networking software that Microsoft supplies along with NT Server (which can also be obtained from other sources). For a visual aid to these possible software relationships, look at Figure 3-1. You'll notice that software components, called shells or requesters, are needed to communicate over the network. The figure also shows that you'll need a LAN driver to provide the link between software and hardware.
Okay, you now know that a protocol suite lets computers share a set of common communications rules. You also know that the protocols handle the movement of information between the hardware on the network interface computer and the applications you run on your machine. The next question is, what's going on between the applications and the hardware while the protocols do their thing?
Much of the interaction between applications and hardware consists of taking messages, breaking them down, and stuffing them into envelopes as you move farther from the application and closer to the hardware. From the other direction -- hardware to software -- the protocols unpack envelopes and stick individual pieces together to build a complete message. We hope that it is a meaningful message, but remember that the one immutable law of computers is GIGO, or garbage in, garbage out.
It might help to think of a post office analogy. The post office handles anything that has an address on it and sufficient postage to pay its way. How is a letter delivered? It goes something like this:
The basic requirements for successful mail delivery are timely pickup, short transit time, and correct delivery. Factors that affect transit time and delivery (barring disgruntled postal workers with firearms) are correct identification of and routing to the mailing address.
The similarity between networking protocols and the postal service lies in the capability to recognize addresses, route messages from senders to receivers, and provide delivery. The major difference is that the postal service, unlike networking protocols, doesn't normally care what's in the envelopes or packages you send as long as they meet size, weight, and materials restrictions. Networking protocols spend most of their time dealing with envelopes of varying sizes and kinds.
For instance, suppose that you want to copy a file from your computer to another computer across the network. The file is sizable, about 1MB. It consists of a spreadsheet covering your sales forecast for the next quarter, so you want it to get there quickly and correctly.
To use the post office (or snail mail), you would copy the file to a floppy and mail it to the recipient, but that's not fast enough. Over the network, it will get there in less than a minute. While the file is moving from your machine to the other machine, there's a lot going on that you aren't privy to.
Size considerations -- the biggest chunk of data you're allowed to move across the network -- are only one reason why messages are put into envelopes. Handling addresses is another reason. In the post office example, the pickup post office cares only about the destination zip code, whereas the delivering mail carrier is concerned with the street address. Along the same lines, one protocol might care about only the name of the computer to which the file is to be shipped; at a lower level, however, the protocol needs to know where to direct the chunks of data moving from sender to receiver as well so that the file can be correctly reassembled upon delivery.
The protocol software spends most of its time taking things apart to deliver them accurately. When you're receiving something, it spends its time stripping off packaging information and putting things back together. The sender and receiver keep talking to each other while all this is going on to monitor the accuracy and effectiveness of their communications and to determine if and when delivery is complete. Protocols also spend a lot of time keeping track of the quality and usability of network links.
We hope this chapter has helped to clear up some of the mysteries that surround protocols. The important thing to remember, though, is that protocols simply allow computers to communicate.