Using the esentutl Command
Although all of the operations covered previously in this section used the Ntdsutil command-line
utility, most actually performed their work by calling the Esentutl command. ESENT (Extensible
Storage Engine for NT) is one of the acronyms used to refer to the ESE database system that Active
Directory uses.The Esentutl command is the maintenance command that is associated with this
database system. Because Microsoft prefers that you use the Ntdsutil command for all low-level
database maintenance operations, they built calls to most of the major Esentutl operations into it.
However, you do not have to use Ntdsutil to perform these operations.The following are two of the
commands from earlier in the chapter with their associated Esentutl command-line arguments:
■Integrity %SYSTEMROOT% \System32\esentutl.exe /g “C:\Windows\NTDS\ntds.dit”
/o
■Recover %SYSTEMROOT%\System32\esentutl.exe /redb /l”C:\Windows\NTDS” /s
“C:\WINNT\NTDS” /8 /o
The esentutl.exe command used in conjunction with the /p switch, shown in Figure 19.19, is
considered the most dangerous of all the low-level database commands. In Windows 2000, this com-
mand was available as the repair option in Ntdsutil, and has been removed in the version of Ntdsutil
that ships with Windows Server 2003.This option performs a very low-level and highly invasive
binary database repair operation. It is very likely that you will lose some data when using this
option, and it is highly possible that it will be data essential to your Active Directory database.
You should use this command with the /p switch only when you have been advised to do so by
Microsoft support personnel, or when you feel that you have tried everything else to get Active
Directory to initialize. Always make a backup of your database file before you run this utility. In most
cases, you will be resorting to this option when Active Directory can no longer initialize, and you
will be booted to Directory Services Restore Mode.The simplest way to back up the database and
related components in this scenario is to copy them to a second location in the file system, using
Windows Explorer.
If Active Directory can initialize and you still feel you should (or Microsoft tech support asks
you to) run this command, you must boot into Directory Services Restore Mode first.The database
must be offline for low-level operations such as this. Microsoft recommends running a semantic
database analysis after this command has completed successfully.To use the repair command, enter
the following at a command prompt: %SYSTEMROOT%\system32\esentutl.exe /p
“C:\Windows\NTDS\ntds.dit” /!10240 /8 /o
656 Chapter 19 • Ensuring Active Directory Availability
Changing the Directory
Services Restore Mode Password
Because the Directory Services Restore Mode password is set during the installation of Active
Directory, administrators often have difficulty remembering the password that was used when it is
needed later. Fortunately, there is a way to change this password without having to remember what
it was originally: by using the Ntdsutil command-line utility.To use this feature, the server on which
you want to change the password cannot be running in Directory Services Restore Mode. Ntdsutil
can be used to change the password on the DC locally, or another DC within the forest.To change
the Directory Services Restore Mode password, follow these steps:
1. Open a command prompt.
2. Type ntdsutil to enter the Ntdsutil utility.This is a command-line utility, so the com-
mand prompt will change to ntdsutil:.
3. Type Set DSRM Password.
4. At the Reset DSRM Administrator Password: prompt, type Reset Password on
server <SERVER NAME>.
5. At the Please type password for DS Restore Mode Administrator Account:
prompt, type the new password that you want to use.
6. At the Please confirm new password: prompt, re-type the new password that you want
to use.
7. Review the feedback on the screen to ensure that the operation was successful. Figure
19.20 shows the full procedure.
Ensuring Active Directory Availability • Chapter 19 657
Figure 19.19 The esentutl Repair Process
8. Type quit or q to return to the ntdsutil: prompt.
9. Type quit or qagain to exit the utility.
10. Close the command prompt window.
658 Chapter 19 • Ensuring Active Directory Availability
Figure 19.20 Using Ntdsutil to Reset the DSRM Password on a Server
Planning, Implementing,
and Maintaining a Name
Resolution Strategy
In this chapter:
Planning for Host Name Resolution
Planning for NetBIOS Name Resolution
Troubleshooting Name Resolution Issues
Introduction
In this chapter, you’ll learn how to plan for the best way of resolving host and NetBIOS
names on your network. We’ll discuss issues involved in designing a DNS namespace,
such as choosing the parent domain name, the conventions and limitations that govern
host names, the relationship of DNS and Active Directory (AD), and how to support
multiple namespaces.
Then we move onto planning DNS server deployment.You’ll find out how to con-
sider factors such as the number of servers, server roles, server capacity, and server place-
ment. We’ll also show you how to plan for zone replication between your DNS servers,
and we’ll address planning for forwarding and how DNS interacts with the Dynamic
Host Configuration Protocol (DHCP) on a Windows Server 2003 network. We’ll dis-
cuss Windows Server 2003 DNS server interoperability with Berkeley Internet Name
Domain (BIND) and other non-Windows DNS implementations.You’ll learn about
zone transfers between Windows Server 2003 DNS servers and BIND servers, and we’ll
discuss supporting AD with BIND.You’ll learn about split DNS configurations and how
interoperability relates to other services such as Windows Internet Name Service
(WINS) and DHCP. Next, we’ll address DNS security issues, including common DNS
threats such as footprinting, redirection, and DNS denial-of-service (DoS) attacks.You’ll
learn how to best secure your DNS deployment by using a split namespace and packet
filtering. We’ll discuss how to determine the best DNS security level for your network.
Next, we’ll look at DNS performance issues. We’ll show you how to monitor DNS
server performance and how to analyze DNS server tests.
Chapter 20
659
In the next section, you’ll find out what’s new for WINS in Windows Server 2003, and we’ll
show you how to plan WINS server deployment and WINS replication. We’ll walk you through the
process of configuring WINS replication partnerships, including push-only, pull-only, and push/pull
configurations. We’ll also discuss common WINS issues, including configuration, performance, and
security issues. We’ll show you how to plan for WINS database backup and how to troubleshoot
name resolution problems related to both host names and NetBIOS names.
Planning for Host Name Resolution
One of the most common sources of trouble on any Windows network—whether it’s a Windows
NT, Windows 2000, or Windows Server 2003 network—is faulty name resolution. When name res-
olution (the process of finding the IP addresses associated with computer names and services run-
ning on those computers) is not working perfectly, a multitude of problems can arise, including (but
not limited to) the following:
■Users might not be able to log on to the network.
■Users might not be able to connect to applications and services residing on remoter com-
puters.
■Domain controllers might not be able to communicate with each other.
In fact, problems with name resolution are so common that a typical first step in trou-
bleshooting problems on a Windows network is to ensure that name resolution is working flawlessly.
A common mantra that reflects this situation is the following:“The problem is irrelevant.The
answer is DNS.” Although this is a gross oversimplification of the problems that can arise on a
Windows network, it does contain a germ of truth.
Planning for host name resolution on a Windows Server 2003 network means developing and
implementing a fault-tolerant and secure strategy, whereby host computers on the network are
always able to resolve computer names to IP addresses and locate services running on the network
in a timely manner. On a Windows Server 2003 network, the primary mechanism for locating the
domain controllers is host name resolution through DNS.
DNS Name Resolution Process
Distributing DNS Resource Records (RRs) among many different zones and domains has an effect
on the name resolution process that needs to occur for a DNS client to find a host name-to-IP
address mapping. Let’s take the example of a client trying to connect to
www.research.microsoft.com.The DNS client is configured to use another DNS server to perform
recursion on its behalf. (Performing recursion simply means that the DNS server will issue iterative
queries to other DNS servers and accept referrals from these servers, until it receives a positive or a
negative response, and then forward that response to the DNS client.) The DNS client issues a recur-
sive query to the DNS server; the DNS server subsequently issues a series of iterative queries to
resolve the name. Figure 20.1 shows the process that occurs in order to resolve
www.research.microsoft.com to the IP address.
660 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy