Tài liệu Module 1: Setup Changes pdf

Setup Action Active Directory Permissions required Install first Exchange 2003 server in a domain Exchange Full Administrator at Organization level Install first Exchange 2003 server in

Contents

Document Overview 1

Setup Changes 2

Setup Architectural Changes 3

Setup Actions Require New Active Directory Permissions 7

New Setup Prerequisite Checks: 21

Lab 1.1: Finding renamed, moved, or deleted groups 26

Cluster-related prerequisite checks 31

Exchange System Manager-only installation prerequisites 33

2000 to 2003 Setup and Upgrade Scenarios blocked 36

New Features/Components in Setup: 39

Setup Changes 44

Security improvements to setup: 49

Troubleshooting Exchange Server 2003 setup failures: 53

General Log Flow 57

Lab 1.2: Logparser and examination of progress logs 68

Lab 1.3: Applying troubleshooting concepts 70

Appendix A: Answers 74

Acknowledgments 76

Module 1: Setup Changes

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

Document Overview

This module discusses differences in the setup process between Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003 In addition to discussing bug-level changes, students will focus on troubleshooting the Exchange Server setup progress logs

Topic 1 Setup changes from Exchange 2000 Server Topic 2 Troubleshooting Exchange Server 2003 setup Topic 3 Learning measure/Labs

Prerequisites

„ Experience with installing Exchange 2000 into Exchange Server 5.5 sites

„ Experience with creating an Exchange Virtual Server (EVS) on Windows

2000 clusters

Setup Changes

This topic discusses differences between the setup architecture from the last product, as well as new features and work items in the setup process Those accustomed to supporting Exchange 2000 Server will expect some of the same product features and behaviors to exist in Exchange 2003 The goal of this topic

is to cover any “gotchas” in differences between the two products that would otherwise cause difficulty in support

Setup Architectural Changes

In Exchange Server 5.5, many customers established administration models so that Exchange administrators were able to administer only Exchange, and domain administrators handled almost everything else Yet Exchange 2000 Server required the installer to be given blanket permissions to the enterprise forest and the Exchange Server 5.5 directory – to the dismay of many companies migrating from, or coexisting with, Exchange Server 5.5 In order to separate these roles once more, the product group established the following

“Full Administrative Group Administrator” setup changes so that network/domain admin roles could be separated from Exchange administrator roles These changes were so extensive that the process flow of setup is nearly re-architected

Setup /forestprep creates a placeholder object

When Exchange 2003 setup is run explicitly in ForestPrep mode (using the

/forestprep switch), and there is no existing Exchange organizational object

within the configuration naming context, setup will create a “temporary”

organization with a hard-coded name (That name is a GUID: 5131-4D45-BE3E-3C6C7F76F5EC}”.) Setup can delegate the first Exchange administrator on this object, create the Exchange configuration underneath it, and so on At a later time, when setup is run to install the first server in the organization – by someone who is an Exchange administrator – setup can rename the existing placeholder object, either to a user-specified name or to match the name of an Exchange 5.5 organization The final naming is decided

