Tài liệu Module 6: Deployment Tools and ADC Tools docx

Contents
Overview 1
Lesson 1: Deployment Tools 2
Lesson 2: ADC Tools 39
Lab 6.1 Exchange 2003 ADC replication
featuring Deployment and ADC Tools 71

Appendix A: Sample log files 86
Appendix B: Learning Measure Answers 107
Acknowledgments 107

Module 6: Deployment
Tools and ADC Tools

Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any

license to these patents, trademarks, copyrights, or other intellectual property.

 2003 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows NT, Active Directory, ActiveX, Excel, Exchange Server
5.5, Exchange 2000 Server, Exchange Server 2003, Internet Explorer, Internet Information Server,
Word are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.

The names of actual companies and products mentioned herein (Groupwise, Lotus cc:Mail, Lotus
Notes) may be the trademarks of their respective owners.


Module 6: Deployment Tools and ADC Tools 1


Overview


For this module, we will discuss the new deployment features available with
Exchange Server 2003 and differentiate the deployment process from Exchange
2000.
Topic 1 Deployment Tools
Topic 2 Active Directory Connector (ADC) Tools
Topic 3 Appendix
Prerequisites
1) Experience with installing Exchange 2000 into Exchange 5.5 sites
2) Prior usage of Virtual PC or Virtual Server

2 Module 6: Deployment Tools and ADC Tools

Lesson 1: Deployment Tools


Basic Overview


History:
Customers that installed Exchange 2000 experienced a paradigm shift in the
complexity of the underlying operating system. With Windows 2000
introducing several new concepts, installers were burdened with learning the
differences in how Active Directory uses Domain Name System (DNS),
Lightweight Directory Access Protocol (LDAP), and a variety of new server
roles for establishing suitable infrastructures for Exchange 2000. Microsoft
Product Support Services learned that these infrastructures failed too often, or
were never configured correctly at their inception. Although many of the
support calls were caused by platform-level mishaps (such as improper DNS
configurations, Active Directory permission-misconfigurations, and lack of
connectivity to operations masters), more daunting challenges existed for
migrations from Exchange 5.5. These Exchange 5.5 migration challenges were
often
 discouraging customers from deploying Exchange 2000. (For example, a
customer might find it extremely difficult to roll back after a failed disaster
recovery scenario following a failed in-place upgrade.)
 completely ignored or skipped by customers. For example, NTDSNoMatch
is supposed to be written on Exchange 5.5 objects, yet customers didn’t
know of the existence of NTDSNoMatch due to delayed documentation
when Exchange 2000’s retail version shipped. Additionally, many
customers skipped configuration of Connection Agreements due to their

complexity, or even worse…
 improperly configured through guesswork. (Installers who were new to
Exchange 2000 were accustomed to “Install first, configure later”
methodologies, yet Exchange 2000 deviated from other server applications
Module 6: Deployment Tools and ADC Tools 3


by requiring tremendous configuration changes to their current topology
before installing. This approach occurred most often with small to medium-
sized companies who lacked the time or manpower to research the
deployment process, and would take a simple approach to running the setup
process without reviewing the appropriate pre-setup steps.)
By not meeting those challenges, what resulted were problems ranging from
unintended standalone orgs incompatible with Exchange 5.5 orgs, to creating
thousands of duplicate Active Directory objects that were improperly replicated
due to no NTDSNoMatching, to disaster recovery on Exchange 5.5 directories
where customers unintentionally created (and then mistakenly deleted)
mismatched accounts, to non-functional transports. These large percentages of
failed or blocked deployments rapidly cost Microsoft Product Support Services
a high price because there was no easy corrective path. Instead, Microsoft
Product Support Services would occasionally clean up corrupted Exchange 5.5
and Active Directories, and then re-deploy Exchange 2000 for customers. Even
today, where installers are armed with a great deal of knowledge that gradually
became publicly available, they are still prone to encountering problems, simply
because of the sheer quantity and complexity of deployment steps. Even
administrators who were simply migrating, who may not be concerned with
Exchange 5.5/2000 interoperability, are required to fumble through the various
coexistence measures because migrations require temporary interoperability
with Exchange 5.5. So a process was needed to improve customer education
and ensure the structural integrity of Exchange 5.5 and Active Directory

