WAAS407SG Vol3 PDF

Table of Contents
Volume 3
Appendices
Overview
Module Objectives
Microsoft Windows Networking

Overview
Objectives
Microsoft Domain Concepts
Windows Authentication and Authorization
Windows Name Resolution and Resource Location
Introduction to CIFS
CIFS Session and Flow
CIFS Locking and Opportunistic Locks
Microsoft Distributed File System
Microsoft Windows Networking References
Lab Reference Guide

Overview
Design Workshop Reference Topologies

Overview
A-1
A-1
A-1
A-3
A-3
A-3
A-4
A-14
A-23
A-40
A-48
A-54
A-61
A-66
B-1
B-1
C-1
C-1
Appendices
Appendices
Overview
The appendices in this section provide additional information on the following topics:
Hands-on lab topology information
Design workshop reference diagrams
Module Objectives
Upon completing this module, you will be able to these appendices provide information on
additional topics and concepts. This includes being able to meet these objectives:
Describe Microsoft Windows Networking concepts
Describe the configuration of the Wide Area Application Services lab on which the course
labs are based
Describe the topologies used for the design case study workshops
A-2
Cisco Wide Area Application Services Technical Training (WAAS) v4.0.7
2007 Cisco Systems, Inc.
Appendix A

Overview
This appendix is intended to assist your understanding of Microsoft Windows Networking. This
is an overview of Microsoft Windows Networking only. Only the most relevant Windows
Networking concepts are overviewed in this module. Students are encouraged to acquire
additional knowledge about Windows environments and their internal workings and
administration by taking additional courses or reading. Many classes are available from
Microsoft on the details of its products. You can find links for Windows Networking materials
at the end of this module.
Objectives
Upon completing this lesson, you will be able to describe Microsoft Windows Networking
concepts. This includes being able to meet these objectives:
Describe Microsoft domain concepts, including Windows NT domains and Active

Directory
Describe Microsoft authentication and authorization concepts including NTLM and

Kerberos
Describe Microsoft Windows name resolution and resource location functions, including
DNS, WINS, and the Computer Browser Service
Describe Microsoft CIFS file-sharing protocol and capabilities
Describe Microsoft CIFS architecture and session flows
Describe CIFS locking, share mode, and opportunistic lock mechanisms
Describe Microsoft distributed file system
Provide a list of reference documents on Microsoft TechNet for additional reference and
reading
Microsoft Domain Concepts

This section describes Microsoft domain concepts, including Windows NT domains and Active
Directory (AD).
Milestones of Windows Networking

1980s:
Personal computer introduced to the public
Microsoft acquires DOS technology (MS-DOS)
Windows version 3 and Windows for Workgroups introduced
Workgroups built on NetBIOS over NetBEUI, IPX/SPX, and TCP/IP
1990s:
Microsoft Windows NT
Windows NT domains
Onset of TCP/IP and internetworking
2000s:
Microsoft Windows 2000
Microsoft Active Directory
2007 Cisco Systems, Inc. All rights reserved.
WAAS v4.0.75-4
The following milestones were reached in the 1980s:
personal computer introduced to the public.
Microsoft acquires disk operating system (DOS) technology (MS-DOS).
Windows version 3 and Windows for Workgroups is introduced.
Workgroups built on NetBIOS over NetBEUI / IPX/SPX / TCP/IP.
The following milestones were reached in the 1990s:
Microsoft Windows New Technology (NT) is introduced.
Windows NT domains are created.
Onset of TCP/IP and internetworking.
The following milestones were reached after 2000:
A-4
Microsoft Windows 2000 is introduced.
Microsoft Active Directory is introduced.
Windows NT Domains
Created to address the manageability and scalability issues of
disparate departmental workgroup networks.
A group of computers have access to a common security and
user account database.
Single sign-on created for all permitted resources in the domain.
Flat hierarchy with one PDC and multiple BDCs.
Resource and account administration only on PDC.
PDC replicates domain database to BDCs regularly; BDC has
read-only replica of account database; can process logins.
Domains interconnected by manually configured trust
relationships.
WAAS v4.0.75-5
The following are some basics about Windows NT domains:
Windows NT domains still exist in organizations that have not fully migrated to AD.
Windows NT domains are a single, flat database structure made of computers, users, and
groups of users.
All administration is completed on the primary domain controller (PDC). All backup
domain controllers (BDCs) have a read-only copy of the flat database that is passed from
the PDC. The PDC manages the database and handles user logins while the BDCs handle
only logins.
If two domains are to have a trust relationship, two one-way trusts must be created. Each
domain must have a one-way trust to the other domain. The trust relationship in Windows
NT allows access to resources in the domain. In AD, trust relationships are automatically
created. In Windows NT the trusts are not automatically created and must be created
manually by the administrator.
Appendix A
A-5
Windows NT Domains (Cont.)

Domain models:
Single domain (<300 nodes)
Master domain (<15000 nodes)
Multiple master domains
Complete trust mesh
R = number of Resource Domains

M = number of Account Master Domains
D = total number of Domains
WAAS v4.0.75-6
The table in the figure shows the number of trusts required for each model.
The following are important to know about Windows NT domains:
A-6
A single Windows NT domain supports less than 300 nodes. When you exceed this number
you have to move to a single-master or multiple-master domain model.
In the master domain model, users are created in the master domain and the resources are
created in the resource domains.
Large deployments in a multiple master or a complete trust design require many trusts to be
administered and makes scaling very challenging. This is why AD is a much better solution
in large environments or in environments that need to scale.
Active Directory
Was built to solve scalability and manageability challenges of
flat hierarchy NT domain structures
Stores information about objects on a network and makes this
information available to users and network administrators
Gives network users access to permitted resources with a single
logon process
Provides network administrators with an intuitive, hierarchical
view of the network and a single point of administration for all
network objects
Provides a distributed approach to network resource and policy
management
WAAS v4.0.75-7
AD is a very common deployment component in Microsoft Networking. It is a directory service

that contains information about objects on a network, including who can access the object and
who administers the object. This is all accomplished through a single login process. The
directory structure of AD provides administrators with an intuitive view of the network and a
single point for administration of all objects.
Appendix A
A-7
Active Directory Domains

Domain:
A collection of computer, user, and group objects defined by
the administrator.
These objects share a common directory database, security
policies, and security relationships with other domains.
Domain controller:
In an AD forest, a server that contains a writable copy of the
AD database participates in AD replication and controls access
to network resources.
Administrators can manage user accounts, network access,
shared resources, site topology, and other directory objects
from any domain controller in the forest.
WAAS v4.0.75-8
In AD, a domain is a collection of computer, user, and group objects that have been created by
the administrator. This domain is hosted by one or several domain controllers (DCs), which
have a writeable copy of the AD database. DCs also participate in AD replication and control
access to the network objects. Administrators use DCs to create and modify users, network
access, resources, and topology.
A-8
Active Directory Trees and Forests

Domain tree:
A hierarchical structure of one or more domains,
connected by transitive, bidirectional trusts that forms
a contiguous name space. Multiple domain trees can
belong to the same forest.
Domain forest:
One or more AD domains that share the same class
and attribute definitions (schema), site and
replication information (configuration), and forestwide
search capabilities (global catalog).
Domains in the same forest are linked with two-way,
transitive trust relationships.
WAAS v4.0.75-9
A domain tree can contain one or more domains connected by trusts. You can have many child
domains under the parent domain similar to a domain name system (DNS) infrastructure.
A domain forest is one or more AD domains that share the same:
Schema: The class and attribute settings.
Configuration: Site and replication information.
Global catalog: Provides forest-wide search capabilities by storing a copy of all AD

objects in the forest. By default the first domain controller becomes the host for the global
catalog.
All domains are linked with two-way transitive trusts, that is, if A trusts B and B trusts C then
A trusts C, as well.
Appendix A
A-9
Active Directory Tree

