1.

RAID (Redundant Array of Independent Disks)

2. Domain Groups
a. Local Group
b. Global Group
c. Universal Group
3. Group Policy
4. DFS (Distributed File System)
5. IIS (Internet Information Services)
6. Backup Types
7. DNS (Domain Naming Server)
a. Primary DNS Roles
i. Forward Lookup Zones
ii.Reverse Lookup Zones
iii.Stub Zones
iv.Active Directory Integrated Zones
b. Secondary DNS Roles
c. Caching Only DNS Roles
8. WINS (Windows Internet Naming Service)
9. DHCP (Dynamic Host Configuration Protocol)
10.Active Directory
a. Logical Element of Active Directory
i. Domain
ii.Trees
iii.Forests
iv.Organizational Units
v.Trust Relationships
b. Physical Element of Active directory
i. Domain Controller
ii.Site Topology
iii.Global Catalog Server
c. Implementing Server Roles (Flexible Singh Master Operation)
i. Schema Master – Forest Wide Role
ii.Domain Naming Master – Forest Wide Role
iii.RID Master – Domain Wide Role
iv.PDC Emulator – Domain Wide Role
v.Infrastructure Master – Domain Wide Role

vi.Transferring FSMO Role

vii.Seizing FSMO Role
d. Backup Active Directory
e. Restoring Active Directory
i. Primary Restore Operation
ii.Non authoritative Restore Operation
iii.Authoritative Restore Operation
f. Active Directory Database Replication
g. Schema
h. UPN
i. Active Directory Structure and Storage Architecture
j. Protocol Used by the Active directory
i. RPC :(Remote Procedure Call):
ii.SMTP: (Simple Mail Transfer Protocol)
k. Ports used by the Active directory

i. TCP 135 : MS-RPC

ii.TCP 1025 & 1026 : AD Login & replication
iii.TCP 389 : LDAP
 iv.TCP & UDP 53 : DNS
v.TCP 445 : SMB , Microsoft-ds
vi.TCP 139 : SMB
vii.UDP 137 & 138 : NetBIOS related
viii.UDP 88 : Kerberos v5
1. RAID (Redundant Array of Independent Disks)

a. RAID-0: This technique has striping but no redundancy of data. It offers the best performance but
no fault-tolerance.
b. RAID-1: This type is also known as disk mirroring and consists of at least two drives that duplicate
the storage of data. There is no striping. Read performance is improved since either disk can be
read at the same time. Write performance is the same as for single disk storage. RAID-1 provides
the best performance and the best fault-tolerance in a multi-user system.
c. RAID-2: This type uses striping across disks with some disks storing error checking and correcting
(ECC) information. It has no advantage over RAID-3.
d. RAID-3: This type uses striping and dedicates one drive to storing parity information. The
embedded error checking (ECC) information is used to detect errors. Data recovery is
accomplished by calculating the exclusive OR (XOR) of the information recorded on the other
drives. Since an I/O operation addresses all drives at the same time, RAID-3 cannot overlap I/O. For
this reason, RAID-3 is best for single-user systems with long record applications.
e. RAID-4: This type uses large stripes, which means you can read records from any single drive.
This allows you to take advantage of overlapped I/O for read operations. Since all write operations
have to update the parity drive, no I/O overlapping is possible. RAID-4 offers no advantage over
RAID-5.
f. RAID-5: This type includes a rotating parity array, thus addressing the write limitation in RAID-4.
Thus, all read and write operations can be overlapped. RAID-5 stores parity information but not
redundant data (but parity information can be used to reconstruct data). RAID-5 requires at least
three and usually five disks for the array. It's best for multi-user systems in which performance is
not critical or which do few write operations.
g. RAID-6: This type is similar to RAID-5 but includes a second parity scheme that is distributed
across different drives and thus offers extremely high fault- and drive-failure tolerance.
h. RAID-7: This type includes a real-time embedded operating system as a controller, caching via a
high-speed bus, and other characteristics of a stand-alone computer. One vendor offers this
system.
i. RAID-10: Combining RAID-0 and RAID-1 is often referred to as RAID-10, which offers higher
performance than RAID-1 but at much higher cost. There are two subtypes: In RAID-0+1, data is
organized as stripes across multiple disks, and then the striped disk sets are mirrored. In RAID-
1+0, the data is mirrored and the mirrors are striped.
j. RAID-50 (or RAID-5+0): This type consists of a series of RAID-5 groups and striped in RAID-0
fashion to improve RAID-5 performance without reducing data protection.
k. RAID-53 (or RAID-5+3): This type uses striping (in RAID-0 style) for RAID-3's virtual disk blocks.
This offers higher performance than RAID-3 but at much higher cost.
l. RAID-S (also known as Parity RAID): This is an alternate, proprietary method for striped parity
RAID from EMC Symmetrix that is no longer in use on current equipment. It appears to be similar
to RAID-5 with some performance enhancements as well as the enhancements that come from
having a high-speed disk cache on the disk array.
2. Domain Groups
There are two types of Domain groups
a. Security Group: A security group is a security principal and so can be used to assign permissions
& rights to a collection of user accounts. This group can be used to distribute email, but it can be
assigned permissions as well.
b. Distribution Group: It is not a security principal & cannot be used to assign permissions. This is
used for email. It can be created when a mailbox is desired for a collection of user accounts, but no
permissions will be needed. It cannot be used to assign permissions or rights
3. There is three domain group scope
 a. Domain Global--This group type can contain user and computer accounts from the group's domain.
If you set the domain level to Win2K native or later, global groups can contain other global groups
from the local domain.
b. Domain local--This group type exists only on domain controllers (DCs) and is used to assign
permissions to a DC's resources (for member servers, you'd use the standard local group type).
Domain local groups can contain users and global groups from any domain in the forest. If you set
the domain level to Win2K native or later, domain local groups can contain other domain local
groups and universal groups.
c. Universal--This group type is available only in Win2K native mode and later and belongs to the
forest rather than to a specific domain. As a result, universal groups can contain users and global
groups from any domain and other universal groups. You can give universal groups access to any
resource in any domain.

4.

What Is the Global Catalog?

Updated: June 3, 2010

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server
2003 with SP2, Windows Server 2008, Windows Server 2008 R2
In this section
• Common Global Catalog Scenarios

• Global Catalog Dependencies and Interactions

• Related Information

The global catalog is a distributed data repository that contains a searchable, partial representation of every
object in every domain in a multidomain Active Directory Domain Services (AD DS) forest. The global catalog is
stored on domain controllers that have been designated as global catalog servers and is distributed through
multimaster replication. Searches that are directed to the global catalog are faster because they do not involve
referrals to different domain controllers.

Note