topologies, leading to improving deployment success rates.
The solution:
Efforts to prevent Exchange 2000 deployment mistakes of the past have
culminated into the creation of the Exchange 2003 deployment tools. A
multipurpose effort, the deployment tools not only avoids the huge gap in
customer education when Exchange 2003 ships; it also proactively scans the
Active Directory and Exchange 5.5 infrastructures for possible problems that
may prevent successful Exchange 2003 deployments. The customer education
effort is achieved through a comprehensive help file/installation guide, which
takes into consideration four major deployment scenarios and provides
prescriptive deployment steps for each. A picture of the help file is shown in
figure 1.1:
4 Module 6: Deployment Tools and ADC Tools



Figure 1.1: An example of the deployment tools step-by-step deployment guide, in the form of a
compiled HTML help file. (pre-release version)
Although the user-education portion may appear informational at first glance,
there are ActiveX controls embedded within each HTML page that, when
clicked, will spawn scripts to proactively check for problems on the local
system, within Exchange 5.5 directory, within Active Directory, or all of the
above. Technically, the scripts call upon the deployment tools, but the
collection of tools plus help file is most commonly-referred as the “Deployment
Tools.”
Module 6: Deployment Tools and ADC Tools 5


Tool Execution

There are three ways to call upon the Deployment Tools:
Method 1 – From the help file (most common): The Deployment Tools’ step-
by-step guide is a compiled HTML help file. In other words, it is a collection of
Web pages that are combined into a single file with a .CHM extension. For
customers to execute the help file, they must launch the HTML application
(exdeploy.hta), which then renders the Exdeploy.chm contents within its frame.
The CHM/HTA file may be navigated just like a collection of Web pages
within a Web site. (See the “Process flow” heading for information about
HTML applications). The CHM file may be decompiled into separate HTML
pages using Visual Studio, though that is outside the scope of this discussion.
Although you could launch the exdeploy.CHM file, and click on “Home” to get
to the starting point of the deployment steps, it is not recommended because of
Internet Explorer browsing problems. Thus, it is recommended to launch
exdeploy.HTA instead.
While browsing through a page that contains a script, users launch each
Deployment Tool by entering-in servername information onto the Web page.
When they hit “run <toolname> now”, a script takes the user input as
parameters to execute the tool(s) in a separate command window, shown by the
bottom portion of figure 1.2:
6 Module 6: Deployment Tools and ADC Tools



Figure 1.2: Tool execution through the help file spawns the exdeploy.exe command line tool with a
hidden switch. Under the hood, the CHM is running “exdeploy.exe /s:racecar /gc:palindromes
/t:orgprepcheck”
The command window disappears when the exdeploy tool has finished
execution. However, during execution, the tools will log success and failure

information into exdeploy.log file, typically located in c:\exdeploy logs. Log
files are appended-to, not overwritten, when tools are run more than once.
Although exdeploy.chm contains links to launch the tools, the tools themselves
may not be launched without the existence of binaries (DLLs and EXEs) within
the same directory as the CHM file. The deployment tools help file and binaries
are located on the Exchange 2003 CD, underneath the \support\exdeploy
directory.
Method 2 – From the command prompt: The error-checking tools may also
be launched from the command line by running exdeploy.exe. Exdeploy.exe is
an executable that can launch various deployment tools depending upon the
switches used. In fact, all of the deployment tools may be launched using
exdeploy.exe, without requiring the CHM file. However, none of the tools may
be launched from the CHM/HTA file if the CHM/HTA exists in a directory
without exdeploy.exe supporting it.
Using Method 2 to manually execute a deployment tool should only be used
when troubleshooting, or when someone is already familiar with the ordering of
the help file (since some tools will fail unless you have performed certain steps
only mentioned in the CHM file). Here is an example of running a deployment
tool from the command prompt:
D:\SUPPORT\EXDEPLOY>exdeploy /s:55server /gc:gc01
/t:adcusercheck
Results of these tools will be logged to 'exdeploy.log'.
Exchange Deployment Tools documentation provides information
on how to solve encountered issues.
Calling ADCUserCheck
ADCUserCheck completed successfully.