A domain is an administrative boundary. Administrative
privileges do not extend to other domains:
Security policy extends to all security accounts within the domain.
Organized in parent-child relationships
Child domain names are always contiguous with the name of the parent
domain (for example, child1.parentdomain)
Transitive trust is applied automatically to all domains that are members
of the domain tree or forest.
WAAS v4.0.75-10
Domains are administrative boundaries that do not extend privileges. The parent-child
relationship can be seen in the figure in the reskit.com and na.reskit.com domains.
Na.reskit.com is a child of reskit.com, and Atlanta.na.reskit.com is a child of na.reskit.com.
Transitive trusts are automatically applied after a trust between two domains is created.
A-10
Active Directory Forest

One or more trees, organized as peers, and connected by twoway, transitive trust relationships.
Trees in the same forest form a noncontiguous name space
based on different DNS root domain names.
Trees in a forest share
a common directory
schema, configuration,
and global catalog.
WAAS v4.0.75-11
An AD forest is having more than one top-level domain along with a noncontiguous name
space, such as reskit.com and acquired.com.
These AD trees in the same forest share a common schema, configuration, and global catalog,
but they do not share the same name space.
Appendix A
A-11
Active Directory Domain Names

Domain naming conventions:
Based on DNS naming conventions:
A child domain can have exactly one parent domain.
Two children of the same parent can not have the same name.
NetBIOS domain names:

15-byte name length limit.
Provides support for applications that use the NetBIOS networking API and flat
NetBIOS names.
Allows Windows NT, ME, and 9x computers to identify and log on to AD domains.
client1
reskit.com
client1.reskit.com
WAAS v4.0.75-12
Two naming conventions are supported under AD, domain naming and NetBIOS domain
naming:
A-12
Domain naming: Each child domain can have only one parent domain. In
child.parent.com, child is the child, or subdomain, and parent is the parent domain. There
can not be two subdomains under the same parent containing the same name.
child.parent.com and child.parent.com are the same name, not two different names.
NetBIOS naming: There is a flat name space (no hierarchy) and a limit to a 15-byte length
for the name. NetBIOS naming supports legacy applications and operating systems, such as
Windows NT, Windows Me, and Windows 9x, and allows them to interoperate with AD.
Active Directory Example
Client1.reskit.com Computer Object in Active Directory

WAAS v4.0.75-13
The AD structure can be viewed as a DNS name space, which is what is seen on the right in the
figure; however, when it is viewed from within the AD name space in Windows, it appears as
shown on the left of the figure. The focus for this example is the client1 computer. In the AD
name space, it is represented under the Computers subfolder of the Reskit folder, while in the
DNS name space, it is represented under the reskit.com domain. In AD, there is also a network
subnet that defines the actual network design behind AD.
The AD name space is translated, based on the network subnet configuration, to the DNS name
space and written to zone files or zone databases, which are hosted in AD.
Appendix A
A-13
Windows Authentication and Authorization

This section describes Microsoft authentication and authorization concepts, including NT LAN
Manager (NTLM) and Kerberos.
Windows Authentication
Only two network authentication options are available for
Windows 2000 domains:
Kerberos v5 protocol:
The Kerberos v5 authentication protocol is the default for authentication of
users who are logging in to domain accounts from computers that are running
Windows 2000, or higher.
NTLM protocol:
The Windows NTLM protocol is the default for authentication in Windows NT
4.0.
It is retained in Windows 2000 for compatibility with clients and servers that
are running Windows NT version 4.0, and earlier.
It is also used to authenticate logins to standalone computers that are running
Windows 2000.
WAAS v4.0.75-15
In Windows 2000 domains there are two protocol options for authentication, Kerberos v5 (the
default method) and NTLM. NTLM support is still available in Windows 2000 to support
earlier operating systems, such as Windows NT 4.0 and Windows 9x products. NTLM is also
used if a standalone computer that is running Windows 2000 attempts to log in to a domain
where it is not a member.
A-14
Kerberos v5
Relies on shared secret authentication, using
secret key cryptography rather than sharing a
password.
The trusted intermediary in the protocol is the
KDC.
The KDC is a service running on the domain
controller.
WAAS v4.0.75-16
Kerberos does not share a password. It uses a shared secret mechanism hosted by the Key
Distribution Center (KDC), a service running on the DC. Windows 2000 supports many DCs in
AD, allowing logins to be supported from any one of these DCs, reducing the load on any one
DC.
Appendix A
A-15
Kerberos v5 (Cont.)
When a client wants to talk to a server:
The client sends a request to the KDC
The KDC distributes a unique session key for the two parties to
use when they authenticate each other.
The server's copy of the session key is encrypted in the server's
long-term key. The client's copy of the session key is encrypted in
the client's long-term key.
Maximum tolerance for computer clock synchronization:

The difference (in minutes) that Kerberos can tolerate between
the time on a clients clock and the time on a servers clock
(default: 5 min).
WAAS v4.0.75-17
The login process with Kerberos v5 is managed with keys rather than actual passwords. This
protects users logins and passwords by using a key to access each resource rather than using
the user name and password (like NTLM).
Clock synchronization is very critical to this process. Network Time Protocol (NTP) is a good
solution for clock synchronization.
A-16
NT LAN Manager Protocol

NTLM credentials consist of a domain name, a user
name, and a one-way hash of users passwords.
NTLM uses an encrypted challenge and response
protocol to authenticate users without sending the user
passwords over the wire.
Network authentication involves a client, a server, and
a DC.
WAAS v4.0.75-18
NTLM provides interactive authentication only. A user accesses a client machine and provides
a domain name, user name, and password. The client computes a cryptographic hash of the
password and discards the actual password.
Nowhere in the process is the password sent across the wire. Only a hash of the actual
password is sent for resource access.
Appendix A
A-17
NT LAN Manager Protocol (Cont.)

Outline of NTLM network authentication:
1. The client sends the user name to the server (in plain text).
2. The server generates a 16-byte random number (called a
challenge) and sends it to the client.
3. The client encrypts this challenge with the users password hash
and returns the result to the server. This is called the response.
4. The server sends three items to the DC: the user name, the
challenge sent to the client, and the response from the client.
5. The DC uses the user name to retrieve the users password
hash from the SAM database. It uses this hash to encrypt the
challenge.
6. If the DC-encrypted challenge is identical to the client response,
then authentication is successful.
WAAS v4.0.75-19
The following is an outline of NTLM network authentication:

1. The client sends the user name to the server (in plain text).
2. The server generates a 16-byte random number (called a challenge) and sends it to the
client.
3. The client encrypts this challenge with the users password hash and returns the result to
the server. This is called the response.
4. The server sends three items to the DC: the user name, the challenge sent to the client, and
the response from the client.
5. The DC uses the user name to retrieve the users password hash from the Subscriber
Access Manager (SAM) database. It uses this hash to encrypt the challenge.
6. If the DC encrypted challenge is identical to the client, then the response authentication is
successful.
A-18
Windows Authorization Overview

If a file or other resource can be shared, it is secured against
unauthorized access by the operating systems own access
control mechanism.
The header of every object includes a security descriptor
with an ACL, maintained by the
objects owner who grants
or denies access and defines
the level of authorization to
any security principal.
Before returning a handle,
the operating system examines
the objects ACL to see whether
the security principal has been
granted access. If not, access
is denied.
WAAS v4.0.75-20
The following is an overview of Windows authorization:

1. If a file or other resource can be shared, it is secured against unauthorized access by the
operating systems own access control mechanism.
2. The header of every object includes a security descriptor with an access control list (ACL)
maintained by the objects owner who grants or denies access and defines the level of
authorization to any security principal.
3. Before returning a handle, the operating system examines the objects ACL to see whether
the security principal has been granted access. If not, access is denied.
Appendix A
A-19
Windows Authorization Overview (Cont.)

Security principals are not identified by name.
Instead, each security principal is assigned a unique
security identifier, an alphanumeric value identifying
the security identifier origin:
The first part of a security identifier identifies the domain where
the security identifier was issued.
The second part of a security identifier identifies an account in
the issuing domain
The value for a domain is unique in an enterprise, and the
value for an account is unique in a domain.
WAAS v4.0.75-21
The security identifier can be assigned to users and user groups. A security identifier has
security principals assigned to it for access or permissions.
A-20

