Windows Server 2003 Info
DHCP has its own database. Stored in this DHCP.mdb are the
addresses, scopes and leases of the clients. Understanding this
database will help you backing up and restore a DHCP server.
Check out this folder: %systemroot%\system32\dhcp\dhcp.mdb
As time goes by the database will grow, and best practice dictates that you should consolidate the database by freeing up space taken up by old leases.
The procedure for compacting the dhcp.mdb database is this.
1) Stop the DHCP service. Either right click
the DHCP Server icon, select All tasks then Stop. Alternatively,
go to the command line and type: NET Stop DHCPServer. (For once
the command really is DHCPserver, NOT DHCPyourservername.)
2) At the command line, navigate to: %systemroot%\system32\dhcp\dhcp.mdb.
3) Jetpack dhcp.mdb temp.mdb. What this does is copies the existing database, compacts it, then copies it back to the original location - clever.
4) Remember to restart DHCP. Either use the GUI, or if you are at the command line, NET Start DHCPServer
Warning: Do not 'mess' with any of the files that you find in the %systemroot%\system32\dhcp folder, if you do, then DHCP will stop working and you will either have to restore, or else re-install DHCP.
File Replication service (FRS)
File Replication service (FRS) is a technology that
replicates files and folders stored in the SYSVOL shared folder
on domain controllers and Distributed File System (DFS) shared
folders. When FRS detects that a change has been made to a file
or folder within a replicated shared folder, FRS replicates the
updated file or folder to other servers. Because FRS is a
multimaster replication service, any server that participates in
replication can generate changes. In addition, FRS can resolve
file and folder conflicts to make data consistent among servers.
By keeping files and folders synchronized across servers, FRS enables organizations to increase the availability of data. If one server becomes unavailable, the files are still available, because they exist on another server. Using multiple servers to host data also helps organizations that have offices in multiple geographic locations, because clients can access servers in or closest to their current site and do not need to use expensive WAN links to access data.
A DNS database
It is made up of records. Therefore, common resource record
types in the DNS database are:
A - Host's IP address. Address record allowing a computer name to be translated into an IP address. Each computer must have this record for its IP address to be located. These names are not assigned for clients that have dynamically assigned IP addresses, but are a must for locating servers with static IP addresses.
PTR - Host’s domain name, host identified by its IP address
CNAME - Host’s canonical name allows additional names or aliases to be used to locate a computer.
MX - The mail exchanger (MX) RR is used by e-mail applications to locate a mail server based on a DNS domain name used in the destination address for the e-mail recipient of a message.
NS - Host’s or domain’s name server(s).
SOA - Indicates authority for the domain
SRV - To locate Active Directory domain controllers, service location (SRV) RRs are required. Typically, you can avoid manual administration of the SRV RR when installing Active Directory.
There are two types of DNS queries that may be sent to a DNS server:
A recursive query forces a DNS server to respond to a request
with either a failure or a successful response. DNS clients
(resolves) typically make recursive queries. With a recursive
query, the DNS server must contact any other DNS servers it
needs to resolve the request.
An iterative query is one in which the DNS server is expected to respond with the best local information it has, based on what the DNS server knows from local zone files or from caching. This response is also known as a referral if the DNS server is not authoritative for the name. If a DNS server does not have any local information that can answer the query, it simply sends a negative response. A DNS server makes this type of query as it tries to find names outside of its local domain(s) (when it is not configured with a forwarder). It may have to query a number of outside DNS servers in an attempt to resolve the name.
There are three types of DNS zones supported in Windows Server 2003:
Primary zone. Original copy of a zone where all resource records are added, modified, and deleted.
Secondary zone. Read-only copy of the primary zone that is created and updated by transferring zone data from the primary zone.
Stub zone. Read-only copy of the primary zone containing only the DNS resource records for the DNS servers listed in the zone (SOA, NS, and glue A resource records).
Understanding stub zones
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.
A stub zone consists of:
1) The start of authority (SOA) resource record, name server (NS) resource records, and the glue A resource records for the delegated zone.
2) The IP address of one or more master servers that can be used to update the stub zone.
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.
A stub zone is like a secondary zone in that it obtains its resource records from other name servers (one or more master name servers). A stub zone is also read-only like a secondary zone, so administrators can't manually add, remove, or modify resource records on it. But the differences end here, as stub zones are quite different from secondary zones in a couple of significant ways.
First, while secondary zones contain copies of all the resource records in the corresponding zone on the master name server, stub zones contain only three kinds of resource records:
1) A copy of the SOA record for the zone.
2) Copies of NS records for all name servers authoritative for the zone.
3) Copies of A records for all name servers authoritative for the zone.