Module 6: Deployment Tools and ADC Tools 7

Like Method 1, tools will still create/append-to logfiles located in the logging
path (c:\exdeploy logs by default). Some tools will even write their own logfile,
named after the tool itself. Often, installers will attempt to run the tools
comprehensively (using the /c switch), so that all of the tools will be run with
one command line execution. Comprehensively running the tools is not useful
for the customer before setup because many of the deployment tools tests will
fail when it checks for existence of Active Directory objects that only exist
post-setup. However, it is useful to Microsoft Product Support Services for
troubleshooting an installation that has already completed, since a low level of
information gathering (i.e. list of server names, sites, list of unreplicated users)
is readily available in c:\exdeploy logs.
Deployment tools may also be launched in tool groups. For instance, when you
run “/t:DSScopescan” you actually launch five deployment tools contained
within that group: DSConfigSum, DSObjectSum, UserCount, VerCheck, and
OrgNameCheck. Tool groupings are documented within exdeploy.exe usage
(simply by typing exdeploy /?) and also within the exdeploy.chm reference
topics.
Method 3 – from the Exchange 2003 setup wizard: The user has no control
here, as setup.exe will automatically launch a few of the deployment tools to
perform some basic pre-requisite checking before continuing setup. In
Exchange 2000, there were fewer checks prior to the file-copy/register phase, so
when setup proceeded to the latter stages, it would often fail catastrophically.
The Exchange 2003 setup program is now improved with additional pre-
requisite checks, some of which look for completion of certain deployment
tools before allowing itself to proceed to file-copy/registry modification phases
of setup. Since setup.exe employs the use of the same tools as exdeploy.exe, we
will discuss the glue DLL that is utilized by both.

Figure 1.3: Exchange 2003 Glue DLL has multiple interfaces, since it is
called by exdeploy and Exchange 2003 setup.

The Exchange 2000/2003 setup program runs through prerequisite checks upon
launch, and if any prerequisite checks fail, their associated errors (possible
8 Module 6: Deployment Tools and ADC Tools


reasons/recommended actions) are displayed as a popup on the setup wizard’s
component selection screen.
[10:44:03] ********** Beginning Exchange Deployment Tools
**********
[10:44:03] Starting Exchange 6851 Deployment Tools on Windows
5.0.2195 at 10:44:03 01/13/2003
[10:44:03] Entering HrDirPreReq_Initialize
[10:44:03] Init called with Domain Controller tilab-dc and
Exchange 5.5 server root55. Setup's language ID is 0
[10:44:03] Entering HrRegisterAXDLL
[10:44:03] Leaving HrRegisterAXDLL
[10:44:03] Entering HrRegisterAXDLL
[10:44:03] Leaving HrRegisterAXDLL
[10:44:03] Leaving HrDirPreReq_Initialize
[10:44:21] Entering HrDirPreReq_ConfigInit
[10:44:55] Leaving HrDirPreReq_ConfigInit
[10:44:55] Entering HrDirPreReq_ObjectInit
[10:45:46] Leaving HrDirPreReq_ObjectInit
[10:45:46] Entering HrDirPreReq_UserInit
[10:46:20] Leaving HrDirPreReq_UserInit
[10:46:20] Entering HrDSConfigSum
[10:46:21] Leaving HrDSConfigSum
[10:46:21] Entering HrDSObjectSum
[10:46:21] Leaving HrDSObjectSum
[10:46:21] Entering HrUserCount