SIDs are never reused:
A problem not easily solved by name-based access control
mechanisms.
Authorization is determined both by users identity

and by users membership in security groups.
The preferred method of controlling resources is to
grant access to groups instead of to individuals.
This method makes it easier to keep ACLs up to date on
networks with thousands of users and millions of objects.
WAAS v4.0.75-22
Authorization to resources is granted based on user and group identity that is defined by SIDs.
With many environments, the preferred method of granting access to resources is by group, not
by individual, because this is much easier to manage. For example, if a new employee starts in
the accounting department, rather than assigning the user to each object or resource that the
new user needs access to, the administrator assigns the new user to the accounting group and
the user immediately takes on all resource assignments of the accounting group.
Appendix A
A-21

Group membership can be managed centrally
by administrators.
Resource security is made easier to manage
by allowing groups to be nested.
Each security group has an SID.
WAAS v4.0.75-23
The following are important basics to know about Windows authorization:
A-22
An administrator can change users level of authorization for many resources by adding or
removing them as a member from a group.
A group created in one domain can be included in the membership of a group created in
another domain or in the membership of a universal group used throughout a tree of trusted
domains.
A users level of authorization is determined by a list of SIDs; one SID for the user and one
SID for each security group to which the user belongs.
Windows Name Resolution and Resource

Location
This section describes Microsoft Windows name resolution and resource location functions
including DNS, WINS, and the Computer Browser Service.
Windows Name Resolution

Windows uses multiple name-resolution services to
translate a computer name to an IP:
NetBIOS over TCP/IP (NetBT) is a flat name space:
Broadcast
WINS
Local LMHOSTS File
DNS is a hierarchical name space, and is required for AD:

DNS Server
Local HOSTS file
WAAS v4.0.75-25
In Windows deployments, name resolution is key to users searching and browsing network
resources.
Appendix A
A-23
Windows Name Resolution (Cont.)

Different Windows versions use different default
name-resolution sequences:
AD clients (Windows 2000/XP/2003/98/Me): HOSTS, DNS,
NetBIOS (name cache, WINS, BCAST, LMHOSTS)
Pre-AD clients (WinNT 4.0, Win 98/95): NetBIOS, HOSTS,
DNS
Sequence can be customized by administrators (registry
settings)
Computer names can be retrieved from AD published

objects or browse lists.
WAAS v4.0.75-26
Name resolution is an important subject, because it is required to access resources on the

network, both in AD and Windows NT 4.0.
A-24
Windows Name Resolution: NetBIOS

NetBIOS broadcast:
Good for small and self-contained networks. Usually confined
to subnet boundaries unless assisted by a router (helper).
A name registration is broadcasted and heard by all broadcastenabled nodes on the subnet (B-, H-, and M-nodes).
If no objections are received, the broadcasting application
assumes permission granted to use the name and issues a
name overwrite demand.
If the name is already in use, a negative name-registration
response is sent by the node using the name. The requesting
application does not have permission to use the name.
WAAS v4.0.75-27
Understanding of NetBIOS resolution is important for troubleshooting. NetBIOS broadcasting

is typically confined by subnet boundaries, unless the router is configured to forward them on.
Appendix A
A-25
NetBIOS (Cont.)
NetBIOS uses a flat, nonhierarchical namespace:
16-byte address:
15 bytes for resource name identification
1 byte (reserved) for service type identification
NetBIOS is a session-level interface:
Establishes logical names on the network
Sessions established between two logical names
Transport agnostic: NetBEUI, TCP, and SPX can be used
WAAS v4.0.75-28
NetBIOS is a session-level interface that allows two devices to create a connection based on
logical names. Because the session level of the Open Systems International (OSI) model is
Layer 5 and the IP address itself is Layer 3, name resolution still must take place before the
session can be created.
A-26
NetBIOS (Cont.)
NetBIOS node types:
Defines default name resolution behavior
b-node: broadcast messages to register and resolve NetBIOS
p-node: point-to-point query against WINS server
m-node: broadcast first (b-node), then query WINS (p-node)
h-node: query WINS first (p-node), then broadcast (b-node)
Windows 2000, and higher, use b-node name resolution

by default and use h-node when configured with a WINS
server.
WAAS v4.0.75-29
The following are NetBIOS node types:
b-node: Uses IP broadcast messages to register and resolve NetBIOS names to IP

addresses.
p-node: Uses point-to-point communication with a Windows Internet Naming Service

(WINS) server to register and resolve computer names to IP addresses.
m-node: Uses a b-node first, and then, if necessary, it uses a server query.
h-node: Uses a hybrid of b-node and p-node. An h-node computer always tries a server
query first. It uses broadcast only if direct queries fail.
Appendix A
A-27
NetBIOS (Cont.)
A NetBIOS name is either a unique name (exclusive) or a group
name (nonexclusive).
Names registered can be divided into three groups:
Computer name
Domain name
Other name (service and so forth)
WAAS v4.0.75-30
NetBIOS uses either a unique name or a group name depending on the number of processes:
A-28
When a NetBIOS process is communicating with a specific process on a specific computer,

a unique name is used.
When a NetBIOS process is communicating with multiple processes on multiple

computers, a group name is used.
Windows Name Resolution: WINS

Windows Internet Name Service:
WINS was created to solve the problems of broadcast-based
NetBIOS name resolution.
Removes the burden of maintaining the static LMHOSTS files.
Maintains a database of resource names and resource types.
Can integrate with DHCP.
Uses directed client-server communication:
Registration
Resolution
Deregistration
Unicast datagrams can cross subnet boundaries
WINS can not forward name resolution requests.
WAAS v4.0.75-31
WINS uses unicast based registration and resolution to reduce the broadcasting burden on the
network. WINS server must contain an entry for each NetBIOS machine on your network, or
name resolution might fail. If the clients are registering with different WINS servers for load
balancing, you have to configure the WINS servers to replicate their databases to one another.
Appendix A
A-29
Windows Internet Name Service

A WINS-enabled client contacts the WINS server to:
Register NetBIOS names of
processes running on the client
Release the NetBIOS names of
processes that are no longer running.
Renew entries in WINS database
Resolve names by obtaining
mappings for user names,
NetBIOS names, DNS names,
and IP addresses from database
WAAS v4.0.75-32
A WINS-enabled client contacts the WINS server to:
A-30
Register in the WINS database NetBIOS names of processes running on the client
Release from the WINS database the NetBIOS names of processes that are no longer
running
Renew entries in WINS database
Resolve names by obtaining mappings for user names, NetBIOS names, DNS names, and
IP addresses from the database
Windows Name Resolution: DNS

DNS is a hierarchical and
logical name space:
DNS is required for support of
AD.
Functions as a locator service
for domain controllers in AD.
Integration with AD:
Increased fault-tolerance
Improved security
WAAS v4.0.75-33
AD DNS integration allows the DNS records to be stored in AD rather than in a flat file
(traditional DNS), providing greater fault-tolerance and security.
Appendix A
A-31
Domain Name System

DNS provides support for dynamic updates and secure
dynamic updates:
Client computers can dynamically update their resource
records in DNS.
Integrated with DHCP.
DNS supports aging and scavenging of records.

DNS can query WINS for name resolution.
DNS supports new resource record types:
Not limited to a static set of resource type, such as WINS.
SRV resource record, which is used by computers to locate
domain controllers.
WAAS v4.0.75-34
Due to the AD integration of DNS, dynamic updates to the DNS Zone files are automatic,
instead of the traditional static management of DNS names.
A-32
Windows Resource Location

After users log on to the network, they need to locate
shared resources.
Windows provides shared resources by:
Publishing objects in AD domains
Using the browse function in SMBbased networks
WAAS v4.0.75-35
Shared resources are located by publishing objects in AD domains and Browsing in Server
Message Block (SMB) based networks.
Appendix A
A-33
Windows Resource Location (Cont.)

