Software for your DCs and administration
Although the software packages installed on the DCs might not be a specific recovery step in the true sense, when you are hard-pressed for time you don’t want to start looking for tools and programs; you want to have them installed and ready to work on, anywhere you need.
There are many tools. Instead of copying the specific executables to your DCs, it is much easier to install the toolkits as part of the deployment when you install a DC.
Windows support tools
For both Windows 2000 and Windows 2003, the support tools package is a must-have. This is included on the installation CD under Support/Tools, as shown in the following screenshot, which shows the contents of a 64-bit installation CD. The location of Windows 2003 Small Business Server Support Tools is on CD 2 of the SDS CD set.
As you can see, what Microsoft considers the most essential tools, namely DcDiag.exe and Repadmin.exe, are available as standalone executables. Among many medium and large-sized organizations, it is considered a best practice to install the support tools on every DC. This is so because the support tools package provides you with essential tools that you can use for troubleshooting when errors appear in the event log, or the DC starts behaving strangely.
Once you have the Support Tools installed, you will have an additional entry in your Start menu for Windows support tools, which contains a link to the Help file and a shortcut to the command prompt.
Windows Resource Kit tools
The Windows Resource Kit traditionally only came as books in the NT 4.0 era. With Windows 2000, Microsoft started making the tools that are included in the Resource Kit available online for free download. You can still purchase the books as well, which are quite useful because they describe each tool and its application in great detail. However, the tools themselves can easily be downloaded. The links are listed here:
- For Windows 2000 (Server and Advanced Server): http://support.microsoft.com/kb/927229.
- For Windows Server 2003 32bit: http://www.microsoft.com/Downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en.
For Windows Server 2003 64bit, there is no Resource Kit because Microsoft’s website clearly states that the tools are not supported on 64-bit platforms. Given that the tools can be run from any XP client as well, this is not much of an issue unless you want to run a complete 64-bit server environment, and would like to distribute the tools with the DCs. One option is to have a virtual DC that runs Windows Server 2003 in 32-bit mode.
As only a handful of tools are necessary for Disaster Recovery, and you can run the tools from a client, it does not matter that much. The main point is that the tools should be available somewhere close to the DCs in every location. So, if you run them from a client, it might be a good idea to copy the tools onto the administration PC. A good option is to keep a CD copy of these tools stored with the Disaster Recovery Guide.
Adminpack for Windows XP/Vista Clients
The Administrative Tools package (Adminpack) is the least-used administrator tool in most organizations. Although it is considered a best practice to install Adminpack onto the administrative PCs or the PCs of the IT department, this is rarely done. In several cases, a lot of the administrative tasks are performed via Remote Desktop, directly on the DCs. This, of course, means that you have to give all of the people who make even small changes in the AD access to log on to the DCs. This might not be a good idea from a security perspective and can lead to actions that could have been prevented, such as downloading things directly to the DC, and installing or copying/modifying settings on the DC directly.
As DCs are the heart that make AD work, these machines should be as secure and isolated as possible.
The Adminpack is actually a file called adminpack.msi, which can be found in the i386 folder on the 32-bit installation CD of Windows 2000 and Windows server 2003. It is also in the same directory on the 64-bit installation CD, but there it is called wadminpack.msi.
The Adminpack contains the necessary snap-ins for the Microsoft Management Console (MMC), and puts them into your Administrative tools folder. These snap-ins are the normal tools you would have on a DC in order to administer the AD (shown in the following screenshot). It is, however, possible to run them directly from your client instead of on the DC.
Using the Adminpack also allows you to re-target the tools to different DCs and you don’t have to log on every time.
Diagnosing and troubleshooting tools
In this section we are going through some of the more advanced uses and possibilities of three tools that will undoubtedly be of great help in diagnosing either AD problems or replication problems.
The three tools that almost every person who needs to perform troubleshooting on Windows Server 2003 should be familiar with are NetDiag.exe, DcDiag.exe, and Repadmin.exe.
All three are command-line utilities, which implies that they can be run from a Windows XP Professional or Windows Vista workstation, and that they are standalone executables that can be copied from one machine to another. A nice feature of these tools is that they connect remotely to the DCs via the Remote Procedure Call service (RPC) and therefore you do not need to log on to the DCs. The only requirement for most of them is that they need to run from a machine that is a member of the domain and has access to the network.
DcDiag
DcDiag is the domain controller diagnostic utility. It allows you to diagnose a domain controller, and check if everything is ok. If it is not, then the tests will run until failure, and based on which tests fail, you can go about finding the cause. Even though this may sound rather simple, this utility, even if run without any flags or options, will execute a set of very meaningful tests, and based on pass or fail, you will have a very good idea of where to start looking. The tests performed are listed in the following tables:
Primary tests |
Descriptions |
Connectivity |
Tests whether or not the DC is connected to the network |
Replications |
Tests to ensure replications can be started, and are run on time |
NCSecDesc |
Checks that the security descriptors on the naming context heads have appropriate permissions for replication |
NetLogons |
Tests if the DC allows the appropriate logons to initiate replication |
Advertising |
Tests if the DC can advertise itself (DNS) |
KnowsOfRoleHolders |
Tests if the DC knows which servers hold the FSMO roles |
RidManager |
Tests if the DC can contact the RidManager |
Machine Account |
Tests if the DC has a valid Machine Account |
Services |
Tests if the necessary services are running on the DC |
ObjectsReplicated |
Tests whether or not the DSA and Machine Account objects have ever been replicated |
frssysvol |
Checks if the sysvol share is listed in the File Replication Service (FRS) |
frsevent |
Tests if FRS errors have been generated |
kccevent |
Tests if KCC errors have been generated |
systemlog |
Tests if there are system errors |
VerifyReferences |
Tests if AD FRS records are intact and correct for the replication infrastructure |
DNS Partition tests |
Descriptions |
Forest DNS tests |
|
CrossRefValidation |
Checks if the replication cross-references are intact in the forest DNS zone |
CheckSDRefDom |
Checks if the Security descriptors for the forest are intact |
Domain DNS tests |
|
CrossRefValidation |
Checks if the replication cross-references are intact in the domain DNS zone |
CheckSDRefDom |
Checks if the Security descriptors for the domain are intact |
Schema, Configuration, and Enterprise tests |
Descriptions |
Schema tests |
|
CrossRefValidation |
Checks if the replication cross-references are intact in the schema itself |
CheckSDRefDom |
Checks if the Security descriptors within the schema are intact |
Configuration |
|
CrossRefValidation |
Checks if the replication cross-references are intact in the current forest configuration |
CheckSDRefDom |
Checks if the Security descriptors within the configuration are intact |
Partition tests |
|
CrossRefValidation |
Checks if the replication cross-references are intact in the current application partition |
CheckSDRefDom |
Checks if the Security descriptors for the application partition are intact |
Enterprise tests |
|
Intersite |
Checks if the inter-site replication can be initiated |
FSMOCheck |
Checks that all FSMO roles are assigned and can be contacted |
As you can see, DCDiag performs a lot of tests. But bear in mind that most of these are run locally on the DC with the data held by that DC. This means that any error in the DNS, Schema, configuration or partition tests can be working on another DC. It is possible that only this particular replica of the DC is malfunctioning.