[10:46:21] Leaving HrUserCount
[10:46:21] Entering HrVerCheck
[10:46:21] VerCheck verifies if your Exchange 5.5 servers can
be upgraded to Exchange 2000. Details are logged in
vercheck.log.
[10:46:21] Leaving HrVerCheck
[10:46:21] Entering HrRunNetdiag
[10:46:21] Entering HrGetDSILog
[10:46:21] Leaving HrGetDSILog
[10:46:36] Entering HrMapFileName
[10:46:36] Entering HrMapFileHandle
[10:46:36] Leaving HrMapFileHandle
[10:46:36] Leaving HrMapFileName
[10:46:36] Entering HrFindPrintErrorMessage
[10:46:36] Warning: Possible error string '. . . : Failed'
detected in netdiag output.
[10:46:36] Leaving HrFindPrintErrorMessage
[10:46:36] HrRunNetdiag
(f:\df6851\dsa\src\deploy\dsintegchk\netdiag.cpp:888). Error
code 0X80040001(1).
[10:46:36] Leaving HrRunNetdiag
[10:46:36] Entering HrOrgNameCheck
[10:46:37] Leaving HrOrgNameCheck
[10:46:37] Entering HrDirPreReq_Terminate
[10:46:37] Leaving HrDirPreReq_Terminate

The exdeploy-progress.log can be opened using logparser.exe. However, its
filters for logging levels do not work, so leave the setting on maximum (log
level 3). The only benefit to opening in logparser is to use logparser’s ability to
Module 6: Deployment Tools and ADC Tools 9

dissect multiple runs of the exdeploy-progress.log so that you can view each
run by itself. Another minor thing to note here is that a lot of the same entries
you find in exdeploy-progress.log will also be logged into the setup wizard’s
progress.log file. Search for HrDirPreReq anytime setup is joining an Exchange
5.5 site, and you’ll get to the deployment tools section of the Exchange Server
Setup Progress.log.
On the right-hand side of figure 1.3, the glue DLL will call into the actual tools
themselves. The tools are EXEs, DLLs, or even scripts. If the individual tool is
a script or separate EXE (such as policytest.exe), then the glue DLL makes a
call to CreateProcess.
10 Module 6: Deployment Tools and ADC Tools


Markers:


Before discussing the process flow, consider that several phases of the
deployment tools will create markers in Active Directory. These “completion”
markers are intended to ensure that customers use the deployment tools and
ADC Tools. Without them in place, setup will block customers from installing
the first Exchange 2003 server any organization containing Exchange 5.5 or
Site Replication services. Without Exchange 2003 setup logic to detect these
markers, installers would skip the proper deployment steps and tools, thereby
encountering the same deployment problems that existed with Exchange 2000.
Also, one of the main differences from Exchange 2000 is that in Exchange
2003, installers will no longer be able to launch the setup wizard from setup.exe
at the root of the CD without being forced into deployment tools. This single
entry-point initiative for setup was deemed necessary for several reasons: 1)

Development and Product Support Services want customers to review the
exdeploy.chm to prevent problems, 2) the deployment tools are not very
discoverable since they are in a completely separate directory from
\setup\i386\setup.exe, and 3) setup will not be able to continue unless a certain
condition (ADCUserCheck marker) is satisfied by the deployment tools.

The backdoor executable (\CD ROOT\setup\i386\setup.exe) may still run
the setup wizard, but this path is less discoverable for unexperienced
installers.

ADCUserCheck, along with other markers, are illustrated in figure 1.4 below:
Note
Module 6: Deployment Tools and ADC Tools 11