Publishing objects in AD:
Share publishing:
Linking any share to
any container in AD
Search mechanism
using Windows search
dialog box
Printer publishing:
Allow users to locate
the most convenient
printer
Query by attributes,
printer type, features
Global catalog:
Stores copies of all
AD objects
WAAS v4.0.75-36
Administrators can publish any shared network folder, including a distributed file system (DFS)
folder, in AD. Creating a shared folder object in AD does not automatically share the folder. It
is a two-step process: You must first share the folder and then publish it in AD. Users can
easily and quickly query AD for a shared folder.
A global catalog is a domain controller that stores a copy of all AD objects in a forest. The
global catalog stores a full copy of all objects in the directory for its host domain and a partial
copy of all objects for all other domains in the forest. The global catalog allows clients to
quickly and easily perform searches across all domains without having to search each domain
individually. The partial copies of all domain objects included in the global catalog are those
most commonly used in user search operations. These attributes are marked for inclusion in the
global catalog as part of their schema definition. Storing the most commonly searched upon
attributes of all domain objects in the global catalog provides users with efficient searches
without affecting network performance with unnecessary referrals to domain controllers. A
global catalog is created automatically on the initial domain controller in the forest. You can
add global catalog functionality to other domain controllers or change the default location of
the global catalog to another domain controller.
A-34
The Browser Service

The Computer Browser and browsing roles:
The Computer Browser service provides a method of locating
shared resources in a domain environment.
Computers running the server service (which includes both
workstations and servers) announce their availability.
Announcements are done by means of broadcast messages,
which are captured by computers designated as browsers or by
registering with WINS.
The function of the browser is to create, maintain, and distribute a
browse list, which is a directory of all shared resources used on
the network.
WAAS v4.0.75-37
The Computer Browser service runs on both workstations and servers. It allows users to access
the resources on that system.
Appendix A
A-35
The Browser Service (Cont.)

Browsing is required by network applications that use
CIFS messaging, such as My Network Places, the net
view command, and Windows NT Explorer.
WAAS v4.0.75-38
Browsing is required by network applications that use Common Internet File System (CIFS)
messaging, such as My Network Places, the net view command, and Windows NT Explorer.
A-36
The Browser Service (Cont.)

Computers can perform the following roles:
Domain master browser
Master browser
Backup browser
Potential browser
Nonbrowser
WAAS v4.0.75-39
Different systems have different browsing roles, such as domain master browser, master
browser, backup browser, potential browser and nonbrowser.
The master browser does the following:
Collects and maintains the list of available network servers in its subnet.
Fully replicates its listed information with the domain master browser to obtain a complete
browse list for the network.
Distributes its completed list to back up browsers located on the same subnet.
The backup browser does the following:
Receives a copy of the browse list from the master browser for its subnet.
Distributes the browse list to other computers on request.
The potential browser does the following:
Under normal conditions, operates similarly to a nonbrowser. Capable of becoming a

backup browser if instructed to by the master browser for the subnet.
This is the default configuration for a Windows 2000- or Windows XP Professionalbased

computer.
The nonbrowser does the following:
Does not maintain a browse list.
Can operate as a browse client, requesting browse lists from other computers operating as
browsers on the same subnet.
Appendix A
A-37
Browsing Roles
Domain master browser:
The domain controller (PDC in NT) operates in this role.
Collects and maintains master browse list of available servers for its domain, as
well as any names for other domains network (12-minute cycle); synchronizes the
browse list with WINS.
Distributes and synchronizes the master browse list for master browsers on other
subnets that have computers belonging to the same domain.
Only server versions of Windows can become domain master browsers.
WAAS v4.0.75-40
The domain master browser is responsible for keeping track of all resources in its domain.
A-38
Browser Elections
Browser elections occur under the following
circumstances:
When a computer can not locate a master browser
When a preferred master browser comes online
When a Windows NT domain controller starts
WAAS v4.0.75-41
If a master browse server already exists:
Windows checks the number of computers in the subnet and the number of browse servers
present.
If the ratio of browse servers to computers in the subnet exceeds the defined ratio (usually
1:32), the master browser can select a potential browser computer to act as a backup
browser.
Appendix A
A-39
Introduction to CIFS
This section describes Microsoft CIFS file-sharing protocol and capabilities.
Introduction to CIFS and SMB

Introduction:
Clients use the CIFS protocol to request file and print services
from servers over a network.
Based on the SMB protocol.
CIFS is a high-level protocol, independent of the transport layer.
History and facts:

In the late 80s, SMB was invented as the core protocol for
network file sharing by Intel and Microsoft.
Most Windows clients support several variations, including PC
Network Program 1.0, LANMAN 1.0, LM1.2X002, and NTLM 0.12.
Each version typically adds more features to the last.
Over 120 different CIFS and SMB operations are available today,
and the number is increasing.
WAAS v4.0.75-43
The following are basics about CIFS and SMB:
Clients use the CIFS protocol to request file and print services from servers over a network.
CIFS is based on the SMB protocol.
CIFS is a high-level protocol that is independent of the transport layer.
The following facts relate to the history of the protocols:
A-40
SMB was invented in the late 80s and represents a core protocol that provides network file
sharing between Intel and Microsoft.
Many features have been added over time. Most Windows clients now support several
different variations, such as PC NETWORK PROGRAM 1.0, LANMAN 1.0, LM1.2X002,
and NTLM 0.12.
Each version typically adds more features to the last.
Over 120 different CIFS and SMB operations are available to date and the number is
growing.
CIFS Features
CIFS features include the following:
File access
File and record locking
Safe caching, read-ahead, and write-behind
File change notification
Protocol version negotiation
WAAS v4.0.75-44
CIFS features include the following:
File access: File operations include open, close, read, write, and seek.
File and record locking: After a file or record is locked, nonlocking applications are
denied access to the file.
Safe caching, read-ahead, and write-behind: Allow read/write access to a file from
multiple clients simultaneously.
File change notification: Applications can register for notifications when a file or
directory contents are modified.
Protocol version negotiation: Client and server negotiate the version (dialect) to be used.
The negotiation also dictates the command set that can be used between the client and the
server.
Appendix A
A-41
CIFS Features (Cont.)

CIFS features also include:
Extended attributes
Distributed replicated virtual volumes (DFS)
Server name resolution independence
Batched requests
Unicode file names
WAAS v4.0.75-45
Extended attributes:
Nonfile system attributes alongside built-in file attributes (timestamps).
Distributed replicated virtual volumes:
Supports multivolume file system subtrees.
CIFS protocol uses referrals to transparently direct a client to the appropriate server.
Distributed File System (DFS) is built on this feature of CIFS.
Server name resolution independence:
Clients can resolve server names with any name resolution mechanism.
Batched requests:
Multiple requests are grouped in a single message to minimize round-trip latencies.
Supports request/result dependency.
ANDX commands represent items that can be batched.
Unicode file names:
A-42
Supports Unicode strings (file names, resource names, and user names).
CIFS Security and Authentication

Each server makes a set of shared
resources available to clients.
Shared resources include:
A directory tree
A printer
A named pipe
Other objects
The CIFS protocol requires server

authentication of users before
resource accesses are allowed.
Each server authenticates its own
users.
The granularity of authorization is up
to the server.
WAAS v4.0.75-46
The following is basic information about CIFS security and authentication:
CIFS allows access to resources on the network on workstations and servers.
Shared resources can be directory trees, printers, named pipes, and other objects.
All authentication is done by the server with the resource.
Appendix A
A-43
CIFS Security and Authentication (Cont.)

Supported CIFS authentication methods include:
Kerberos (GSS-API, RFC 2478)
NTLM v1
NTLM v2
Share-level Security
CIFS passes authentication and authorization:

File server handles authentication and authorization
WAAS v4.0.75-47
Kerberos (GSS-API, RFC 2478):
Performed through _SESSION_SETUP_ANDX.
CIFS authentication is performed in a separate security layer.
The security blob might span across several messages.
NTLM v1:
NTLM v1 is a legacy form of challenge-response authentication (Windows NT 4.0).
Challenge and response are encrypted.
NTLM v2:
An enhancement to NTLM v1.
Key space is increased to 128 bits.
Enables using a secure channel (for signing and encryption) prior to the challenge/response.
Share-level security:
A-44
Common in Windows 95.
Legacy method is a directory tree protected by a common password.
Performed through SMB_COM_TREE_CONNECT_ANDX requests that include a