In Windows Server® 2003 and Microsoft Windows® 2000 Server, the directory service is named
Active Directory. In Windows Server 2008 R2 and Windows Server 2008, the directory service is named
Active Directory Domain Services. The rest of this topic refers to AD DS, but the information is also
applicable to Active Directory.
In addition to configuration and schema directory partition replicas, every domain controller in a forest stores a
full, writable replica of a single domain directory partition. Therefore, a domain controller can locate only the
objects in its domain. Locating an object in a different domain would require the user or application to provide
the domain of the requested object.
The global catalog provides the ability to locate objects from any domain without having to know the domain
name. A global catalog server is a domain controller that, in addition to its full, writable domain directory
partition replica, also stores a partial, read-only replica of all other domain directory partitions in the forest. The
additional domain directory partitions are partial because only a limited set of attributes is included for each
object. By including only the attributes that are most used for searching, every object in every domain in even
the largest forest can be represented in the database of a single global catalog server.

Note

A global catalog server can also store a full, writable replica of an application directory partition, but objects
in application directory partitions are not replicated to the global catalog as partial, read-only directory
partitions.
The global catalog is built and updated automatically by the AD DS replication system. The attributes that are
replicated to the global catalog are identified in the schema as the partial attribute set (PAS) and are defined by
default by Microsoft. However, to optimize searching, you can edit the schema by adding or removing attributes
that are stored in the global catalog.
In Windows 2000 Server environments, any change to the PAS results in full synchronization (update of all
attributes) of the global catalog. Later versions of Windows Server reduce the impact of updating the global
catalog by replicating only the attributes that change.
In a single-domain forest, a global catalog server stores a full, writable replica of the domain and does not store
any partial replica. A global catalog server in a single-domain forest functions in the same manner as a non-
global-catalog server except for the processing of forest-wide searches.

Common Global Catalog Scenarios

The following events require a global catalog server:

• Forest-wide searches. The global catalog provides a resource for searching an AD DS forest. Forest-
wide searches are identified by the LDAP port that they use. If the search query uses port 3268, the query
is sent to a global catalog server.

• User logon. In a forest that has more than one domain, two conditions require the global catalog during
user authentication:

• In a domain that operates at the Windows 2000 native domain functional level or higher, domain
controllers must request universal group membership enumeration from a global catalog server.

• When a user principal name (UPN) is used at logon and the forest has more than one domain, a global
catalog server is required to resolve the name.

• Universal Group Membership Caching: In a forest that has more than one domain, in sites that have
domain users but no global catalog server, Universal Group Membership Caching can be used to enable
caching of logon credentials so that the global catalog does not have to be contacted for subsequent user
logons. This feature eliminates the need to retrieve universal group memberships across a WAN link from
a global catalog server in a different site.

Note

Universal groups are available only in a domain that operates at the Windows 2000 native domain
functional level or higher.

• Exchange Address Book lookups. Servers running Microsoft Exchange Server rely on access to the global
catalog for address information. Users use global catalog servers to access the global address list (GAL).

Search Requests
Because a domain controller that acts as a global catalog server stores objects for all domains in the forest, users
and applications can use the global catalog to locate objects in any domain within a multidomain forest without a
referral to a different server.

When a forest consists of a single domain, every domain controller has a full, writable copy of every object in the
domain and forest. However, it is important to retain the global catalog on at least one domain controller
because many applications use port 3268 for searching. For example, if you do not have any global catalog
servers, the Search command on the Start menu cannot locate objects in AD DS.
The replicas that are replicated to the global catalog also include the access permissions for each object and
attribute. If you are searching for an object that you do not have permission to access, you do not see the object
in the list of search results. Users can find only objects to which they are allowed access.

User Logon Support

In addition to its role as a search provider, in a forest that has more than one domain, the global catalog has a
role as an identity source during the user logon process. Universal groups can provide access to resources
outside of the users domain. User principal names (UPNs) can specify a domain other than the domain of the
user. By making universal group membership and UPN domain-user mapping information available on all global
catalog servers, the global catalog provides the definitive source for groups that are capable of providing access
in more than one domain and names that do not unequivocally identify the domain of the user.

Universal Group Membership

During the domain logon process, the user must be authenticated. During the authentication process, the user is
validated (the domain controller verifies the identity of the user) and the user receives authorization data for
access to resources. To provide authorization data of a user, the authenticating domain controller retrieves the
security identifiers (SIDs) for all security groups of which the user is a member and adds these SIDs to the user’s
access token. In a forest that has more than one domain, the global catalog is the only location where
memberships of all universal groups in that forest can be ascertained. For this reason, access to a global catalog
server is required for successful authentication in a domain that can have universal groups.

The global catalog stores the membership (the member attribute) of only universal groups. The membership of
other groups can be ascertained at the domain level.

Because a universal group can have members from domains other than the domain where the group object is
stored and can be used to provide access to resources in any domain, only a global catalog server is guaranteed
to have all universal group memberships that are required for authentication.

For example, a user might be a member of a universal group that has its group object stored in a different
domain but provides access to resources in the user’s domain. To ensure that the user can be authorized to
access resources appropriately in this domain, the domain controller must have access to the membership of all
universal groups in the forest.

If a global catalog server is not available, the user logon fails.

User Principal Name

A user principal name (UPN) is a logon name that takes the form of an e-mail address. A UPN specifies the user
ID followed by a DNS domain name, separated by an "@" character (for example, jsmith@contoso.com). UPNs
allow administrative management of the UPN suffix to provide logon names that:

• Match the user’s e-mail name.

• Do not reveal the domain structure of the forest.

When a user account is created, the UPN suffix is generated by default as userName@ DnsDomainName, but
it can be changed administratively. For example, in a forest that has four domains, the UPN suffix might be
configured to map to the external DNS name for the organization. The userPrincipalName attribute of the user
account identifies the UPN and is replicated to the global catalog.

When you use a UPN to log on to a domain, your workstation contacts a global catalog server to resolve the
name because the UPN suffix is not necessarily the domain for which the contacted domain controller is
authoritative. If the DNS domain name in the UPN suffix is not a valid DNS domain, the logon fails. Assuming the
UPN suffix is a valid DNS name, the global catalog server returns the name of the AD DS domain to your
workstation, which then queries DNS for a domain controller in that domain.

If a company has more than one forest and uses trust relationships between the domains in the different forests,
a UPN cannot be used to log on to a domain that is outside the user’s forest because the UPN is resolved in the
global catalog of the user’s forest.
Universal Group Membership Caching
Universal Group Membership Caching eliminates the need for a domain controller in a multidomain forest to
contact a global catalog server during the logon process in domains where universal groups are available.
Caching group membership reduces WAN traffic, which helps in sites where updating the cached group
membership of security principals, including user and computer accounts, generates less traffic than replicating
the global catalog to the site.

Use the following criteria to determine if a site is a good candidate for Universal Group Membership Caching:

