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
Không có nhận xét nào:
Đăng nhận xét