password or that use challenge/response.
Windows CIFS Transports

CIFS over NetBIOS includes:
NetBIOS session service.
TCP 139.
CIFS over TCP-IP includes:

Microsoft-DS service.
TCP 445.
Transport defaults depend on operating environment:

In a mixed-mode AD domain, Win2K and XP clients use CIFS
over NetBIOS by default.
In a native-mode AD domain, Win2K and XP clients use CIFS
over TCP/IP by default and revert to NetBIOS, if needed.
WAAS v4.0.75-48
CIFS over NBT (NetBIOS over TCP/IP):
Legacy support for Windows NT 4.0, Windows 9x, and more
CIFS messages transferred with NetBIOS session service
NetBIOS session established over TCP port 139
Auxiliary NetBIOS ports:
Port 137: NetBIOS name resolution
Port 138: computer browsing datagrams
If the DNS is used:
The called name is constructed from the first component (or host portion) of the server's
DNS name in the following sequence:
1. Truncated to 15 characters, if necessary.

2. The called name is padded to 16 characters with blanks (0x20) characters.
CIFS Over TCP/IP (typically used in Windows 2000, and higher):
DNS provides name resolution (no broadcasting, no need for WINS).
AD provides accurate, flexible resource browsing.
CIFS messages are transferred with TCP/IP to eliminate NetBIOS overhead.
CIFS session established over TCP port 445.
Appendix A
A-45
CIFS File Access and Name Spaces

A single file can not span more than one server:
Entire file must be accessible from one location
Location of file on file server physical disk is not relevant
Servers can be accessed in a number of ways:

Universal Resource Locator (URL):
file: //fs.megacorp.com/users/fred/stuff.txt
Universal Naming Convention (UNC):

\\corpserver\public\policy.doc
Mapped network drive:

X:\policy.doc
X: is an index to a UNC, for example: \\corpserver\public
WAAS v4.0.75-49
A single file can not span more than one server. A client can not be redirected to another
physical location (CIFS server) to access portions of a file that is already open. The entire file
must be accessed from only the server that the client is communicating with.
A file can span multiple volumes in multiple locations, but this is outside the scope of the CIFS
protocol definitions. The physical location of the file on the physical disks attached to the file
server is not relevant to CIFS.
Name resolution is performed by the client and is not controlled by the CIFS protocol. CIFS
traffic only uses the name in the data process, it does not use the IP address. The clients and
servers perform name resolution prior to establishing a session.
A-46
Server Name Resolution

Examples of server name resolution include:
Domain Name System (DNS).
NetBIOS name resolution (RFC 1001, RFC 1002)
The name resolution mechanism can constrain the form

of the server name:
NetBIOS: The server name must be 15 characters or less, and be
in uppercase.
WAAS v4.0.75-50
The following are examples of server name resolution:
DNS
NetBIOS name resolution (RFC 1001, RFC 1002)
The name resolution mechanism can constrain the form of the server name:
NetBIOS: The server name must be 15 characters or less, and be in uppercase.
Appendix A
A-47
CIFS Session and Flow

This section describes Microsoft CIFS architecture and session flows.
CIFS Session Flow

To negotiate and establish a CIFS session:
The client first approaches the server with a list of the CIFS
dialects that the client can support. (_NEGOTIATE packet).
The server selects the best dialect to use and warns the client if
user challenge-response authentication is required, and then
sends a challenge security blob (_SESSION_SETUP_ANDX).
ANDX-type client commands can chain multiple I/O commands
together in a single client request, saving both transport and TCP
wrapping.
Transaction and Transaction-2-type commands support large data
transfers
WAAS v4.0.75-52
ANDX-type client commands allow for aggregation of I/O commands into one request instead
of having multiple requests going back and forth. Many CIFS commands are dependant on one
another and sometimes are very small, so sending them together saves time in the
communication process.
Understanding the CIFS session flow and different packets is important for troubleshooting. If
you could capture packets from the network, you would see the negotiation, the session setup,
and then the transaction process, which is the actual send of the data.
A-48
CIFS Session Flow (Cont.)
NAS
Server \\NAS1
\docs shared as \share1
\priv shared as \share2
NAS
Server \\NAS2
\user shared as \user
sion
1 Ses
1 Se
ssion
X: \\NAS1\share1
Y: \\NAS1\share2
Z: \\NAS2\user
Network Attached
Storage
WAAS v4.0.75-53
Clients access shared resources by way of the session that is established between the client and
the server. The figure shows that, regardless of the number of resources accessed, typically only
one session is open between the client and the server at any given time.
Appendix A
A-49
CIFS Packets
Each packet consists of a fixed header and a variable
data portion.
The fixed header includes:
A command code
Status flags
Client process and server file identifiers
WAAS v4.0.75-54
The header shows which user is accessing the file as well as which file is being accessed.
A-50
CIFS Session Termination

The server can terminate a session with a client at any
time:
When there is already a connection
When there are malformed or illogical requests
When hard errors are encountered
When client session idle time exceeds the timeout counter of 15
minutes
WAAS v4.0.75-55
A CIFS session is terminated for the following reasons:
If a server receives a transport establishment request from a client with which it is already
conversing, the server can terminate all other transport connections to that client.
A server can drop the transport connection to a client at any time if the client is generating
malformed or illogical requests.
If a server gets a hard error on the transport, such as a send failure, the transport connection
to that client can be terminated.
A server can terminate the transport connection when the client has no open resources on
the server. The Windows idle timeout default is 15 minutes. This idle timeout is not
determined by CIFS; it is determined by the server application.
Appendix A
A-51
CIFS Session Tracking

Tree ID:
Identifies the resource a CIFS packet is referring to
File ID:
Used for subsequent operations on a file
Process ID:
Identifies which client process is issuing CIFS request
User ID:
Identifies user issuing CIFS requests on client
Multiplex ID:
Allows multiple outstanding client requests to exist
WAAS v4.0.75-56
Session tracking is important because some of the session information for the client can be
reused for subsequent requests.
Tree ID (TID) identifies the resource a CIFS packet is referring to. This resource can be a share
on a server:
In the _TREE_CONNECT_ANDX packet, the share or printer name is specified.
In the response packet, the server sets the TID to any number that it pleases.
The client uses the TID to make requests specific to that resource for following requests.
File ID (FID):
After a client successfully opens a file, the server response includes an FID that the client
should use for subsequent operations on the file.
Process ID (PID) identifies the process that is issuing the CIFS request on the client:
The server uses the PID to check for concurrency issues to prevent corruption by
competing client processes.
User ID (UID) identifies the user who is issuing CIFS requests on the client side:
The server provides a UID upon successful authentication.
The client uses the assigned UID in all future CIFS requests.
The UID is meaningless and ignored in share-level security mode.
The UID is issued by the server and is meaningless to the client.
Multiplex ID (MID) allows multiple outstanding client requests to exist without confusion:
A-52
The server ensures that the response it sends matches the request MID that it received.
The client can always know exactly which outstanding request an incoming reply is
correlated to.
CIFS Session Example

SMB_COM_NEGOTIATE
The first packet sent by client lists SMB supported

dialects; server response indicates which SMB
dialect to use.
SMB_COM_SESSION_SETUP_ANDX
Sends user name and credentials for verification.

Server response has a UID field set for subsequent
SMBs on behalf of this user.
SMB_COM_TREE_CONNECT_ANDX
Transmits the name of the disk or printer share to

access; server response has the TID field set for
subsequent packets referring to this resource.
SMB_COM_OPEN_ANDX
Sends the name of the file, relative to the TID;

server response has an FID for the client to supply
in subsequent operations on this file.
SMB_COM_READ
Client supplies TID, FID, file offset, and bytes to

read; server response has the requested file data.
SMB_COM_CLOSE
Client closes the file represented by TID and FID;