Figure 1.4: The deployment tools completion markers, viewed through ADSI Edit
As seen in the above illustration, markers are attribute values stamped in the
“description” attribute of the Microsoft Exchange container in Active Directory.
Each value contains three fields:
 The marker name - named after the tool that stamped it.
 The timestamp of the marker – indicates the time (not in GMT) that the tool
was last executed.
 A status flag – describing if the tool’s result was a success or failure.
The marker of biggest concern is the ADCUserCheck marker, which is stamped
when the user clicks the button to run Step2’s Data Collection or to verify step
4 in the ADC tools (discussed in Lesson #2). ADCUserCheck is the most
important marker, since its absence will prevent setup from proceeding beyond
its initialization phase. Also, notice the timestamp: 2003003282359. If that
value is more than two weeks old, the installer will be warned about the need to

rerun the tool. The purpose of the timestamp is to prevent the tool’s result from
becoming stale, since customer environments may have changed drastically
over weeks or months, and it is highly likely they have more unreplicated
objects from the time they originally passed ADCUserCheck. Specifically, the
purpose of rerunning the tool is that after a time threshold, customers may need
to rereplicate or configure new Connection Agreements.

12 Module 6: Deployment Tools and ADC Tools



As an installer and for the purposes of saving time, you
could manually insert the ADCUserCheck marker using ADSIEdit and skip all
of the deployment tools. However, normal customers should not utilize this
shortcut since you want them to utilize deptools/adctools.


Troubleshootin
g
Tip
Module 6: Deployment Tools and ADC Tools 13


Process Flow


The deployment process begins when customers insert their Exchange 2003 CD
or run setup.exe from the root of the CD. Either action launches the intro/splash
screen, which in previous versions of Exchange provided a direct link to
setup.exe within the \setup\i386 folder. In Exchange 2003, the splash screen no

longer allows Exchange setup to be directly launched. Instead, installers may
only choose the deployment tools link.

14 Module 6: Deployment Tools and ADC Tools


Figure 1.5: The introductory splash screen, no longer allows on-demand Exchange installations.
The splash screen link to the deployment tools actually points to
\support\exdeploy\exdeploy.hta, which is a simple HTML application that calls
upon exdeploy.chm. Framed within the HTA, the CHM file’s content and
ordering is preserved while at the same time it bypasses script and security
errors that would otherwise have been apparent if the CHM file was used to
launch scripts.
The CHM file’s main menu contains a resource link to download the latest
version of the help file, as well as four links to the various phases of
deployment.
These four menu options are shown on the left-hand side of figure 1.6 and the
installer should begin with “Deploy the first Exchange 2003 server.” Clicking
on this link will produce a second-tier menu for the most significant decision-
making step where customers can identify in which of these four scenarios they
reside.
Module 6: Deployment Tools and ADC Tools 15


Deployment Scenarios


1. Coexistence with Exchange 5.5 – This option is a necessity for intra-
organizational migrations.
2. Coexistence with Mixed Mode Exchange 2000 and Exchange 5.5 –This

scenario covers installing Exchange 2003 as another member of a mixed-
mode organization. This option also applies when there are Site Replication
Servers running in the organization, even if there are no more Exchange 5.5
servers.
3. Upgrade from Exchange 2000 Native mode – This scenario’s name not only
implies in-place upgrading an Exchange 2000 server to Exchange 2003; it
also covers joining an Exchange 2003 server as another member of a pure
Exchange 2000 organization with no running Site Replication Servers.
4. New Exchange 2003 – This scenario is the simplest of all, as no preparatory
work is necessary for any existing Exchange servers.

16 Module 6: Deployment Tools and ADC Tools





Figure 1.6: Process flow for all of the steps covered by exdeploy.chm
Figure 1.6 illustrates the process flow, which contains scenarios identified at the
top of the screen, enclosed by borders. The most full-featured scenario for
installing the first Exchange 2003 server is “Coexistence with Exchange 5.5.”
In the coexistence scenario, deptools examines the existing Exchange 5.5 and
Active Directory infrastructure for Exchange 2003 suitability. Note that inter-
organizational (cross-forest) migrations or deployments of multiple Exchange
organizations are too advanced and are not discussed by exdeploy.chm. Cross-
forest deployments is discussed in another training module.
Module 6: Deployment Tools and ADC Tools 17


DSScopeScan

Since the “Coexistence with Exchange 5.5” scenario runs through the entire
gamut of deployment tools, this discussion will concentrate on the Exchange
5.5/2003 deployment. Beginning with the DSScopeScan tool group, which runs
a set of tools intended to provide administrators a quick estimate of the size of
the organization to help with gauging the deployment project’s length, one may
easily foresee possible deployment blockers. When the deployment
administrator/consultant runs the DSScopescan tool group, the following tools
execute:
 DSConfigSum: Outputs server name, Windows version, and Exchange
version. Notes whether the server contains a public folder store. Notes
whether Key Management Service is installed. Notes whether Internet Mail
Service is installed. Notes whether the server is a directory bridgehead
server. Outputs any inbound, outbound, or 2-way connectors. This tool is
probably more beneficial to support engineers in data gathering, as it
outputs site names and Exchange server versions within those sites. This
additional output is logged to DSConfigSum.log.
 DSObjectSum: Notes number of public folders. Notes number of
distribution lists. Notes number of distribution lists with hidden
membership. Notes number of contact objects. There is no additional
logfile; all output for this tool is directed to exdeploy.log. This tool is useful
in determining how many groups may be affected with disappearing
membership: More information is in KB article 321205.
 UserCount: Notes number of users in each site. Notes total number of users
in the Exchange 5.5 directory. If this number is ever zero, it generally
indicates a permissions problem (you might be running deptools with the
wrong credentials to the 5.5 directory) or an LDAP protocol configuration
problem (search buffer might be set too low per KB article 320482).
Extended output is fed to usercount.log.

 VerCheck: Determines if any Exchange 5.5 server versions are not
compatible with the Active Directory connector. (At least one must be
Exchange 5.5 SP3). Outputs to vercheck.log.
18 Module 6: Deployment Tools and ADC Tools


 Orgreport: Determines if an existing object, whose objectclass is
msExchOrganizationContainer, exists underneath cn=Microsoft
Exchange,cn=services,cn=configuration,dc=<dn of forest root> If one is
found, the tool does not qualify it as an error. However, it will write the
displayname of the object to exdeploy.log if it was not created by Exchange
2003 forestprep. The existence of an org object means that an Exchange
2000 installation attempt, either through a forestprep or typical setup, was
performed in the past. Additionally, this signifies the possible existence of a
rogue Exchange 2000 server object in Active Directory. If this is the case,
rollback using the removeorg switch (Q312878).
 GCVerCheck: Checks local and adjacent Windows sites for a Windows
global catalog that is SP3 or greater. If none is found, then setup will not
proceed. Although Exchange 2003 setup has a prerequisite check for this
situation, it is convenient to scan for this prior to setup, so that
administrators can plan upgrades of their domain controllers accordingly.
 OrgNameCheck: Determines if the Exchange 5.5 organization or site
names exceed 64 characters or contain any of the following (excluding the
surrounding braces). { , = + < > # \ " ~ ! @ # $ % ^ & * ( ) _ + = { } [ ] | \ : ;
" ' < , > . ? / }. Additionally, this tool determines if an Exchange 5.5 SMTP
address generator (from site addressing) contains the same invalid
characters that do not follow RFC 821. Exchange 2003 setup will run this
tool also as a part of setup, and will not proceed unless the Exchange 5.5 site
addressing is corrected, as invalid characters would cause problems with
recipient policies if replicated to Active Directory. OrgNameCheck logs

additional details into orgnamecheck.log.
Troubleshooting a hanging tool: Should a tool hang, you can control-break
and run exdeploy /t: <name_of_hanging_tool> from the command prompt.
Each execution of exdeploy will append to the exdeploy.log and exdeploy-
progress.log files. For a list of tool names, run exdeploy.exe without switches.
Troubleshooting a permissions issue: You may encounter an error message
warning that you may not be able to view hidden objects in the Exchange 5.5
directory. This is most often caused by lack of a trust and
organization/site/config-level permissions to Exchange 5.5 if it exists in a
Windows NT 4 domain.
Debugging anything else in exdeploy.exe: If a tool is reporting a problem
which you know to be false (for example, exdeploy.log says that the Exchange
5.5 server cannot be connected to, even though you can use LDP.exe to bind to
its LDAP port), you may enable debug logging by typing “set
DebugWalksDLL=1” at the command prompt. Output would look like the
following:
#*** Exdeploy began: 06/12/2003 15:39:29 ***#
+ Exchange 5.5 Server: rescon01:389
+ Global Catalog Server: resdc01
+ Tools run: DSScopeScan.

TestEXConnect - Open rescon01:389 failed error=-81
- Error: Could not connect to the Exchange 5.5 server
'rescon01:389'. Tools that require an Exchange 5.5 server will
not run.
TestNTConnect - Open resdc01 succeeded

Module 6: Deployment Tools and ADC Tools 19

In the output above, the entries “TestEXConnect” and “TestNTConnect” are the
result of the additional debug logging. Enabling this environment variable also
causes exdeploy.log to be produced with debug output whenever Exchange
2003 setup.exe calls upon the deployment tools glue DLL.

20 Module 6: Deployment Tools and ADC Tools


DCDiag/NetDiag


Following the DSScopeScan tool group, the installer is instructed to download
the Windows 2000/2003 support tool, dcdiag, or alternatively, install it from the
Windows server CD’s support tools. This utility comes in two operating
system-specific versions, and is used to search for Active directory-related
problems. This tool checks for a variety of domain controller issues, but most
importantly, it checks for any operations master role holders which cannot be
contacted.
Troubleshooting DCDiag:
If DCDiag fails to run due to a “DsIsMangledDnW error,” check to see if the
version of dcdiag.exe is compatible with the operating system. The file version
for the Windows 2003 DCDiag is 5.2.xxxx, whereas the Windows 2000 version
should be 5.0.xxxx.
If dcdiag reports that, for example, a schema role holder is not available,
forestprep will not be able to run. In this instance, one would utilize Q324801
or Q255504 to transfer or seize the role. Forestprep will also have problems if
DCDiag reports that a domain controller is not contactable, when in fact it has
been removed from the forest (but its metadata remained). In that scenario, one
would remove the orphaned domain or domain controller via q230306.
If there are any other errors output by DCDiag, one would run dcdiag with the

verbose (/v) switch for more details regarding the possible root cause.
Additionally, the /q switch suppresses non-problematic information, so you can
get to the meat of the failure quickly.
Netdiag follows DCDiag, and in the same manner, it examines various aspects
of the computer’s network configuration to determine if there are any errors.
Netdiag troubleshooting tip: Netdiag with the /q switch will suppress most
tests marked with “Pass,” which eases readability for failures. If netdiag
encounters a problem, the /fix switch may be used to resolve transient issues.
For example, if there is a negative cache issue that would eventually go away in
ten minutes, /fix would correct the issue sooner. However, hard configuration
problems – such as a misconfigured DNS server setting – cannot be fixed.
Module 6: Deployment Tools and ADC Tools 21


Running these tools would be useless if the customer does not review their
output, so following the execution of netdiag, dcdiag, and the dsscopescan tool
group, installers should search through the exdeploy.log, netdiag.log, and
dcdiag log files for any errors. These errors, along with their corrective
suggestive actions, are generally covered in the help file. However, there may
be instances where the help file does not log any errors. So engineers should
often ask themselves, “Does this output make sense?” For example, it is a fact
that any organization contains least one site and at least one server per site.
However, if the site or server count is zero, one may conclude that
DSConfigSum did not perform its task properly. In this instance, one would
also determine if there are more than 100 sites or 100 servers within a container.
(100 is the default number for reporting zero objects because that is the default
threshold for Exchange 5.5 directory service to enumerate a container via
LDAP.) If there are indeed containers with more than 100 objects (not counting
recipient subcontainers), one would reconfigure the Exchange 5.5 LDAP
protocol’s search limit above 100.

Forestprep/Domainprep
The next steps are for the user to run setup /forestprep and /domainprep.
Traditionally, these switches were executed only from the command prompt.
The exdeploy.chm now includes an embedded script to launch these modes
from the ActiveX® control, provided that the path is populated correctly.
Running the help file from a file share or a path that contains a space will most
likely output an Internet Explorer popup saying “An invalid server name was
entered.” For this reason, the HTA is used to run the CHM file to slightly alter
the behavior.
22 Module 6: Deployment Tools and ADC Tools


OrgPrepCheck


Once these actions are completed, the user is prompted to run the
OrgPrepCheck tool group - comprised of the following tools:
 OrgCheck: verifies the Exchange extensions to the Active Directory
schema, checks the existence and membership of the Exchange Domain
Servers group and Exchange Enterprise servers group, and checks that a
global catalog server is available in a domain in which DomainPrep has
been run. There is no additional logfile.
 PolCheck: This exdeploy command simply runs a Createprocess to launch
policycheck.exe (inherited from the support directory of the Exchange 2000
CD). PolCheck will determine if the Exchange Enterprise Servers group has
been granted the SeSecurityPrivilege (a.k.a. “Manage Auditing and Security
Logs”). Effectively, this determines if the domainprep procedure has
completed successfully, and ample time has been given for this right to
propagate to the domain controllers of the present domain. The extended
output of all domain controllers rights will be logged to exdeploy-

polcheck.log, and will appear similar to the following:
Module 6: Deployment Tools and ADC Tools 23


[17:43:01] #*** Policy Check began: 01/08/2003 17:43:01 ***#
[17:43:03] Entering HrMapFileHandle
[17:43:03] Leaving HrMapFileHandle
[17:43:03] PolicyTest.exe results:

This tool will check every domain controller in the local
domain to see if the "Manage auditing and security logs"
privilege granted to the "Exchange Enterprise Servers"
group by DomainPrep has replicated to that DC. If the
policy change has not yet replicated to all DCs, then
you should avoid making policy changes on any DC that
has not received those changes yet.

You must have Domain Admin rights to run this tool
successfully. If you see an error that says:
!! LsaEnumerateAccountRights returned error 5 !!
then you don't have permission to open the LSA on the
given DC.


===============================================
Local domain is "ti.vm" (TI)
Account is "TI\Exchange Enterprise Servers"
========================
DC = "TINETDC"
In site = "Default-First-Site-Name"

Right found: "SeSecurityPrivilege"
[17:43:03] Entering HrFindPrintErrorMessage
[17:43:03] Leaving HrFindPrintErrorMessage
[17:43:03] PolCheck completed successfully.
[17:43:03] #*** Policy Check finished: ***#

Install Active Directory Connector and Run ADC Tools
The next step in the deployment process is for the deployment
administrator/consultant to install the Exchange 2003 ADC Service, and then
use the ADC tools to prepare for and then create connection agreements. The
ADC Tools process is somewhat lengthy, so we will discuss its internals in
more detail in Lesson 2. At this point, it is only important to note that when the
installer completes the second or last step of the ADC Tools, completion
markers are written to Active Directory. These markers, though hidden from the
user, are read by the setup engine later in the deployment process to determine
whether the proper preparatory steps have been accomplished. If the installer
does not complete the second or last steps of the ADC Tools, the completion
marker will not exist and setup will block installation into an Exchange 5.5 site.