“{335A1087-by the answer to the “Installation Type” screen Improving upon Exchange

2000 setup, the organization name deferral was designed so that

• Administrators are not forced to make the organization name decision during forestprep

• Enterprise/schema admins are not forced to be given Exchange Server 5.5 admin site permissions to run forestprep

Conversely, Exchange 2003 installers (who are admins of an Exchange 5.5 site) are not required to have enterprise/schema admin permissions when later installing the first Exchange Server 2003 machine Installers are also no longer

required to have the Active Directory Connector (ADC) installed when running forestprep

Troubleshooting temporary org object creation: Should there be any problems

creating this GUID, it will most likely be a permissions issue, caught at the requisite stage with a descriptive error message If this is the case, one should

pre-ensure that the logged-on user has full control privileges on the cn=Microsoft Exchange,cn=services,cn=configuration,dc=<forest root DN> container (By

default, Enterprise Admins has this permission) Although it is possible to manually-create the temporary org object, it is neither recommended nor supported since it would also require manually creating scores of child objects and setting their permissions appropriately

“Installation Type” prompt moves to server setup mode

In Exchange 2000 Server, running setup with the /forestprep switch whilst in a clean forest (where there is no Exchange organization object) would always prompt the installer with the “Installation Type” screen This page of the setup wizard would ask if a new Exchange organization needed to be created or if setup should join an existing Exchange 5.5 organization Therefore, Exchange

2000 setup /forestprep not only extended the schema; for the 5.5-joining case, it would also connect and perform intensive sync operations (via a temporary config CA) with the Exchange 5.5 directory This is why with Exchange 2000 setup, the platinum-osmium synchronizer ran twice: once during explicit forestprep and again during normal server setup (The exception is if only setup.exe is run without switches, thereby setting the forestprep component to

“Install” mode so that the platinum-osmium synchronizer runs only once.)

Figure 1.1: The “Installation Type” prompt is no longer shown during /forestprep mode

In Exchange Server 2003, the “Installation Type” prompt has moved to the server setup mode That is, the prompt will only occur when running setup.exe without switches, and it will only occur once: when the first Exchange Server

2003 machine is being installed into a forest with no pre-existing Exchange organization object (The Exchange organization object is located at (cn=<orgname>,cn=Microsoft Exchange, cn=services, cn=configuration, dc=<dn of the forest root>.) If the installer chooses to create a new organization, the placeholder orgname is renamed to whatever the installer desires If the installer chooses the Exchange 5.5 coexistence option, the temporary orgname is renamed to match the Exchange 5.5 organization name

In Exchange Server 2003, the 5.5 (Osmium) synchronization process with Active Directory will occur only once, so only a permanent config CA comes into existence (i.e no temporary config CA will exist) Table 1.1 outlines the different states of the organizational object that can exist in Active Directory:

Setup Action/

Detected State setup /ForestPrep setup (install a server)

No organization object

Create temporary org

Ask user for org type/name;

create org Temporary

organization object

3C6C7F76F5EC}

{335A1087-5131-4D45-BE3E-N/A Ask user for org

type/name;

rename temporary org

Named organization object (exists in place of GUID)

N/A N/A

Table 1.1: Creation flow for Exchange Organization object in Active Directory

This architectural change does not affect manual creation of first Administrative Group through System Manager (per 215930) However, when customers launch Exchange System Manager to manually create their administrative group, they might be surprised to see the GUID, {335A1087-5131-4D45-BE3E-3C6C7F76F5EC}

Note: When the temporary organization object exists, you must not run

Exchange 2000 Server setup Although it does not get blocked through a requisite check, later in the setup process the Exchange 2000 Server setup wizard does not understand the GUID organization object, and the installation

pre-is likely to fail catastrophically

Server Setup mode no longer stamps organization-level permissions

Previously, the Exchange 2000 Server SETUP program would re-stamp Exchange Organization permissions on each server install The drawback was that this action would overwrite any custom changes to the permissions structure, such as removing the permission for all users to create top level public folders So if a customer kept having his/her top-level permissions reset, this was a perceived security risk

In Exchange Server 2003, the setup process has changed so that it will only stamp default permissions on the Exchange Organization object once (on the first server install/upgrade) and will not re-stamp permissions for subsequent installations Although this resolves the workaround for security, the previous behavior was a useful support tool for quickly fixing customers who have inappropriately modified their Active Directory permissions on containers that cause operational problems in Exchange A typical problem would be a paranoid administrator removing required access control lists (ACLs) on various objects underneath the “Microsoft Exchange” container So in order to

Setup Actions Require New Active Directory Permissions

Because there are several setup modes and component options, setup will require different combinations of Active Directory permissions, depending upon the detected topology For example, setup operations dealing with a Site Replication Service (SRS) still require Exchange Full Administrator at the Organization level Table 1.2 outlines the required permissions of the person being logged on

Setup Action Active Directory Permission(s) required

Install first Exchange 2003 server in a domain Exchange Full Administrator at Organization level

Install first Exchange 2003 server into a 5.5 site

(SRS-enable) Exchange Full Administrator at Organization level

Uninstall/reinstall Exchange 2003 with an SRS Exchange Full Administrator at Organization level

First “ForestPrep” in forest [with schema update] or

ADC’s Setup when older schema is detected or

ADC’s setup used with the explicit “schemaonly” switch

Enterprise Admin [+ Schema Admin]

Subsequent “ForestPrep” Exchange Full Administrator at Organization level

Install a server to have first instance of a

Groupwise/Lotus Notes connector Exchange Full Administrator at Organization level

Install, maintain or remove server containing Key

Management Server Enterprise Admin

Install, maintain or remove server with SRS enabled Exchange Full Administrator at Organization level

Install additional server (non-SRSs, clusters EVSs) Exchange Full Administrator at Admin Group level +

machine account added to Domain Servers group Run maintenance mode on any server (except Key

Management Server or SRS enabled) Exchange Full Administrator at Admin Group level

Remove a server (no SRS present) Exchange Full Administrator at Admin Group level +

remove machine account from Domain Servers group

after setup Remove last server in org Exchange Full Administrator at Organization level Apply service pack Exchange Administrator at Admin Group level

Table 1.2: Setup Matrix

Several of the above actions require “Exchange Full Administrator” at the organizational level Although it is possible to manually create and grant Exchange Administrator-like permissions through ADSI Edit, it is not recommended because the specific combination of permissions and inherited rights settings are not easy to set, and setting “Full Control” on the organization object would be overkill The recommended methods for granting Exchange Full Administrator at the org level are to either:

„ Rerun /forestprep so that the Exchange setup wizard will prompt for an additional account to be granted Org permissions, or

„ Use the Exchange System Manager’s delegation wizard by right-clicking on the top-most organization object

The proper method of granting Exchange Full Administrator at the Admin Group level is to launch Exchange System Manager’s delegation wizard by right-clicking on an Administrative Group name

In Exchange 2000, you needed to be a full admin at the organization level to install, maintain, or remove any server Unfortunately, customers desired to deploy with well-separated admin groups and delegate administrators on those administrative groups who would be able to handle routine tasks like installing and maintaining servers (This had been the 5.5 model, of course.) Many efforts from our customer experience team and customers, themselves, expended considerable ingenuity in trying to find ways to work around this requirement in Exchange 2000 setup, but all in vain even if you managed to bypass the permission prerequisite, setup would still fail, since it refreshed org-level settings and permissions during every server install; and without org-level rights, you wouldn't have access to those objects

In Exchange 2003, full admin-group level admins can now install, maintain, and remove most servers within their own administrative group However, there are still exceptions: You still need full org admin permissions when installing the SRS or first Exchange 2003 server into a domain In the latter case, the first server installed into any given domain must set the access control entries (ACEs) for that domain’s "Exchange Domain Servers" group on the org-level object, which means that setup needs full org permissions

New Per-Object Permissions Changes During Setup:

In addition to new permissions requirements, Exchange 2003 setup modifies Access Control Entries that were set by Exchange 2000 Tables 1.5-1.6 describe these Active Directory object-level access control list (ACL) changes, and tables 1.7-1.8 describe the NTFS-ACL changes However, interpreting the tables requires a key:

Key to Reading the tables

Permissions that are listed in the tables with a double strike-through are removed by Exchange 2003 setup They represent permissions that were set in Exchange 2000, but which have since been deprecated from the security model Each table begins with the distinguished name (also known as DN) of the object

it applies to After that, the table lists when the right is stamped: during the ForestPrep phase, while installing a server, etc

In some cases, the ACL is not stamped on the usual property (ntSecurityDescriptor), but on some other property – e.g.,

“msExchMailboxSecurityDescriptor” The directory service, of course, cannot enforce security that is not specified in the NT security descriptor; in most cases, these ACLs will be picked up and replicated to store ACLs on appropriate objects by the store service There is, unfortunately, no tool for viewing these ACLs as anything other than raw binary data

The columns of the table are as follows:

Account The security principal granted or denied the

permissions

A Checked if this is an allow ACE

D Checked if this is a deny ACE Allow and Deny are

mutually exclusive

I Checked if this ACE inherits to child objects

Right The permissions allowed or denied Extended rights are

given in italics

On Property/Applies To In some cases, the permission applies only to a given

property, property set, or object class; if so, that is specified here

Reason The reason this permission is required

Table 1.3: Legend for columns of charts 1.5-1.9

The rights are generally listed in the table by the names used on the ADSIEdit Security property page, under the “Advanced” view, on the “View/Edit” tab The ADSIEdit Security property page lists a much more condensed view of the rights LDP.exe displays the access mask directly, as a numerical value The setup code refers to the rights by predefined constants

The following table summarizes the relationships between these values:

ADSIEdit Advanced Page,

Binary value

ADSIEdit Summary Page

View/Edit Tab

#define

(“Mask” in LDP)

WRITE_OWNER | WRITE_DAC | READ_CONTROL | DELETE |

ACTRL_DS_CONTROL_ACCESS | ACTRL_DS_LIST_OBJECT | ACTRL_DS_DELETE_TREE | ACTRL_DS_WRITE_PROP | ACTRL_DS_READ_PROP | ACTRL_DS_SELF | ACTRL_DS_LIST | ACTRL_DS_DELETE_CHILD |

Full Control

Full Control

ACTRL_DS_CREATE_CHILD

0x000F01FF

List Contents +

ACTRL_DS_LIST |

Read All Properties +

ACTRL_DS_READ_PROP | Read

Read Permissions

READ_CONTROL

0x00020014

Write All Properties +

ACTRL_DS_WRITE_PROP | Write

All Validated Writes

Writes All

Extended Rights

ACTRL_DS_CONTROL_ACCESS 0x00000100

Create All Child Objects

Create All Child Objects

ACTRL_DS_CREATE_CHILD 0x00000001

Delete All Child Objects

Delete All Child Objects

ACTRL_DS_DELETE_CHILD 0x00000002

ACTRL_DS_LIST_OBJECT 0x00000080

Table 1.4: Bit values for tables Permissions Modified On Active Directory Objects in the

Configuration Naming Context

Microsoft Exchange Container

cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=<domain>

Account A D I Right On Property/Applies To Reason

During ForestPrep phase

List Contents Authenticated Users X

Read All Properties

to read Full Org Admins Designated Admin Account X X Full Control Allow Full Org

Admin to administer org

During server install

Read Permissions Read All Properties Exchange Domain Servers X X

List Contents

servers to read config info

During ADC setup

Exchange Services X X Full Control Allow ADC servers

to create/delete objects to keep Exchange config

up to date

ADC Connection Agreement Container

cn=Active Directory Connections,cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=<domain>

Account A D I Right On Property/Applies To Reason

During server install

Exchange Domain Servers X X Full Control

Organization Container

cn=<org>,cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=<domain>

Account A D I Right On Property/Applies To Reason

During ForestPrep phase

Read All Properties Authenticated Users X

ACTRL_DS_LIST_OBJECT

to read Full Org Admins

Designated admin account X X Send As Exchange admins

are not allowed to open mailboxes Designated admin account X X Receive As Exchange admins

are not allowed to open mailboxes

During server install

Enterprise Admins X X Send As NT admins are not

allowed to open mailboxes Enterprise Admins X X Receive As NT admins are not

allowed to open mailboxes Domain Admins of root domain X X Send As NT admins are not

allowed to open mailboxes Domain Admins of root domain X X Receive As NT admins are not

allowed to open mailboxes Everyone X X Create top-level public folder

Everyone X X Create named properties in the

Read Permissions Applies to object class:

Read All Properties msExchPrivateMDB List Contents

ACTRL_DS_LIST_OBJECT

Read Permissions Applies to object class:

Read All Properties msExchPublicMDB List Contents

ACTRL_DS_LIST_OBJECT

Read Permissions Applies to object class:

Read All Properties mTA List Contents

ACTRL_DS_LIST_OBJECT

ANONYMOUS LOGON X X Create top-level public folder

ANONYMOUS LOGON X X Create public folder In Windows 2003

“Everyone” no longer includes

“Anonymous Logon,” so we must grant those rights explicitly ANONYMOUS LOGON X X Create named properties in the

Read Permissions Applies to object class:

Read All Properties msExchPrivateMDB List Contents

ANONYMOUS LOGON X X

ACTRL_DS_LIST_OBJECT

“

Read Permissions Applies to object class:

Read All Properties msExchPublicMDB List Contents

Public Information enabled config

objects (e.g., MAD.EXE) Property Set:

Exchange Domain Servers X X Write Property

Personal Information

Maintain enabled config objects (e.g., MAD.EXE) Applies to object class:

mail-Exchange Domain Servers X X Full Control

siteAddressing

When enabling an SRS (ACE is removed when SRS is disabled)

Create All Child Objects Delete All Child Objects

ACTRL_DS_LIST_OBJECT

to create/delete admin groups

Address Lists Container

cn=Address Lists Container,cn=<org>,cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=<domain>

Account A D I Right On Property/Applies To Reason

During server install

Addressing Container

cn=Addressing,cn=<org>,cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=<domain>

Account A D I Right On Property/Applies To Reason

During server install

List Contents Read All Properties Authenticated Users X X

Read Permissions

Recipient Update Services Container

cn=Recipient Update Services,cn=Address Lists Container,cn=<org>,cn=Microsoft Exchange,cn=Services,cn=Configuration

Account A D I Right On Property/Applies To Reason

During server install

Exchange Domain Servers X X Full Control

Administrative Group

cn=<admin group>,cn=Administrative Groups,cn=<org>,cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=<domain>

Account A D I Right On Property/Applies To Reason

During server install (set on attribute msExchPFDefaultAdminACL)

Authenticated Users X X Create public folder

Default TLH

cn=Public Folders,cn=All Folder Hierarchies,cn=<admin group>,cn=Administrative Groups,cn=<org>,cn=Microsoft Exchange Account A D I Right On Property/Applies To Reason

During server install (set on attribute msExchPFDefaultAdminACL)

Authenticated Users X X Create public folder

Connections Container

cn=Connections,cn=<routing group>,cn=Routing Groups,cn=<admin group>,cn=Administrative Groups,cn=<org>

Account A D I Right On Property/Applies To Reason

During server install

Exchange Domain Servers X X Full Control

Servers Container

cn=Servers,cn=<admin group>,cn=Administrative Groups,cn=<org>,cn=Microsoft Exchange,cn=Services

Account A D I Right On Property/Applies To Reason

During server install, or during Exchange 2003 setup /ForestPrep

Exchange Domain Servers X X Receive As No server needs to

read mail except

on its own store

During server install (ACEs defined in schema defaultSecurityDescriptor)

Server Object

cn=<server>,cn=Servers,cn=<admin group>,cn=Administrative Groups,cn=<org>,cn=Microsoft Exchange,cn=Services

Account A D I Right On Property/Applies To Reason

During server install (if the server is NOT a cluster Virtual Machine)

able to maintain its own config

During server install (if the server IS a cluster Virtual Machine)

NODE1$

NODE2$

etc

X X Full Control Every node in a

cluster that owns

an EVS must be able to maintain the EVS config Exchange Domain Servers X X Full Control EVS must be able

to maintain its own config, but setup can’t tell which specific server to grant control to

During server install (ACEs defined in schema defaultSecurityDescriptor)

Authenticated Users X Read Properties

When EDSLOCK script is run; ACE is REMOVED by Titanium ForestPrep

Exchange Domain Servers X X Receive As No server needs to

read mail except

on its own stores

Protocols

Container

Account A D I Right On Property/Applies To Reason

During server install (set on attribute msExchMailboxSecurityDescriptor)

Read Permissions fsdspermUserSendAs

fsdspermUserMailboxOwner

Read Permissions fsdspermUserSendAs Exchange Domain Servers X X

fsdspermUserMailboxOwner

5.5 Service Account Read Permissions

(if given) fsdspermUserSendAs

cn=Microsoft MTA,cn=<server>,cn=Servers,cn=<admin group>,cn=Administrative Groups,cn=<org>

Account A D I Right On Property/Applies To Reason

During server install or when enabling an SRS

5.5 Service Account

(if given)

send/receive mail from 5.5 servers 5.5 Service Account

(if given)

send/receive mail from 5.5 servers

Table 1.5: Configuration Naming Context permission changes

Permissions Modified On Active Directory Objects in Domain

Naming Context

Domain Container

dc=<domain>

Account A D I Right On Property/Applies To Reason

During DomainPrep phase

Property Set:

Exchange Enterprise Servers X X Write Property

Public Information

Maintain mail- enabled user attributes Property Set:

Exchange Enterprise Servers X X Write Property

Personal Information

Maintain mail- enabled user attributes

n changes Exchange Enterprise Servers X X List Contents Duplicates

permissio

ns granted

to Windows

“Pre-2000 Compatibl

e Access” group Exchange Enterprise Servers X Read Permissions “

Read Permissions Applies to object class:

Read All Properties user List Contents Exchange Enterprise Servers X X

ACTRL_DS_LIST_OBJECT

“

Read Permissions Applies to object class:

Read All Properties group List Contents Exchange Enterprise Servers X X

ACTRL_DS_LIST_OBJECT

“

Applies to object class:

Exchange Enterprise Servers X X Modify Permissions

group

Maintain ACLs for groups with Hidden members hip

During DomainPrep phase (if running against Whistler schema)

Read Permissions Applies to object class:

Read All Properties InetOrgPerson List Contents

Exchange Enterprise Servers X X

ACTRL_DS_LIST_OBJECT

We need same perms on InetOrgPe rsons as

on Users

Domain Proxy Container

cn=Microsoft Exchange System Objects,dc=<domain>

Account A D I Right On Property/Applies To Reason

During DomainPrep phase

Exchange Enterprise Servers X X Full Control Add/delet

e/modify proxy objects Exchange Domain Servers X X Full Control Add/delet

e/modify proxy objects Authenticated Users X X Read Permissions Allow

access to

PF objects Authenticated Users X X Read Property garbageCollPeriod Allow

access to

PF objects Authenticated Users X X Read Property adminDisplayName Allow

access to

PF objects Authenticated Users X X Read Property modifyTimeStamp Allow

access to

PF objects

During DomainPrep (ACEs defined in schema defaultSecurityDescriptor)

Read Permissions Read All Properties

Write All Properties Create All Child Objects Delete All Child Objects Read Permissions Read All Properties List Contents

All delegated org-level and admin-group

level View-Only Admins X X

ACTRL_DS_LIST_OBJECT

AdminSDHolder Container

cn=AdminSDHolder,cn=System,dc=<domain>

Account A D I Right On Property/Applies To Reason

During DomainPrep phase

Read Property Property Set:

Exchange Enterprise Servers X X

Write Property Public Information

This ACL

is applied

to users with domain admin rights Read Property Property Set:

Exchange Enterprise Servers X X

Write Property Personal Information

“

Read Property On property:

Exchange Enterprise Servers X X

Write Property displayName

“

Exchange Enterprise Servers X X List Contents “

Pre-Windows 2000 Compatible Access Group

cn=Pre-Windows 2000 Compatible Access,cn=Builtin,dc=<domain>

Account A D I Right On Property/Applies To Reason

During DomainPrep phase

On property:

Exchange Enterprise Servers X X Write Property

member

The Recipient Update Service must add all Exchange Domain Servers groups to every domains’ Pre-W2K group

Exchange Enterprise Servers Group

cn=Exchange Enterprise Servers,cn=Users,dc=<domain>

Account A D I Right On Property/Applies To Reason

During DomainPrep phase

All existing org-level Full Admins X Full Control Admins

running setup must be able to add/remo

ve machine accounts from group Exchange Enterprise Servers X Full Control

Set by the Recipient Update Service

All delegated org-level Full Admins X X Full Control

Exchange Domain Servers Group

cn=Exchange Domain Servers,cn=Users,dc=<domain>

Account A D I Right On Property/Applies To Reason

During DomainPrep phase

All existing org-level Full Admins X Full Control Admins

running setup must be able to add/remo

ve machine accounts from group Exchange Enterprise Servers X Full Control

Set by the Recipient Update Service

All delegated org-level Full Admins X X Full Control

Table 1.6: Domain Naming Context permission changes

File System Permissions Modified During Setup

When setting ACLs in the file system, setup generally first examines the ACL

to see if there are any explicit (i.e., non-inherited) ACEs on the folder If there are, then setup assumes that one of two cases applies:

1 Setup has previously stamped ACLs on this folder, and there is no need to

C:\Program Files\Exchsrvr (by default; may be chosen during setup)

Account A D I Right On Property/Applies To Reason

During server install (if no pre-existing explicit ACEs)

For this folder, setup reads the ACL from the “Program Files” folder and duplicates it; the permissions shown below are those that exist by default on Program Files

Authenticated Users X X Read & Execute

Mailroot Directory

\Exchsrvr\Mailroot

Account A D I Right On Property/Applies To Reason

During server install

Exchweb Directory

\Exchsrvr\exchweb

Account A D I Right On Property/Applies To Reason

During server install (if no pre-existing explicit ACEs)

Exchweb\bin Directory

\Exchsrvr\exchweb\bin

Account A D I Right On Property/Applies To Reason

During server install (if no pre-existing explicit ACEs)

Authenticated Users X X Read & Execute

Exchweb\bin\auth Directory

\Exchsrvr\exchweb\bin\auth

Account A D I Right On Property/Applies To Reason

During server install (if no pre-existing explicit ACEs)

Exchweb\img Directory

\Exchsrvr\exchweb\img

Account A D I Right On Property/Applies To Reason

During server install (if no pre-existing explicit ACEs)

Exchweb\controls Directory

\Exchsrvr\exchweb\controls

Account A D I Right On Property/Applies To Reason

During server install (if no pre-existing explicit ACEs)

Exchweb\cabs Directory

\Exchsrvr\exchweb\cabs

Account A D I Right On Property/Applies To Reason

During server install (if no pre-existing explicit ACEs)

Exchweb\views Directory

\Exchsrvr\exchweb\views

Account A D I Right On Property/Applies To Reason

During server install (if no pre-existing explicit ACEs)

Exchweb\help Directory

\Exchsrvr\exchweb\help

Account A D I Right On Property/Applies To Reason

During server install (if no pre-existing explicit ACEs)

Table 1.7: NTFS changes to Installation Directory and Subdirectories

New Setup Prerequisite Checks:

To ensure that an admin reads and performs the preparatory steps using the deployment and ADC tools, rather than attempting to bypass the process blindly, setup enforces this check when the first Exchange 2003 joins an admin group containing any Exchange 5.5 directories (which include SRSs) Marker checks are not performed on additional installs into mixed AGs where the 1stExchange 2003 has already joined an Exchange 5.5 site

Note that the string “- Error: ADC Tools were not run in your organization.” Is

a variable string (%s) which can be replaced if other conditions are satisfied For example, if the ADCUserCheck marker exists, but other markers do not, then the error message follows this format:

“Setup detected one or more of the following conditions that may affect your Exchange deployment Microsoft recommends resolving these conditions before continuing this installation:\r\n%s\r\nPlease refer to your Exchange

Server 2003 Deployment Tools documentation on your CD for information about correcting this problem.”

Where the %S string indicates that something has not yet finished replicating,

or has not been run from the deployment tools Specifically, depending upon the status of the other completion markers, ADCObjectCheck and

PubfoldCheck the %s string will change accordingly However, the failure to pass ADCObjectCheck and PubfoldCheck markers will only warn the installer

of that specific problem, but will not prevent setup from continuing as in the ADCUserCheck case

If the customer is halted with the blocking error message, use ADSI Edit or LDP.exe to view the description attribute This is where any

of the three completion markers may exist If ADCUserCheck is present, check

to see if its timestamp is older than two weeks Note that if you’re not using credentials of a person who has full exchange org permissions, you may not be able to see this attribute If you do not have the marker present, there are three ways to populate it:

„ Manual entry through ADSIEdit

„ Running exdeploy.exe from command line, using the /adcusercheck switch (If 5.5-Active Directory objects are not in sync, this method will populate the %S string with a warning indicating that objects have not replicated However, setup will not be blocked.)

„ Running ADC Tools’ Step 2 button, or Step 4 (Verify button)

Although setup enforces the prerequisites, it is a non-setup “glue” DLL (originally from deployment tools) that passes the prerequisite result back to setup Walksdll.dll is the “glue” because it is a wrapper that is called not only

by setup, but also from the deployment tools Since setup shares the wrapper, you may find that the DLL exists in two places on the CD: within the setup\i386 folder, and also within \support\exdeploy Upon launching setup, the markers are checked using this logic:

Troubleshooting Tip

References to “Greenfield scenario” or “Pure TI or pure TI/PT” in the diagram above means that Pure Exchange 2003 or Exchange 2000/2003 admin groups do not require marker checks

Note

Server prerequisites for server FQDN == any SMTP domain on a recipient policy

In the UNIX world, and especially at university-run UNIX mail servers, it was common practice to host users whose e-mail addresses contained domain names matching the fully-qualified domain names of the mail servers themselves (For example, the server whose FQDN was mailserver.univ.edu hosted a mailbox with SMTP address user@mailserver.univ.edu) When these customers deployed Exchange 2000 in the same fashion, mail flow would become inoperable between Exchange 2000 servers This behavior is by design per KB Article Q288175 This new prerequisite prevents Exchange 2003 from being installed into an existing organization when the FQDN of the server (listed on the networkAddress/ncacn_ip_tcp attribute) matches any SMTP addresses on the recipient policy

Setup checks if domain prepped GC is available for DSAccess

Setup will iterate through all GCs in local and adjacent sites, checking if their domains have been domain prepped If no suitable GC has been found with the SACL, setup will not continue

Setup checks for stopped SRS

On upgrades or reinstalls of machines that are supposed to have their replication service enabled, setup performs a prerequisite check to ensure this directory service is running so that setup can write to it, if necessary To manually determine if a site replicate service is supposed to be enabled on a machine, look for the existence of the “Microsoft DSA” object underneath the server object in Active Directory (CN=Microsoft

site-DSA,CN=<servername>,CN=Servers,CN=<Admin Group Name>,CN=Administrative Groups,CN=<Organization Name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<DN of forest root>) If such

an object exists, setup will perform this prerequisite check and will block from installing unless the “Microsoft Exchange Site Replication Service” is set to either “Manual” or “Automatic” and that the service is started

Setup will not install until all ADC services are upgraded to Exchange

2003 version

This check ensures that no Windows 2000 ADC services exist The reason behind this is because Windows 2000 ADCs, when running public folder connection agreements, have been known to cause corruption on public folders This prerequisite is checked on each run of Exchange 2003 setup.exe when no switches are specified Although it may not seem necessary to execute this prerequisite check when the org is native mode, existing ADC installations will

be checked, nevertheless

Setup checks for Exchange Domain Servers/Exchange Enterprise

ƒ A prerequisite was added to normal setup (not domainprep) to check for the renaming or movement of these groups This check only applies

to subsequent (not the first) server installations, or re-installs of the first Exchange 2003 server, in the forest However, this prerequisite check cannot run during setup /domainprep because there is no way for domain admins (lacking Exchange permissions) to query the Recipient Update Service object for the domain, to which the objectGUIDs or SIDs of Exchange Domain Servers/Exchange Enterprise Servers groups are linked Consequently, rerunning setup /domainprep will still cause the 0X80072030 error, which is documented in KB Article

818470

Lab 1.1: Finding renamed, moved, or deleted groups

If the customer has a very large directory that is difficult to search visually, you can search for the objectGuid of the Exchange Domain Servers/Exchange Enterprise Servers groups by following these steps:

1 Power-on the virtual Machine “Solo” (Administrator/password)

3 Ask a lab partner or instructor to hide either Exchange Domain Servers group or Exchange Enterprise Servers group in one of the organizational units (OUs), and rename it This will simulate supporting a large OU hierarchy with thousands of users, where it would be painstakingly difficult

to determine where the object was moved

4 If you were to run setup at this time, you would receive the prerequisite message blocking setup

5 Use ADSI Edit or a similar tool to view the properties of the domain Recipient Update Service object (CN=Recipient Update Service (STANDALONE),CN=Recipient Update Services,CN=Address Lists Container,CN=Microsoft,CN=Microsoft

Exchange,CN=Services,CN=Configuration,DC=<forest root DN>)

6 Locate the following attributes on the domain Recipient Update Service, since they contain the GUIDs for the Exchange Enterprise Servers and Exchange Domain Servers groups, respectively:

msExchDomainLocalGroupGuid, msExchDomainGlobalGroupGuid Copy the values they contain Let us assume that

msExchDomainLocalGroupGuid was 8DC57F85F270}

{1E519285-D987-42C8-BE35-7 Convert the GUIDs from string to Hex format In the above example, {1E519285-D987-42C8-BE35-8DC57F85F270} becomes

“\85\92\51\1E\87\D9\C8\42\BE\35\8D\C5\7F\85\F2\70” would be replaced

by the values you converted in step 7

10 Hit the FIND button, and you will be presented with the new name of the group (if it has been renamed)

11 To determine the OU in which it resides, choose the “object” property sheet

to determine its changed location If there are no objects found, this means the group(s) have been deleted Rerunning domain prep recreates these

3) How easy it is to perform custom LDAP queries without any special tools installed

New Setup Prerequisite Checks (2 of 2)

Disasterrecovery: Setup checks for existence of server object

Running /disasterrecovery is useless if there is not a corresponding server object in Active Directory This is because the purpose of a disasterrecovery setup is to restore a server based on its configuration stored in Active Directory

If a customer attempts this setup mode without first having created the server from a prior installation, Exchange setup assumes that the installation must be brand new, and therefore provides a prerequisite failure message indicating that they must abandon this switch and run setup normally to create the server object

Setup checks for W3SVC to be installed

Since Windows 2003 no longer installs the World Wide Web Publishing service by default with IIS, Exchange setup must ensure that it is installed through this prerequisite

Setup checks for correct ASP.Net and Net Framework versions

Because there can be various versions of ASP.Net/.Net framework installed from different packages, setup ensures that 1.1.4322 is installed, or else a prerequisite is fired

Setup now checks for 5.5 permissions on SRS upgrade/reinstall

This prerequisite prevents a delegated Exchange administrator from setting

“upgrade” or “reinstall” actions on the messaging and collaboration component

Exchange Domain Servers group now added to “Pre-Windows 2000 Compatible Access” group

Due to how the Exchange Enterprise servers group was only a domain local group in Exchange 2000 implementations, servers would not always get all the read access they needed in multi-domain forests ACLs and attributes couldn’t

be read, leading to various potential issues As a workaround, Exchange Server

2003 setup adds the Exchange Domain servers group to the Pre-Windows 2000 Compatible Access built-in group This is performed during the domain prep mode of setup Additionally, an access control entry is added to the Pre-Windows 2000 compatible access group, allowing the local domain’s Exchange Enterprise Servers group to modify the membership So when a Recipient Update Service is designated for a domain, it will add all other domains’

Exchange Domain Servers groups to the Pre-Windows 2000 Compatible Access group

Prerequisites for Windows 2000 SP3 GC’s

Exchange Server 2003 requires that it only uses domain controllers that are Windows 2000 SP3 or later To enforce this requirement, setup uses the process (below) to search for well-versioned domain controllers, or else halt the

deployment

Cluster-related prerequisite checks

Required Resource States

When manipulating the Exchange Virtual Server (EVS), here are the scenarios and prerequisites:

INSTALLING EVS:

- network name resource must be online

REMOVING EVS:

- network name resource must be online

- System Attendant resource must be offline

UPGRADING EVS:

- network name resource must be online

- System Attendant resource must be offline

Setup blocks removal of cluster node if EVS is running on that node

Previously, Exchange 2000 Server administrators were able to uninstall the last node of a cluster, without first removing the virtual server/system attendant resource Neglecting the proper removal of the EVS would orphan the virtual server object in Active Directory To prevent the orphaning, a new prerequisite

in Exchange 2003 will determine if the node is a possible owner for any Exchange virtual server resources and halts if they are

Setup /disasterrecovery is now blocked on cluster nodes

The disasterrecovery switch was never supported on Exchange 2000 Server clusters However, this was a support hit to Microsoft Product Support Services,

as customers would continually attempt to run setup.exe /disasterrecovery on cluster nodes and fail catastrophically with 0x80005000 errors on the Information Store service To prevent this from happening, a prerequisite check

blocks this setup switch if the machine is a node of a cluster, thus customers may only run normal setup Additionally, the normal setup routine on a cluster node no longer presents a message indicating that setup will install the cluster-aware version, whereas the Exchange 2000 setup version would popup that dialog

Clusters now require Kerberos-enabled Network Name resource

A new requirement of Exchange Server 2003 clusters is for the network name resource to be Kerberos-friendly If this prerequisite fails on a Windows 2003 server, ensure that from within cluster administrator, the network name resource properties shows that the Kerberos setting enabled If the cluster is Windows

2000, look for the RequireKerberos property by using cluster.exe:

Cluster.exe res <resource name> /priv

If the listing shows that RequireKerberos is 0, you must set it to 1 by

1 Ensuring the network name resource offline

2 Type the following at a command prompt:

Cluster.exe res <displayname_of_network_name_resource> /priv RequireKerberos=1:DWORD

Preventing Exchange 2003 clusters from being the first non-legacy server in a pure Exchange 5.5 site

Non-legacy in this heading refers to Exchange 2000 (6.0) or Exchange 2003 (6.5) servers Previously, customers could run setup and join Exchange 2000 clusters as the first 6.x servers in Exchange 5.5 sites However, this was an unsupportable situation because the SRS is supposed to reside on the very first 6.x server in a 5.5 site Since the SRS is not a clusterable component, customers painstakingly needed to uninstall their cluster, install a non-clustered Exchange

2000 server, and then redeploy their cluster To prevent this scenario for Exchange Server 2003, setup currently prevents the installation of the first Exchange 2003 server joining an Exchange Server 5.5 org on a cluster by graying out "Join an existing Exchange 5.5 Organization" choice on the

“Installation type” page Once a mixed site (having an SRS) has been established, the creation of the System Attendant resource allows the EVS to join the mixed site

Clusters require Q329938 hotfix or Windows 2000 SP4

With the new Kerberos authentication requirements for clusters, a prerequisite

Exchange System Manager-only installation prerequisites

For both Exchange 2000 Server and Exchange Server 2003, the component selection screen allows for the granularity to install the System Management Components without the messaging and collaboration components This is what

is called an “Exchange System Management-only” install mode, and Exchange administrators use this mode to administer their Exchange servers from their workstations

Previously for Exchange 2000 System Manager-only installs, customers were only required to have the Windows 2000 administration package (which includes Active Directory Users and Computers) to be installed onto their Windows 2000 Professional edition operating systems On Windows XP operating systems, Exchange 2000 System Manager could not be installed without hotfix q815529 This was due to the fact that the Exchange 2000 setup engine, using a prerequisite check, searched for the GUID of the Windows administration package When the Exchange 2000 Server setup engine was built, it only knew to check for the Windows 2000, and not Windows 2003, administration package

For a successful Exchange Server 2003 System Manager-only mode installation, the following operating system prerequisites must be met:

Windows XP SP1:

„ Internet Information Services Snap-In component (In Add/Remove Programs)

„ SMTP Service component (In Add/Remove Programs)

„ SMTP Service should be disabled after service is installed (reason for disabling is that SMTP snap-in is only needed, and not the service itself Additionally, leaving SMTP service running leaves open another possible point of attack)

„ WWW Service (SMTP requires this) should be disabled after service is installed (reason being that it is a security threat)

„ Windows 2003 AdminPack (provides NNTP snap-in and Active Directory Users and Computers snap-in)

Windows XP SP2 (planned):

„ Internet Information Services Snap-In component (In Add/Remove Programs)

„ SMTP snap-in is now provided as part of IIS Manager component

„ Windows 2003 AdminPack (provides NNTP snap-in and Active Directory Users and Computers snap-in)

„ SMTP Service component (In Add/Remove Programs)

„ Should disable service after installed (only need the SMTP snap-in)

„ NNTP Service component (In Add/Remove Programs)

„ Should disable service after installed (only need the NNTP snap-in)

Applies to all scenarios:

„ Setup prerequisites against installing admin-only on a workstation that does not belong to a domain

„ Exchange Server 2003 Forestprep required before installing System Manager

Although the Exchange Server 2003 System Manager may manage any Exchange Server 5.5 and Exchange 2000 Server servers in the organization, it may not manage the following components that were retired in Exchange Server 2003:

„ Instant Messaging service

„ Key Management Server

„ Chat Service

„ Lotus cc:Mail Connector

Exchange System

Manager Compatibility

property sheets on Exchange 2003 servers

2000 to 2003 Setup and Upgrade Scenarios blocked

Attempts to upgrade in the following situations are blocked:

If the server does not have Exchange 2000 Server SP3 installed or Windows

2000 SP3 installed, then the prerequisite check fails For clusters, setup will remotely check each node to ensure other nodes in the cluster are at the proper service pack level

Attempts to in-place upgrade Exchange 2000 Server SP2 to Exchange Server

2003 are blocked This prerequisite fires unless Exchange 2000 Server SP3 or greater are installed

In-place upgrades from English Exchange 2000 Server to Korean, Chinese, or any other double-byte character set (DBCS) of Exchange Server 2003 are blocked if the Groupwise connector is already installed This is because the Groupwise connector in Exchange Server 2003 does not support Japanese character sets or any DBCSs Once the Groupwise connector is uninstalled, an English version of Exchange 2000 may then be in-place upgraded to a DBCS version of Exchange 2003

In-place upgrade of Exchange 2000 back-end server is blocked if there exists an Exchange 2000 front-end in the same Administrative group Beta versions are not checked; the prerequisite only enforces the major version (6.5 versus 6.0) and not the minor versions (6944 versus 6895) The reason for pr-requisite is because front-ends must be upgraded first, in order to prevent various problems with Outlook Web Access This block is only enforced when both front-end and

Management Server administration is being replaced by Windows 2003’s Certificate Server feature Instant Messaging server and Chat server functionality can be replaced by the features within the Microsoft Office Real-Time Communications Server 2003 product

When upgrading an Exchange 2000 Server cluster to Exchange Server 2003, the Microsoft Distributed Transaction Coordinator (MS DTC) resource is required In most cases, Exchange 2000 Server setup would have created that resource However, there are some scenarios in which Windows 2000 did not allow Exchange 2000 Server setup to create the MS DTC resource, and so a blocking prerequisite message is displayed when upgrading to Exchange Server

2003 setup To create the MS DTC resource on a Windows 2000 cluster, simply type Comclust.exe on each node of the cluster, and the MS DTC resource is added automatically (205796) Note: You should not use cluster administrator

to create the MS DTC resource manually

Setup Blocks for upgrades or installs

In-place upgrade from Exchange Server 5.5 is blocked

This stops customers from attempting an in-place upgrade from Exchange Server 5.5 to Exchange server 2003, as this path is unsupported

Setup blocked if Windows 2003 POP3 service is installed

A new feature of the Windows 2003 operating system is a lightweight Post Office Protocol (POP3) server service Due to port conflicts and questionable supportability of two mail systems on a single machine, Exchange Server 2003 setup prevents the two from coexisting, by means of a prerequisite check: “-You must remove the Windows POP3 Service component in order for Setup to continue.” To remove this Windows 2003 feature to bypass the prerequisite check, go to Add/Remove Programs, then Add/Remove Windows Components, and select the details of the “E-mail services” category

If MIS is installed, a prerequisite blocks install/upgrade

To prevent collisions between different versions of mobility components, this prerequisite ensures that Mobile Information Server doesn’t already exist on the machine being setup with Exchange 2003 If this prerequisite is fired when the customer has already removed Mobile Information Server, check for the existence of the registry key

"Software\\Microsoft\\Exchange\\DMI\\EventMessageFile" and remove it if it exists Furthermore, the prerequisite will fire if the Mobile Information Server Exchange Event sink is registered in

“HKLM/Software/Classes/Wnotify.MoExSink” Although Mobile Information Server and Exchange Server 2003 may not reside on the same machine, there is

no problem with these two products coexisting within the same forest on different servers

Setup disallows /disasterrecovery to convert an EVS to a standalone

Setup checks if the Exchange server object was previously an Exchange virtual server If it was, and the installer attempts to run /disasterrecovery on a non-clustered machine with the same name as the EVS’s old network name resource, setup will halt In the past, Exchange 2000 would not check for this, and some servers would be installed without message transfer agents (MTAs)

If a new, standalone server must be installed using the same name as the old EVS, then one must (a) delete the Exchange server object from the