• Number of users and computers in the site: The site has less than 500 combined users and computers,
including transient users who log on occasionally but not on a regular basis. The cache of a user who logs
on once continues to be updated periodically for 180 days after the first logon. A general limit of
500 membership caches can be updated at a time. If greater than 500 security principals have cached
group memberships, some caches might not be updated.

• Number of domain controllers: Each domain controller performs a refresh on every user in its site once
every eight hours. Depending on the number of domains in the forest, 500 security principals and two
domain controllers could generate more WAN traffic than placing a global catalog server in the site.
Therefore, you need to rationalize the WAN costs when exceeding 500 security principals and two domain
controllers.

• Tolerance for high latency in group updates. Because domain controllers in the site where Universal
Group Membership Caching is enabled update the membership caches every eight hours, and because
credentials are always taken from the cache, updates to group memberships are not reflected in the
security principal’s credentials for up to eight hours.

Address Book Lookups

Exchange Server uses the global catalog to store mail recipient data that enables clients in a forest to send and
receive e-mail messages.

Global Catalog Dependencies and Interactions

Global catalog servers have the following dependencies and interactions with other Windows Server
technologies:

• AD DS installation. When AD DS is installed on the first domain controller in a forest, the installation
application creates that domain controller as a global catalog server.

• AD DS replication. The global catalog is built and maintained by AD DS replication:

• Subsequent to forest creation, when a domain controller is designated as a global catalog server,
AD DS replication automatically transfers PAS replicas to the domain controller, including the partial
replica of every domain in the forest other than the local domain.

• To facilitate intersite replication of global catalog server updates, AD DS replication selects global
catalog servers as bridgehead servers whenever a global catalog server is present in a site and
domains that are not present in the site exist in other sites in the forest.

• Domain Name System (DNS). Global catalog server clients depend on DNS to provide the IP address of
global catalog servers. DNS is required to advertise global catalog servers for domain controller location.

• Net Logon service. Global catalog advertisement in DNS depends on the Net Logon service to perform
DNS registrations. When replication of the global catalog is complete, or when a global catalog server
 starts, the Net Logon service publishes service (SRV) resource records in DNS that specifically advertise
the domain controller as a global catalog server.

• Domain controller Locator: When a global catalog server is requested (by a user or application that
launches a search over port 3268, or by a domain controller that is authenticating a user logon), the
domain controller Locator queries DNS for a global catalog server.

In the following diagram, global catalog interactions include tracking a global catalog server through the
following interactions, which are indicated by boxes:

• Active Directory installation of a new forest: Global catalog creation occurs during AD DS installation
of the first domain controller in the forest.

• Net Logon registration: Resource records are registered in DNS to advertise the domain controller as a
global catalog server.

• AD DS replication:

• When a new domain controller (DC2) is created and an administrator designates it as a global catalog
server, replication of the PAS from DC1 occurs.

• DC1 in DomainA replicates changes for DomainA to DC2, and DC2 replicates updates to data for
DomainB to DC1.

• DC location: The dotted lines enclose the processes whereby two clients locate a global catalog server
by querying DNS:

• A through C: (A) ClientX sends a query to the global catalog, which prompts (B) a DNS query to locate
the closest global catalog server, and then (C) the client contacts the returned global catalog server
DC2 to resolve the query.

• 1 through 5: (1) ClientY logs on to the domain, which prompts (2) a DNS query for the closest domain
controllers. (3) ClientY contacts the returned domain controller DC3 for authentication. (4) DC3 queries
DNS to find the closest global catalog server and then (5) contacts the returned global catalog server
DC2 to retrieve the universal groups for the user.

Interactions with Other Windows Technologies

The global catalog solves the problem of how to locate domain data that is not stored on a domain controller in
the domain of the client that requires the information. By using different ports for standard LDAP queries
(port 389) and global catalog queries (port 3268), AD DS effectively separates forest-wide queries that require a
global catalog server from local, domainwide queries that can be serviced by the domain controller in the user’s
domain.

Active Directory Structure and Storage Technologies

Updated: March 28, 2003

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server
2003 with SP2, Windows Server 2008, Windows Server 2008 R2
Administrators use Active Directory to store and organize objects on a network (such as users, computers,
devices, and so on) into a secure hierarchical containment structure that is known as the logical structure.
Although the logical structure of Active Directory is a hierarchical organization of all users, computers, and other
physical resources, the forest and domain form the basis of the logical structure. Forests, which are the security
boundaries of the logical structure, can be structured to provide data and service autonomy and isolation in an
organization in ways that can both reflect site and group identities and remove dependencies on the physical
topology.

Note

In Windows 2000 Server and Windows Server 2003, the directory service is named Active Directory. In
Windows Server 2008 and Windows Server 2008 R2, the directory service is named Active Directory Domain
Services (AD DS). The rest of this topic refers to Active Directory, but the information is also applicable to
Active Directory Domain Services.
Domains can be structured in a forest to provide data and service autonomy (but not isolation) and to optimize
replication with a given region. This separation of logical and physical structures improves manageability and
reduces administrative costs because the logical structure is not affected by changes in the physical structure.
The logical structure also makes it possible to control access to data. This means that you can use the logical
structure to compartmentalize data so that you can control access to it by controlling access to the various
compartments.
The data that is stored in Active Directory can come from many diverse sources. With so many different data
sources and so many different types of data, Active Directory must employ some type of standardized storage
mechanism so that it can maintain the integrity of the data that it stores. In Active Directory, objects are used to
store information in the directory, and all objects are defined in the schema. The object definitions contain
information, such as data type and syntax, that the directory uses to ensure that the stored data is valid. No data
can be stored in the directory unless the objects that are used to store the data are first defined in the schema.
The default schema contains all the object definitions that Active Directory needs to function; however, you can
also add object definitions to the schema.
While the directory is exposed to you through a logical structure that consists of elements such as domains and
forests, the directory itself is implemented through a physical structure that consists of a database that is stored
on all domain controllers in a forest. The Active Directory data store handles all access to the database. The data
store consists of both services and physical files. These services and physical files make the directory available,
and they manage the processes of reading and writing the data inside the database that exists on the hard disk
of each domain controller.

Active Directory Structure and Storage Architecture

The Active Directory structure and storage architecture consists of four parts:

• Active Directory domains and forests. Forests, domains, and organizational units (OUs) make up the core
elements of the Active Directory logical structure. A forest defines a single directory and represents a
security boundary. Forests contain domains.

• Domain Name System (DNS) support for Active Directory. DNS provides a name resolution service for
domain controller location and a hierarchical design that Active Directory can use to provide a naming
convention that can reflect organizational structure.

• Schema. The schema provides object definitions that are used to create the objects that are stored in the
directory.

• Data store. The data store is the portion of the directory that manages the storage and retrieval of data
on each domain controller.
The following figure illustrates the Active Directory data structure and storage architecture.

Active Directory Data Structure and Storage Architecture

