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

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

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

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

Prerequisites

1) Experience with installing Exchange 2000 into Exchange 5.5 sites 2) Prior usage of Virtual PC or Virtual Server

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

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:

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.”

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:

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

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

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

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

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

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

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

Troubleshooting Tip

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

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 making step where customers can identify in which of these four scenarios they reside

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

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

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

„ 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

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

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

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

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:

[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

[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

Process Flow

SetupPrep

Setupprep is the next tool that the exdeploy.chm runs, although it is not actually

a tool group that can be run from exdeploy.exe When the user runs SetupPrep, the CHM file silently launches exdeploy.exe with the /t: OrgNameCheck, OrgCheck, and PubFoldCheck switches The first two tools are redundant, and

do not serve any additional purpose since they were run previously The last tool, PubFoldCheck, is significant in that it performs the same operation as the DS/IS Consistency Adjuster against the public information store This resolves potential issues with “zombie users” causing public folder accessibility and performance problems previously seen in Exchange 2000 deployments into Exchange 5.5 sites Article 309788 contains information about this problem The DS/IS Consistency Adjuster options performed by pubfoldcheck are

„ Remove unknown user accounts from public folder permissions:

PubFoldCheck removes users that are no longer valid from public folder permissions

„ Inconsistencies more than 1 day: PubFoldercheck performs the above actions for only inconsistencies that are older than one day

Although the help file may indicate the opposite, the code in PubfoldCheck will not use the DS/IS option to rehome public folders because of the possibility causing replication storms, thereby causing a support call-generator The helpfile text, though incorrect on the release CD, will be fixed in the web-release version of the Exdeploy package

Run Server Setup

At this stage, the user needs to run setup to install Exchange 2003 Since setup detects that this is the first server being installed into Active Directory, it displays the “installation type” screen This screen asks whether a new Exchange organization is being created, or if the installer is joining an Exchange 5.5 org The latter option needs to be selected for the “Coexistence with Exchange 5.5” scenario In the next screen, the user is prompted to enter the Exchange 5.5 server name As soon as the Exchange 5.5 server name is passed to the setup engine, setup.exe will pop up a message indicating that it is

testing “prerequisite conditions.” In the background, setup makes several calls into the deployment tools wrapper/glue DLL for pass/fail-type results against the Exchange 5.5 directory and Active Directory The Exchange server setup progress.log file will contain entries similar to the following:

[00:09:57] Entering HrDirPreReq_Initialize [00:09:57] Init called with Domain Controller Z2 and Exchange 5.5 server z0:389 Setup's language ID is 1033 ActiveX Path

is (null) [00:09:57] Entering HrRegisterAXDLL [00:09:58] Leaving HrRegisterAXDLL [00:09:58] Leaving HrDirPreReq_Initialize [00:09:58] Entering HrDirPreReq_Test [00:09:58] Entering HrDirPreReq_ConfigInit [00:10:31] Leaving HrDirPreReq_ConfigInit [00:10:31] Entering HrDirPreReq_UserInit [00:11:04] Leaving HrDirPreReq_UserInit [00:11:04] Entering HrDirPreReq_ObjectInit [00:11:52] Leaving HrDirPreReq_ObjectInit [00:11:52] Entering HrDirPreReq_CheckOrgAndSiteNames [00:11:52] Leaving HrDirPreReq_CheckOrgAndSiteNames [00:11:52] Entering HrDirPreReq_OrgCheck

[00:11:52] Leaving HrDirPreReq_OrgCheck [00:11:52]

[00:11:52] Entering HrDirPreReq_ADCUserCheck [00:11:52] Leaving HrDirPreReq_ADCUserCheck [00:11:52] HrDirPreReq_Test

(f:\df6900\dsa\src\deploy\dsintegchk\dsintegchk.cpp:2003) Error code 0X00000001(1)

[00:11:52] Entering HrDirPreReq_ADCObjectCheck [00:11:52] Leaving HrDirPreReq_ADCObjectCheck [00:11:52] HrDirPreReq_Test

(f:\df6900\dsa\src\deploy\dsintegchk\dsintegchk.cpp:2062) Error code 0X00000001(1)

[00:11:52] Warning: ADCObjectCheck detected that some objects were not replicated from the Exchange 5.5 directory to Active Directory

[00:11:52] Looking for Public Folder DS/IS Consistency Check status marker

[00:11:52] Entering HrDirPreReq_GetSiteName [00:12:08] Leaving HrDirPreReq_GetSiteName [00:12:08] Entering HrDirPreReq_CheckMarker [00:12:08] Leaving HrDirPreReq_CheckMarker [00:12:08] PublicFolderCheck-HubSite was last run 120 minutes ago The value returned was 0

[00:12:08] Finished looking for Public Folder DS/IS Consistency Check status marker

[00:12:08] Some tests returned failure or warning, but the prereqs passed overall Returning 1 warning string(s) [00:12:08] Message 0: Warning: ADC Tools detected that some users were not replicated from the Exchange 5.5 directory to Active Directory

[00:12:08] Leaving HrDirPreReq_Test [00:12:08] Entering HrDirPreReq_Terminate [00:12:08] Leaving HrDirPreReq_Terminate

In the above sample output, the ADCUserCheck marker exists, but not all of the objects have been replicated between Exchange 5.5 and Active Directory (determined by the trailing flag within the ADCUserCheck value) So if any completion marker (ADCUserCheck in this case) contains a trailing “1” flag at the end of the value (for example, ADCUserCheck;2003003282359;1) the “1”

value signifies that a tool detected an error, so setup will only warn the user about out-of-sync directories, as shown in figure 1.7:

Figure 1.7: Setup shows the result of its calls upon the deployment tools, or the result from a deployment tool’s completion marker in Active Directory

In the above figure, setup warns the user of unreplicated objects, but it does not prevent setup from continuing So after being warned, the customer may continue with setup, and subsequently install Exchange 2003 and the Site Replication Service If the flag was set to 0, there would be no warning

However, if the ADCUserCheck marker does not exist, setup will block itself from continuing, as shown by the blocking message in figure 1.8:

Figure 1.8: Blocking message if ADC Tools have not been executed

Simultaneously, the following text would be logged to the progress.log:

exdeploy-[08:30:28] HrDirPreReq_Test is failing Returning 1 warning

or error string(s) [08:30:28] Message 0: Error: ADC Tools were not run in your organization

[08:30:28] Leaving HrDirPreReq_Test [08:30:28] Entering HrDirPreReq_Terminate [08:30:28] Leaving HrDirPreReq_Terminate

Pointing connection agreements to the Site Replication Service

After setup completes, reconfiguring connection agreements is mentioned as the next step in the deployment tools Although this step is not necessary for small environments, it is good practice to point all of the recipient connection agreements for the upgraded site to the site replication service once it has been created The benefit is realized when pure Exchange 2000/2003 admin groups are created, whose objects can only be replicated to Site Replication Services (see KB article Q291170)

Validation Tools

Validation Tools

These are a series of tools used to check on the success of the server installation The output of these tests should give customers a better idea of what problems exist that are not normally seen by any existing GUI administration tool

ADCConfigCheck – verifies that the config Connection Agreement (created during setup) properly replicated server objects, connector objects, store objects, etc from the Exchange 5.5 directory to Active Directory If there are any inconsistencies, unsynchronized system objects are enumerated in adcconfigcheck.log and exdeploy.log A sample adcconfigcheck.log output would look like this:

Error: Configuration object 'cn=Internet Mail Connector (Z0),cn=Connections,cn=Configuration,ou=HubSite,o=Microsoft' has not replicated to Active Directory

Troubleshooting ADCConfigCheck: If any errors are reported at this point,

ensure that the config Connection Agreement is replicating By default, its endpoints are the Site Replication Service and a global catalog, so ensure that the fully-qualified domain names (FQDNs) of these servers haven’t been tampered with on the Connection Agreement properties Check name resolution, since the new kerberos authentication functionality demands proper DNS resolution If you are unsure of the Configuration Connection

Agreement’s ability to be replicated by the ADC service, restart the ADC service and check for events suggesting that the config Connection Agreement has been misconfigured, or events mentioning a protocol error (event 8026)

ConfigDSInteg – Ported from E2kDSInteg from the previous Exchange 2000

SP2 support tool, ConfigDSInteg checks the health of Active Directory after Exchange 2003 setup and ADC have made directory modifications This tool generates a simple report in e2kdsinteg.log that documents anomalies or suspect

objects E2kdsinteg does not make changes to any objects in Active Directory Depending on the number of mail-enabled objects and configuration objects in Active Directory, it may take a substantial period of time to process the mail-enabled objects for any of the following issues:

„ Public mailbox database contains no home message transfer agent (MTA)

„ Public mailbox database contains no Exchange 5.5 distinguished name

„ Public mailbox database does not belong to an existing top-level hierarchy

„ Public mailbox database does not contain an owning server

„ Public mailbox database contains no proxy addresses

„ Public mailbox database contains no primary SMTP address

„ Public mailbox database contains no primary X.400 address

„ Public mailbox database contains an ambiguous Exchange 5.5 distinguished name

„ Private mailbox database contains no Exchange 5.5 distinguished name

„ Private mailbox database is not linked to a corresponding public mailbox database

„ Private mailbox database does not have a corresponding gateway object in Active Directory

„ Private mailbox database contains an ambiguous Exchange 5.5 distinguished name

„ MTA contains duplicate Exchange 5.5 distinguished name

„ MTA contains an ambiguous Exchange 5.5 distinguished name

„ Site Replication Service contains no proxy addresses

„ Site Replication Service contains no primary SMTP address

„ Site Replication Service contains no primary X.400 address

„ Site Replication Service contains no home mailbox database

„ Site Replication Service contains no home MTA

„ Site Replication Service contains no Exchange 5.5 distinguished name

„ Site Replication Service has duplicate Exchange 5.5 distinguished name

„ System attendant contains no proxy addresses

„ System attendant contains no primary SMTP address

„ System attendant contains no primary X.400 address

„ System attendant contains no home mailbox database

„ System attendant contains no home MTA

„ System attendant contains no Exchange 5.5 distinguished name

„ System attendant contains an ambiguous Exchange 5.5 distinguished name

„ Exchange server does not belong to a routing group

„ Exchange server does not have a responsible MTA server

„ Exchange server contains no Exchange 5.5 distinguished name

„ Exchange server contains an ambiguous Exchange 5.5 distinguished name

„ Recipient policy does not contain an associated administrative group

„ Recipient Update Service contains no globally unique identifier (GUID) to the Exchange Enterprise Servers group

„ Recipient Update Service contains no security identifier (SID) to the Exchange Enterprise Servers group

„ Recipient Update Service contains no GUID to the Exchange Domain Servers group

„ Recipient Update Service contains no SID to the Exchange Domain Servers group

„ GWART contains no relative ID (RID) operations master

„ Connector contains no home mailbox database

„ The GUID in the name of this object does not reference a valid mailbox database

„ MAIL_GATEWAY Object is mailbox enabled and contains no home MTA

„ Connector contains no Exchange 5.5 distinguished name

„ Connector contains an ambiguous Exchange 5.5 distinguished name

„ Object is of unknown type

RecipientDSInteg – ported from E2kDSInteg in Exchange 2000 SP2, this

utility complements ConfigDSInteg in that it checks for the status of suspicious mail-enabled group, user, or contact objects that might have potential problems, such as missing proxy addresses, no homeservername, etc Even on existing Exchange 2000 server organizations, this tool is useful in finding these hidden problems that would have otherwise gone unnoticed:

„ User is both mail enabled and mailbox enabled

„ User is mailbox enabled and contains no home mailbox database

„ User is mailbox enabled and contains no home message transfer agent

„ User is mailbox enabled and contains no home server name

„ User is mailbox enabled and contains no mailbox GUID

„ User is mailbox enabled and does not contain an account control

„ User contains no Exchange 5.5 distinguished name

„ User contains no proxy addresses

„ User contains no primary SMTP address

„ User contains no primary X.400 address

„ User is not hidden and does not belong to an address list

„ Disabled User is mailbox enabled and does not contain an associated external account

„ (For a user object) Keyword "ntdsnomatch" could not be found within any extension attribute

„ User contains an ambiguous Exchange 5.5 distinguished name

„ User contains an ambiguous mailbox GUID

„ User contains an ambiguous master account SID

„ Group contains no Exchange 5.5 distinguished name

„ Group contains no proxy addresses

„ Group contains no primary SMTP address

„ Group contains no primary X.400 address

„ Group is not hidden and does not belong to an address list

„ Group contains an ambiguous Exchange 5.5 distinguished name

„ Contact contains no Exchange 5.5 distinguished name

„ Contact contains no proxy addresses

„ Contact contains no primary SMTP address

„ Contact contains no primary X.400 address

„ Contact is not hidden and does not belong to an address list

„ Contact does not contain a target address

„ Contact contains an ambiguous Exchange 5.5 distinguished name

„ Public folder contains no Exchange 5.5 distinguished name

„ Public folder contains no proxy addresses

„ Public folder contains no primary SMTP address

„ Public folder contains no primary X.400 address

„ Public folder is not hidden and does not belong to an address list

„ Public folder does not contain a target address

„ Public folder contains no home mailbox database

„ Public folder contains an ambiguous Exchange 5.5 distinguished name

„ Object is of unknown type

PrivFoldCheck – This tool performs a DS/IS against the Exchange 5.5 private

information store Like PubFoldCheck, it removes zombie entries from access control lists (ACLs) to prevent performance issues when the mailboxes are moved to Exchange 2003 Output is appended to exdeploy.log

Post-installation steps

The process flow for the Exchange 5.5 coexistence scenario ends after privfoldcheck, but the installer has several additional tasks if the project plan involves migration Per figure 1.6, exdeploy.chm provides an optional path for deploying an additional server installation This additional path does not introduce new steps from the first server installation, so its details will not be discussed here Afterwards, exdeploy.chm leads towards the post-installation steps, which discuss moving mailboxes from Exchange 5.5 to Exchange 2003, using pfmigrate to rehome public folders from 5.5, optimizing memory usage, using the Internet mail wizard, configuring remote procedure call (RPC) over HTTP, and subscribing to Microsoft security bulletins Among that list, the only new admin component feature from Exchange 2000 that is not covered in any other training module is PFMigrate, which is used for migrating public folder and system folder content

PFMigrate

Once customers have moved mailboxes from Exchange 5.5 to Exchange 2003, exdeploy.chm will instruct customers to move their public folders to the new Exchange 2003 server Pfmigrate.wsf is used to automatically update the hierarchy by programmatically changing replica settings of all public folders that are homed on any source server (Exchange 5.5 SP3 or later)

This is a script that was developed because the administrative process for rehoming public folders through Exchange System Manager is not clearly spelled out in steps, and customers administering thousands of public folders would have a frustrating migration experience by repetitively clicking through the UI

Nevertheless, PFMigrate is not absolutely necessary, so customers may opt not

to use the script Instead, they may propagate the public/system folder replica list within the Exchange 5.5 admin.exe UI (Q185043) or Exchange System Manager (Q288150)

Usage: PFMigrate cannot be launched from the exdeploy help file Instead, it is

used from the command prompt with the following syntax:

pfMigrate.wsf /S:<source server> /T:<target server>

[/WMI:<server>] [/N:<number of public folders>] [/A] [/D] [/R] [/F<log file path>] [/NNTP] [/Y] [/SYNC] [/SF]

The tool will work by connecting to an Exchange 2003 Windows Management Instrumentation (WMI) server (Exchange 2000 does not have the necessary WMI monitoring interfaces.) The Target and Source servers must be at least Exchange 5.5 SP3 Lastly, the tool only works with the MAPI public folder hierarchy (Anything underneath “Public Folders” object in Exchange System Manager) It does not touch application public folder trees The command line options are explained in this list:

S: Name of the Exchange server where folders are currently replicated Only Folders with SOURCE on the replica list will

be affected

T: Name of the Exchange server where folders will be replicated to Only folders without TARGET on the replica list will be affected

WMI: Name of the Exchange 2003 server that will provide WMI services If not specified, the local machine will be used N: Number of public folders to modify This option limits the number of public folders updated by the script If not specified, all affected folders will be updated This is required in Add mode but optional in Delete mode

A: Adds the TARGET server to the replica list of folders where the SOURCE server is also a replica

D: Deletes the SOURCE server from the replica list of folders where the TARGET server is also a replica

R: Run a report on the current status of the SOURCE server

NOTE: /A, /D and /R cannot be specified together

F: File where log information should be appended If not specified the default is pfmigrate.log in the current

SYNC: Executes the WMI query in synchronous mode

SF: Migrate System Folders: ‘Offline Address Book’,

‘Eforms Registry’ and ‘Schedule+ Free Busy’

For example, the following command line execution of pfmigrate will add up to

4000 public folder replicas to a server called “tinetdc” and a report is generated

in the “mypfs.txt” file:

>pfmigrate.wsf /S:ozpdc /T:tinetdc /n:4000 /a /f:mypfs.txt

After running the above command twice (appending the /sf switch on the second iteration), here is what will be logged to the output file:

Microsoft Exchange Public Folder Migration Tool Mon Jan 20 17:31:21 EST 2003

Source Server: OZPDC Version 5.5 (Build 2653.23: Service Pack 4)

Target Server: TINETDC Version 6.5 (Build 6803.8) WMI Server: TINETDC

Add Replica Mode in progress

Analysis of 4 folders with replica on 'OZPDC' completed

3 folders without replica on 'TINETDC'

The analysis was limited by the /n parameter

Adding 'TINETDC' to the replica list of the following 3 folders:

/PF-DeletedAccountOwner/

/PF-DL-ACLd/

/e55user1-PF/

3 folders updated successfully

Mon Jan 20 17:31:38 EST 2003 - -

Microsoft Exchange Public Folder Migration Tool Mon Jan 20 17:32:56 EST 2003

Source Server: OZPDC Version 5.5 (Build 2653.23: Service Pack 4)

Target Server: TINETDC Version 6.5 (Build 6803.8) WMI Server: TINETDC

Add Replica Mode in progress

Analyzing system folders under 'OFFLINE ADDRESS BOOK' Analysis of 2 folders with replica on 'OZPDC' completed Analyzing system folders under 'EFORMS REGISTRY'

Analysis of 0 folders with replica on 'OZPDC' completed Analyzing system folders under 'SCHEDULE+ FREE BUSY' Analysis of 1 folders with replica on 'OZPDC' completed

1 folders without replica on 'TINETDC'

The analysis was limited by the /n parameter

Adding 'TINETDC' to the replica list of the following 1 folders:

/NON_IPM_SUBTREE/OFFLINE ADDRESS BOOK/EX:/o=MSFT/ou=EMS/OAB Version 2/

1 folders updated successfully

Mon Jan 20 17:33:12 EST 2003 -

After the pfmigrate script finishes, customers will tend to open the report file immediately However, it is possible for them to see no progress in the report, and they might not see any changes to the Exchange 5.5 replica list because of latency in the scripting engine Because the pfmigrate report lags behind the actual processing, customers should be patient with the utility until the above text is logged

What PFMigrate does when adding replicas:

1 Verify there is a WMI server specified

2 Verify the servers are in the same site (or Routing Group), if not, you will see the fail string: “The Microsoft Exchange Public Folder Migration Tool only works when the source server and the target server are in the same routing group.”

3 Find the folders (via WMI, not using Active Directory) in the public folder store on the source server where the target server is not in the replica list

4 Verify that there is a MAPI Public folder store on the Target Server and the Source Server Otherwise, you will receive this string: “The Microsoft Exchange Public Folder Migration Tool only works with MAPI Public Folder stores There must be a MAPI Public Folder store on both servers specified in the /s: and /t: parameters.”

5 Add the target server to the replica list

a Do not remove ANY servers from the replica list

6 Output the display name of the folder to the screen (and the log)

7 See if we have modified the input number of folders

a If not, modify the next folder

b If so, output the completion strings to the screen (and the log)

8 If in 5a no more folders can be found, output the completion strings to the screen (and the log)

Steps for PFMigrate to delete replicas

1 Run a report (/R switch) to make sure that the source and target have the same number of public folders (to indicate that replica list has finished replicating)

2 Prompt the user with a confirmation string to see if they really want to run delete mode

String: “Are you sure you want to want to remove %SourceServer% from the replica list? yes/no”

3 Verify there is a WMI Server

4 Verify that there is a MAPI Public Folder tree on the Target Server and the Source Server

Note

a Error string; “The Microsoft Exchange Public Folder Migration Tool only works with MAPI Public Folder stores There must be a MAPI Public Folder store on both servers specified in the /s: and /t:

parameters.”

5 Find the folders in the public folder store on the source server where the source server and the target server are in the replica list

6 Remove the source server from the replica list

Do not remove any other servers from the replica list

7 Output the display name to the screen (and the log)

8 Move on to the next folder

9 Run the report mode and show results The Exchange 5.5 server actually retains the data from the removed replica until the nightly Information Services (IS) maintenance window runs, typically starting at 1:00 A.M Therefore, even on a barely-used server, public and system folders may take hours to be removed, even after the script returns control to the command prompt

Note