ACTIVE
DIRECTORY – DNS – FSMO – GROUP POLICY
What
Is Active Directory?
Active
Directory consists of a series of components that constitute both its
logical structure and its physical structure. It provides a way for
organizations to centrally manage and store their user objects,
computer objects, group membership, and define security boundaries in
a logical database structure.
Purpose
of Active Directory
Active
Directory stores information about users, computers, and network
resources and makes the resources accessible to users and
applications. It provides a consistent way to name, describe, locate,
access, manage, and secure information about these resources
Functions
of Active Directory
Active
Directory provides the following functions:
Centralizes
control of network resources
By
centralizing control of resources such as servers, shared files, and
printers, only authorized users can access resources in Active
Directory.
Centralizes
and decentralizes resource management
Administrators
have Centralized Administration with the ability to delegate
administration of subsets of the network to a limited number of
individuals giving them greater granularity in resource management.
Store
objects securely in a logical structure
Active
Directory stores all of the resources as objects in a secure,
hierarchical logical structure.
Optimizes
network traffic
The
physical structure of Active Directory enables you to use network
bandwidth more efficiently. For example, it ensures that, when users
log on to the network, the authentication authority that is nearest
to the user, authenticates them reducing the amount of network
traffic.
Sites
within Active Directory
Sites are defined as
groups of well-connected computers. When you establish sites, domain
controllers within a single site communicate frequently. This
communication minimizes the latency within the site; that is, the
time required for a change that is made on one domain controller to
be replicated to other domain controllers. You create sites to
optimize the use of bandwidth between domain controllers that are in
different locations
Operations
Master Roles
When
a change is made to a domain, the change is replicated across all of
the domain controllers in the domain. Some changes, such as those
made to the schema, are replicated across all of the domains in the
forest. This replication is called multimaster
replication.
During
multimaster replication, a replication conflict can occur if
originating updates are performed concurrently on the same object
attribute on two domain controllers. To avoid replication conflicts,
Active Directory uses single
master replication,
which designates one domain controller as the only domain controller
on which certain directory changes can be made. This way, changes
cannot occur at different places in the network at the same time.
Active Directory uses single master replication for important
changes, such as the addition of a new domain or a change to the
forest-wide schema.
Operations
that use single-master replication are arranged together in specific
roles in a forest or domain. These roles are called operations
master roles.
For each operations master role, only the domain controller that
holds that role can make the associated directory changes. The domain
controller that is responsible for a particular role is called an
operations master for that role. Active Directory stores information
about which domain controller holds a specific role.
Forest-wide
Roles
Forest-wide
roles are unique to a forest, forest-wide roles are:
Schema
master
Controls all updates to the schema. The schema contains
the master list of object classes and attributes that are used to
create all Active Directory objects, such as users, computers, and
printers.
Domain
naming master
Controls the addition or removal of domains in the
forest. When you add a new domain to the forest, only the domain
controller that holds the domain naming master role can add the new
domain.
There
is only one schema master and one domain naming master in the entire
forest.
Domain-wide
Roles
Domain-wide
roles are unique to each domain in a forest, the domain-wide roles
are:
Primary
domain controller emulator (PDC)
Acts as a Windows NT PDC to support any backup domain
controllers (BDCs) running Microsoft Windows® NT within a
mixed-mode domain. This type of domain has domain controllers that
run Windows NT 4.0. The PDC emulator is the first domain controller
that you create in a new domain.
Relative
identifier master (RID)
When
a new object is created, the domain controller creates a new
security principal that represents the object and assigns the object
a unique security identifier (SID). This SID consists of a domain
SID, which is the same for all security principals created in the
domain, and a RID, which is unique for each security principal
created in the domain. The RID master allocates blocks of RIDs to
each domain controller in the domain. The domain controller then
assigns a RID to objects that are created from its allocated block
of RIDs.
Infrastructure
master
when
objects are moved from one domain to another, the infrastructure
master updates object references in its domain that point to the
object in the other domain. The object reference contains the
object’s globally unique identifier (GUID), distinguished
name, and a SID. Active Directory periodically updates the
distinguished name and the SID on the object reference to reflect
changes made to the actual object, such as moves within and between
domains and the deletion of the object.
The
global catalog contains:
The
attributes that are most frequently used in queries, such as a
user’s first name, last name, and logon name.
The
information that is necessary to determine the location of any
object in the directory.
The
access permissions for each object and attribute that is stored in
the global catalog. If you search for an object that you do not have
the appropriate permissions to view, the object will not appear in
the search results. Access permissions ensure that users can find
only objects to which they have been assigned access.
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. Taking a user object as an example, it would by
default have many different attributes such as first name, last name,
phone number, and many more. The GC will by default only store the
most common of those attributes that would be used in search
operations (such as a user’s first and last names, or login
name, for example). The partial attributes that it has for that
object would be enough to allow a search for that object to be able
to locate the full replica of the object in active directory. This
allows searches done against a local GC, and reduces network traffic
over the WAN in an attempt to locate objects somewhere else in the
network.
Domain
Controllers always contain the full attribute list for objects
belonging to their domain. If the Domain Controller is also a GC, it
will also contain a partial replica of objects from all other domains
in the forest.
Active
Directory uses DNS as the name resolution service to identify domains
and domain host computers during processes such as logging on to the
network.
Similar
to the way a Windows NT 4.0 client will query WINS for a NetBIOS
DOMAIN[1B] record to locate a PDC, or a NetBIOS DOMAIN[1C] record for
domain controllers, a Windows 2000, 2003, or Windows XP client can
query DNS to find a domain controller by looking for SRV records.
Integration
of DNS and Active Directory
The
integration of DNS and Active Directory is essential because a client
computer in a Windows 2000 network must be able to locate a domain
controller so that users can log on to a domain or use the services
that Active Directory provides. Clients locate domain controllers and
services by using A
resource
records and SRV
records. The A
resource record contains the FQDN and IP address for the domain
controller. The SRV
record contains the FQDN of the domain controller and the name of the
service that the domain controller provides.
What
Are Active Directory Integrated Zones?
One
benefit of integrating DNS and Active Directory is the ability to
integrate DNS zones into an Active Directory database. A zone is a
portion of the domain namespace that has a logical grouping of
resource records, which allows zone transfers of these records to
operate as one unit.
Active
Directory Integrated Zones
Microsoft
DNS servers store information that is used to resolve host names to
IP addresses and IP addresses to host names in a database file that
has the extension .dns
for each zone.
Active
Directory integrated zones are primary zones that are stored as
objects in the Active Directory database. If zone objects are stored
in an Active Directory domain partition, they are replicated to all
domain controllers in the domain.
What
Are DNS Zones?
A
zone starts as a storage database for a single DNS domain name. If
other domains are added below the domain used to create the zone,
these domains can either be part of the same zone or belong to
another zone. Once a subdomain is added, it can then either be:
Managed
and included as part of the original zone records, or
Delegated
away to another zone created to support the subdomain
Types
of Zones
1
There
are two types of zones, forward lookup and reverse lookup. Forward
lookup zones contain information needed to resolve names within the
DNS domain. They must include SOA and NS records and can include any
type of resource record except the PTR resource record. Reverse
lookup zones contain information needed to perform reverse lookups.
They usually include SOA, NS, PTR, and CNAME records.
With
most queries, the client supplies a name and requests the IP address
that corresponds to that name. This type of query is typically
described as a forward lookup. Active Directory requires forward
lookup zones.
However,
what if a client already has a computer's IP address and wants to
determine the DNS name for the computer? This is important for
programs that implement security based on the connecting FQDN, and is
used for TCP/IP network troubleshooting. The DNS standard provides
for this possibility through reverse lookups.
Once
you have installed Active Directory, you have two options for storing
your zones when operating the DNS server at the new domain
controller:
Standard
Zone
Zones
stored this way are located in .dns
text files that are stored in the %SystemRoot%\System32\Dns
folder
on each computer operating a DNS server. Zone file names correspond
to the name you choose for the zone when creating it, such as
Example.microsoft.com.dns
if the zone name was example.microsoft.com.
This
type offers the choice of using either a Standard Primary zone or a
Standard Secondary zone.
Standard
Primary Zone
For
standard primary-type zones, only a single DNS server can host and
load the master copy of the zone. If you create a zone and keep it as
a standard primary zone, no additional primary servers for the zone
are permitted. Only one server is allowed to accept dynamic updates,
also known as DDNS, and process zone changes. The standard primary
model implies a single point of failure.
Standard
Secondary Zone
A
secondary name server gets the data for its zones from another name
server (either a primary name server or another secondary name
server) for that zone across the network. The data in a Secondary
zone is Read only, and updated information must come from additional
zone transfers. The process of obtaining this zone information (i.e.,
the database file) across the network is referred to as a zone
transfer. Zone transfers occur over TCP port 53.
Secondary
servers can provide a means to offload DNS query traffic in areas of
the network where a zone is heavily queried and used. Additionally,
if a primary server is down, a secondary server can provide some name
resolution in the zone until the primary server is available.
Note A
Standard Primary zone will not replicate its information to any other
DNS servers, but may allow zone transfers to Secondary zones. Win2003
also supports stub zones. A secondary or stub zone cannot be hosted
on a DNS server that hosts a primary zone for the same domain name.
Directory-integrated
Zone
Zones
stored this way are located in the Active Directory tree under the
domain object container. Each directory-integrated zone is stored in
a dnsZone container object identified by the name you choose for the
zone when creating it. Active Directory integrated zones will
replicate this information to other domain controllers in that
domain.
Note If
DNS is running on a Windows 2000 server that is not a domain
controller, it will not be able to use an Active Directory integrated
zones, or replicate with other domain controllers since it does not
have Active Directory installed.
DNS
Records
After
you create a zone, additional resource records need to be added to
it. The most common resource records (RRs) to be added are:
Table
1. Record Types
Name | Description |
Host | For |
Alias | For |
Mail | For |
Pointer | For |
Service | For |
| Other |
Q1. What does the
logical component of the Active Directory structure include?
■ Objects:-Resources
are stored in the Active Directory as objects.
Sub
category: object class
An
object is really just a collection of attributes. A user object, for
example, is made up of attributes such as name, password, phone
number, group membership, and so on. The attributes that make up an
object are defined by an object
class. The user class, for
example, specifies the attributes that make up the user object.
The Active Directory
Schema:-
The classes and the
attributes that they define are collectively referred to as the
Active Directory Schema—in database terms, a schema is the
structure of the tables and fields and how they are related to one
another. You can think of the Active Directory Schema as a collection
of data (object classes) that defines how the real data of the
directory (the attributes of an object) is organized and stored
■ Domains
The basic organizational
structure of the Windows Server 2003 networking model is the domain.
A domain represents an administrative boundary. The computers, users,
and other objects within a domain share a common security database.
■ Trees
Multiple
domains are organized into a hierarchical structure called a tree.
Actually, even if you have only one domain in your organization, you
still have a tree. The first domain you create in a tree is called
the root domain. The next domain that you add becomes a child domain
of that root. This expandability of domains makes it possible to have
many domains in a tree. Figure 1-1 shows an example of a tree.
Microsoft.com was the first domain created in Active Directory in
this example and is therefore the root domain.
Microsoft.com
sales.microsoft.com
RND.Microsoft.com
West.Microsoft.com
East.Microsoft.com
Figure 1-1 A tree is a
hierarchical organization of multiple domains.
All
domains in a tree share a common schema and a contiguous namespace.
In the example shown in Figure 1-1, all of the domains in the tree
under the microsoft.com root domain share the namespace
microsoft.com. Using a single tree is fine if your organization is
confined within a single DNS namespace. However, for organizations
that use multiple DNS namespaces, your model must be able to expand
outside the boundaries of a single tree. This is where the forest
comes in.
■ Forest
A
forest is a group of one or more domain trees that do not form a
contiguous namespace but may share a common schema and global
catalog. There is always at least one forest on a network, and it is
created when the first Active Directory–enabled computer
(domain controller) on a network is installed.
This
first domain in a forest, called the forest root domain, is special
because it holds the schema and controls domain naming for the entire
forest. It cannot be removed from the forest without removing the
entire forest itself. Also, no other domain can ever be created above
the forest root domain in the forest domain hierarchy.
Figure
1-2 shows an example of a forest with two trees. Each tree in the
forest has its own namespace. In the figure, microsoft.com is one
tree and contoso.com is a second tree. Both are in a forest named
microsoft.com (after the first domain created)
Root
domain of microsoft.com forest & tree
Root
domain of Contoso.com forest
Microsoft.com
sales.microsoft.com
RND.Microsoft.com
West.Microsoft.com
East.Microsoft.com
Contoso.com
West.contoso.com
East.contoso.com
Figure 1-2 Trees in a
forest share the same schema, but not the same namespace.
A
forest is the outermost boundary of Active Directory; the directory
cannot be larger than the forest. However, you can create multiple
forests and then create trust relationships between specific domains
in those forests; this would let you grant access to resources and
accounts that are outside of a particular forest.
■Organizational
Units
Organizational
Units (OUs) provide a way to create administrative boundaries within
a domain. Primarily, this allows you to delegate administrative tasks
within the domain.
OUs serve as containers
into which the resources of a domain can be placed. You can then
assign administrative permissions on the OU itself. Typically, the
structure of OUs follows an organization’s business or
functional structure. For example, a relatively small organization
with a single domain might create separate OUs for departments within
the organization.
Q2. What does the
physical structure of active directory contain?
Physical structures
include domain controllers and sites.
Q3.What
is nesting?
The
creation of an OU inside another OU.
IMP: - once you go beyond
about 12 OUs deep in a nesting structure, you start running into
significant performance issues.
Q4.
What is trust relationship and how many types of trust relationship
is there in exchange 2003?
Since
domains represent security boundaries, special mechanisms called
trust relationships allow objects in one domain (called the trusted
domain) to access resources in another domain (called the trusting
domain).
Windows Server 2003
supports six types of trust relationships:
■ Parent
and child trusts
■ Tree-root
trusts
■ External
trusts
■ Shortcut
trusts
■ Realm
trusts
■ Forest
trusts
Q5.
What is a site?
A Windows Server 2003
site is a group of domain controllers that exist on one or more IP
subnets (see Lesson 3 for more on this) and are connected by a fast,
reliable network connection. Fast means connections of at least
1Mbps. In other words, a site usually follows the boundaries of a
local area network (LAN). If different LANs on the network are
connected by a wide area network (WAN), you’ll likely create
one site for each LAN.
Q6.
What is the use of site?
Sites are primarily used
to control replication traffic. Domain controllers within a site are
pretty much free to replicate changes to the Active Directory
database whenever changes are made. Domain controllers in different
sites compress the replication traffic and operate based on a defined
schedule, both of which are intended to cut down on network traffic.
More specifically, sites
are used to control the following:
■ Workstation
logon traffic
■ Replication
traffic
■ Distributed
File System (DFS)
Distributed
File System (DFS) is a server component that provides a unified
naming convention for folders and files stored on different servers
on a network. DFS lets you create a single logical hierarchy for
folders and files that is consistent on a network, regardless of
where on the network those items are actually stored. Files
represented in the DFS might be stored in multiple locations on the
network, so it makes sense that Active Directory should be able to
direct users to the closest physical location of the data they need.
To this end, DFS uses site information to direct a client to the
server that is hosting the requested data within the site. If DFS
does not find a copy of the data within the same site as the client,
DFS uses the site information in Active Directory to determine which
file server that has DFS shared data is closest to the client.
■ File
Replication Service (FRS)
Every
domain controller has a built-in collection of folders named SYSVOL
(for System Volume). The SYSVOL folders provide a default Active
Directory location for files that must be replicated throughout a
domain. You can use SYSVOL to replicate Group Policy Objects, startup
and shutdown scripts, and logon and logoff scripts. A Windows Server
2003 service named File Replication Service (FRS) is responsible for
replicating files in the SYSVOL folders between domain controllers.
FRS uses site boundaries to govern the replication of items in the
SYSVOL folders.
Q7.
What are the objects a site contains?
Sites contain only two
types of objects. The first type is the domain controllers contained
in the site. The second type of object is the site links configured
to connect the site to other sites.
Q8.What
is a Site link?
Within a site,
replication happens automatically. For replication to occur between
sites, you must establish a link between the sites. There are two
components to this link: the actual physical connection between the
sites (usually a WAN link) and a site link object. The site link
object is created within Active Directory and determines the protocol
used for transferring replication traffic (Internet Protocol [IP] or
Simple Mail Transfer Protocol [SMTP]). The site link object also
governs when replication is scheduled to occur.
Q9.
Explain Replication in Active directory?
Windows
Server 2003 uses a replication model called multimaster
replication, in which all
replicas of the Active Directory database are considered equal
masters. You can make changes to the database on any domain
controller and the changes will be replicated to other domain
controllers in the domain.
Domain controllers in the
same site replicate on the basis of notification. When changes are
made on a domain controller, it notifies its replication partners
(the other domain controllers in the site); the partners then request
the changes and replication occurs. Because of the high-speed,
low-cost connections assumed within a site, replication occurs as
needed rather than according to a schedule.
You should create
additional sites when you need to control how replication traffic
occurs over slower WAN links. For example, suppose you have a number
of domain controllers on your main LAN and a few domain controllers
on a LAN at a branch location. Those two LANs are connected to one
another with a slow (256K) WAN link. You would want replication
traffic to occur as needed between the domain controllers on each
LAN, but you would want to control traffic across the WAN link to
prevent it from affecting higher priority network traffic. To address
this situation, you would set up two sites— one site that
contained all the domain controllers on the main LAN and one site
that contained all the domain controllers on the remote LAN.
Q10.
What are the different types of replication?
Single
site (called intrasite replication)
Replication
between sites (called intersite replication).
■ Intrasite
Replication Intrasite
replication sends replication traffic in an uncompressed format. This
is because of the assumption that all domain controllers within the
site are connected by high-bandwidth links. Not only is the traffic
uncompressed, but replication occurs according to a change
notification mechanism. This means that if changes are made in the
domain, those changes are quickly replicated to the other domain
controllers.
■ Intersite
Replication Intersite
replication sends all data compressed. This shows an appreciation for
the fact that the traffic will probably be going across slower WAN
links (as opposed to the LAN connectivity intrasite replication
assumes), but it increases the server load because
compression/decompression is added to the processing requirements. In
addition to the compression, the replication can be scheduled for
times that are more appropriate to your organization. For example,
you may decide to allow replication only during slower times of the
day. Of course, this delay in replication (based on the schedule) can
cause inconsistency between servers in different sites.
Q11. What is LDAP?
LDAP, Lightweight
Directory Access Protocol, is an Internet protocol that email and
other programs use to look up information from a server.
An
LDAP-aware directory service (such as Active Directory) indexes all
the attributes of all the objects stored in the directory and
publishes them. LDAP-aware clients can query the server in a wide
variety of ways.
Q12.What
types of naming convention active directory uses?
Active Directory supports
several types of names for the different formats that can
accessActive Directory.
These names include:
■ Relative
Distinguished Names
The
relative distinguished name (RDN) of an object identifies an object
uniquely, but only within its parent container. Thus the name
uniquely identifies the object relative
to the other objects within
the same container. In the example
CN=wjglenn,CN=Users,DC=contoso,DC=com,
the relative
distinguished name of the object is CN=wjglenn. The relative
distinguished name of the parent organizational unit is Users. For
most objects, the relative distinguished name of an object is the
same as that object’s Common Name attribute. Active Directory
creates the relative distinguished name automatically, based on
information provided when the object is created. Active Directory
does not allow two objects with the same relative distinguished name
to exist in the same parent container.
The notations used in the
relative distinguished name (and in the distinguished name discussed
in the next section) use special notations called LDAP attribute tags
to identify each part of the name. The three attribute tags used
include:
■ DC
The Domain Component (DC)
tag identifies part of the DNS name of the domain, such as COM or
ORG.
■ OU
The Organizational Unit
(OU) tag identifies an organizational unit container.
■ CN
The Common Name (CN) tag
identifies the common name configured for an Active Directory object.
■ Distinguished
Names
Each
object in the directory has a distinguished name (DN) that is
globally unique and identifies not only the object itself, but also
where the object resides in the overall object hierarchy. You can
think of the distinguished name as the relative distinguished name of
an object concatenated with the relative distinguished names of all
parent containers that make up the path to the object.
An example of a typical
distinguished name would be:
CN=wjglenn,CN=Users,DC=contoso,DC=com.
This distinguished name
would indicate that the user object wjglenn is in the Users
container, which in turn is located in the contoso.com domain. If the
wjglenn object is moved to another container, its DN will change to
reflect its new position in the hierarchy. Distinguished names are
guaranteed to be unique in the forest, similar to the way that a
fully qualified domain name uniquely identifies an object’s
placement in a DNS hierarchy. You cannot have two objects with the
same distinguished name.
■ User
Principal Names
The
user principal name that is generated for each object is in the form
username@ domain_name. Users can log on with their user principal
name, and an administrator can define suffixes for user principal
names if desired. User principal names should be unique, but Active
Directory does not enforce this requirement. It’s best,
however, to formulate a naming convention that avoids duplicate user
principal names.
■ Canonical
Names
An
object’s canonical name is used in much the same way as the
distinguished name— it just uses a different syntax. The same
distinguished name presented in the preceding section would have the
canonical name:
contoso.com/Users/wjglenn.
As you can see, there are
two primary differences in the syntax of distinguished names and
canonical names. The first difference is that the canonical name
presents the root of the path first and works downward toward the
object name. The second difference is that the canonical name does
not use the LDAP attribute tags (e.g., CN and DC).
Q13. What is
multimaster replication?
Active Directory follows
the multimaster replication which every replica of the Active
Directory partition held on every domain is considered an equal
master. Updates can be made to objects on any domain controller, and
those updates are then replicated to other domain controllers.
Q14.Which two
operations master roles should be available when new security
principals are being created and named?
Domain naming master and
the relative ID master
Q15.
What are different types of groups?
■ Security
groups Security groups are
used to group domain users into a single administrative unit.
Security groups can be assigned permissions and can also be used as
e-mail distribution lists. Users placed into a group inherit the
permissions assigned to the group for as long as they remain members
of that group. Windows itself uses only security groups.
■ Distribution
groups These are used for
nonsecurity purposes by applications other than Windows. One of the
primary uses is within an e-mail
As with user accounts,
there are both local and domain-level groups. Local groups are stored
in a local computer’s security database and are intended to
control resource access on that computer. Domain groups are stored in
Active Directory and let you gather users and control resource access
in a domain and on domain controllers.
Q16. What is a group
scope and what are the different types of group scopes?
Group
scopes determine where in the Active Directory forest a group is
accessible and what objects can be placed into the group. Windows
Server 2003 includes three group scopes: global, domain local, and
universal.
■ Global
groups are used to gather
users that have similar permissions requirements. Global groups have
the following characteristics:
1.
Global groups can contain user
and computer accounts only from the domain in which the global group
is created.
2.
When the domain functional
level is set to Windows 2000 native or Windows Server 2003 (i.e., the
domain contains only Windows 2000 or 2003 servers), global groups can
also contain other global groups from the local domain.
3.
Global groups can be assigned
permissions or be added to local groups in any domain in a forest.
■ Domain
local groups exist on
domain controllers and are used to control access to resources
located on domain controllers in the local domain (for member servers
and workstations, you use local groups on those systems instead).
Domain local groups share the following characteristics:
1.
Domain local groups can contain
users and global groups from any domain in a forest no matter what
functional level is enabled.
2.
When the domain functional
level is set to Windows 2000 native or Windows Server 2003, domain
local groups can also contain other domain local groups and universal
groups.
■ Universal
groups are normally used to
assign permissions to related resources in multiple domains.
Universal groups share the following characteristics:
1.
Universal groups are available
only when the forest functional level is set to Windows 2000 native
or Windows Server 2003.
2. Universal groups exist
outside the boundaries of any particular domain and are managed by
Global Catalog servers.
3. Universal groups are
used to assign permissions to related resources in multiple domains.
4. Universal groups can
contain users, global groups, and other universal groups from any
domain in a forest.
5. You can grant
permissions for a universal group to any resource in any domain.
Q17. What are the
items that groups of different scopes can contain in mixed and native
mode domains?
Q18. What is group
nesting?
Placing of one group in
another is called as group nesting
For example, suppose you
had juniorlevel administrators in four different geographic
locations, as shown in Figure 4-10. You could create a separate group
for each location (named something like Dallas Junior
Admins). Then, you could
create a single group named Junior Admins and make each of the
location-based groups a member of the main group. This approach would
allow you to set permissions on a single group and have those
permissions flow down to the members, yet still be able to subdivide
the junior administrators by location.
Q19.
How many characters does a group name contain?
64
Q20. Is site part of
the Active Directory namespace?
NO:
- When a user browses the
logical namespace, computers and users are grouped into domains and
OUs without reference to sites. However, site names are used in the
Domain Name System (DNS) records, so sites must be given valid DNS
names.
Q21.
What is DFS?
The Distributed File
System is used to build a hierarchical view of multiple file servers
and shares on the network. Instead of having to think of a specific
machine name for each set of files, the user will only have to
remember one name; which will be the 'key' to a list of shares found
on multiple servers on the network. Think of it as the home of all
file shares with links that point to one or more servers that
actually host those shares.
DFS has the capability of
routing a client to the closest available file server by using Active
Directory site metrics. It can also be installed on a cluster for
even better performance and reliability.
Understanding
the DFS Terminology
It
is important to understand the new concepts that are part of DFS.
Below is an definition of each of them.
Dfs
root:
You
can think of this as a share that is visible on the network, and in
this share you can have additional files and folders.
Dfs
link:
A link is another share somewhere on the network that goes under the
root. When a user opens this link they will be redirected to a shared
folder.
Dfs
target (or replica):
This can be referred to as either a root or a link. If you have two
identical shares, normally stored on different servers, you can group
them together as Dfs Targets under the same link.
The image
below shows the actual folder structure of what the user sees when
using DFS and load balancing.
Figure
1:
The actual folder structure of DFS and load balancing
Windows 2003 offers a
revamped version of the Distributed File System found in Windows
2000, which has been improved to better performance and add
additional fault tolerance, load balancing and reduced use of network
bandwidth. It also comes with a powerful set of command-line
scripting tools which can be used to make administrative backup and
restoration tasks of the DFS namespaces easier. The client windows
operating system consists of a DFS client which provides additional
features as well as caching.
Q22. What are the
types of replication in DFS?
There are two types of
replication:
* Automatic - which is only available for Domain DFS
* Manual - which is available for stand alone, DFS and requires
all files to be replicated manually.
Q23. Which service is
responsible for replicating files in SYSVOL folder?
File Replication Service
(FRS)
Q24. What all can a
site topology owner do?
The
site topology owner is the name given to the administrator (or
administrators) that oversee the site
topology.
The owner is responsible for making any necessary changes to the site
as the physical network grows and changes. The site topology owner’s
responsibilities include:
■ Making
changes to the site topology based on changes to the physical network
topology.
■ Tracking
subnetting information for the network. This includes IP addresses,
subnet masks, and the locations of the subnets.
■ Monitoring
network connectivity and setting the costs for links between sites.
Q1.
What is DNS.
DNS
provides name registration and name to address resolution
capabilities. And DNS drastically lowers the need to remember numeric
IP addresses when accessing hosts on the Internet or any other
TCP/IP-based network.
Before
DNS, the practice of mapping friendly host or computer names to IP
addresses was handled via host files. Host files are easy to
understand. These are static ASCII text files that simply map a host
name to an IP address in a table-like format. Windows ships with a
HOSTS file in the \winnt\system32\drivers\etc subdirectory
The
fundamental problem with the host files was that these files were
labor intensive. A host file is manually modified, and it is
typically centrally administrated.
The
DNS system consists of three components: DNS data (called resource
records),
servers (called name
servers),
and Internet protocols for fetching data from the servers.
Q2.
Which are the four
generally accepted naming conventions?
NetBIOS
Name
(for instance, SPRINGERS01)
TCP/IP
Address
(121.133.2.44)
Host
Name
(Abbey)
Media
Access Control (MAC)—this
is the network adapter hardware address
Q3.
How
DNS really works
DNS
uses a client/server model in which the DNS server maintains a static
database of domain names mapped to IP addresses. The DNS client,
known as the resolver, perform queries against the DNS servers. The
bottom line? DNS resolves domain names to IP address using these
steps
Step
1. A client (or “resolver”) passes its request to its
local name server. For example, the URL term www.idgbooks.com typed
into Internet Explorer is passed to the DNS server identified in the
client TCP/IP configuration. This DNS server is known as the local
name server.
Step
2. If, as often happens, the local name server is unable to resolve
the request, other name servers are queried so that the resolver may
be satisfied.
Step
3. If all else fails, the request is passed to more and more,
higher-level name servers until the query resolution process starts
with far-right term (for instance, com) or at the top of the DNS tree
with root name servers
Below
is the Steps explained with the help of a chart.
Figure
8-5: How DNS works
Q4.
Which are the major records in DNS?
1.
Host or Address Records (A):-
map the name of a machine to its numeric IP address. In clearer
terms, this record states the hostname and IP address of a certain
machine. Have three fields: Host Name, Domain, Host IP Address.
E.g.:-
eric.foobarbaz.com.
IN A 36.36.1.6
It
is possible to map more than one IP address to a given hostname. This
often happens for people who run a firewall and have two
cards in one machine. All you must do is add a second A record, with
every column the same save for the IP address.
2.
Aliases or Canonical
Name Records (CNAME)
“CNAME”
records simply allow a machine to be known by more than one hostname.
There must always be an A record for the machine before aliases can
be added. The host name of a machine that is stated in an A record is
called the canonical, or official name of the machine. Other records
should point to the canonical name. Here is an example of a CNAME:
www.foobarbaz.com.
IN CNAME eric.foobarbaz.com.
You
can see the similarities to the previous record. Records always read
from left to right, with the subject to be queried about on the left
and the answer to the query on the right. A machine can have an
unlimited number of CNAME aliases. A new record must be entered for
each alias.
You
can add A or CNAME records for the service name pointing to the
machines you want to load
balance.
3.
Mail Exchange Records (MX)
MX”
records are far more important than they sound. They allow all mail
for a domain to be routed to one host. This is exceedingly useful –
it abates the load on your internal hosts since they do not have to
route incoming mail, and it allows your mail to be sent to any
address in your domain even if that particular address does not have
a computer associated with it. For example, we have a mail server
running on the fictitious machine eric.foobarbaz.com. For convenience
sake, however, we want our email address to be “user@foobarbaz.com”
rather than “user@eric.foobarbaz.com”. This is
accomplished by the record shown below:
foobarbaz.com.
IN MX 10 eric.foobarbaz.com.
The
column on the far left signifies the address that you want to use as
an Internet email address. The next two entries have been explained
thoroughly in previous records. The next column, the number “10”,
is different from the normal DNS record format. It is a signifier of
priority. Often larger systems will have backup mail servers, perhaps
more than one. Obviously, you will only want the backups receiving
mail if something goes wrong with the primary mail server. You can
indicate this with your MX records. A lower number in an MX record
means a higher priority, and mail will be sent to the server with the
lowest number (the lowest possible being 0). If something happens so
that this server becomes unreachable, the computer delivering the
mail will attempt every other server listed in the DNS tables, in
order of priority.
Obviously,
you can have as many MX records as you would like. It is also a good
idea to include an MX record even if you are having mail sent
directly to a machine with an A record. Some sendmail programs only
look for MX records.
It
is also possible to include wildcards in MX records. If you have a
domain where your users each have their own machine running mail
clients on them, mail could be sent directly to each machine. Rather
than clutter your DNS entry, you can add an MX record like this one:
*.foobarbaz.com.
IN MX 10 eric.foobarbaz.com.
This
would make any mail set to any individual workstation in the
foobarbaz.com domain go through the server eric.foobarbaz.com.
One
should use caution with wildcards; specific records will be given
precedence over ones containing wildcards.
4.
Pointer Records (PTR)
Although
there are different ways to set up PTR records, we will be explaining
only the most frequently used method, called “in-addr.arpa”.
In-addr.arpa
PTR records are the exact inverse of A records. They allow your
machine to be recognized by its IP address. Resolving a machine in
this fashion is called a “reverse lookup”. It is becoming
more and more common that a machine will do a reverse lookup on your
machine before allowing you to access a service (such as a World Wide
Web page). Reverse lookups are a good security measure, verifying
that your machine is exactly who it claims to be. In-addr.arpa
records look as such:
6.1.36.36.in-addr.arpa.
IN PTR eric.foobarbaz.com.
As
you can see from the example for the A record in the beginning of
this document, the record simply has the IP address in reverse for
the host name in the last column.
A
note for those who run their own name servers: although Allegiance
Internet is capable of pulling zones from your name server, we cannot
pull the inverse zones (these in-addr.arpa records) unless you have
been assigned a full class C network. If you would like us to put PTR
records in our name servers for you, you will have to fill out the
online web form on the support.allegianceinternet.com page.
5.
Name Server Records (NS)
NS
records are imperative to functioning DNS entries. They are very
simple; they merely state the authoritative name servers for the
given domain. There must be at least two NS records in every DNS
entry. NS records look like this:
foobarbaz.com.
IN NS draven.foobarbaz.com.
There
also must be an A record in your DNS for each machine you enter as A
NAME server in your domain.
If
Allegiance Internet is doing primary and secondary names service, we
will set up these records for you automatically, with “nse.algx.net”
and “nsf.algx.net” as your two authoritative name
servers.
6.
Start Of Authority Records (SOA)
The
“SOA” record is the most crucial record in a DNS entry.
It conveys more information than all the other records combined. This
record is called the start of authority because it denotes the DNS
entry as the official source of information for its domain. Here is
an example of a SOA record, then each part of it will be explained:
foobarbaz.com.
IN SOA draven.foobarbaz.com. hostmaster.foobarbaz.com. (
1996111901
; Serial
10800
; Refresh
; Retry
3600000
; Expire
86400
) ; Minimum
The
first column contains the domain for which this record begins
authority for. The next two entries should look familiar. The
“draven.foobarbaz.com” entry is the primary name server
for the domain. The last entry on this row is actually an email
address, if you substituted a “@” for the first “.”.
There should always be a viable contact address in the SOA record.
The
next entries are a little more unusual then what we have become used
to. The serial number is a record of how often this DNS entry has
been updated. Every time a change is made to the entry, the serial
number must be incremented. Other name servers that pull information
for a zone from the primary only pull the zone if the serial number
on the primary name server’s entry is higher than the serial
number on it’s entry. In this way the name servers for a domain
are able to update themselves. A recommended way of using your serial
number is the YYYYMMDDNN format shown above, where the NN is the
number of times that day the DNS has been changed.
Also,
a note for Allegiance Internet customers who run their own name
servers: even if the serial number is incremented, you should still
fill out the web form and use the comment box when you make changes
asking us to pull the new zones.
All
the rest of the numbers in the record are measurements of time, in
seconds. The “refresh” number stands for how often
secondary name servers should check the primary for a change in the
serial number. “Retry” is how long a secondary server
should wait before trying to reconnect to primary server if the
connection was refused. “Expire” is how long the
secondary server should use its current entry if it is unable to
perform a refresh, and “minimum” is how long other name
servers should cache, or save, this entry.
There
can only be one SOA record per domain. Like NS records, Allegiance
Internet sets up this record for you if you are not running your own
name server.
Quick
Summary of the major records in DNS
|
|
|
|
|
|
|
|
|
|
|
|
Q5.What
is a DNS zone
A
zone is simply a contiguous section of the DNS namespace.
Records for a zone are stored and managed together. Often,
subdomains are split into several zones to make manageability
easier. For example, support.microsoft.com
and
msdn.microsoft.com
are
separate zones, where support
and
msdn are
subdomains within the Microsoft.com domain.
Q6.
Name the two Zones in DNS?
DNS
servers can contain primary
and secondary
zones. A primary zone is a copy of a zone where updates can be
made, while a secondary zone is a copy of a primary zone. For
fault tolerance purposes and load balancing, a domain may have
several DNS servers that respond to requests for the same
information.
The
entries within a zone give the DNS server the information it needs to
satisfy requests from other computers or DNS servers.
Q7.
How many SOA record does each zone contain?
Each
zone will have one SOA record. This records contains many
miscellaneous settings for the zone, such as who is responsible for
the zone, refresh interval settings, TTL (Time To Live) settings, and
a serial number (incremented with every update).
Q8.
Short summary of the records in DNS.
The
NS records are used to point to additional DNS servers. The PTR
record is used for reverse lookups (IP to name). CNAME records
are used to give a host multiple names. MX records are used
when configuring a domain for email.
Q9. What is an
AD-integrated zone?
AD-integrated zones store
the zone data in Active Directory and use the same replication
process used to replicate other data between domain controllers. The
one catch with AD-integrated zones is that the DNS server must also
be a domain controller. Overloading DNS server responsibilities on
your domain controllers may not be something you want to do if you
plan on supporting a large volume of DNS requests.
Q10.What is a STUB
zone?
A stub zone is a copy of
a zone that contains only those resource records necessary to
identify the authoritative Domain Name System (DNS) servers for that
zone. A stub zone is used to resolve names between separate DNS
namespaces. This type of resolution may be necessary when a corporate
merger requires that the DNS servers for two separate DNS namespaces
resolve names for clients in both namespaces.
The master servers for a
stub zone are one or more DNS servers authoritative for the child
zone, usually the DNS server hosting the primary zone for the
delegated domain name.
Q11. What does a stub
zone consists of?
A stub zone consists of:
|
|
|
|
Q12. How the
resolution in a stub zone takes place?
When a DNS client
performs a recursive query operation on a DNS server hosting a stub
zone, the DNS server uses the resource records in the stub zone to
resolve the query. The DNS server sends an iterative query to the
authoritative DNS servers specified in the NS resource records of the
stub zone as if it were using NS resource records in its cache. If
the DNS server cannot find the authoritative DNS servers in its stub
zone, the DNS server hosting the stub zone attempts standard
recursion using its root hints.
The DNS server will store
the resource records it receives from the authoritative DNS servers
listed in a stub zone in its cache, but it will not store these
resource records in the stub zone itself; only the SOA, NS, and glue
A resource records returned in response to the query are stored in
the stub zone. The resource records stored in the cache are cached
according to the Time-to-Live (TTL) value in each resource record.
The SOA, NS, and glue A resource records, which are not written to
cache, expire according to the expire interval specified in the stub
zone's SOA record, which is created during the creation of the stub
zone and updated during transfers to the stub zone from the original,
primary zone.
If the query was an
iterative query, the DNS server returns a referral containing the
servers specified in the stub zone.
Q
13.What is the benefits
of Active Directory Integration?
For networks deploying
DNS to support Active Directory, directory-integrated primary zones
are strongly recommended and provide the following benefits:
* Multimaster update
and enhanced security based on the capabilities of Active Directory
In a standard zone
storage model, DNS updates are conducted based upon a single-master
update model. In this model, a single authoritative DNS server for a
zone is designated as the primary source for the zone.
This server maintains the
master copy of the zone in a local file. With this model, the primary
server for the zone represents a single fixed point of failure. If
this server is not available, update requests from DNS clients are
not processed for the zone.
With directory-integrated
storage, dynamic updates to DNS are conducted based upon a
multimaster update model.
In this model, any
authoritative DNS server, such as a domain controller running a DNS
server, is designated as a primary source for the zone. Because the
master copy of the zone is maintained in the Active Directory
database, which is fully replicated to all domain controllers, the
zone can be updated by the DNS servers operating at any domain
controller for the domain.
With the multimaster
update model of Active Directory, any of the primary servers for the
directory-integrated zone can process requests from DNS clients to
update the zone as long as a domain controller is available and
reachable on the network.
Also, when using
directory-integrated zones, you can use access control list (ACL)
editing to secure a dnsZone object container in the directory tree.
This feature provides granulated access to either the zone or a
specified RR in the zone.
For example, an ACL for a
zone RR can be restricted so that dynamic updates are only allowed
for a specified client computer or a secure group such as a domain
administrators group. This security feature is not available with
standard primary zones.
Note that when you change
the zone type to be directory-integrated, the default for updating
the zone changes to allow only secure updates. Also, while you may
use ACLs on DNS-related Active Directory objects, ACLs may only be
applied to the DNS client service.
* Directory
replication is faster and more efficient than standard DNS
replication.
Because Active Directory
replication processing is performed on a per-property basis, only
relevant changes are propagated. This allows less data to be used and
submitted in updates for directory-stored zones.
Note:
Only primary zones can
be stored in the directory. A DNS server cannot store secondary zones
in the directory. It must store them in standard text files. The
multimaster replication model of Active Directory removes the need
for secondary zones when all zones are stored in Active Directory.
Q14. What is
Scavenging?
DNS scavenging is the
process whereby resource records are automatically removed if they
are not updated after a period of time. Typically, this applies to
only resource records that were added via DDNS, but you can also
scavenge manually added, also referred to as static, records. DNS
scavenging is a recommended practice so that your DNS zones are
automatically kept clean of stale resource records.
Q15. What is the
default interval when DNS server will kick off the scavenging
process?
The default value is 168
hours, which is equivalent to 7 days.
DNS Q&A corner
Q1.
How do I use a load
balancer with my name servers?
Just wanted to ask a
question about load balanced DNS servers
> via an external
network load balancing appliance (i.e - F5's Big IP,
> Cisco's
Content Switches/ Local Directors).
> The main question being
the configuration whether to use 2
> Master/Primary Servers or
is it wiser to use 1 Primary and 1
> Secondary? The reason is
that I feel there are two configurations
> that could be
setup. One in which only the resolvers query the
> virtual IP
address on the load balancing appliance or actually
>
configure your NS records to point to the Virtual Address so that
all
> queries, ie - both by local queries directly from local
users and
> also queries from external DNS servers. I've
included a text
> representation of the physical
configuration. Have you ever
> heard or architected such a
configuration?
> VIP
= 167.147.1.5
> ------------------------------------
>>
Load Balancer Device |
>
------------------------------------
>
|
>
|
> -----------------
>
| |
>
---------------- --------------
>>
DNS 1 |
| DNS 2 |
> ----------------
--------------
> 1.1.1.1
1.1.1.2
There's usually not much
need to design solutions like these, since most
name server
implementations will automatically choose the name server
that
responds most quickly. In other words, if DNS 1 fails, remote
name
servers will automatically try DNS 2, and vice versa.
However, it can be useful
for resolvers. In that case, you don't need to
worry about NS
records (since resolvers don't use them), just setting up
a
virtual IP address.
> Also, Is there any
problems in running two Master/Primaries?
Just that you'd have to
synchronize the zone data between the two
manually.
Q2.
How does reverse mapping
work?
How can reverse lookup
possibly work on the Internet - how can a local
> resolver or
ISP's Dns server find the pointer records please? E.g. I run
>
nslookup 161.114.1.206 & get a reply for a Compaq server
>
- how does it know where to look? Is there a giant reverse lookup
zone in
> the sky?
Yes, actually, there is:
in-addr.arpa.
If a resolver needs to reverse map, say,
161.114.1.206 to a domain name, it first inverts the octets of the
IP address and appends "in-addr.arpa." So, in this case,
the IP address would become the domain name
206.1.114.161.in-addr.arpa.
Then the resolver sends a query
for PTR records attached to that domain name. If necessary, the
resolution process starts at the root name servers. The root name
servers refer the querier to the 161.in-addr.arpa name servers, run
by an organization called ARIN, the American Registry for Internet
Numbers. These name servers refer the querier to
1.114.161.in-addr.arpa name servers, run by Compaq. And, finally,
these name servers map the IP address to inmail.compaq.com.
Q3.
What are the pros and
cons of running slaves versus caching-only name servers?
> Question: I am in
the process of setting up dns servers in several locations for my
>
business. I have looked into having a primary master server running
in my server
> room and adding slave servers in the other
areas. I then thought I could just
> setup a primary and a
single slave server and run caching only servers in the other
>
areas. What are the pros and cons of these two options, or should I
run a slave
> server in every location and still have a
caching server with it? I just don't
> know what the best way
would be. Please help.
The main advantage of
having slaves everywhere is that you have a
source of your own
zone data on each name server. So if you have
a community of hosts
near each slave that look up domain names in
your zones, the local
name server can answer most of their queries.
On the other hand,
administering slaves is a little more work than
administering
caching-only name servers, and a little greater burden
on the
primary master name server.
Q4.
Can I set a TTL on a
specific record?
> Is it possible to
setup ttl values for individual records in bind?
Sure. You specify
explicit TTLs in a record's TTL field, between the owner
field and
the class field:
foo.example. 300 IN A
10.0.0.1
Q5.
Can I use an A record instead of an MX record?
> I have a single
machine running DNS mail and web for a domain
> and I'm not
sure that I have DNS setup properly. If the machine
> that is
running the mail is the name of the domain does there need
> to
be an MX record for mail?
Technically, no. Nearly
all mailers will look up A records for a
domain name in a mail
destination if no MX records exist.
> If an MX record is
not needed, how would you put in an MX
> record for a backup
mailserver.
You can't. If you want to
use a backup mailer, you need to use
MX records.
> www cname
192.168.0.1
> mail cname 192.168.0.1
> pop cname
192.168.0.1
> smtp cname 192.168.0.1
These CNAME records are
all incorrect. CNAME records create
an alias from one domain name
to another, so the field after "CNAME"
must contain a
domain name, not an IP address. For example:
www CNAME
foo.example.
Q6.
What are a zone's NS
records used for?
> Could you elaborate
a little bit on why do we need to put NS records for
> the zone
we are authoritative for ?
> The parent name server handles
these already. Is there any problem if our
> own NS records
have lower TTLs than the records from parent name server ?
That's a good question.
The NS records from your zone data file are used for several things:
- Your name servers
returns them in responses to queries, in the authority section of the
DNS message. Moreover, the set of NS records that comes directly from
your name server supersedes the set that a querier gets from your
parent zone's name servers, so if the two sets are different, yours
"wins."
- Your name servers use
the NS records to determine where to send NOTIFY messages.
- Dynamic updaters
determine where to send updates using the NS records, which they
often get from the authoritative name servers.
Q7.
Do slaves only communicate with their masters over TCP?
> When the slave zone
checks in with the master zone for the serial number, is
> all
this traffic happening on TCP. For example, if you have acl's
blocking
> udp traffic but allowing tcp traffic will the
transfer work or will it fail
> due to the slaves inability to
query for the SOA record on udp?
No. The refresh query
(for the zone's SOA record) is usually done over UDP.
Q8.
What's the largest number I can use in an MX record?
> Could you tell us
the highest possible number we can use for the MX
> preference
?
Preference is an unsigned, 16-bit number, so the largest
number you
can use is 65535.
Q9.
Why are there only 13 root name servers?
> I'm very wondering
why there are only 13 root servers on globally.
> Some
documents explain that one of the reason is technical limit on Domain
> Name System (without any detailed explanation).
> From
my understanding, it seems that some limitation of NS record
numbers
> in DNS packet that specified by certain RFCs, or just
Internet policy stuff.
>
> Which one is proper reason?
It's a technical
limitation. UDP-based DNS messages can be up to 512 bytes
long,
and only 13 NS records and their corresponding A records will fit
into a DNS message that size.
IMP information
http://www.menandmice.com/online_docs_and_faq/glossary/glossarytoc.htm
Q1.Which
is the FIVE FSMO roles?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q2.
What are their functions?
|
|
|
|
|
|
|
|
|
|
|
Q3.
What
if a FSMO server fails? 
|
|
|
|
|
|
|
|
|
|
Q4.
Where are these FSMO server roles found?
The
first domain controller that is installed in a Windows 2000 domain,
by default, holds all five of the FSMO server roles. Then, as more
domain controllers are added to the domain, the FSMO roles can be
moved to other domain controllers.
Q5.
Can you Move FSMO roles?
Yes,
moving a FSMO server role is a manual process, it does not happen
automatically. But what if you only have one domain controller
in your domain? That is fine. If you have only one domain
controller in your organization then you have one forest, one domain,
and of course the one domain controller. All 5 FSMO server
roles will exist on that DC. There is no rule that says you
have to have one server for each FSMO server role.
Q6.
Where to place the FSMO roles?
Assuming you do have
multiple domain controllers in your domain, there are some best
practices to follow for placing FSMO server roles.
The
Schema Master and Domain Naming Master should reside on the same
server, and that machine should be a Global Catalog server.
Since all three are, by
default, on the first domain controller installed in a forest, then
you can leave them as they are.
Note:
According to MS, the Domain Naming master needs to be on a Global
Catalog Server. If you are going to separate the Domain Naming
master and Schema master, just make sure they are both on Global
Catalog servers.
IMP:-
Why Infrastructure Master should not be on the same server that acts
as a Global Catalog server?The
Infrastructure Master should not be on the same server that acts as a
Global Catalog server.
The reason for this is the Global Catalog
contains information about every object in the forest. When the
Infrastructure Master, which is responsible for updating Active
Directory information about cross domain object changes, needs
information about objects not in it's domain, it contacts the Global
Catalog server for this information. If they both reside on the
same server, then the Infrastructure Master will never think there
are changes to objects that reside in other domains because the
Global Catalog will keep it constantly updated. This would
result in the Infrastructure Master never replicating changes to
other domain controllers in its domain.
Note:
In a single domain environment this is not an issue.Microsoft
also recommends that the PDC Emulator and RID Master be on the same
server. This is not mandatory like the Infrastructure Master
and the Global Catalog server above, but is recommended. Also, since
the PDC Emulator will receive more traffic than any other FSMO role
holder, it should be on a server that can handle the load.It
is also recommended that all FSMO role holders be direct replication
partners and they have high bandwidth connections to one another as
well as a Global Catalog server.
Q7.What permissions
you should have in order to transfer a FSMO role?
Before you can transfer a
role, you must have the appropriate permissions depending on which
role you plan to transfer:
|
|
|
|
|
|
|
|
|
|
FSMO
TOOLS
Q8.
Tools to find out what servers in your domain/forest hold what server
roles?
1.
Active Directory Users
and Computers:- use this
snap-in to find out where the domain level FSMO roles are located
(PDC Emulator, RID Master, Infrastructure Master), and also to change
the location of one or more of these 3 FSMO roles.
Open Active
Directory Users and Computers, right click on the domain you want to
view the FSMO roles for and click "Operations Masters". A
dialog box (below) will open with three tabs, one for each FSMO role.
Click each tab to see what server that role resides on. To
change
the server roles, you must first connect to the domain controller you
want to move it to. Do this by right clicking "Active
Directory Users and Computers" at the top of the Active
Directory Users and Computers snap-in and choose "Connect to
Domain Controller". Once connected to the DC, go back into
the Operations Masters dialog box, choose a role to move and click
the Change button.
When you do connect to another DC, you will
notice the name of that DC will be in the field below the Change
button (not in this graphic).
2.
Active
Directory Domains and Trusts
- use this snap-in to find out where the Domain Naming Master FSMO
role is and to change it's location.
The process is the same
as it is when viewing and changing the Domain level FSMO roles in
Active Directory Users and Computers, except you use the Active
Directory Domains and Trusts snap-in. Open Active Directory Domains
and Trusts, right click "Active Directory Domains and Trusts"
at the top of the tree, and choose "Operations Master".
When you do, you will see the dialog box below. Changing
the server that houses the Domain Naming Master requires that you
first connect to the new domain controller, then click the Change
button. You can connect to another domain controller by right
clicking "Active Directory Domains and Trusts" at the top
of the Active Directory Domains and Trusts snap-in and choosing
"Connect to Domain Controller".
3.
Active
Directory Schema
- this snap-in is used to view and change the Schema Master FSMO
role. However... the Active Directory Schema snap-in is not part of
the default Windows 2000 administrative tools or installation. You
first have to install the Support Tools from the \Support directory
on the Windows 2000 server CD or install the Windows 2000 Server
Resource Kit. Once you install the support tools you can open
up a blank Microsoft Management Console (start, run, mmc) and add the
snap-in to the console. Once the snap-in is open, right click
"Active Directory Schema" at the top of the tree and choose
"Operations Masters". You will see the dialog box
below. Changing
the server the Schema Master resides on requires you first connect to
another domain controller, and then click the Change button.
You
can connect to another domain controller by right clicking "Active
Directory Schema" at the top of the Active Directory Schema
snap-in and choosing "Connect to Domain Controller
4.Netdom
The
easiest and fastest way to find out what server holds what FSMO role
is by using the Netdom
command line utility. Like the Active Directory Schema snap-in,
the Netdom utility is only available if you have installed the
Support Tools from the Windows 2000 CD or the Win2K Server Resource
Kit.
To use Netdom to view the FSMO role holders, open a
command prompt window and type:
netdom query fsmo and press enter.
You will see a list of the FSMO role servers:
5.
Active
Directory Relication Monitor another
tool that comes with the Support Tools is the Active
Directory Relication Monitor.
Open this utility from Start, Programs, Windows 2000 Support
Tools. Once open, click Edit, Add Monitored Server and add the
name of a Domain Controller. Once added, right click the Server
name and choose properties. Click the FSMO Roles tab to view
the servers holding the 5 FSMO roles (below). You cannot change roles
using Replication Monitor, but this tool has many other useful
purposes in regard to Active Directory information. It is
something you should check out if you haven't already.
Finally,
you can use the Ntdsutil.exe
utility
to gather information about and change servers for FSMO roles.
Ntdsutil.exe, a command line utility that is installed with
Windows 2000 server, is rather complicated and beyond the scope of
this document.
6.
DUMPFSMOS
Command-line
tool to query for the current FSMO role holders
Part
of the Microsoft Windows 2000 Server Resource Kit
Downloadable
from http://www.microsoft.com/windows2000
/techinfo/reskit/default.asp
Prints
to the screen, the current FSMO holders
Calls
NTDSUTIL to get this information
7.
NLTEST
Command-line
tool to perform common network administrative tasks
Type
“nltest /?” for syntax and switches
Common
uses
Get a
list of all DCs in the domain
Get
the name of the PDC emulator
Query
or reset the secure channel for a server
Call
DsGetDCName to query for an available domain controller
8.
Adcheck (470k) (3rd
party)
A
simple utility to view information about AD and FSMO roles
http://www.svrops.com/svrops/downloads/zipfiles/ADcheck.msi
Q9.
How to Transfer and Seize a FSMO Role
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q255504
GROUP POLICY
Q1.
What are Group Policies?
Group Policies are
settings that can be applied to Windows computers, users or both. In
Windows 2000 there are hundreds of Group Policy settings. Group
Policies are usually used to lock down some aspect of a PC. Whether
you don't want users to run Windows Update or change their Display
Settings, or you want to insure certain applications are installed on
computers - all this can be done with Group Policies.
Group
Policies can be configured either Locally
or by Domain Polices.
Local policies can be accessed by clicking Start, Run and typing
gpedit.msc. They can also be accessed by opening the Microsoft
Management Console (Start, Run type mmc), and adding the Group Policy
snap-in. You must be an Administrator to configure/modify Group
Policies. Windows 2000 Group Policies can only be used on
Windows 2000 computers or Windows XP computers. They cannot be
used on Win9x or WinNT computers.
Q2. Domain policy gets
applied to whom ?
Domain
Policies are applied to computers and users who are members of a
Domain, and these policies are configured on Domain
Controllers. You can
access Domain Group Polices by opening Active Directory Sites and
Services (these policies apply to the Site level only) or Active
Directory Users and Computers (these policies apply to the Domain
and/or Organizational Units).
Q3.
From Where to create a Group Policy?
To
create a Domain Group Policy Object open Active Directory Sites and
Services and right click Default-First-Site-Name or another Site
name, choose properties, then the Group Policy tab, then click the
New button.
Give the the GPO a name, then click the
Edit button to configure
the policies.
For Active Directory Users and Computers, it the
same process except you right click the Domain or an OU and choose
properties.
Q4.
Who can Create/Modify
Group Policies?
You have to have
Administrative privileges to create/modify group policies. The
following table shows who can create/modify group policies:
|
|
|
|
|
|
|
|
|
|
Q5.
How are Group Policies
Applied?
Group
Polices can be configured locally, at the Site level, the Domain
level or at the Organizational Unit (OU) level. Group Policies are
applied in a Specific Order, LSDO - Local
policies first, then Site
based policies, then Domain
level policies, then OU
polices, then nested OU
polices (OUs within OUs). Group polices cannot be linked to a
specific user or group, only container objects.
In order to
apply Group Polices to specific users or computers, you add users (or
groups) and computers to container objects. Anything in the container
object will then get the policies linked to that container. Sites,
Domains and OUs are considered container objects.
Computer and
User Active Directory objects do
not have to put in the same
container object. For example, Sally the user is an object in Active
Directory. Sally's Windows 2000 Pro PC is also an object in Active
Directory. Sally the user object can be in one OU, while her computer
object can be another OU. It all depends on how you organize your
Active Directory structure and what Group Policies you want applied
to what objects.
User
and Computer Policies
There
are two nodes in each Group Policy Object that is created. A
Computer
node and a User
Node. They are called Computer
Configuration and User
Configuration (see image
above). The polices configured in the Computer node apply to the
computer as a whole. Whoever logs onto that computer will see those
policies.
Note:
Computer policies are also referred to as machine policies.
User
policies are user specific. They only apply to the user that is
logged on. When creating Domain Group Polices you can disable
either the Computer node or User node of the Group Policy Object you
are creating. By disabling a node that no policies are defined
for, you are decreasing the time it takes to apply the polices.
To
disable the node polices:
After creating a Group Policy Object, click that Group Policy Object
on the Group Policy tab, then click the Properties button. You
will see two check boxes at the bottom of the General tab.
It's
important to understand that when Group Policies are being applied,
all the policies
for a node are evaluated first, and then applied. They are not
applied one after the other. For example, say Sally the user is a
member of the Development OU, and the Security OU. When Sally
logs onto her PC the policies set in the User node of the both the
Development OU and the Security OU Group Policy Objects are
evaluated, as a whole, and then applied to Sally the user. They
are not applied Development OU first, and then Security OU (or visa-
versa).
The same goes for Computer policies. When a computer
boots up, all the Computer node polices for that computer are
evaluated, then applied.
When computers boot
up, the Computer policies
are applied. When users login,
the User policies are applied. When user and computer group
policies overlap, the computer
policy wins.
Note:
IPSec and EFS policies are not additive. The last policy
applied is the policy the user/computer will have.
When
applying multiple Group Policies Objects from any container, Group
Policies are applied from bottom to top in the Group Policy Object
list. The top Group Policy in the list is the last to be applied. In
the above image you can see three Group Policy Objects associated
with the Human Resources OU. These polices would be applied No
Windows Update first, then No Display Settings, then No ScreenSaver.
If there were any conflicts in the policy settings, the one
above it would take precedence.
Q6.How
to disable Group Policy Objects
When
you are creating a Group Policy Object, the changes happen
immediately. There is no "saving" of GPOs. To
prevent a partial GPO from being applied, disable
the GPO while you are
configuring it. To do this, click the Group Policy Object on the
Group Policy tab and under the Disable column, double click - a
little check will appear. Click the Edit button, make your
changes, then double click under the Disable column to re-enable the
GPO. Also, if you want to temporarily disable a GPO for
troubleshooting reasons, this is the place to do it. You can
also click the Options button on the Group Policy tab and select the
Disabled check box.
Q7.
When does the group policy Scripts run?
Startup
scripts are processed at computer bootup and before the user logs
in.
Shutdown
scripts are processed after a user logs off, but before the computer
shuts down.
Login
scripts are processed when the user logs in.
Logoff
scripts are processed when the user logs off, but before the shutdown
script runs.
Q8.
When the group policy gets refreshed/applied?
Group
Policies can be applied when a computer boots up, and/or when a user
logs in. However, policies are also refreshed automatically according
to a predefined schedule. This is called Background
Refresh.
Background
refresh for non DCs
(PCs and Member Servers) is every 90 mins., with a +/- 30
min.
interval. So the refresh could be 60, 90 or 120 mins.
For DCs
(Domain Controllers), background refresh is every
5 mins.
Also, every 16
hours every PC will request
all group policies to be reapplied (user and machine) These settings
can be changed under Computer and User Nodes, Administrative
Templates,System, Group Policy.
Q9. Which are the
policies which does not get affected by background refresh?
Policies
not affected by background refresh. These policies are only applied
at logon time:
Folder Redirection
Software Installation
Logon, Logoff,
Startup, Shutdown Scripts
Q9.
How to refresh Group Policies suing the command line?
Secedit.exe
is a command line tool that can be used to refresh group policies on
a Windows 2000 computer. To use secedit, open a command prompt
and type:
secedit
/refreshpolicy user_policy
to refresh the user policies
secedit
/refreshpolicy machine_policy
to refresh the machine (or computer) policies
These
parameters will only refresh any user or computer policies that have
changed since the last refresh. To force a reload of all group
policies regardless of the last change, use:
secedit
/refreshpolicy user_policy /enforce
secedit
/refreshpolicy machine_policy /enforce
Gpupdate.exe
is a command line tool that can be used to refresh group policies on
a Windows XP computer. It has replaced the secedit command. To
use gpupdate, open a command prompt and
type:
gpupdate
/target:user to
refresh the user policies
gpupdate
/target:machine to
refresh the machine (or computer) policies
As
with secedit, these parameters will only refresh any user or computer
policies that have changed since the last refresh. To force a
reload of all group policies regardless of the last change,
use:
gpupdate
/force
Notice
the /force switch applies to both user and computer policies. There
is no separation of the two like there is with secedit
Q10. What is the
Default Setting for Dial-up users?
Win2000 considers a slow
dial-up link as anything less than 500kbps. When a user logs
into a domain on a link under 500k some policies are not applied.
Windows 2000 will
automatically detect the speed of the dial-up connection and make a
decision about applying Group Policies.
Q11. Which are the
policies which get applied regardless of the speed of the dial-up
connection?
Some policies are always
applied regardless of the speed of the dial-up connection. These are:
Administrative
Templates
Security Settings
EFS Recovery
IPSec
Q12. Which are the
policies which do not get applied over slow links?
IE Maintenance
Settings
Folder Redirection
Scripts
Disk Quota
settings
Software Installation and Maintenance
These settings can be
changed under Computer and User Nodes, Administrative
Templates,
System, Group Policy.
If the user connects to
the domain using "Logon Using Dial-up Connection" from the
logon screen, once the user is authenticated, the computer policies
are applied first, followed by the user policies.
If
the user connects to the domain using "Network and Dial-up
Connections", after
they logon, the policies
are applied using the standard refresh cycle.
Q13. Which are the two
types of default policies?
There
are two default
group policy objects that are created when a domain is created. The
Default Domain policy and the Default Domain Controllers
policy.
Default
Domain Policy - this GPO
can be found under the group policy tab for that domain. It is
the first policy listed. The default domain policy is unique in
that certain policies can only be applied at the domain level.
If
you double click this GPO and drill down to Computer Configuration,
Windows Settings, Security Settings, Account Policies, you will see
three policies listed:
Password Policy
Acount Lockout
Policy
Kerberos Policy
These 3 policies can only be set at
the domain level. If you set these policies anywhere else- Site
or OU, they are ignored. However,
setting these 3 policies at the OU level will have the effect of
setting these policies for users who log on locally
to their PCs. Login to the domain you get the domain policy,
login locally you get the OU policy.
If you drill down to
Computer Configuration, Windows Settings, Security Settings, Local
Policies, Security Options, there are 3 policies that are affected by
Default Domain Policy:
Automatically log off users when logon
time expires
Rename Adminsitrator Account - When set at the domain
level, it affects the Domain Administrator account only.
Rename
Guest Account - When set at the domain level, it affects the Domain
Guest account only.
The Default Domain Policy should be used
only for the policies listed above. If you want to create
additional domain level policies, you should create additional domain
level GPOs.
Do not delete the Default Domain Policy. You can
disable it, but it is not recommended.
Default
Domain Controllers Policy -
This policy can be found by right clicking the Domain Controllers OU,
choosing Properties, then the Group Policy tab. This policy
affects all Domain Controllers in the domain regardless of where you
put the domain controllers. That is, no matter where you put
your domain controllers in Active Directory (whatever OU you put them
in), they will still process this policy.
Use the Default
Domain Controllers Policy to set local
policies for your domain
controllers, e.g. Audit Policies, Event Log settings, who can logon
locally and so on.
Q14.How to restore
Group policy setting back to default?
The following command
would replace both the Default Domain Security Policy and Default
Domain
Controller Security Policy. You can specify Domain
or
DC
instead
of Both,
to only
restore one or the other.
> dcgpofix
/target:Both
Note
that this must be run from a domain controller in the target domain
where you want to reset the GPO
If you've ever made
changes to the default GPOs and would like to revert back to the
original
settings,
the dcgpofix
utility
is your solution. dcgpofix
works
with a particular version of
schema. If the version it
expects to be current is different from what is in Active Directory,
it
not
restore the GPOs. You can work around this by using the /ignoreschema
switch,
which
restore
the GPO according to the version dcgpofix
thinks
is current. The only time you might
experience this issue is
if you install a service pack on a domain controller (dc1) that
extends
schema, but have not
installed it yet on a second domain controller (dc2). If you try to
run
dcgpofix
from
dc2, you will receive the error since a new version of the schema and
the
dcgpofix
utility
was installed on dc1.
Resolving GPOs from
Multiple Sources
Because GPOs can come
from different sources to apply to a single user or computer, there
must be a way of determining how those GPOs are combined. GPOs are
processed in the following order:
1.
Local GPO The local GPO on
the computer is processed and all settings specified in that GPO are
applied.
2.
Site GPOs GPOs linked to
the site in which the computer resides are processed. Settings made
at this level override any conflicting settings made at the preceding
level. If multiple GPOs are linked to a site, the site administrator
can control the order in which those GPOs are processed.
3.
Domain GPOs GPOs linked to
the domain in which the computer resides are processed and any
settings are applied. Settings made at the domain level override
conflicting settings applied at the local or site level. Again, the
administrator can control the processing order when multiple GPOs are
linked to the domain.
4.
OU GPOs GPOs linked to any
OUs that contain the user or computer object are processed. Settings
made at the OU level override conflicting settings applied at the
domain, local, or site level. It is possible for a single object to
be in multiple OUs. In this case, GPOs linked to the highest level OU
in the Active Directory hierarchy are processed first, followed by
the next highest level OU, and so on. If multiple GPOs are linked to
a single
Q15.
What are the two exceptions to control the inheritance of the group
policy?
■ No
Override When you link a
GPO to a container, you can configure a No Override option that
prevents settings in the GPO from being overridden by settings in
GPOs linked to child containers. This provides a way to force child
containers to conform to a particular policy.
■ Block
Inheritance You can
configure the Block Inheritance option on a container to prevent the
container from inheriting GPO settings from its parent containers.
However, if a parent container has the No Override option set, the
child container cannot block inheritance from this parent.
Q16. How to Redirect
New User and Computer Accounts?
By default, new user and
computer accounts are created in the Users and Computers containers,
respectively. You cannot link a GPO to either of these built-in
containers. Even though the built-in containers inherit GPOs linked
to the domain, you may have a situation that requires user accounts
and computer accounts to be stored in an OU to which you can link a
GPO. Windows Server 2003 includes two new tools that let you redirect
the target location
for new user and computer
accounts. You can use redirusr.exe to redirect user accounts and
redircomp.exe to redirect computer accounts. Once you choose the OU
for redirection, new user and computer accounts are created
directly
in the new target OU, where the appropriate GPOs are linked. For
example, you could create an OU named New Users, link an appropriate
GPO to the OU, and then redirect the creation of new-users accounts
to the New Users OU. Any new users created would immediately be
affected by the settings in the GPO. Administrators could then move
the new user accounts to a more appropriate location later. You can
find both of these tools in the %windir%\system32 folder on any
computer running Windows Server 2003. You can learn more about using
these tools in Knowledge Base article 324949, “Redirecting the
Users and Computers Containers in Windows Server 2003 Domains,”
in the Microsoft Knowledge Base at http://support.microsoft.com.
Q17.
What permissions
should a administrator have to manage GPOs?
Editing GPOs linked to
sites requires Enterprise Administrative permissions.
Editing GPOs linked to
domains requires Domain Administrative
Editing GPOs linked to
OUs requires permissions for the OU.
Q18. What is the
client requirement for supporting GPOs?
For
client computers to accept Group Policy settings, they must be
members of Active Directory. Support for Group Policy for key
operating systems includes the following:
■ Windows
95/98/Me do not support Group Policy.
■ Windows
NT 4.0 and earlier versions do not support Group Policy.
■ Windows
2000 Professional and Server support many of the Group Policy
settings available in Windows Server 2003, but not all. Unsupported
settings are ignored.
■ Windows
XP Professional, Windows XP 64-bit Edition, and Windows Server 2003
fully support Group Policy.