Active Directory Domains and Forests
Domains partition the directory into smaller sections within a single forest. This partitioning results in more
control over how data is replicated so that an efficient replication topology can be established and network
bandwidth is not wasted by replicating data where it is not required. OUs make it possible to group resources in a
domain for management purposes, such as applying Group Policy or delegating control to administrators.

The following figure illustrates the relationships of OUs, domains, and forests in the logical structure architecture.

Logical Structure Architecture

DNS Support for Active Directory

Active Directory uses DNS as its domain controller location mechanism. When any of the principal
Active Directory operations, such as authentication, updating, or searching, is performed, domain joined
computers use DNS to locate Active Directory domain controllers, and these domain controllers use DNS to
locate each other. For example, when a network user with an Active Directory user account logs on to an
Active Directory domain, the user’s computer uses DNS to locate a domain controller for the Active Directory
domain to which the user wants to log on.

To log on to a network that consists of an Active Directory forest, a client workstation must first be able to locate
a nearby domain controller. The domain controller is necessary for initial authentication of both the workstation
and the user and for subsequent authorization of the user for the files and resources to which the user needs
access. The support that is provided to Active Directory by DNS enables a client workstation to locate a domain
controller.

Active Directory Schema

The Active Directory schema contains definitions for all the objects that are used to store information in the
directory. There is one schema per forest. However, a copy of the schema exists on every domain controller in
the forest. This way, every domain controller has quick access to any object definition that it might need, and
every domain controller uses the same definition when it creates a given object. The data store relies on the
schema to provide object definitions, and the data store uses those definitions to enforce data integrity. The
result is that all objects are created uniformly, and it does not matter which domain controller creates or modifies
an object because all domain controllers use the same object definition.

The following figure illustrates the relationship of the schema to the data store in the schema architecture.

Schema Architecture
Active Directory Data Store
The Active Directory data store is made up of several components that together provide directory services to
directory clients. These components include the following:

• Four interfaces:

• Lightweight Directory Access Protocol (LDAP)

• Replication (REPL) and domain controller management interface

• Messaging API (MAPI)

• Security Accounts Manager (SAM)

• Three service components:

• Directory System Agent (DSA)

• The database layer

• Extensible Storage Engine (ESE)

• The directory database where the data is actually stored

The following figure illustrates the relationships of these components in the data store architecture.

Data Store Architecture

Active Directory Structure and Storage Components

You can define some components for structure and storage in Active Directory, while others are defined by the
system and cannot be modified.

• Forests, domains, and OUs are components that constitute the logical structure of Active Directory. You
define them during the installation of Active Directory.

• DNS support for Active Directory includes components that are used to locate domain controllers and that
use DNS naming schemes. Each domain in a forest must adhere to DNS naming schemes, and domains
are organized in a root and subordinate domain hierarchy.
 • The schema is a single component that exists inside the directory. The schema contains definitions of the
objects that are used to store information in the directory. These object definitions include two primary
components: classSchema objects and attributeSchema objects.

• The data store consists of three layers of components. The first layer provides the interfaces that clients
need to access the directory. The second layer provides the services that perform the operations that are
associated with reading data from and writing data to the directory database. The third layer is the
database itself, which exists as a single file on the hard disk of each domain controller.

Active Directory Domains and Forests

The logical structure of Active Directory is a hierarchical structure of Active Directory domains and OUs in a
forest. The relationships of the components in the logical structure control access to stored data, and they
control how information is replicated between the various domain controllers in the forest. The main components
of the Active Directory logical structure are described in the following table.

Domain and Forest Components

Compon
ent Description

Forest A forest is the highest level of the logical structure hierarchy. An Active Directory forest
represents a single self-contained directory. A forest is a security boundary, which means that
administrators in a forest have complete control over all access to information that is stored
inside the forest and to the domain controllers that are used to implement the forest.

Domain Domains partition the information that is stored inside the directory into smaller portions so that
the information can be more easily stored on various domain controllers and so that
administrators have a greater degree of control over replication. Data that is stored in the
directory is replicated throughout the forest from one domain controller to another. Some data
that is relevant to the entire forest is replicated to all domain controllers. Other data that is
relevant only to a specific domain is replicated only to domain controllers in that particular
domain. A good domain design makes it possible to implement an efficient replication topology.
This is important because it enables administrators to manage the flow of data across the
network, that is, to control how much data is replicated and where that replication traffic takes
place.

OU OUs provide a means for administrators to group resources, such as user accounts or computer
accounts, so that the resources can be managed as one unit. This makes it much easier to apply
Group Policy to multiple computers or to control the access of many users to a single resource.
OUs also make it easier to delegate control over resources to various administrators.

DNS Support for Active Directory

In Active Directory, DNS is the means by which directory clients locate, or discover, domain controllers. The
primary components of the architecture for DNS support of Active Directory include the domain controller
Locator, Active Directory domain names in DNS, and Active Directory DNS objects.

The following table describes the Active Directory components that help directory clients locate nearby domain
controllers.

Active Directory DNS Support Components

Active Directory/D Description

 NS Component

Locator Locator, which is implemented in the Net Logon service, enables a client to locate a
domain controller. Locator contains Internet Protocol (IP)/DNS–compatible and
Windows NT 4.0–compatible locators, which provide interoperability in a mixed Active
Directory environment.

Active Directory Every Active Directory domain has a DNS domain name (for example,
domain names in cohovineyard.com), and every domain joined computer has a DNS name (for
DNS example, server1.cohovineyard.com). Architecturally, domains and computers are
represented both as objects in Active Directory and as nodes in DNS.

Active Directory When DNS data is stored in Active Directory, each DNS zone is an Active Directory
DNS objects container object (class dnsZone). The dnsZone object contains a DNS node object
(class dnsNode) for every unique name in that zone. The dnsNode object has a
dnsRecord multivalued attribute that contains a value for every resource record that
is associated with that DNS name.

For more information about DNS support for Active Directory, see “DNS Support for Active Directory Technical
Reference.”

Active Directory Schema

Everything that is stored in Active Directory is stored in an object. A definition for every type of object is stored in
the schema. The definitions themselves consist of two types of objects: class objects and attribute objects.
Classes define groups of attributes that are used to describe common objects. New object definitions are created
by combining various class objects and attribute objects to make new combinations that contain the necessary
attributes to meet the storage requirements of the new object type. The two main types of object definitions that
are stored in the Active Directory schema are described in the following table.

Schema Components

Component Description

classSchema classSchema objects are object definitions that are stored in the schema, and they are
objects used to define classes. classSchema objects define groups of attributes that have
something in common. For example, an object that is used to store a user account needs
to store the user’s logon name, first name, last name, and password. It is possible to
create a user class that has a logon name attribute, a first name attribute, a last name
attribute, and a password attribute. Anytime a new user account is created, the directory
uses the user class as the definition, and every user account object that is created uses
those attributes. classSchema objects can be nested to create more complex objects.