server responds with success code.
SMB_COM_TREE_DISCONNECT
Client disconnects from resource represented by

TID.
WAAS v4.0.75-57
The figure depicts a typical CIFS session.
Appendix A
A-53
CIFS Locking and Opportunistic Locks

This section describes CIFS locking, share mode, and opportunistic lock mechanisms.
CIFS Locking
CIFS locking allows a client process to prevent read
and write access to regions of a file by other
processes.
A client request defines a region by specifying its
length and offset values within a file.
The locked regions are associated with the file handle
(FID) and can be anywhere in the logical file.
Only processes using the FID specified in the locking
request have access to the locked bytes.
Locking a region fails entirely if any subregions or
overlapping regions are already locked.
WAAS v4.0.75-59
CIFS locking allows the entire file, or part of the file, to be locked by a client or clients.
Whether the entire file or part of the file can be locked is a function of the client/server
application.
A-54
CIFS Locking (Cont.)

A timeout field defines the maximum amount of time the
server will wait for the regions specified to become
unlocked.
A CIFS shared lock exists to allow multiple clients to
gain read-only access to the file region.
Closing a file with locks in force to release locks.
Locks are released in no defined order.
A pending lock request can be canceled by the server.
A lock type can be changed from shared to exclusive
and vice versa without losing the lock completely.
WAAS v4.0.75-60
Many options are available for CIFS locking. Full details can be found by searching
www.microsoft.com for CIFS file locking.
Appendix A
A-55
CIFS Opportunistic Locks

Opportunistic locks (oplocks) allow a server to tell a client that
a requested file is being used only by that client.
With oplock granted, the client can safely perform caching and
cached read-and-write operations.
Breaking an oplock is accomplished as follows:
The server notifies the client when a second process
attempts to open or otherwise modify the locked file.
Upon oplock break notification, the client is then expected to
perform the following:
Flush any dirty buffers to the server (problematic over slow
WAN).
Submit file locks and unlocks or otherwise close the file.
Applications can break their own oplocks (for example,
Microsoft Office)
WAAS v4.0.75-61
Upon an Opportunistic Lock (oplock) break notification, any dirty buffers are flushed. This is
problematic over a slow WAN because the client might be holding too much data before the
flush process. The CIFS lock timeout from the other client can time out while waiting for the
flush or the request itself can time out because the connection to the server can time out.
The timeout for any CIFS operation is 90 seconds.
If the application such as Microsoft Word has an oplock and there are two separate threads to
the file, the second thread can cause the first lock to timeout and create errors within the
application.
A-56
Type II Oplock
A type II oplock is characterized by the following:
There are multiple concurrent clients of a file, and none have yet
modified it.
Allows the client to perform read operations and file attribute
fetches with cached or read-ahead local information.
All other requests have to be sent to the server.
WAAS v4.0.75-62
A type II oplock is characterized by the following:
There are multiple concurrent clients of a file, and none have yet modified it.
Allows the client to perform read operations and file attribute fetches with cached or readahead local information.
All other requests must be sent to the server.
Appendix A
A-57
Exclusive Oplock
An exclusive oplock is characterized by the following:
The client is the only entity to have a file open.
Allows the client to perform all file operations with cached or readahead local information until it closes the file
Upon file close, server must be updated with any changes made to
the state of the file (contents and attributes).
WAAS v4.0.75-63
An exclusive oplock is characterized by the following:
A-58
Exclusive oplock allows the client to perform file operations using cached or read-ahead
local information until it closes the file.
Upon file close, the server must be updated with any changes made to the state of the file
(contents and attributes).
Batch Oplock
A batch oplock is characterized by the following:
Allows the client to perform all file operations on cached or readahead local information (including open and close operations).
Break reasons of lower-level oplock types also apply.
WAAS v4.0.75-64
The following are characteristics of batch oplock:
Batch oplock allows the client to perform all file operations on cached or read-ahead local
information, including open and close operations.
Break reasons of lower-level oplock types also apply.
Word and Excel are examples of client applications that use batch oplocks.
Appendix A
A-59
CIFS Share Modes

Create or open requests (NT_CREATE_ANDX) contain another
mean of concurrency control: a flag called ShareAccess.
Used independently or in conjunction with CIFS locks.
Share access is another way of setting a file lock.
Four share modes are available:
FILE_NO_SHARE
FILE_SHARE_READ
FILE_SHARE_WRITE
FILE_SHARE_DELETE
Open share modes are commonly used by Microsoft Office

applications.
WAAS v4.0.75-65
An application can choose not to use locks; instead, it can choose to open the file in a share
mode:
FILE_NO_SHARE: Prevents the file from being shared.
FILE_SHARE_READ: Allows only read access to other open operations.
The following are CIFS share modes:
A-60
FILE_SHARE_WRITE: Allows write access to other open operations.
FILE_SHARE_DELETE: Allows delete access to other open operations.
Microsoft Distributed File System

This section describes Microsoft distributed file system (DFS).
Distributed File System

The CIFS protocol dialects of NTLM 0.12, and later,
support DFS operations.
A DFS allows a user to access network shares on
different physical servers through a single entry path.
The CIFS DFS is based on a referral model.
The storage of the topological knowledge of the DFS is
out of the scope of the CIFS protocol.
WAAS v4.0.75-67
The storage of the DFS topology for a single DFS server design is in the Windows registry. The
storage of the DFS topology for multiple DFS servers is in the AD database. Please see the
Microsoft Windows Networking module for more detailed information on DFS.
Appendix A
A-61
Distributed File System (Cont.)

DFS enables name transparency by building a
hierarchical view of multiple file servers and shares on
the network:
Provides name transparency
Redirection based on site awareness
and site proximity
Increased availability and failover
Load sharing within site boundaries
WAAS v4.0.75-68
With name transparency, users can navigate the logical name space without having to know the
physical locations of the data.
Site awareness and site proximity support include the following:
A-62
Routes clients to closest file server by using AD site metrics.
Windows 2000 provides Site Awareness and Windows 2003 added Site Proximity Support.
This allows the user to get to the closest server that contains the data they are looking for.
This is very important when deploying Wide Area File Services (WAFS) Edge Wide Area
Application Engines (WAEs).

X: UNC \\company.com\DFS\share1
DFS terminology:
DFS root: Clients map to the
DFS root as a starting point to
locate shared directories.
DFS link: Object in the DFS
tree that provides redirection to
another location on the
network (that is, to a nearby file
server or Edge WAE published
name).
DFS target (replica): The
physical location of the share
being accessed on the nearby
file server or Edge WAE
published name.
3
\\server1\share1
1
\\company.com\DFS\share1
2
\\server1
\share1
\share2
\share3
REFERRAL LIST
(prioritized)
\\sever1\share1
\\server2\share1
DFS root
\\company.com\DFS
\share1
\share2
\share3
\\server2
\share1
\share2
\share3
Replicas:
\\server1\share1
\\server1\share2
\\server1\share3
\\server2\share1
\\server2\share2
\\server2\share3
WAAS v4.0.75-69
DFS root:
The share at the top of the DFS topology that is the starting point for the links and shared
files that make up the DFS name space.
A DFS root can be defined at the domain level for domain-based operation or at the server
level for standalone operation.
Domain-based DFS can have multiple roots in the domain but only one root on each server.
If the DFS root goes away, then the users pointing to it are not able to see the DFS data.
DFS link:
A link is another share somewhere on the network that goes under the root. When a user
opens this link, they are redirected to a shared folder.
DFS target (replica):
Both DFS Roots and DFS links can have replicas for high availability and load sharing.
If you have two identical shares, normally stored on different servers.
Note
Alias names as published by a WAFS Edge WAE can be added to DFS as replicas.
The server and the client use CIFS protocol to communicate. The DFS client intercepts Shared
Folder access requests and checks the local cache for a valid referral containing the Universal
Naming Convention (UNC) for the requested shared folder. If one is found, the user is referred
to the specified shared folder transparently. If the target shared folder has never been requested
before or if the data in the cache for it has expired, the DFS client asks the DFS server for a
referral. The DFS server looks in the partition knowledge table (PKT) and returns a referral to
the client. If the referral contains a replica set, the server uses the IP address of the client to
determine the site in which the client resides. It then randomizes the list of replicas, giving
preference to those located in the same site as the client. The client receives the referral and
connects to the first available server in the randomly ordered list. The referral is stored in the
Appendix A
A-63
local PKT cache and locked. If the time to live (TTL) has not expired, the client always selects
the first replica on the list. If a failover occurs, the client walks down the list for an available
replica. If no replicas are available, the client gets a new replica list from the DFS server.
A-64
WAAS v4.0.75-70
This slide shows a representation of the DFS process.