attributeSchem attributeSchema objects define the individual attributes of a single object. For example, a
a objects user account object has a number of attributes that are used to store and define various
pieces of data that are related to a user account, such as a logon name attribute and a
password attribute. Each of these attributes also has its own attributes that specify the
type of data that it stores, the syntax of the data that it stores, and whether or not the
attribute is required or optional. The directory service uses attributeSchema objects to
store data and verify that the stored data is valid.

Active Directory Data Store

The Active Directory data store is implemented on every domain controller in the forest. The data store consists
of components that store and retrieve data inside the directory. The components of the Active Directory data
store are described in the following table.

Data Store Components

 Component Description

Interfaces The data store interfaces provide a way for directory clients and other directory servers to
(LDAP, REPL, communicate with the data store.
MAPI, SAM)

DSA The DSA (which runs as Ntdsa.dll on each domain controller) provides the interfaces
(Ntdsa.dll) through which directory clients and other directory servers gain access to the directory
database. In addition, the DSA enforces directory semantics, maintains the schema,
guarantees object identity, and enforces data types on attributes.

Database The database layer is an application programming interface (API) that resides in Ntdsa.dll
layer and provides an interface between applications and the directory database to protect the
database from direct interaction with applications. Calls from applications are never made
directly to the database; they go through the database layer. In addition, because the
directory database is flat — with no hierarchical namespace — the database layer provides
the database with an abstraction of an object hierarchy.

ESE (Esent.dll) The ESE (which runs as Esent.dll) communicates directly with individual records in the
directory database on the basis of an object’s relative distinguished name attribute.

Database files The data store stores directory information in a single database file. In addition, the data
store also uses log files, to which it temporarily writes uncommitted transactions.

Types of backup

Updated: January 21, 2005

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server
2003 with SP2

Types of backup
The Backup utility supports five methods of backing up data on your computer or network.

Copy backup
A copy backup copies all the files you select, but does not mark each file as having been backed up (in other
words, the archive attribute is not cleared). Copying is useful if you want to back up files between normal and
incremental backups because copying does not affect these other backup operations.

Daily backup
A daily backup copies all the files that you select that have been modified on the day the daily backup is
performed. The backed-up files are not marked as having been backed up (in other words, the archive attribute
is not cleared).

Differential backup
A differential backup copies files that have been created or changed since the last normal or incremental backup.
It does not mark files as having been backed up (in other words, the archive attribute is not cleared). If you are
performing a combination of normal and differential backups, restoring files and folders requires that you have
the last normal as well as the last differential backup.

Incremental backup
An incremental backup backs up only those files that have been created or changed since the last normal or
incremental backup. It marks files as having been backed up (in other words, the archive attribute is cleared). If
you use a combination of normal and incremental backups, you will need to have the last normal backup set as
well as all incremental backup sets to restore your data.

Normal backup
A normal backup copies all the files you select and marks each file as having been backed up (in other words, the
archive attribute is cleared). With normal backups, you only need the most recent copy of the backup file or tape
to restore all of the files. You usually perform a normal backup the first time you create a backup set.

Backing up your data using a combination of normal backups and incremental backups requires the least amount
of storage space and is the quickest backup method. However, recovering files can be time-consuming and
difficult because the backup set might be stored on several disks or tapes.

Backing up your data using a combination of normal backups and differential backups is more time-consuming,
especially if your data changes frequently, but it is easier to restore the data because the backup set is usually
stored on only a few disks or tapes.

Active Directory; GUID, SID, DN, CN, SAM, and UPN

In this article we’ll discuss SAM Account Name, UPN and OID and some basics about important parts of the Active
Directory.
SAM Account Name
In an NT domain, every object in the SAM must have a unique name. This is true for computers, users, and
groups. A unique name guarantees that the object will have a unique NetBIOS presence in the network as well as
a one-to-one correspondence between the logon name (in the case of users and computers) and the SID used to
control resource access. The same restriction is left in place in Windows 2000 and Windows Server 2003. Every
user, computer, and group in a domain must have a unique name. This attribute is called SAM Account Name,
although you might hear it called logon name or flat name. When you create a new security principal, regardless
of the container where you place the object, it must have a unique flat name in the domain.
User Principal Name (UPN) and Service Principal Name (SPN)
Just as unique flat names identify security principals in NetBIOS, User Principal Names (UPNs) identify security
principals within the hierarchical LDAP namespace in Active Directory. A UPN takes the form
User@Company.com. Unique UPNs ensure that users can log on with their UPN rather than the classic
domain\username construct. The Global Catalog is used to “crack” the UPN into its constituent parts. To assure
uniqueness, when a security principal is created, the system refers to the Global Catalog to verify that the UPN
has not already been used. If a GC server is not available, the system displays an error message prompting the
administrator to wait until a GC is available so that uniqueness can be verified. In a Parent/Child trust
configuration, the UPN suffix of the root domain is assigned to every security principal. In a Tree Root trust
configuration, you must manually assign a common UPN suffix. This is done using the Properties window of the
domain tree in the AD Domains and Trusts console.
Object Identifier (OID)
In addition to the attributes that assure uniqueness of a particular object, Active Directory needs a way to assure
that objects of the same class all come from the same Schema object. This is done by assigning a unique Object
Identifier, or Object Identifier (OID) to each object in the Schema naming context. ISO defines the structure and
distribution of OIDs in ISO/IEC 8824:1990, “Information Technology-Open Systems Interconnection-Specification
of Abstract Syntax Notation One (ASN. 1).”
ASN.1 provides a mechanism for standards bodies in various countries to enumerate standard data items so that
they do not conflict with one other. ASN.1 governs more than just directory services classes and attributes. For
example, OIDs are used extensively in SNMP to build hierarchies of Management Information Base (MIB)
numbers. They are also assigned to many items associated with the Internet. If you’re interested in the list of
organizations that assign OID numbers and their hierarchy, it is available at ftp.isi.edu/in-
notes/iana/assignments/enterprise-numbers.
If you ever need to create a new attribute or object class in Active Directory, you must have a unique OID.
The Active Directory Database (NTDS Folder)
The engine used by Active Directory is based on Microsoft’s Jet database technology. This uses tree file
structure with transaction logs to ensure recoverability in the event of a system or drive failure. It’s also used in
Exchange and DNS services. The AD database consists of two basic tables.
When you promote a server to a domain controller, you select where to put the Active Directory files. The default
path is in the boot partition under \Windows\NTDS. Generally, it is a good idea to put them on a separate volume
from the operating system files to improve performance.
There are a couple of important files you can find within the Active Directory Architecture:
Ntds.dit.
This is the main AD database. NTDS stands for NT Directory Services. The DIT stands for Directory Information
Tree. The Ntds.dit file on a particular domain controller contains all naming contexts hosted by that domain
controller, including the Configuration and Schema naming contexts. A Global Catalog server stores the partial
naming context replicas in the Ntds.dit right along with the full Domain naming context for its domain.
Edb.log.
This is a transaction log. Any changes made to objects in Active Directory are first saved to a transaction
log. The database engine commits the transactions into the main Ntds.dit database. This ensures that the
database can be recovered in the event of a system crash. Entries that have not been committed to Ntds.dit are
kept in memory to improve performance. Transaction log files used by the ESE engine are always 10MB.
Edbxxxxx.log.
These are auxiliary transaction logs used to store changes if the main Edb. log file gets full before it can be
flushed to Ntds.dit. The xxxxx stands for a sequential number in hex. When the Edb. log file fills up, an Edbtemp.
log file is opened. The original Edb. log file is renamed to Edb00001. log, and Edbtemp. log is renamed to Edb.
log file, and the process starts over again.
ESENT uses circular logging. Excess log files are deleted after they have been committed. You may see more
than one Edbxxxxx. log file if a busy domain controller has many updates pending.
Edb.chk.
This is a checkpoint file. It is used by the transaction logging system to mark the point at which updates are
transferred from the log files to Ntds.dit. As transactions are committed, the checkpoint moves forward in the
Edb. chk file. If the system terminates abnormally, the pointer tells the system how far along a given set of
commits had progressed before the termination.
Res1.log and Res2.log.
These are reserve log files. If the hard drive fills to capacity just as the system is attempting to create an
Edbxxxxx. log file, the space reserved by the Res log files is used. The system then puts a dire warning on the
screen prompting you to take action to free up disk space quickly before Active Directory gets corrupted. You
should never let a volume containing Active Directory files get even close to being full. File fragmentation is a big
performance thief, and fragmentation increases exponentially as free space diminishes. Also, you may run into
problems as you run out of drive space with online database defragmentation (compaction). This can cause
Active Directory to stop working if the indexes cannot be rebuilt.
Temp.edb.
This is a sort of scratch pad used to store information about in-progress transactions and to hold pages pulled
out of Ntds.dit during compaction.
Schema.ini.
This file is used to initialize the Ntds.dit during the initial promotion of a domain controller. It is not used after
that has been accomplished.
Globally Unique IDentifier) An implementation of the universally unique ID (see UUID) that is computed by
Windows and Windows applications. Using a pseudo-random 128-bit number, GUIDs are used to identify user
accounts, documents, software, hardware, software interfaces, sessions, database keys and other items.
Introduction to Administering SYSVOL
Updated: March 2, 2005
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server
2003 with SP2
The Windows Server 2003 System Volume (SYSVOL) is a collection of folders and reparse points in the file
systems that exist on each domain controller in a domain. SYSVOL provides a standard location to store
important elements of Group Policy objects (GPOs) and scripts so that the File Replication service (FRS) can
distribute them to other domain controllers within that domain.

Note

Only the Group Policy template (GPT) is replicated by SYSVOL. The Group Policy container (GPC) is
replicated through Active Directory replication. To be effective, both parts must be available on a domain
controller.
FRS monitors SYSVOL and, if a change occurs to any file stored on SYSVOL, then FRS automatically replicates the
changed file to the SYSVOL folders on the other domain controllers in the domain.
The day-to-day operation of SYSVOL is an automated process that does not require any human intervention other
than watching for alerts from the monitoring system. Occasionally, you might perform some system maintenance
as you change your network.
This objective describes the basic tasks required for managing SYSVOL in order to maintain capacity and
performance of SYSVOL, for hardware maintenance, or for data organization.
Key considerations for administering SYSVOL
To manage SYSVOL, ensure that FRS properly replicates the SYSVOL data and that enough space is provided to
store SYSVOL. Implement a monitoring system to detect low disk space and potential FRS disruptions so that you
can address those issues before the system stops replicating. You can use the Ultrasound utility to monitor FRS.
To download Ultrasound, see Ultrasound - Monitoring and Troubleshooting Tool for File Replication Service (FRS)
on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=23439).
Other key considerations for managing SYSVOL are:
• Capacity.

Depending upon the configuration of your domain, SYSVOL can require a significant amount of disk space to
function properly. During the initial deployment, SYSVOL might be allocated adequate disk space to function.
However, as your Active Directory grows in size and complexity, the required capacity can exceed the available
disk space.
If you receive indications that disk space is low, determine if the cause is due to inadequate physical space on
the disk or a registry setting that limits the size of the staging area. By modifying a setting in the registry, you
can allocate more staging area space, rather than relocating SYSVOL or the staging area. Increasing the space
allocation in the registry is much faster and easier than relocation
• Performance.

Any changes made to SYSVOL are automatically replicated to the other domain controllers in the domain. If the
files stored in SYSVOL change frequently, the replication increases the input and output for the volume where
SYSVOL is located. For example, editing a GPO can potentially force a GPO-level replication. If the volume is also
host to other system files, such as the directory database or the pagefile, then the increased input and output for
the volume can impact the performance of the server.
• Hardware maintenance.

System maintenance, such as removal of a disk drive, can require you to relocate SYSVOL. Even if the
maintenance occurs on a different disk drive, verify that that maintenance does not affect the system volume.
Logical drive letters could change after you add and remove disks. FRS locates SYSVOL by using pointers stored
in the directory and the registry. If drive letters change after you add or remove disk drives, be aware that these
pointers are not automatically updated.
• Backing up Group Policy objects (GPOs).

The successful operation of Group Policy is heavily dependant on the reliable operation of SYSVOL. Key
components of the GPO exist in the SYSVOL (in the policies subdirectory) and it is essential that these remain in
sync with related components in Active Directory. Therefore, backing up only the SYSVOL component does not
represent a full and complete backup of your GPOs. The Group Policy Management Console (GPMC) provides
both UI-based and scriptable methods for backing up GPOs. It is important that you back up GPOs as part of your
regular backup/disaster recovery processes. Soon after installation of a new domain, the default domain and
default domain controllers' GPOs should be backed up. They should also be backed up after any subsequent
changes are made.
Understanding the SYSVOL folder structure
Before you attempt to relocate all or portions of the system volume, you must clearly understand the folder
structure and the relationships between the folders and the path information that is stored in the registry and the
directory itself. When folders are relocated, any associated parameters that are stored in the registry and the
directory must be updated to match the new location. The folder structure contains junctions that might also
require updating when folders get moved to a new location.
Maintaining the relationship between the folders, junctions, and stored parameters is important when you must
relocate all or portions of SYSVOL. Failure to do so can result in files being replicated to or from the wrong
location. It can also result in files failing to replicate, yet FRS will not report any errors. Due to the configuration
error, FRS looks in the wrong location for the files that you want to replicate.
The folder structure used by the system volume uses a feature called a junction point. Junction points look like
folders and behave like folders (in Windows Explorer you cannot distinguish them from regular folders), but they
are not folders. A junction point contains a link to another folder. When a program opens it, the junction point
automatically redirects the program to the folder to which the junction point is linked. The redirection is
completely transparent to the user and the application.
If you open Folder3, Windows Explorer is redirected to Folder1 and displays the contents of Folder1. You receive
no indication of the redirection because it is transparent to the user and to Windows Explorer. If you look at the
contents of Folder1, you see that it is exactly the same as the contents displayed when you open Folder3. If you
open a command prompt and list a directory, all three folders appear in the output. The first two are type <DIR>
and Folder3 is type <JUNCTION>. If you list a directory of Folder3, you see the contents of Folder1.