The PKT cache shows the DFS name and each of the links (targets) as well as their TTL.
The DFS Server stores the PKT information in the registry in a standalone design or in AD in a
domain-based (multiple server) DFS design.
Appendix A
A-65
Microsoft Windows Networking References

This section provides a list of reference documents on Microsoft TechNet for additional
reference and reading.
References
Links to the following references can be found on
http://www.microsoft.com/technet.
Active Directory
Active Directory Concepts
Win2K Distributed Systems Guide Ch. 1 - Active Directory Logical
Understanding Domain Trusts
W2K Authentication
Win2K Distributed Systems Guide Ch. 11 - Authentication
Access Control
Win2K Distributed Systems Guide Ch. 12 Access Control
W2K Client-Side Name Resolution

WAAS v4.0.75-72
Links to the following subjects can be found on http://www.microsoft.com/technet.

Active Directory:
Active Directory Concepts
Win2K Distributed Systems Guide: Chapter 1, Active Directory Logical
Understanding Domain Trusts
Windows 2000 (W2K) authentication:
Win2K Distributed Systems Guide: Chapter 11, Authentication
Access control:
Win2K Distributed Systems Guide: Chapter 12, Access Control
W2K client-side name resolution
A-66
References (Cont.)
WINS:
WINS Overview
Win2K TCP/IP Networking Guide: Ch. 7, Windows Internet Name Service
DNS:
Win2K TCP/IP Networking Guide: Ch. 5 Introduction to DNS
Win2K TCP/IP Networking Guide: Ch. 6 Windows 2000 DNS
Computer Browser Service:

Description of Microsoft Computer Browser Service
A list of names that are registered by Windows Internet Naming Service
CIFS and DFS:
The CIFS Protocol Overview

CIFS File Locking
CIFS Opportunistic Locks
Step-by-Step Guide to DFS
Win2K Distributed Systems Guide : Ch. 17, Distributed File System
Windows 2003 DFS
WAAS v4.0.75-73
WINS:
WINS Overview
Win2K TCP/IP Networking Guide: Chapter 7, Windows Internet Name Service
DNS:
Win2K TCP/IP Networking Guide: Chapter 5, Introduction to DNS
Win2K TCP/IP Networking Guide: Chapter 6, Windows 2000 DNS
Computer Browser Service:
Description of the Microsoft Computer Browser Service
A list of names that are registered by Windows Internet Naming Service
DFS:
Step-by-Step Guide to Distributed File System
Win2K Distributed Systems Guide: Chapter 17, Distributed File System
Windows 2003 DFS
Appendix A
A-67
A-68
Appendix B
Lab Reference Guide

Overview
This appendix describes the configuration of the Wide Area Application Services (WAAS) lab
on which the course labs are based.
Pod Topology
Branch Office
WAN
Data Center
Edge Router
WAN: VLAN 200
10.10.200.X
Central Manager WAE

10.10.100.24X
VLAN 100
LAN: 802.1q
VLAN X0: 10.10.X0.1
VLAN X1: 10.10.X1.1
DC Router
WAN: VLAN
201
10.10.200.1X
Internal (NME-WAE)
VLAN X2: 10.10.X2.1
Windows XP PC
WANBridge
10.10.90.254
Edge WAE
10.10.X1.250
VLAN X1
Edge NME-WAE
VLAN X2:
10.10.X2.250
Server
(Domain, FTP,
DC Router
CIFS, Web,
LAN: 802.1q
TFTP)
VLAN 100: 10.10.100.X
10.10.100.100
VLAN X3: 10.10.X3.1
Core WAE VLAN 100
10.10.X3.250
VLAN X3
Domain NetBIOS name: WAAS
FQDN: waas.local
X = your pod number
WAAS v4.0.75-2
The topology of a single pod is shown in the figure.
B-2
VLANs
Branch Office
WAN
Data Center
VLAN 100
VLAN 200
VLAN 201
VLAN X0
VLAN X1
VLAN X2
VLAN X3
WAAS v4.0.75-3
The topology of a single pod is shown in the figure.
Appendix B
B-3
Switch VLANs
A LAN switch is a shared resource and configured with VLANs:
VLAN X0 (branch workstation VLAN, per pod)
VLAN X1 (branch WAE appliance VLAN, per pod)
VLAN X2 (branch NME-WAE VLAN, per pod)
VLAN X3 (data center WAE appliance VLAN, per pod)
VLAN 100 (data center access VLAN, shared)
VLAN 200 (WAN subnet, shared, branch facing)
VLAN 201 (WAN subnet, shared, data center facing)
The LAN switch should have an IP address in each VLAN of
10.10.(vlan).253.
WAAS v4.0.75-4
The LAN switch is a shared resource and is configured with VLANs:
VLAN X0 (branch office workstation VLAN, per pod)
VLAN X1 (branch office WAE VLAN, per pod)
VLAN X2 (data center WAE VLAN, per pod)
VLAN 90 (branch-facing WAN subnet, shared)
VLAN 91 (DC-facing WAN subnet, shared)
VLAN 100 (data center access VLAN, shared)
The LAN switch should have an IP address in VLAN 100 of 10.10.100.253.
B-4
Router VLANs
Each branch router should be configured to trunk two VLANs to the
branch LAN via the branch LAN interface:
VLAN x0: Branch office client workstation
VLAN x: Branch office WAE appliance
Note: The branch office WAE VLAN is also physically inline for both of these VLANs
between the router and the switch
The branch router should also have an internal interface to support

the NME-WAE:
VLAN x2: Branch NME-WAE VLAN
Each data center router should be configured to trunk two VLANs to

the data center LAN with the data center LAN interface:
VLAN x3: Data center WAE appliance
VLAN 100: Data center server and Central Manager WAEs
VLANs 200 and 201 are the WAN VLANs. WANBridge installs as a
bridge between these VLANs to provide WAN emulation between
branch routers and data center routers.
WAAS v4.0.75-5
Each branch router should be configured to trunk two VLANs to the branch LAN with the
branch LAN interface:
VLAN x0: A client branch VLAN (workstation access)
VLAN x1: A client WAE branch VLAN (edge WAE access)
Each data center router should be configured to trunk two VLANs to the data center LAN with
the data center LAN interface:
VLAN x2: A client WAE DC VLAN (core WAE access)
VLAN 100: A shared DC VLAN (CM WAEs, printer, server)
WAN VLANs include 90 (branch-facing) and 91 (DC-facing). NIST installs as a router