Note

To create or update junctions, you need the Linkd.exe tool supplied with the Windows 2000 Server
Resource Kit. Linkd allows you to create, delete, update, and view the links that are stored in junction
points.
By default, the system volume is contained in the %systemroot%\SYSVOL folder. The tree of folders contained
within this folder can be extensive, depending on how your network uses FRS. When relocating folders in the
system volume, ensure that you move all folders (including any hidden folders) and ensure that the relationships
of the folders do not change unintentionally. When you relocate folders, you need to be concerned with the first
three levels of subdirectories in order to properly update the parameters used by FRS. These levels are affected
by junction points and parameter settings. These folders include:
• %systemroot%\SYSVOL

• %systemroot%\SYSVOL\Domain

• %systemroot%\SYSVOL\Domain\DO_NOT_REMOVE_Ntfrs_ Preinstalled_Directory

• %systemroot%\SYSVOL\Domain\Policies

• %systemroot%\SYSVOL\Domain\Scripts

• %systemroot%\SYSVOL\Staging

• %systemroot%\SYSVOL\Staging\Domain

• %systemroot%\SYSVOL\Staging Areas

• %systemroot%\SYSVOL\Staging Areas FQDN

• %systemroot%\SYSVOL\Sysvol

• %systemroot%\SYSVOL\Sysvol FQDN

(where FQDN is the fully qualified domain name of the domain that this domain controller hosts.)
If you use Windows Explorer to view these folders, they appear to be typical folders. If you open a command
prompt and type dir to list these folders, you will notice two special folders are listed as <JUNCTION>. Both
folders labeled FQDN are junction points. The junction in %systemroot%\SYSVOL\Sysvol links to %systemroot
%\SYSVOL\Domain. The junction in %systemroot%\SYSVOL\Staging Areas is linked to %systemroot
%\SYSVOL\Staging\Domain. If you change the path to the folders to which the junctions are linked, you must also
update the junctions, including drive letter changes and folder changes.
Besides junction points linking to folders within the system volume tree, the registry and the directory also store
references to folders. These references contain paths that you must update if you change the location of the
folder. FRS uses two values that are stored in the directory. The first value, fRSRootPath, points to the location of
the policies and scripts that are stored in SYSVOL. By default, this location is the %systemroot%\SYSVOL\Domain
folder. The second value, fRSStagingPath, points to the location of the folders used as the staging area. By
default, this location is the %systemroot%\SYSVOL\Staging\Domain folder. The Net Logon service uses a
parameter stored in the registry to identify the location of the folder that it uses to create the SYSVOL and
NETLOGON share points. By default, this path is %systemroot%\SYSVOL\Sysvol. If you change the paths to these
folders, you must update these values.
When relocating SYSVOL, you first move the entire folder structure to a new location; then you update all the
junction points and the parameters that are stored in the registry and the directory in order to maintain the
relationships between the parameters, the folders, and the junctions. Optionally, you can relocate the staging
area and leave the rest of the system volume at its original location. In this case, you must update the
fRSStagingPath parameter in the directory and the junction point stored at %systemroot%\SYSVOL\staging areas.

Active Directory Schema

Windows Server 2003 Active Directory uses a database set of rules called "Schema". The Schema is defines as
the formal definition of all object classes, and the attributes that make up those object classes, that can be
stored in the directory. As mentioned earlier, the Active Directory database includes a default Schema, which
defines many object classes, such as users, groups, computers, domains, organizational units, and so on. These
objects are also known as "Classes". The Active Directory Schema can be dynamically extensible, meaning that
you can modify the schema by defining new object types and their attributes and by defining new attributes for
existing objects. You can do this either with the Schema Manager snap-in tool included with Windows 2000/2003
Server, or programmatically.

Introduction to WINS
Windows Internet Name Service (WINS) is the Windows implementation of a NetBIOS name server (NBNS), which
provides a distributed database for registering and querying dynamic mappings of NetBIOS names to IPv4
addresses used on your network. WINS is designed to provide NetBIOS name resolution in routed TCP/IP
networks with multiple subnets. Without WINS, you must maintain Lmhosts files.
Before two hosts that use NetBIOS over TCP/IP (NetBT) can communicate, the destination NetBIOS name must be
resolved to an IPv4 address. TCP/IP cannot establish communication using a NetBIOS computer name. The basic
procedure for WINS-based NetBIOS name resolution is the following:
1. Each time a WINS client starts, it registers its NetBIOS name-to-IPv4 address mappings with a configured
WINS server.

2. When a NetBIOS application running on a WINS client initiates communication with another host, NetBT
sends a NetBIOS Name Query Request message with the destination NetBIOS name directly to the WINS
server, instead of broadcasting it on the local network.

3. If the WINS server finds a NetBIOS name-to-IPv4 address mapping for the queried name in its database, it
returns the corresponding IPv4 address to the WINS client.

Using WINS provides the following advantages:

• Client requests for name resolution are sent directly to a WINS server. If the WINS server can resolve the
name, it sends the IPv4 address directly to the client. As a result, a broadcast is not needed and
broadcast traffic is reduced. However, if the WINS server is unavailable or does not have the appropriate
mapping, the WINS client can still use a broadcast in an attempt to resolve the name.

• The WINS database is updated dynamically so that it is always current. This process allows NetBIOS name
resolution on networks using DHCP and eliminates the need for local or centralized Lmhosts files.

• WINS provides computer browsing capabilities across subnets and domains. Computer browsing provides
the list of computers in My Network Places.

Top of page
How WINS Works
The WINS Server service in Windows Server 2003 is an implementation of an NBNS as described in Requests for
Comments (RFCs) 1001 and 1002. WINS clients use a combination of the following processes:
• Name registration

Each WINS client is configured with the IPv4 address of a WINS server. When a WINS client starts, it
registers its NetBIOS names and their corresponding IPv4 addresses with its WINS server. The WINS
server stores the client’s NetBIOS name-to-IPv4 address mappings in its database.

• Name renewal

All NetBIOS names are registered on a temporary basis so that if the original owner stops using a name, a
different host can use it later. At defined intervals, the WINS client renews the registration for its NetBIOS
names with the WINS server.

• Name resolution

A WINS client can obtain the IPv4 addresses for NetBIOS names by querying the WINS server.

• Name release

When a NetBIOS application no longer needs a NetBIOS name, such as when a NetBIOS-based service is
shut down, the WINS client sends a message to the WINS server to release the name.

These processes are described in greater detail in the following sections.

All WINS communications between WINS clients and WINS servers use unicast NetBIOS name management
messages over User Datagram Protocol (UDP) port 137, the reserved port for the NetBIOS Name Service.

Name Registration
When a WINS client initializes, it registers its NetBIOS names by sending a NetBIOS Name Registration Request
message directly to its configured WINS server. NetBIOS names are registered when NetBIOS services or
applications start, such as the Workstation, Server, and Messenger services.
If the NetBIOS name is unique and another WINS client has not already registered the name, the WINS server
sends a positive Name Registration Response message to the WINS client. This message contains the amount of
time, known as the Time to Live (TTL), that the NetBIOS name is registered to the WINS client. The TTL is
configured on the WINS server.

When a Duplicate Name Is Found

If a duplicate unique name is registered in the WINS database, the WINS server sends a challenge to the
currently registered owner of the name as a unicast NetBIOS Name Query Request message. The WINS server
sends the challenge three times at 500-millisecond intervals.
If the current registered owner responds to the challenge successfully, the WINS server sends a negative Name
Registration Response message to the WINS client that is attempting to register the duplicate name. If the
current registered owner does not respond to the WINS server, the server sends a positive Name Registration
Response message to the WINS client that is attempting to register the name and updates its database with the
new owner.

When WINS Servers are Unavailable

A typical WINS client is configured with a primary and a secondary WINS server, although you can configure
more than two WINS servers. A WINS client makes three attempts to register its names with its primary WINS
server. If the third attempt gets no response, the WINS client sends name registration requests to its secondary
WINS server (if configured) and any additional servers that have been configured. If none of the WINS servers are
available, the WINS client uses local broadcasts to register its NetBIOS names.

Name Renewal
To continue using the same NetBIOS name, a client must renew its registration before the TTL it received in the
last positive Name Registration Response message expires. If the client does not renew the registration, the
WINS server removes the NetBIOS name from its database. After that point, other computers cannot resolve the
NetBIOS name to the address of the former owner and another client can register the name for itself.
Name Refresh Request
Every WINS client attempts to renew its NetBIOS names with its primary WINS server by sending a NetBIOS
Name Refresh message when half of the TTL has elapsed or when the computer or the service restarts. If the
WINS client does not receive a NetBIOS Name Registration Response message, the client sends another refresh
message to its primary WINS server every 10 minutes for one hour. If none of these attempts is successful, the
client then tries the secondary WINS server every 10 minutes for one hour. The client continues to send refresh
messages to the primary server for an hour and then to the secondary server for an hour until either the name
expires or a WINS server responds and renews the name.
If the WINS client succeeds in refreshing its name, the WINS server that responds to the NetBIOS Name Refresh
message resets the renewal interval. If the WINS client fails to refresh the name on either the primary or
secondary WINS server during the renewal interval, the name is released.

Name Refresh Response

When a WINS server receives the NetBIOS Name Refresh message, the server sends the client a positive Name
Registration Response message with a new TTL.

Name Release
When a NetBIOS application running on a WINS client is closed, NetBT instructs the WINS server to release the
unique NetBIOS name used by the application. The WINS server then removes the NetBIOS name mapping from
its database.
The name release process uses the following types of messages:
• Name Release Request

The Name Release Request message includes the client’s IPv4 address and the NetBIOS name to be
removed from the WINS database.

• Name Release Response

When the WINS server receives the Name Release Request message, the server checks its database for
the specified name. If the WINS server encounters a database error or if a different IPv4 address maps to
the registered name, the server sends a negative Name Release Response message to NetBT on the
WINS client.

Otherwise, the WINS server sends a positive Name Release Response message and then designates the
specified name as inactive in its database. The positive Name Release Response message contains the
released NetBIOS name and a TTL value of 0.

Name Resolution
Computers that are running Windows Server 2003 or Windows XP and that are configured with the IPv4
addresses of WINS servers by default use the H-node NetBIOS node type. NetBT always checks the WINS server
for a NetBIOS name-to-IPv4 address mapping before sending a broadcast. The NetBIOS name resolution process
is the following:

1. NetBT checks the NetBIOS name cache for the NetBIOS name-to-IPv4 address mapping of the destination.

2. If the name is not resolved from the NetBIOS name cache, NetBT sends a unicast NetBIOS Name Query
Request message to the configured primary WINS server.

If the primary WINS server can resolve the name, the server responds with a positive NetBIOS Name
Query Response message that contains the IPv4 address for the requested NetBIOS name.

If the primary WINS server does not respond after three separate attempts or responds with a negative
Name Query Response message, the client sends a NetBIOS Name Query Request message to its
configured secondary WINS server.

If additional WINS servers are configured and the secondary WINS server does not respond after three
separate attempts or responds with a negative Name Query Response message, the client sends a
 NetBIOS Name Query Request message to the additional configured WINS server or servers in
configuration order.

3. If none of the servers respond with a positive Name Query Response message, the WINS client broadcasts
up to three Name Query Request messages on the local subnet.

If the name is not resolved from these methods, the WINS client might still resolve the name by parsing the
Lmhosts file; converting the NetBIOS name to a single-label, unqualified domain name; and checking it against
the local host name, the Domain Name System (DNS) client resolver cache, and DNS. For more information, see
Chapter 11, "NetBIOS Over TCP/IP."
Top of page

The WINS Client

You can configure the WINS client, known as the TCP/IP NetBIOS Helper service in the Services snap-in, in the
following ways:
• Automatically, using the Dynamic Host Configuration Protocol (DHCP) and DHCP options.

• Manually, using either the Netsh tool or the properties of the Internet Protocol (TCP/IP) component in
Network Connections.

• Automatically, for Point-to-Point Protocol (PPP) connections.

To determine the IPv4 addresses of the WINS servers that are assigned to the connections of your computer
running Windows Server 2003 or Windows XP, do one of the following:
• Use the ipconfig /all command.

• Use the netsh interface ip show wins command.

• Open the Network Connections folder, right-click a connection, and click Status. Click the Support tab,
and then click Details.

DHCP Configuration of a WINS Client

You can assign WINS servers to DHCP clients by configuring the WINS/NBNS Servers DHCP option (option 44) on
your DHCP server. If WINS servers are manually configured in the properties of the Internet Protocol (TCP/IP)
component, the WINS client ignores the DHCP-based WINS server settings.
WINS clients running Windows Server 2003 or Windows XP automatically use the H-node NetBIOS node type
when it is assigned IPv4 addresses of WINS servers. Because of this behavior, you do not also need to configure
the 046 WINS/NBT Node Type DHCP option (option 46) with a value of 0x8 (H-node) on your DHCP server.