between these VLANs and must be configured as a network router (policy routing).
Appendix B
B-5
IP Addressing Schema
The shared LAN switch should be configured with the following
VLANs and use the following IP address schema:
10.10.(vlan#).(node#)
Class C subnet universally
Where:
.1 is always the router interface
.10 is the Windows PC
.100 is the server
.24X is the CM WAE (Central Manager WAEs only)
.250 is the WAE (optimization WAEs only)
.253 is the switch
.254 is the WANBridge
WAAS v4.0.75-6
The shared LAN switch should be configured with the following VLANs and use the following
IP address schema:
10.10.(vlan#).(node#)
Class C subnet universally
Where:
B-6
.1 is always the router interface
.10 is the Windows PC
.11 is the Linux PC
.100 is the server
.101-.109 is reserved for VPN users
.200 is the printer
.24X is the CM WAE (Central Manager WAEs only)
.250 is the WAE (optimization WAEs only)
.253 is the switch
.254 is the NISTnet interface
Servers
The data center server is a shared component with a single (required)
network interface in the shared data center VLAN.
Configured to provide the following services:
Domain controller (single domain)
CIFS file services, shares, and files, with appropriate permissions
configured per student pod (user)
Intranet web services with sample content to download
FTP server service for content upload and download
TFTP server service for device image transfer and configuration transfer
Network printer controlled by server
Domain name is waas.local.

The server must be configured with static routes for user workstations
to go through that users router path.
WAAS v4.0.75-7
The data center server is a shared component with a single (required) network interface in the
shared data center VLAN. It is configured to provide the following services:
Domain controller (single domain)
CIFS file services, shares, and files with appropriate permissions configured per student
pod (user)
Intranet web services with sample content to download
FTP server service for content upload and download
TFTP server service for device image transfer and configuration transfer
Network printer, controlled by server
The domain name is waas.local. The server must be configured with static routes for user
workstations to go through that users router path.
Appendix B
B-7
WAN Emulation
WANBridge is installed as a bridging device between VLANs 90
and 91. No routing configuration is required, because it does not
insert itself beyond Layer 2.
Assumes that correct Layer 3 configuration and routing are
configured:
Must ensure that client workstation traffic going to server traverses routers
associated only with client pod
Must ensure that server traffic returning to client workstation traverses routers
associated only with client pod
WANBridge configuration possibilities:

Dedicated WANBridge PC per pod; common EIGRP AS on each of the pod
routers (branch and data center) (recommended)
Shared WANBridge PC per pod; unique EIGRP AS on each of the pod routers
(branch and data center)
Shared WANBridge PC per pod; static routing
WANBridge should be configured with IP address 10.10.200.254

to permit students to examine NTOP for network statistics.
WAAS v4.0.75-8
WANBridge is installed as a bridging device between VLANs 90 and 91. No routing

configuration is required, because it does not insert itself beyond Layer 2.
This assumes that correct Layer 3 configuration and routing are configured:
You must ensure that client workstation traffic going to server traverses routers is
associated only with client pods.
You must ensure that server traffic returning to client workstation traverses routers is
associated only with client pods.
WANBridge configuration possibilities include:
Dedicated WANBridge PC per pod; common EIGRP AS on each of the pod routers
(branch and data center) (recommended)
Shared WANBridge PC per pod; unique EIGRP AS on each of the pod routers (branch and
data center)
Shared WANBridge PC per pod; static routing
WANBridge should be configured with IP address 10.10.200.254 to permit students to examine

NTOP for network statistics.
B-8
Accessing the Lab

1.
Browse to www.labgear.net.
2.
Log in with instructor-supplied

credentials.
Click the green buttons to

access devices.
Use the Device Manager
menu control power or
clear console.
WAAS v4.0.75-9
To access the LabGear WAAS lab, follow these steps:

Step 1
Browse to www.labgear.net.
Step 2
Log in using instructor-supplied credentials.
Step 3
Click the green buttons to access devices.
Step 4
Use the Device Manager menu control power or clear console.
Appendix B
B-9
Passwords
Device
User Name
Password
WAEs
admin
default
Routers
admin
cisco
Windows PCs
administrator
cisco
WAAS v4.0.75-10
The figure shows the default user names and passwords for both labs.
B-10
Appendix C
Design Workshop Reference

Topologies
Overview
This appendix describes the topologies used for the design case study workshops.
FogHorn International
Bellevue, WA
Branch Office
1Mbps WAN
50 Users
2 Servers
Provo, UT
Branch Office
1Mbps WAN
15 Users
0 Servers
Denver, CO
Branch Office
1Mbps WAN
30 Users
2 Servers
St Paul, MN
Branch Office
45Mbps WAN
200 Users
4 Servers
Chicago, IL
Branch Office
45Mbps WAN
300 Users
4 Servers
St Louis, MO
Branch Office
1Mbps WAN
20 Users
2 Servers
Anaheim, CA
Branch Office
45Mbps WAN
300 Users
8 Servers
Houston, TX
Data Center
155Mbps WAN
New York, NY
Branch Office
10Mbps WAN
150 Users
2 Servers
Cary, NC
Branch Office
8Mbps WAN
100 Users
2 Servers
Orlando, FL
Branch Office
1.5Mbps WAN
50 Users
2 Servers
WAAS v4.0.75-2
This slide shows the topology of FogHorn International.
C-2
XYZ Limited
Seattle, WA
Regional Office
155Mbps WAN
300 Users
4 Servers
San Jose, CA
Data Center
1Gbps WAN
10,000 Users
50 Servers
Denver, CO
Regional
Office
45Mbps WAN
100 Users
2 Servers
Chicago, IL
Regional Office
155Mbps WAN
400 Users
5 Servers
Boxborough, MA
Regional Office
310Mbps WAN
800 Users
10 Servers
Raleigh, NC
Data Center
1Gbps WAN
5000 Users
20 Servers
Richardson, TX
Regional Office
155Mbps WAN
500 Users
30 Servers
WAAS v4.0.75-3
This slide shows the topology of XYZ Limited.
Appendix C
C-3
C-4

WAAS407SG Vol3 PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WAAS407SG Vol3 PDF

Uploaded by

Copyright:

Available Formats

Table of Contents

Microsoft Windows Networking

Lab Reference Guide

Design Workshop Reference Topologies

Microsoft Windows Networking

Hands-on lab topology information

Design workshop reference diagrams

Describe Microsoft Windows Networking concepts

Cisco Wide Area Application Services Technical Training (WAAS) v4.0.7

2007 Cisco Systems, Inc.

Microsoft Windows Networking

Describe Microsoft domain concepts, including Windows NT domains and Active

Describe Microsoft authentication and authorization concepts including NTLM and

Describe Microsoft CIFS file-sharing protocol and capabilities

Describe Microsoft CIFS architecture and session flows

Describe CIFS locking, share mode, and opportunistic lock mechanisms

Describe Microsoft distributed file system

Microsoft Domain Concepts

Milestones of Windows Networking

The following milestones were reached in the 1980s:

personal computer introduced to the public.

Microsoft acquires disk operating system (DOS) technology (MS-DOS).

Windows version 3 and Windows for Workgroups is introduced.

Workgroups built on NetBIOS over NetBEUI / IPX/SPX / TCP/IP.

The following milestones were reached in the 1990s:

Microsoft Windows New Technology (NT) is introduced.

Windows NT domains are created.

Onset of TCP/IP and internetworking.

The following milestones were reached after 2000:

Microsoft Windows 2000 is introduced.

Microsoft Active Directory is introduced.

Cisco Wide Area Application Services Technical Training (WAAS) v4.0.7

2007 Cisco Systems, Inc.

2007 Cisco Systems, Inc. All rights reserved.

The following are some basics about Windows NT domains:

2007 Cisco Systems, Inc.

Windows NT Domains (Cont.)

R = number of Resource Domains

Cisco Wide Area Application Services Technical Training (WAAS) v4.0.7

2007 Cisco Systems, Inc.

2007 Cisco Systems, Inc. All rights reserved.

AD is a very common deployment component in Microsoft Networking. It is a directory service

2007 Cisco Systems, Inc.

Active Directory Domains

2007 Cisco Systems, Inc. All rights reserved.

Cisco Wide Area Application Services Technical Training (WAAS) v4.0.7

2007 Cisco Systems, Inc.

Active Directory Trees and Forests

Schema: The class and attribute settings.

Configuration: Site and replication information.

Global catalog: Provides forest-wide search capabilities by storing a copy of all AD

2007 Cisco Systems, Inc.

Active Directory Tree

2007 Cisco Systems, Inc. All rights reserved.

Cisco Wide Area Application Services Technical Training (WAAS) v4.0.7

2007 Cisco Systems, Inc.

Active Directory Forest

2007 Cisco Systems, Inc. All rights reserved.

2007 Cisco Systems, Inc.

Active Directory Domain Names

NetBIOS domain names:

2007 Cisco Systems, Inc. All rights reserved.