Module 1: Setup Changes - gattner.namegattner.name/simon/public/microsoft/MS Exchange/70-284...

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

Last Saved: 7/24/2003 1:55 AM Last Printed: 7/24/2003 12:55 PM

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. 2003 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows NT, Active Directory, ActiveX, Excel, Exchange Server 5.5, Exchange 2000 Server, Exchange Server 2003, Internet Explorer, Internet Information Server, Word are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein (Groupwise, Lotus cc:Mail, Lotus Notes) may be the trademarks of their respective owners.

Module 1: Setup Changes 1


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

2 Module 1: Setup Changes


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: “{335A1087-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 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 pre-requisite stage with a descriptive error message. If this is the case, one should 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 {335A1087-5131-4D45-BE3E-

3C6C7F76F5EC}

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 pre-requisite check, later in the setup process the Exchange 2000 Server setup wizard does not understand the GUID organization object, and the installation 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 correct the problem, or to revert back to Exchange 2000 Server settings, one must now manually correct the Active Directory permissions by applying the permissions listed in Table 1.4 under the section entitled “New per-object permissions changes during setup.” If the customer does not mind that the security settings revert back to the Exchange 2000 Server configuration, then run Exchange 2000 setup to “join” a new Exchange 2000 server object to the existing Exchange 2003 organization.



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

“DomainPrep” Domain Administrator

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

ACTRL_DS_SELF

0x00000028

List Contents

ACTRL_DS_LIST 0x00000004

Read All Properties

ACTRL_DS_READ_PROP 0x00000010

Write All Properties

ACTRL_DS_WRITE_PROP 0x00000020

Delete DELETE 0x00010000

Delete Subtree

ACTRL_DS_DELETE_TREE 0x00000040

Read Permissions

READ_CONTROL 0x00020000

Modify Permissions

WRITE_DAC 0x00040000

Modify Owner

WRITE_OWNER 0x00080000

All Validated

ACTRL_DS_SELF 0x00000008



Writes

All Extended Rights

ACTRL_DS_CONTROL_ACCESS 0x00000100

Create All Child Objects


ACTRL_DS_CREATE_CHILD 0x00000001

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

Allow DomainPrep 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

Allow Exchange 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>



Exchange Domain Servers X X Full Control

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


During ForestPrep phase

Read All Properties Authenticated Users X

ACTRL_DS_LIST_OBJECT

Allow DomainPrep 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


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 public folder

Everyone X X Create named properties in the information store

Read Permissions Applies to object class:

Read All Properties msExchPrivateMDB

List Contents

Everyone X X



Read All Properties msExchPublicMDB

List Contents

Everyone X X



Read All Properties mTA

List Contents

Everyone X X


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 information store

“


Read All Properties msExchPrivateMDB

List Contents

ANONYMOUS LOGON X X


“


Read All Properties msExchPublicMDB

List Contents

ANONYMOUS LOGON X X


“


Read All Properties mTA

List Contents

ANONYMOUS LOGON X X


“

Exchange Domain Servers X X All Extended Rights

Exchange Domain Servers X X Create All Child Objects

Exchange Domain Servers X X Write Property Property Set: Maintain mail-



Public Information enabled config objects (e.g., MAD.EXE)

Property Set: Exchange Domain Servers X X Write Property

Personal Information

Maintain mail-enabled config objects (e.g., MAD.EXE)

Applies to object class: Exchange Domain Servers X X Full Control

siteAddressing

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



MACHINE$ X X


SRS must be able to create/delete admin groups

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



Authenticated Users X X List Contents

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



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




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


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


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




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


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)

Authenticated Users X List Contents

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


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

MACHINE$ X X Full Control Server must be 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 cn=Protocols,cn=<server>,cn=Servers,cn=<admin group>,cn=Administrative Groups,cn=<org>,cn=Microsoft Exchange...



Everyone X X List Contents

Everyone X X Read metabase properties

System Attendant Object cn=Microsoft System Attendant,cn=<server>,cn=Servers,cn=<admin group>,cn=Administrative Groups,cn=<org>...




During server install (set on attribute msExchMailboxSecurityDescriptor)

Read Permissions

fsdspermUserSendAs

LocalSystem X X

fsdspermUserMailboxOwner

Read Permissions

fsdspermUserSendAs

Exchange Domain Servers X X


5.5 Service Account Read Permissions

(if given) fsdspermUserSendAs

X X


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


During server install or when enabling an SRS

5.5 Service Account

(if given)

X X Send As Required to send/receive mail from 5.5 servers

5.5 Service Account

(if given)

X X Receive As Required to 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>


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

On property: Exchange Enterprise Servers X X Write Property

groupType


displayName

Exchange Enterprise Servers X Manage Replication Topology Allow Recipient Update Service to track replication changes

Exchange Enterprise Servers X X List Contents Duplicates permissions granted to “Pre-Windows



2000 Compatible Access” group

Exchange Enterprise Servers X Read Permissions “


Read All Properties user

List Contents

Exchange Enterprise Servers X X


“


Read All Properties group

List Contents



“

Applies to object class: Exchange Enterprise Servers X X Modify Permissions

group

Maintain ACLs for groups with Hidden membership

During DomainPrep phase (if running against Whistler schema)


Read All Properties InetOrgPerson

List Contents



We need same perms on InetOrgPersons as on Users

Domain Proxy Container cn=Microsoft Exchange System Objects,dc=<domain>



Exchange Enterprise Servers X X Full Control Add/delete/modify proxy objects

Exchange Domain Servers X X Full Control Add/delete/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

List Contents

Authenticated Users X


Set by the Recipient Update Service

All delegated org-level and admin-group level Full Admins

X X Full Control

Read Permissions

List Contents

All Validated Writes

All delegated org-level and admin-group level Admins

X X

Read All Properties



Write All Properties



Read Permissions

Read All Properties

List Contents

All delegated org-level and admin-group level View-Only Admins

X X


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



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>




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>



All existing org-level Full Admins X Full Control Admins running setup must be able to add/remove machine accounts from group

Exchange Enterprise Servers X Full Control




All delegated org-level Full Admins X X Full Control

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



All existing org-level Full Admins X Full Control Admins running setup must be able to add/remove machine accounts from group

Exchange Enterprise Servers X Full Control


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 do so again.

2. An administrator has manually adjusted permissions to his or her liking, and setup should not overwrite those settings.

The effect is that, in the default case, setup stamps file system permissions on a clean install, but does not modify them on reinstalls.

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


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

Server Operators X X Modify

Administrators X X Full Control

CREATOR OWNER X X Full Control

TERMINAL SERVER USER X X Modify

SYSTEM X X Full Control

Mailroot Directory ...\Exchsrvr\Mailroot



Everyone X X Full Control

ANONYMOUS LOGON X X Full Control

Exchweb Directory ...\Exchsrvr\exchweb



Authenticated Users X X Read

Exchweb\bin Directory ...\Exchsrvr\exchweb\bin



Authenticated Users X X Read & Execute

Exchweb\bin\auth Directory ...\Exchsrvr\exchweb\bin\auth





ANONYMOUS LOGON X X Read

Exchweb\img Directory ...\Exchsrvr\exchweb\img




Exchweb\controls Directory ...\Exchsrvr\exchweb\controls




Exchweb\cabs Directory ...\Exchsrvr\exchweb\cabs




Exchweb\views Directory ...\Exchsrvr\exchweb\views




Exchweb\help Directory ...\Exchsrvr\exchweb\help




Table 1.7: NTFS changes to Installation Directory and Subdirectories



New Setup Prerequisite Checks:

Marker Checks During server setup, if the installer chooses to join an Exchange 5.5 site, additional marker checks are enforced. This means that setup will check to see if the deployment tools have been executed as far as step 2 in the ADC Tools snap-in. (That step should have written the completion marker, ADCUserCheck, to the description attribute of cn=Microsoft Exchange, cn=services, cn=configuration, dc=<forest root DN> object in the configuration naming context.) If the marker exists, setup will continue; otherwise, the following error is displayed:

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 1st Exchange 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 [email protected]). 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 site-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 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 Servers Customers that renamed or moved their Exchange Domain Servers or Exchange Enterprise Servers groups outside of their default “Users” containers caused various problems with Exchange 2000. To prevent this from happening, Exchange Server 2003’s setup has two improvements:

The setup /domainprep modifies the description attribute of these groups to include the string “DO NOT move or rename.”



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 {1E519285-D987-42C8-BE35-8DC57F85F270}

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

8. In Active Directory Users and computers, right-click on the domain object, and choose FIND. Do a custom search, and select the advanced tab.

9. Enter an LDAP query similar to the following: objectGUID=\85\92\51\1E\87\D9\C8\42\BE\35\8D\C5\7F\85\F2\70 Where “\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 groups.

After completing this exercise, students should be able to recognize the

following: 1) Does the msexchdomainlocalgroupguid correspond to the Exchange

Domain Servers group? (Y/N) 2) Recognize patter of reversed bits when converting GUIDs from string

format to hexadecimal string



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 when the admin does not have permissions to the SRS. This is an improvement over Exchange 2000 setup, where if the prerequisite check didn’t fire, customers would encounter this error message later in setup: “Could not bind to the Microsoft Exchange Directory server Name_of_Ex2000_server. You do not have the permissions required to complete the operation.” The installer should have at least “permissions admin” role in Exchange 5.5 organization, site, and configuration containers.



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 check scans the operating system version of the target server. If the operating system is Windows 2000 SP3, then setup will look in the registry to see if the key "HKLM\SOFTWARE\Microsoft\Updates\Windows 2000\SP4\Q329938" is present. If the operating system is below or above Windows 2000 SP3, this prerequisite passes. (In the case that it is below SP3, another prerequisite will fire a warning about the operating system service pack level.)



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)

Windows 2003 Internet Information Services Manager component (In Add/Remove

Programs)

Windows 2000 SP3 Professional Internet Information Services Snap-In component (In Add/Remove

Programs) Windows 2000 Server AdminPack (provides SMTP snap-in, NNTP snap-in

and Active Directory Users and Computers snap-in)

Windows 2000 SP3 Server Internet Information Services Snap-In component (In Add/Remove

Programs) 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 MS-Mail Connector Microsoft Mail Directory Synchronization Connector Schedule+ Free/Busy Connector

Therefore, some customers will need to retain a full Exchange 2000 server or Exchange 2000 Exchange System Manager-only installation in their organization in order to manage the services above.

Exchange 2000 System Manager may only be used to view (read-only)

Exchange System Manager Compatibility

Note



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 back-end are in the same administrative group which means there is still an unchecked scenario: When front-ends and back-ends exist in different administrative groups, then customers will not encounter the prerequisite block, so Outlook Web Access users will experience error messages throughout the web interface (for example, script errors in Internet Explorer).

Exchange 2000 servers with Key Management Server component Chat server component, or Instant Messaging server components are blocked from being upgraded unless those components are removed from the Exchange 2000 server. This is because Exchange Server 2003 has dropped support for those components, and would not be able to upgrade these components properly. Key



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



configuration Naming Context, then (b) rerun setup without the /disasterrecovery switch.

Setup prevents any Exchange 2003 SKUs from installing on a Windows 2003 Web Edition server (212624) The Windows 2003 Web Edition is targeted as a low-cost Web-application server. Ideally, this edition of Windows 2003 would be a fitting platform for installing Outlook Web Access front-end servers. Nevertheless, the Web Edition of Windows is not a full-featured server product containing all the component services on which Exchange 2003 depends. Therefore Exchange 2003 setup is designed to check specifically to ensure that customers do not attempt to install on this scaled-down operating system. Although customers might feel that the Web Edition would be ideal for Exchange 2003 front-end servers, technical reasons preclude this from happening at this time.

In place upgrades of front-end servers from Enterprise to Standard edition You cannot in-place upgrade an Exchange 2000 Server enterprise front-end to become an Exchange Server 2003 standard front-end.

On a single machine, there is no direct upgrade path from Exchange 5.5 to Exchange 2003. To reduce the test matrix, and to prevent Exchange 5.5 disaster-recovery scenarios on failed upgrades, a decision was made to bar in-place upgrades from 5.x. Instead, customers should install Exchange Server 2003 on separate servers, and then use the move-mailbox method.

If you recall that Exchange 2000 may not be installed on Windows 2003 server, you may also deduce that upgrading the operating system where Exchange 2000 server resides on Windows 2000 may not work either. The upgrade path for the operating system would require that one must first in-place upgrade the Exchange version to Exchange Server 2003 before in-place upgrading the operating system. Otherwise, the Exchange 2000 Server setup will be prevented, since Windows 2003 server will proactively prevent its setup routine.



New Features/Components in Setup:

Clusters create computer objects One new, notable feature when running on a cluster is that the Exchange 2003 System Attendant resource indirectly creates a computer object in the Computers OU of the domain. This may sound odd, since previously for Windows 2000 clusters, the existence of a pre-existing computer object would prevent the network name resource from starting, and these two events would be logged:

Event ID 1052 Source: Cluster Service Clussvc Category: 2056 Type: Stop Description: Cluster network name resource "<ResourceName>" could not be brought online because the name could not be added to the system.

Event ID 1069 Source: Cluster Service Clussvc Category: 4 Type: Stop Description: Cluster resource "<ResourceName>"

With Exchange 2003 installed on Windows 2000, the existence of the network name will not prevent the Exchange virtual server’s network name from starting. This change is a side-affect of the resource’s private property requiring Kerberos support, because when the system attendant is created, it sets the requirekerberos property on the network name resource. With Windows 2003 (regardless of whether Exchange 2003 is installed), the default behavior is such that ANY network name resource will automatically create a corresponding computer object.



Outlook Mobile Access This is the mobility component that is automatically installed with every Exchange 2003 installation, but disabled by default. (To enable it, use Exchange System Manager | Global Settings | Mobile Services | Properties) Similar to Outlook Web Access, the installer has no choice here, as it is not a selectable component on the setup wizard’s component selection screen. Outlook Mobile Access is the first Exchange Server 2003 component written in C#, and therefore needs ASP.NET 1.1 installed.

Some parts of Outlook Mobile Access are installed through scripts (.INS files within the Exchange setup source directory). For example, omabrowseinstall.exe is called by a script (.INS) file. But since omabrowseinstall.exe is a separate module from the main setup program, it is not tied to the rich error/diagnostic reporting provided by the backoffice setup engine. Thus, we cannot get much information from it if errors are encountered. At the time of this writing, “OmaBrowseInstall.exe counters /create” is called by a script, and may sometimes fail if other software is installed on the same machine. To avoid a catastrophic failure that would have caused customers disasterrecovery measures in the upgrade scenario, the setup team has updated the counter creation to ignore failures during counter installation, but unfortunately a warning is not logged to the application log during installation.

The methods to determine (post-setup) if there was a problem with installing Outlook Mobile Access counters is to

a) Examine the application event log for an exit code in the setup progress.log, such as the one below:

[09:36:52] ++++ Starting interpreter on file z:\titanium\rtm\6944.1\server\rtl\usa\setup\i386\exchange\browse.ins ++++ -- ID:31258 -- [09:36:52] Interpreting line <CreateProcessSafe:D:\Program Files\Exchsrvr\OMA\Browse\bin;"D:\Program Files\Exchsrvr\OMA\Browse\bin\OmaBrowseInstall.exe" counters / create;180000> -- ID:31259 -- [09:36:52] Process created ... waiting (180000) [09:36:58] Ignoring exit code fffffffffd

b) Wait for the following event ID to be generated when a mobile user attempts to access their mailbox through Outlook Mobile Access:

Event Type: Warning Event Source: MSExchangeOMA Event Category: (1000) Event ID: 1101 Date: 6/12/2003 Time: 2:33:58 PM User: N/A Computer: BTSLABFE Description: Outlook(R) Mobile Access Browse Application could not initialize its performance monitor counters because of the following error: The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly.



.NET Framework, ASP.NET 1.1 and ASP.NET Device Update-2 These components are installed automatically if running Exchange Server 2003 setup on a Windows 2000 server lacking the .NET Framework. However, since ASP.NET is a component of Windows 2003, it must be installed as a component. One may verify if .NET Framework is installed on a machine by ensuring it is on the list of installed applications: Start/Control Panel/Add or Remove Programs/Change or Remove Programs/Microsoft .NET Framework - <version>. However, there is no information about version of the ASP.NET there.

It is possible to have a several .NET Frameworks installed on the same computer. There are some problems with multiple versions of ASP.NET and .NET Framework installed on the same server, with servers promoted from Windows 2000 to Windows 2003 and from member servers to domain controllers. (Also, a possible problem occurs when customers inappropriately upgraded beta versions of Windows 2003 to the release version). For each operating system, we hope the latest versions of .NET Framework and ASP.NET are used. The latest version of enabled-ASP.NET is used on Windows 2003. Device Update-2 is a standalone application and it is installed by Exchange Server 2003 Setup. They are installed using the following files:

...\i386\exchange\oma\browse\dotnetfx.exe

...\i386\exchange\oma\browse\dupdate.exe

How does it work? Windows 2000+SP3: Exchange Server 2003 Setup installs the .NET Framework version 1.1.4322.557 if ASP.NET 1.1.0000 or above has not been installed before. ASP.Net is always enabled on Windows 2000 if .NET Framework is installed there. If the version of .NET Framework installed is below 1.1.4322.557, Setup will automatically uninstall it using this series of commands:

"MsiExec.exe /X{DF420000-A5AB-407C-92FF-D1D4B709B8F9} /q" "MsiExec.exe /X{8542DFF7-5CAB-4424-AAF7-BFEB3104D8AC} /q" "MsiExec.exe /X{C9913503-1500-4454-94CD-365ADC1BB9B9} /q"

Thus, you may possibly use these commands to clean up a server you suspect has incompatible .NET Framework versions. Then, to install ASP.NET as a component:

1. Start/Control Panel/Add or Remove Programs/Add/Remove Windows Components/Application Server/ASP.NET.

2. Check the check box and install it. 3. To enable ASP.NET: 4. Run Internet Information Services (IIS) Manager; 5. Navigate to "Web Service Extensions". 6. Select "ASP.NET v1.1.4322" and click on “Allow”

Troubleshooting ASP.NET errors: There are a few typical scenarios where ASP.NET and Device Update-2 are not installed or/and configured properly. Before troubleshooting, a simple verification test on Windows 2003 is to see if the correct version is installed is to:



1. Run Internet Information Services (IIS) Manager; 2. Navigate to "Web Service Extensions". 3. Ensure that "ASP.NET v1.1.4322" exists, and that its extension status is set

to “Allowed” You should also ensure the existence of this directory:

%windir%\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll

Previous Cases with problems: Engineers may want to review these previous beta-build problems as possible troubleshooting methods for post-release problems:

Scenario: .NET Framework versions < 4322 (for example: 3629) + ASP.NET 1.0 (for example: 1.0.3709) -> 3678 or above.

Problem: ASP.NET, installed as a .NET component is the same (3709) after upgrade. Uninstalling and re-installing ASP.NET does not help, since the same ASP.NET 3709 is installed.

How to fix:

1. Uninstall ASP.NET 2. IInstall .NET Framework 4322 (from

...\i386\exchange\oma\browse\dotnetfx.exe) 3. Enable ASP.NET through Add/Remove Programs.

Scenario: Windows 2000+SP3 + ASP.NET upgrading to Windows 2003 build 3678

or

Member Server (both Windows 2000+SP3 and .NET) + ASP.NET promoted to a Domain Controller (bug 214215). It always happens if Jupiter/Autosetup/Topoweb is used.

Problem: If you upgrade to Windows 2003 and dcpromo.exe, all the ACLs in the %windir% folders are reset. As a result, the ACLs do become misconfigured for some ASP.NET folders.

To fix, here is the recommended path:

1. Run the aspnet_regiis.exe with the -i switch on the server: 2. Browse to "<%windir%>\Microsoft.NET\Framework\<version of the

framework>" (for example, C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322);

3. Run "aspnet_regiis.exe -i". Not recommended, but this helps:

Manually: uninstall ASP.NET and install it back, or 1) Add user "NETWORK_SERVICE" with "Full Control" to the folder "<%windir%>\Microsoft.NET\Framework\<version of the framework>\Temporary ASP.NET Files" (for example,



C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files).



Setup Changes

Improvements to the progress log Since the setup progress log is not localized (appears only in English), it was difficult for non English-speaking customers and support engineers to examine the progress log file. Exchange Server 2003’s setup progress logs now contain "-- ID:xxxxx --" tags after entries that are localized string resources. A new logparser (with the ability to parse these string IDs) is now available.

M: drive removed In Exchange 2000 Server, the M: drive caused a lot of problems, as it was easily exposed through explorer and customers adopted the impression that mailbox and public folder permissions could be manipulated through this file system interface. Furthermore, file-based antivirus and backup software would manipulate objects in the M: drive, accidentally corrupting messages or setting the archive bits on them such that they would not be properly accessible. Therefore, Exchange Server 2003 no longer presents the Exchange Installable File System as drive letter M. Reclaiming the M: drive is possible by enabling this registry parameter, although it is strongly discouraged:

Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS\Parameters\ Parameter: DriveLetter Type: String Value: M

The M: drive should only be exposed for gaining access to non-MAPI file data (such as editing an .asp that executes out of the store). You should not share out portions of the M: drive for SMB user access (instead, you should use Web Folders).

Enabling the Installable File System drive will lead to prompts for Note



reboots during future upgrades.

Setup creates configuration Connection Agreement with fully qualified domain names When setup installs the first Exchange 2003 server into a pure Exchange 5.5 site, the Site Replication Service (SRS) is always added to the Exchange 2003 server. Each SRS requires a configuration Connection Agreement to replicate configuration naming context data between Active Directory and Exchange Server 5.5. This replication data comprises of new or changed server properties, connectors, address generator settings, etc. Creation of the Configuration connection agreement by Exchange 2000 setup would populate the endpoints - msexchserver1networkname and msexchserver2networkname (domain controller and Exchange 5.5 directory service, respectively) - to NetBIOS server names. In Exchange Server 2003, setup will configure the configuration connection agreement (located on the ‘Connections’ property sheet) to fully-qualified domain names.

How this affects Microsoft Product Support Services: When troubleshooting why server settings, connectors, or site addressing properties are not replicating between Exchange Server 5.5 and Active Directory, we will need to check if DNS name resolution is non-problematic. Although deployment tools prevents this before setup is run, customers may misconfigure their DNS settings post-setup in a way such that an endpoint is not resolvable through DNS. If this is the case, the configuration connection agreeements will not be able to synchronize the endpoints. To correct, either enter the NetBIOS names of server endpoints or ensure DNS has an updated host record for the Exchange 5.5 or domain controller servers.

Launch.exe replaced by setup.exe at CD root Tthe splash screen that autoruns upon inserting a product CD, was able to be launched manually by executing launch.exe in Exchange 2000. In Exchange 2003, launch.exe has been dropped so that setup.exe at the root will spawn the splash screen.. However, the root setup.exe should not be confused with the real setup wizard, located in \setup\i386\setup.exe. If the root setup.exe is run with any switches, then rather than spawning the splash screen, the root setup.exe will automatically redirect the switches to the real setup.

Files will be recopied upon reinstall In Exchange 2000 and earlier builds of Exchange Server 2003, the reinstall process would always skip copying files from source media if an installed file has the same or greater file version. Due to how there could be some corruption on the target file, Exchange 2003 changes the process by ensuring source files are re-copied and that installed files are overwritten if their timestamps are not greater than their source. A minor disadvantage in copying more files, is the amount of time it takes to reinstall a server increases.

Files renamed during setup Files on the CD are not guaranteed to have the same filename that will appear on an installed server. Since all files on the CD need unique names (which is done when the Build Team builds the drop), setup will rename them back to their original filenames during the install. For example, language-specific Outlook Mobile Access files are renamed during setup because, on the CD, these files reside in different language directories. Once setup installs them, they rename those DLLs to a non-language-specific name.



If a file cannot be read from the installation media, or if you ever need to manually replace an installed file that has already been installed, consult the following list for special files when searching from new media; you may need to manually copy the file to disk and then rename it to emulate the setup process.

List of files renamed during setup: Exwfmsg.dll will be renamed during the installation. For example, the source file

Setup\i386\exchange\res\<Code_Page>\exwfmsg.dll.<Code_Page>

will lose its language-codepage extension when the file-copy phase of setup renames it to Exwfmsg.dll

The following Outlook Web Access Controls files will be renamed in the CD:

Setup\i386\exchange\exchweb\<Version_WMTEMPLATEST>\Controls\blank.htm.0 Setup\i386\exchange\exchweb\<Version_WMTEMPLATEST>\Controls\dlg_ANR.js.0 Setup\i386\exchange\exchweb\<Version_WMTEMPLATEST>\Controls\dlg_GAL.css.0 Setup\i386\exchange\exchweb\<Version_WMTEMPLATEST>\Controls\dlg_GAL.js.0 Setup\i386\exchange\exchweb\<Version_WMTEMPLATEST>\Controls\dls_Recurrence.js.0

The following Outlook Web Access Themes files will be renamed on the CD:

Setup\i386\exchange\exchweb\themes\0\*.0 Setup\i386\exchange\exchweb\themes\1\*.1 Setup\i386\exchange\exchweb\themes\2\*.2 Setup\i386\exchange\exchweb\themes\3\*.3 Setup\i386\exchange\exchweb\themes\4\*.4

The Help files of WebClient will be renamed in the drop:

Setup\i386\exchange\exchweb\HELP\<Client_Lang>\ie3\*.ie3.<Client_Lang> Setup\i386\exchange\exchweb\HELP\<Client_Lang>\ie3\basics\*.ie3.basics.<Client_Lang> Setup\i386\exchange\exchweb\HELP\<Client_Lang>\ie3\gif\*.ie3.gif.<Client_Lang> Setup\i386\exchange\exchweb\HELP\<Client_Lang>\ie5\*.ie5.<Client_Lang> Setup\i386\exchange\exchweb\HELP\<Client_Lang>\ie5\basics\*.ie5.basics.<Client_Lang>

The following files from Setup\i386\Exchange\conndata\dxanotes folder will be renamed:

Troubleshooting Tip



Amap.tlb.0 Mapmex.tlb.0

All the Outlook Mobile Access resources files will be renamed in the CD:

Setup\i386\Exchange\Oma\Browse\bin\<Culture_Lang>\*.<Culture_Lang>

The CDO.dll in Setup\i386\Exchange\Oma\Browse\bin will be renamed to CDO.dll.0.

Logoff.asp has been renamed in Setup\i386\exchange\exchweb\bin\<Client_Lang> folder to logoff.asp.<Client_Lang>

Logon.asp has been renamed in Setup\i386\exchange\exchweb\bin\auth\<Client_Lang> folder to logon.asp.<Client_Lang>

ChooseDC switch The Exchange 2003 SETUP.EXE program has a new switch; /choosedc. This allows you to specify which domain controller should be using during the installation process for reading and writing directory information. Its command-line syntax is:

Setup.exe /choosedc name_of_DC

This switch may be used in conjunction with other switches, such as /domainprep. However, the user-specified domain controller must be in the same domain as the installing server (ScPRQ_ChosenDCMustBeInSameDomain is the prerequisite check which enforces same-domain domain controller).

One good use of this switch is when you are installing multiple Exchange servers simultaneously into the same domain (e.g. test lab or training room) and have multiple domain controllers; you can hone all installations to use the same domain controller. By doing this, when SETUP adds the computer account to the 'Exchange Domain Servers' group, the change will only take place on a single domain controller and replicate out. Without this switch, setup behaves like in Exchange 2000 Server, in that it talks to multiple domain controllers and then you get replication clashes - the net result being that some Exchange servers fail to start their services after installation.

If you need to confirm that a customer typed the /chooseDC switch properly, search the progress log for this string (without the servername) to verify:

User has specified a DC; m_strDC = "CDCS00"

Otherwise, if /chooseDC switch contains bad syntax, such as a colon (for example setup.exe /choosedc:CDCS00) or if the switch isn’t used at all, this entry is written to the progress log:

Tip



No user-specified DC; setup has chosen m_strDC = "CDCS00"

If the /chooseDC switch is used, but does not have a server name after the switch, then this window appears:

Service startup state retained through reinstalls or upgrades If an Exchange 2000 service, such as MSExchangeMTA, is disabled before the upgrade to Exchange 2003, the upgrade process will leave the Exchange 2003 MTA disabled. This is a major change from Exchange 2000, as reinstalls and upgrades would reset their component services to a default state (typically automatic).

Changes to IIS6 after upgrading to Windows 2003 On Windows 2000, Exchange 2003 services run in the same IIS application pool as any other services. So just like Exchange 2000, this is potentially less stable because any problems in any one IIS ISAPI application can cause problems with all of InetInfo – including Exchange services. So in Windows 2003, IIS6 apps run in their own dedicated application pools, though not by default when upgraded from IIS5. Therefore, immediately after an operating system upgrade, the Exchange metabase update service run by the system attendant creates two dedicated app pools – one for DAV, Web forms, exadmin; and one for spellcheck for the web client. In addition to creating the metabase keys for application protection, Exchange benefits from all of the security improvements included in the worker process isolation mode. However the rest of IIS6 still runs in IIS5Compat mode until the administrator switches to worker-process isolation mode.

Changes to Maximum Hop Count during install (225648) The maximum hop count on SMTP virtual server instances has changed from 15 to 30. For new server installations, a value of 30 is always set. For upgrades and reinstalls, the existing value is checked; if it is 15, the value is automatically changed to 30. If the existing value is something other than 15, no change is applied.



Security improvements to setup:

Relaxed Permissions on cluster service accounts Previously in Exchange 2000, anybody who wanted to install a cluster needed to ensure that the cluster service account was granted Full Exchange Administrator rights at the organizational level. The permissions have been relaxed in Exchange 2003, so the Windows 2003 Cluster Admin account does not need to have any rights on the Exchange org level. The cluster service account just needs to be a local admin on each node of the cluster. Though Windows 2000 cluster service accounts still needs permissions to Active Directory, but they are not needed on the org level unless the EVS is the first server in the org.

Windows 2000 Cluster Service Account: Local Administrator on each Node in the cluster

Exchange Full Administrator on org object if other Exchange 2000 clusters with same cluster service account remain in org

Windows 2003 Cluster Service Account Local Administrator on each Node

No permissions required on org

If you are upgrading, you can remove the Exchange Full Admin right from the cluster service account once you have upgraded all your servers to Exchange 2003.

Exchange Domain Servers group no longer granted Receive-As right during DomainPrep In Exchange 2000 Server, a rogue Exchange Admin could access mailboxes in remote domains when using the Computer account (LocalSystem account



context). The workaround was to use the “EDSLOCK.VBS” script to lockdown permissions. In Exchange Server 2003, the servers are locked-down by default by removing the computer account’s ability to read mail from servers other than its own. In addition to the domainprep change, setup now does these things during forestprep and first server install:

EXCHANGE 2003 ForestPrep: Enumerates all existing "Exchange Domain Servers" groups and all admin groups; set a "Deny-Receive-As" ACE for each Exchange Domain Servers group on each admin group's "Servers" container [this happens every time ForestPrep is run].

Enumerates all server objects, searches the ACL of each one for any "Deny-an Exchange Domain Servers group-Receive-As" ACEs (which were set by the EDSLOCK script) and removes them. This happens only the first time EXCHANGE 2003 ForestPrep is run. The heuristics bit on the Microsoft Exchange object is set to “6” to represent this change. (In Exchange 2000, it was only set to “2” after forestprep).

EXCHANGE 2003 server install: If installing the first Exchange 2003 server in a new domain, setup enumerate all admin groups, and sets a "Deny-Receive-As" ACE for the new Exchange Domain Server group on each admin group's "Servers" container.

For every install/reinstall/upgrade, setup searches the ACL of the server object for any "Deny-an Exchange Domain Servers group-Receive-As" ACEs and removes them.

When creating a new Exchange 2003 admin group (via setup or Exchange System Manager), setup enumerates all existing Exchange Domain Server groups, and sets a "Deny-Receive-As" ACE for each Exchange Domain Server group on the new admin group's "Servers" container.

Authenticated Users removed from local (and terminal) login Previously in Exchange 2000 Server, no changes were made to the local security settings of member servers by setup. This meant that a normal user could potentially wreak havoc with server settings for files. Although this security setting already prevents domain users from logging onto domain controllers, Exchange Server 2003 takes security steps for member servers by improving the setup to remove "BUILTIN\Users" from the "Log on locally" policy (called "Allow log on locally" on 2003 servers.) BUILTIN\Users contains "Authenticated Users" and "Domain Users" by default, so setup removes those users' ability to log on to the machine. Administrators, power users, and backup operators are still allowed to log on. This change applies to install, upgrade, and reinstall modes.

Exchange Server 2003 drops support for FAT partitions As part of hardening the product for security, setup no longer allows the installation path to reside on a FAT partition. Setup checks for the partition of the installation directory path on the component selection screen, as well as the following locations:

The System partition



The partition where Exchange binaries are held The partition(s) containing transaction log files The partition(s) containing database files Any partition(s) containing other Exchange files Exchange Management component only (a.k.a. Exchange System Manager-

only) installations. If the partition is non-NTFS, the prerequisite check halts installation. Although this is very reasonable for securing servers, installing Exchange System Manager on workstations may cause minor problems due to the perception that workstations need not be as secure. There is a way to workaround this prerequisite check by mounting a FAT partition to a directory on an NTFS partition. However, the recommended solution is to convert the FAT file system, using the convert /fs:NTFS command.

Message limits reset on installs When the very first Exchange Server 2003 Server is installed into an org, the Sending Message Size and Receiving Message Size will be set to 10,240 KB (10 MB) if the value is not currently set. This also means that on upgrades from Exchange 2000 Server, reinstalls of Exchange Server 2003, or Exchange 2003 service pack upgrades, that the global message size restriction will be set to 10 MB if it isn’t already set. If the message size restriction is already set to some value, then that value will be preserved. Additionally, on every Exchange Server 2003 server installation or upgrade, the Maximum Item Size for Public Folder postings will be set to 10 MB if the value is not already set, and preserved if it is.

NNTP/POP3/IMAP4 services disabled by default As most Exchange 2000 customers did not use the Network News Transfer Protocol (NNTP), Post Office Protocol version 3 (POP3), and Internet Message Access Protocol version 4rev1 (IMAP4) services, Exchange 2003 setup disables them by default in order to prevent any possible protocol attacks. Additionally, on each server installation, upgrade, or reinstallation, the default NNTP Virtual Server Instance is reset so that anonymous auth is disabled. On uninstalls of Exchange Server 2003, NT_Auth will be disabled. Extending this security push to clusters, EVS creation will no longer create the POP3/IMAP4 resources. So for the latter case, customers not only need to enable these services on each node; they must also manually create the POP3 and IMAP4 resources for each virtual server. These services/resources will not be affected if in-place upgraded from Exchange 2000 Server.

Non-admins are no longer able to create top-level public folders Due to a relaxed default permissions set, any user in an Exchange 2000 Server organization could potentially litter the public folder hierarchy with tons of top-level folders. Because this was a common administrative problem, Exchange Server 2003 “secures” the public folders from users: The permission to ‘Allow create top level public folder’ has been removed from ‘Everyone’ and ‘Anonymous Logon’ ACEs at the organization container’s level. This ACE is checked during each instance of setup /forestprep.

Message Tracking Logs share is more secure In Exchange 2000, the servername.log share, which contained the message tracking log files, wasn’t secure. The ‘Everyone’ group had access to read the



tracking logs, so attackers could read username and servername information throughout the Exchange organization. In Exchange 2003, the tracking logs share is locked down so that ‘Administrators’ built-in group is the only default ACE.



Troubleshooting Exchange Server 2003 setup failures:

Where to start: There are many different ways setup can go wrong, as there are many distributed processes occurring on the network environment to complete the task. Although the deployment tools avoid many of the directory and DNS mis-configuration problems of past Exchange 2000 Server experiences, problems can still occur. Therefore, you may find that traditional Exchange 2000 Server troubleshooting methods to still apply. Much of this begins with reading from the application event log to determine whether the setup completed, or if the problem logged by the setup program is consistent with the customer’s problem description. A minor new feature in Exchange Server 2003 is the improvement on informational events from the source MSExchangeSetup, and you can expect to see the following at the end of each successful setup session:

Event Category: Microsoft Exchange Setup Event ID: 1001 Description: Exchange Server setup (build 6885) completed successfully.

You should examine the event, error, and setup.log files located in the \Program Files\Microsoft Integration\exchsrvr\logs folder. The setup.log file will tell you which components were selected to be installed, as they are not easy to glean from the progress log (discussed below).

The Exchange 2003 setup engine is not much different from the Exchange 2000 setup process, which was designed to tolerate minor errors. If a minor error occurs during installation, you can correct the cause of the error and continue. In fact, Setup attempts to run as many checks as possible before the actual installation takes place. When you are presented with the component selection, you can determine whether errors occurred during the initial checks. If you see four dashes (----) adjacent to a component instead of Install, it usually means that an error message will occur if you try to perform an action (Install, Remove, and so forth) on that component. The error messages at this stage provide useful information about what the error might be. Setup may be unable



find installed prerequisite services, such as NNTP and SMTP, or the installer doesn’t have the permissions to run setup. Thus, when selecting the install action, you will be warned of the problem.

If the initial Setup checks do not uncover an error, and you proceed to the later stages of setup, a catastrophic failure occurs. Usually, you are notified in which component or action the error occurred, and then given a hexadecimal error number; for example, 0xC0070430. If you encounter such an error, try clicking Retry because a transient error may have occurred on either the local computer or network. For example, the error code earlier in this paragraph indicates that Setup attempted to install a service that already exists. You might get this error if you are reinstalling the server after a failed attempt. If you are not proceeding in Setup after you click Retry, use the Knowledge Base to see if the error is known.

Your next step is to look at the progress log in the root directory of your system partition. Exchange 2003 setup will always generate or append to the Exchange Server Setup Progress.log file. In cases where you are joining the first Exchange 2003 server to an Exchange 5.5 site, the SRS and configuration connection agreement must be created. Any replication errors between Active Directory and the SRS would appear in the Active Directory Connector.log file.

The progress log contains extremely detailed lists of all functions called and the results of the Setup process. Because you need the source code to understand the function names, not everything in the progress log is recognizable. However, by viewing the contents of a log file, you can discover reasons why Setup failed.

Progress logs are concatenated. This means that all Setup attempts are recorded in one long file, so it is best to go to the end of the file and work backwards. Just plant the cursor at the last byte of the progress log, and search upwards for errors. Some useful keywords to search on are the word “failed,” and snippets of text/error codes from popup dialogs during the setup session, such as “0xC0070430” from the previous example.

Note that setup errors can be either soft or hard, and both kinds of errors appear in the logs. Soft errors are ignored by the Setup process, and you will not see a visual indication of them in the user interface. Here is a prime example of a soft error:

[09:49:41] ScGetClusterSvcDir (l:\admin\src\libs\exsetup\exmisc.cxx:2339) Error code 0XC0070424 (1060): The specified service does not exist as an installed service.

Setup is attempting to access the shared cluster directory. If your computer is not in a cluster, you would expect to see this error. After the soft errors, you see a statement in the logs that indicates that these errors were ignored:

[09:49:41] === IGNORING PREVIOUS ERRORS === CFileManager::ScAutoDetectDirectoryLocations (l:\admin\src\udog\setupbase\tools\filemgr.cxx:569) The operation has completed successfully.

Interestingly, you see the file name and path to the source code in these errors. One of the most interesting sections of the progress log is the following:



[10:56:58] Setup configuration information: -- ID:62227 -- [10:56:58] This is a(n) Enterprise version of Microsoft Exchange Server -- ID:62232 -- [10:56:58] This is an evaluation copy of Microsoft Exchange Server; it expires in 360 days -- ID:62233 -- [10:56:58] InstallSourceDir = d:\setup\i386\exchange -- ID:62228 -- [10:56:58] InstallDestDir = C:\Program Files\Exchsrvr -- ID:62228 -- [10:56:58] InetSrvDir = C:\WINNT\System32\inetsrv -- ID:62228 -- [10:56:58] System32Dir = C:\WINNT\System32 -- ID:62228 -- [10:56:58] LocalServer = TILAB-DC02 -- ID:62228 -- [10:56:58] SchemaMasterDC = TILAB-GC01 -- ID:62228 -- [10:56:58] DC = TILAB-DC02 -- ID:62228 -- [10:56:58] Domain = tilab.gsx -- ID:62228 -- [10:56:58] DomainDN = /dc=gsx/dc=tilab -- ID:62228 -- [10:56:58] NetBIOSDomain = TILAB -- ID:62228 -- [10:56:58] NT5Site = Default-First-Site-Name -- ID:62228 -- [10:56:58] Org = Microsoft -- ID:62228 -- [10:56:58] LegacyOrg = Microsoft -- ID:62228 -- [10:56:58] AdminGroup = GSXSite1 -- ID:62228 -- [10:56:58] LegacyAdminGroup = GSXSite1 -- ID:62228 -- [10:56:58] AdminGroupContainingRoutingGroup = GSXSite1 -- ID:62228 -- [10:56:58] RoutingGroup = GSXSite1 -- ID:62228 -- [10:56:58] 55ServiceAccountLogin = Uninitialized -- ID:62229 -- [10:56:58] PTAdministratorAccount = TILAB\exservice -- ID:62228 -- [10:56:58] This is not a clustered machine -- ID:62231 –

The most important information included in this excerpt concerns the domain controller from which the server reads Active Directory. You can also see the schema master here, so if you receive an error saying that Setup cannot contact the schema master, you can find the computer name of the schema master and try to contact it manually.

Short names are used frequently in the logs. It helps if you understand some of them, such as the following:

Whether the installation process is successful or unsuccessful, the last entry in the log indicates that the Setup process is being removed from memory, and looks something like the following:

[16:03:46] CComBOIFacesFactory::QueryInterface (K:\admin\src\udog\BO\bofactory.cxx:52) Error code 0X80004002 (16386): No interface.

The log files may provide more information than you need. Fortunately, there is a tool called LogParser (\\exutils\exes\logparser\2003) that reads the progress logs and presents them to you in a format that is easier to read. This does not



mean that LogParser translates errors, but it does show you the individual installation attempts and categorizes the errors.

New to Exchange 2003 is this new entry that appears in all progress logs. Logparser sees it as a “hard error,” but it may be safely ignored:

GetServerAppletalkAddress (f:\df6803\admin\src\udog\excommon\ptudutil.cxx:1917) Error code 0X00273F (10047): An address incompatible with the requested protocol was used.

In summary, troubleshooting the progress log file can be straightforward, even though you do not know what any functions mean: Simply gather as much information relating to which setup options were selected for which components (i.e. typical, custom, change, remove, etc.), and use logparser to locate the date and time of the problem setup session. When you locate the failure in the progress log, refer to the Knowledge Base; otherwise, examine the calls that are made at or around the error. At times, you may find it necessary to troubleshoot at a lower layer, such as obtaining a network trace between the installing server and a domain controller, to determine why setup is failing.



General Log Flow

In a full length setup log instance (a log instance from a successful setup), the general, high-level flow of logged information is as follows (colors stand for phases of setup: Initialization (plum/burgundy), PreSetup (orange), Setup (blue), PostSetup (red)

Initialization

Beginning of log Setup initialization

o Gathering of domain information o Checking domain schema version o Gathering Exchange org information o Checking permissions

Dump of component selection o Checking for prerequisites

Configuration information o Install source and destination directories o Local server, schema master server, domain controller server o Domain information, o Exchange org information o Service and Administrator Account information

PreSetup

Setting installation action on selected components OrgPrep actions (ForestPrep, DomainPrep), as appropriate Stopping of services Creation of file copy queues File copy

SetUp

Installation of components/subcomponents o Registry entries

Delivery Tip Student workbooks will not see color. Instructors may want to display the electronic file information in color to illustrate.



o Creation of directory objects o Metabase entries

Post-Setup

Post-Setup o Start services

How a Log Instance Begins: The first line of every log instance looks like this:

[04:12:39] ************** Beginning Setup run **************

The second line of every log entry is also the same:

[15:33:20] Starting Exchange 6885 setup on Windows 5.2.3765. at 15:33:20 02/24/2003

Notice the Exchange version information, the operating system version information, and the time/date information.

Strategy Tip: Because each log instance is appended to each previous instance in the log, it can be difficult to find the Setup log instance you’re interested in. To quickly scan through the instances in the log, cut and paste a portion of the first line, without the time stamp (************** Beginning Setup run **************) into a Search window. As you encounter each instance in the log, quickly scan the second line of the instance to find Exchange version information, as well as the time/date stamp of that particular setup. Of course, you can also continue searching until you find the last entry of the first-line text, which will be the start of the log instance for the most recently run Setup (up to and including any in-progress setup.exe or update.exe).

How a Log Instance Ends: The Setup log always has as its last entry (except when viewed in-progress, or when setup ended prematurely):

[13:36:40] CComBOIFacesFactory::QueryInterface (k:\admin\src\udog\bo\bofactory.cxx:54) Error code 0X80004002 (16386): No interface.

The error code in this case is expected.

Terminology The progress log will be scattered with component names or their nicknames, as well as notes from prior versions of Exchange. Use the following table to decipher what a progress log is trying to check:

55 = Exchange Server 5.5 Osmium = Exchange Server 5.5 Oz = Exchange Server 5.5



Pt or Platinum = Exchange 2000 Server PtOz = Mixed Exchange 5.5 and Exchange 2000 site or organization Udog = Exchange Setup Underdog = Exchange Setup Cartman = BackOffice Setup MSIExec = Windows installer service

For example, CAtomPtOz::ScLaunchADCToSynchPtWithOzTopology may be seen from a customer’s log. You can figure-out that setup is at a phase where it’s probably instructing the ADC to replicate the configuration connection agreement, thereby replicating Active Directory and the Exchange 5.5 naming context (via the SRS).

Configuration Information One of the first places to look for an idea of how Exchange Setup interpreted your domain, org, and accounts is in the configuration information section of the log. The configuration information looks like this:



[15:45:12] Setup configuration information: -- ID:62227 -- [15:45:12] This is a(n) Enterprise version of Microsoft Exchange Server -- ID:62232 -- [15:45:12] This is not an evaluation copy of Microsoft Exchange Server; it will not expire -- ID:62234 -- [15:45:12] InstallSourceDir = c:\ti6885.0\setup\i386\exchange -- ID:62228 -- [15:45:12] InstallDestDir = C:\Program Files\Exchsrvr -- ID:62228 -- [15:45:12] InetSrvDir = C:\WINDOWS\system32\inetsrv -- ID:62228 -- [15:45:12] System32Dir = C:\WINDOWS\system32 -- ID:62228 -- [15:45:12] LocalServer = DARKWINGDUCK -- ID:62228 -- [15:45:12] SchemaMasterDC = DARKWINGDUCK -- ID:62228 -- [15:45:12] DC = DARKWINGDUCK -- ID:62228 -- [15:45:12] Domain = darkforest.internal -- ID:62228 -- [15:45:12] DomainDN = /dc=internal/dc=darkforest -- ID:62228 -- [15:45:12] NetBIOSDomain = DARKFOREST -- ID:62228 -- [15:45:12] NT5Site = Default-First-Site-Name -- ID:62228 -- [15:45:12] Org = Microsoft -- ID:62228 -- [15:45:12] LegacyOrg = Microsoft -- ID:62228 -- [15:45:12] AdminGroup = First Administrative Group -- ID:62228 -- [15:45:12] LegacyAdminGroup = First Administrative Group -- ID:62228 -- [15:45:12] AdminGroupContainingRoutingGroup = First Administrative Group -- ID:62228 -- [15:45:12] RoutingGroup = First Routing Group -- ID:62228 -- [15:45:12] 55ServiceAccountLogin = Uninitialized -- ID:62229 -- [15:45:12] PTAdministratorAccount = DARKFOREST\Administrator -- ID:62228 -- [15:45:12] This is not a clustered machine -- ID:62231 --

With the configuration information, a user can tell which is the Schema operations master setup is trying to contact, which domain controller setup has contacted, what domain it thinks it is a part of, and often what account has been granted installation permissions (PTAdministratorAccount).

How Failures Get Logged There are several ways for Exchange Setup to “fail”. Many of these have been anticipated, and checks are made to ensure that the conditions leading to such failures are not present. These checks constitute Setup prerequisites. Prerequisite “failures” should happen early – usually when a user attempts to set an illegal installation action on the Component Picker page. In these cases the user will be presented with the prerequisite failure message through the UI. However, in the case of unattended setups, the UI is never presented, so the user must go to the logs to determine the cause of failure. Multiple prerequisite messages may be logged together.



A prerequisite failure will occur in the initialization phase of setup, and looks like this:

[04:12:39] Prerequisites for Microsoft Exchange Messaging and Collaboration Services failed: Multiple components cannot be assigned the requested action(s) because: - Setup is unable to access the Windows 2000 Active Directory - Failed to look up the Windows 2000 site to which this computer belongs. Please verify that your computer is configured with correct site information and is in a Windows 2000 domain where the domain controller is reachable.

The component "Microsoft Exchange Messaging and Collaboration Services" cannot be assigned the action "Install" because: - The NNTP component of Microsoft Internet Information Services (IIS) is not installed

If a user has successfully launched setup, satisfying all the Exchange setup prerequisites, there are several kinds of setup errors that are logged to the progress log, some of which are expected. Whenever setup attempts to perform an action, and that action fails, an error is returned. In many cases we expect failure, so you will see many errors logged like this:

[16:05:11] CService::ScQueryServiceConfig (f:\df6885\admin\src\libs\exsetup\service.cxx:539) Error code 0XC0070424 (1060): The specified service does not exist as an installed service. [16:05:11] Service = 'MSExchangeSRS' CServiceManager::ScGetServiceInfo (f:\df6885\admin\src\udog\setupbase\tools\svcmgr.cxx:415) Error code 0XC0070424 (1060): The specified service does not exist as an installed service. [16:05:11] Service = 'MSExchangeSRS' CServiceManager::ScStartService (f:\df6885\admin\src\udog\setupbase\tools\svcmgr.cxx:481) Error code 0XC0070424 (1060): The specified service does not exist as an installed service. [16:05:11] Failed to start the SRS on server DARKWINGDUCK [16:05:11] CAtomSRS::ScRemoveAllDRCsAssociatedWithLocalServer (f:\df6885\admin\src\udog\exsetdata\components\server\a_srs.cxx:2443) Error code 0XC0070424 (1060): The specified service does not exist as an installed service. [16:05:11] Leaving CAtomSRS::ScRemoveAllDRCsAssociatedWithLocalServer [16:05:11] === IGNORING PREVIOUS ERRORS === ScRemoveAllDRCsAssociatedWithLocalServer called from CAtomSRS::ScRemoveDSObjects (f:\df6885\admin\src\udog\exsetdata\components\server\a_srs.cxx:1967) The operation has completed successfully.



In these cases, setup may be trying to query the status of a service it has not yet created, or starting a service that is not installed, or trying to clean up directory objects that do not exist.

However, in the case of a fatal string of errors, you might see something more like this (notice the component error message, in bold):



[11:13:59] The command "x:\Exchange Server 2003\rtm\6623.0\server\rtl\usa\setup\i386\exchange\adc" -console -RO -CA "cn=Config CA_FirstAG_EXSETUPLAB57,cn=Active Directory Connections,cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=alextestdom22,dc=extest,dc=microsoft,dc=com" -dc EXSETUPLAB64 -log 2 "D:\Active Directory Connector.Log" failed, returning error code -2147467259 (8An unknown error has occurred.). ScCreateProcess (k:\admin\src\libs\exsetup\hiddenw1.cxx:1816) Error code 0XC103798A (31114): An internal component has failed. [11:13:59] CAtomPtOz::ScLaunchADCToSynchPtWithOzTopology (k:\admin\src\udog\exsetdata\components\server\a_ptoz.cxx:462) Error code 0XC103798A (31114): An internal component has failed. [11:13:59] While launching the ADC for synchronization, Setup encountered an error:' Error: 'An internal component has failed.' (k:\admin\src\udog\exsetdata\components\server\a_ptoz.cxx:1045) Error code 0XC103798A (31114): An internal component has failed. [11:13:59] CAtomPtOz::ScAddDSObjects(), while calling ScLaunchADCToSynchPtWithOzTopology (k:\admin\src\udog\exsetdata\components\server\a_ptoz.cxx:1046) Error code 0XC103798A (31114): An internal component has failed. [11:13:59] CAtomPtOz::ScAddDSObjects (k:\admin\src\udog\exsetdata\components\server\a_ptoz.cxx:271) Error code 0XC103798A (31114): An internal component has failed. [11:13:59] CBaseAtom::ScAdd (k:\admin\src\udog\setupbase\basecomp\baseatom.cxx:885) Error code 0XC103798A (31114): An internal component has failed [11:13:59] Service = '' CBaseServiceAtom::ScAdd (k:\admin\src\udog\setupbase\basecomp\basesvcatom.cxx:203) Error code 0XC103798A (31114): An internal component has failed. [11:13:59] CAtomPtOz::ScAdd (k:\admin\src\udog\exsetdata\components\server\a_ptoz.cxx:204) Error code 0XC103798A (31114): An internal component has failed. [11:13:59] mode = 'Install' (61953) CAtomPtOz::ScSetup (k:\admin\src\udog\exsetdata\components\server\a_ptoz.cxx:2176) Error code 0XC103798A (31114): An internal component has failed.



[11:13:59] >>>>>>>>>> Setup encountered a fatal error during Microsoft Exchange Forest Preparation Install component task. CBaseComponent::ScSetup (k:\admin\src\udog\exsetdata\components\forprep\compforprep.cxx:461) Error code 0XC103798A (31114): An internal component has failed.

This is the kind of error that would result in a failed installation.

Strategy Tip for any Error Messages: If you have an instance of setup running, and are being presented with an error message, you can open up the setup log while setup is still running and skip right to the end of the log, which should have as its last entry the error which generated the UI error message. Highlight the last log entry, and several lines above it (look for the closest Entering CAtom… line above the error entry. It will contain the name of the function being called by setup at the time of the failure, which is very useful for tracking down the section of code in which the error occurred), and cut and paste that section into a separate text file. By grabbing the error text in this way, you will make it easier to find in the log later. If you instead continue with the setup, allowing setup to complete, the error message can be difficult to find, “hidden” as it is in the body of the log file.

Strategy for “Retry” dialog boxes: If your setup is hung with a retry/cancel pair of buttons, you are often at a recoverable state if the problem is a transient network error (as mentioned in the Troubleshooting Exchange 2003 failures section). A bad entry in a DNS cache (i.e. negative DNS caching), would be an example of a transient error that can go away if not retried in ten minutes. However, if resolving the root cause requires user interaction, and if the errors in the progress log are vague, there are some utilities you can use to assist in assisting setup to recover:

Use network monitor to capture packets between the installing server, any Exchange 5.5 servers in the site, the ADC server, and the domain controllers and global catalogs chosen by setup (gleaned from the progress log’s configuration information section). Once the capture filter is set, start the capture and immediately hit retry. The server will usually make the same calls (hopefully across the wire) and you can later examine the capture to determine where the problem resides. To keep the number of frames small so that you need not examine extraneous traffic, immediately stop the capture as soon as the “retry/cancel” dialog returns.

If the error message relates to Active Directory Service Interfaces (ADSI), or if the error code in the progress log is accompanied by an LDAP protocol error similar to those listed in 218185 - Microsoft LDAP Error Codes, the directory service is probably from a domain controller. In the case where the problem is reproducible, running setup again using the /chooseDC switch is used to narrow-down the domain controller choices, thereby making it easier to decipher the netmon capture.

If the error code or the surrounding progress log entries mention ‘DAPI’, then you can focus on the Exchange 5.5 directory service. The root cause could just be a simple permissions setting on a naming context. However, in most cases, the root cause is with IIS, WMI, or some other operating system-level



component. Use the clues from the progress log to initiate general troubleshooting in those areas, and contact a platforms specialist in case KB-hunting results in nothing fruitful.

Strategy for common “Exchange 2000” errors: Often, error messages that you search upon will produce search results matching Exchange 2000 errors. Do not discount the errors, as Exchange 2000 and Exchange 2003 setup engines are essentially the same. For example, if you receive a 0xC103798A error during Exchange 2003 setup, and setup is having problems registering a DLL, you may find Exchange 2000 KB article Q245029. Do attempt the workaround in that article, even if the documented DLL is different. It is likely that there is still an Exchange 5.5 exchmem.dll present on the server.

0xC103798A is an EXTREMELY generic error, and so a Knowledge Base resolution should never be used after diagnosing that error code alone. This error means that an internal component has failed, and thus you must ALWAYS dig within the progress log when troubleshooting this. Customers will typically only use the error code before searching in KB, and so their initial problem reports may mislead you by quoting from the KB. Thus, you should always be diligent in obtaining the progress log when troubleshooting.

0X80072030 is another common error code, and it typically means that an object could not be found – either a file on the local disk, a local registry entry, but more typically in the Active Directory. If it is the first two, use filemon or regmon (from www.sysinternals.com) to monitor the setup program. If it is the latter, use network monitor to determine what object the setup program is attempting to use. The packets in the network monitor trace can be viewed by timestamp (Display | Options | Time of Day), and you can correlate these with the timestamps on the errors in the setup progress log.

Strategy for clusters: Unlike single-server installations, where the files are copied and registered and directory service objects are added in a single session, cluster installs are divided into phases. The first phase is the file-copy and registration phase of the binaries onto each node. Here, the setup engine logs to the progress log as usual. However, setup does not create objects in Active Directory. Although setup will declare success for installing on each node, the installation is only partially complete. The second phase involves manipulating the cluster administrator program (cluadmin.exe) to create the necessary resources. At this stage, the setup engine is not running, and instead, cluadmin.exe performs the background processing. Surprisingly, the creation of the Exchange System Attendant resource will write to the setup progress log, logging another session beginning with “Beginning setup run.” So when troubleshooting problems with the System Attendant creation or initial startup, check in 2 places:

The Exchange Server Setup Progress.Log The cluster.log file, located in %windir%\cluster on each node. The

cluster.log file shows important cluster properties such as whether or not a parameter is being set, based upon an application’s needs:

Progress log sometimes misleading: The progress log will usually tell you what actions the user selected on the “Component selection” screen. However, you cannot always trust what the



progress log says the installer has selected. This is because the progress log will pre-process through some of the installation types even before the user has a chance to pick an action from the component picker tree. For example, in a forest containing a single domain controller that already has Exchange 2000 Server SP2 installed, the progress log for Exchange 2003 setup will say:

[09:18:51] Prerequisites for Microsoft Exchange Messaging and Collaboration Services failed: The component "Microsoft Exchange Messaging and Collaboration Services" cannot be assigned the action "Upgrade" because: - The local domain configuration is not up-to-date. You must run setup with the "/DomainPrep" switch within this domain. If you have already done this with the current version of Setup, then you must wait for replication to complete. Consult your documentation for details. - Server Z2 must be a Microsoft Exchange 2000 server with Microsoft Exchange Service Pack 3, or higher, installed.

The above text may mislead you to believe that the installer chose the “upgrade” action, but this is what the progress log contains, even before the user has a chance to choose an action on the component selection screen. Another strategy is to search the progress log for the string “is set to action” for the components’ selected action in the component picker tree. However, these too may show system-selected component actions. You may be inclined at this point to look at the setup.log in \program files\microsoft integration\Microsoft Exchange\logs, but that log only lists the summary of chosen components post-installation.

To accurately determine what action the customer selected during installation, look for a series of looping entries. (These looping entries correspond to user clicks onto the component picker screen itself, but not an action that the user has selected.) At the end of those loops, you may find an entry similar to the following:

[09:39:25] Using cached result for domain "/dc=com/dc=contoso" Following the “cached result” entry, the progress log will show the actual user-selected action. In most cases, it will look exactly like the pre-processed entries from above. However, in some cases, the installer may have chosen another action, such as “remove.”

Troubleshooting setup example: Problem description: Setup shows a popup with “Setup failed while installing sub-component Miscellaneous Atom with error code 0xC1037989 (please consult the installation logs for a detailed description). You may cancel the installation or try the failed step again.” Setup has already exited, and the customer has already attempted to uninstall/reinstall WMI per Q318731. However, the next setup attempt results in the same error.

Troubleshooting steps: If the knowledge base does not produce any hits, you would search for 0xC1037989 from the end of “Exchange server setup progress.log” located at the root of the system partition. Here is the relevant text within the progress log file, when logparser is used to view problems at level 0:



[18:34:08] CInsParser::ScProcessLine (K:\admin\src\libs\exsetup\hiddenw1.cxx:1226) Error code 0XC1037989 (31113): An internal component is not responding. [18:34:08] Processing file 'z:\setup\i386\exchange\Misc.ins', at or near line 10 (CreateProcess:C:\WINNT\System32\WBEM;C:\WINNT\System32\WBEM\mofcomp.exe "C:\WINNT\System32\WBEM\exwmi.mof";600000) CInsParser::ScProcessLine (K:\admin\src\libs\exsetup\hiddenw1.cxx:486) Error code 0XC1037989 (31113): An internal component is not responding. [18:34:08] Registry file name: 'z:\setup\i386\exchange\Misc.ins' CRegistryManager::ScProcessFile (K:\admin\src\udog\setupbase\tools\regmgr.cxx:95) Error code 0XC1037989 (31113): An internal component is not responding. [18:34:08] Filename = '%sourcedir%\Misc' CBaseAtom::ScRefreshRegistryKeys (K:\admin\src\udog\setupbase\basecomp\baseatom.cxx:1217) Error code 0XC1037989 (31113): An internal component is not responding. [18:34:08] CBaseAtom::ScReinstall (K:\admin\src\udog\setupbase\basecomp\baseatom.cxx:1015) Error code 0XC1037989 (31113): An internal component is not responding. [18:34:08] Service = '' CBaseServiceAtom::ScReinstall (K:\admin\src\udog\setupbase\basecomp\basesvcatom.cxx:231) Error code 0XC1037989 (31113): An internal component is not responding. [18:34:08] mode = 'Reinstall' (61955) CBaseAtom::ScSetup (K:\admin\src\udog\setupbase\basecomp\baseatom.cxx:775) Error code 0XC1037989 (31113): An internal component is not responding.

Any of these functions could be causing the problem, and the main clue may likely have appeared when setup runs the misc.ins script. Since setup has already exited, you may often find that manually running some of the commands that setup attempted will reveal more clues: When running ‘mofcomp.exe "C:\WINNT\System32\WBEM\exwmi.mof” from the command prompt revealed that it was successful after 25 minutes (1,500,000 milliseconds), this meant that the 600,000 millisecond sleep parameter wasn’t enough. At this point, one would copy all of the setup files to the hard drive, modify line ten of the misc.ins script file by bumping-up the sleep time, and then rerun setup. In this case, setup proceeded past this point and completed successfully.



Lab 1.2: Logparser and examination of progress logs

Objective: This lab will get the student familiarized with logparser and significant sections of the progress log. Answers are in Appendix A, but the learning experience will be ruined if answers viewed prematurely.

1. Power on any virtual machine (preferably SOLO since we will be using it in the next lab).

2. Mount the “Admin_Labfiles.ISO” CD image into the virtual machine. 3. Open the file d:\module1_setupquestions\question1.log using notepad. 4. Can you tell what option(s) were set during component selection?

5. Open the Exchange Server Setup Progress log from

d:\module1_setupquestions\question2.log. Can notepad easily show you how many times setup was run?

6. Navigate to the D: drive and install the new version of the logparser utility. 7. Launch logparser and reopen the question2.log. How many times was setup

run? (Hint: The number of sessions is on the upper-left panel of logparser) 8. When was Exchange initially installed? Which version was it? 9. What version was the most recent install? Was it successful? 10. On the last setup session, is the user installing into the forest root domain?



11. Try to find out the scenario (i.e. pure Exchange 2003, mixed Exchange 2003 with Exchange 5.5, Exchange 2003 and Exchange 2000, or all server versions (5.5/2000/2003) installed) (Hint, if logparser only has configuration information checked, you might find useful data.)

12. Open the Exchange Server setup progress log from d:\module1_setupquestions\question3.log

13. Was setup successful? Did the services start? 14. If the customer says that his Exchange services are inoperable, and he sent

you progress3.log, can you explain why it is not operable? Do you think the stores mounted?

15. Open the Exchange Server setup progress log from

d:\module1_setupquestions\question4.log 16. Was the /chooseDC switch used? 17. How many administrative groups exist in the Exchange organization? Do

we have proper permissions to read them?

Other questions: 18. Marker checks are enforced in which of the following scenarios? (Check all

that apply) a) Setup of a new Exchange 2003 server in a site where Exchange 5.5 and

Exchange 2000 servers exist b) Setup of a new Exchange 2003 server in a site where Exchange 2003

and Exchange 5.5 servers exist c) Setup of new Exchange 2003 server in a site where Exchange 5.5 exists d) Setup of new Exchange 2000 server in a site where Exchange Server

5.5 and Exchange 2000 Server exist e) Setup of new Exchange 2000 server in a site where only one Exchange

Server 2003 server already exists. 19. T/F: There are a fixed number of atoms running during setup.



Lab 1.3: Applying troubleshooting concepts

Objectives: In the next three exercises, students will

practice troubleshooting using the above procedures. recognize that even the simplest of problems are ambiguous.

Exercise 1: In this exercise, students will troubleshoot an upgrade from Exchange 2000 SP3 to Exchange Server 2003 build 6851. There is a specific problem to this pre-release build that does not exist in the released/shipped build. However, we can practice troubleshooting using the procedures discussed in the troubleshooting lesson.

Lab setup: Power-on “Solo.”

Username: Standalone\Administrator

Password: password

“Solo” is a Windows 2000 SP3 domain controller running Exchange 2000 Server SP3. It is a standalone server with no complicated components (no SRS or installed connectors). Exchange Server 2003 build 6851 forestprep and domainprep have already been executed without problems.

1) Use Logparser to examine the existing progress log file on the C: drive. Can you determine if forestprep and domainprep have already been executed? Were there any problems with those installs?

2) Mount the Exchange 2003 beta build (6851) .ISO image onto the virtual CD ROM drive, and start the server upgrade process. Setup will fail catastrophically during the setup phase. DO NOT choose the CANCEL button!

3) For each time you choose “retry” confirm that you see “Retrying failed operation.” DO NOT choose the CANCEL button!

4) Make a copy of the setup progress.log file, and you may run logparser against that copy. (The reason we choose to make a copy is because the logparser cannot open the file that is already locked by setup. Similarly, if logparser opens a previous progress log, a new setup instance cannot append to the progress log because is locked. Then, setup will resort to creating a new progress log with a “2” suffix.) DO NOT choose the CANCEL button! As in the upgrade scenario, pressing cancel will result in a partial/broken installation.

5) Proceed to troubleshoot only using logparser against the progress log file.

Instructor notes: The mssearch service has been disabled. In this simple exercise, students are to simply review the progress log file while they get the “retry/cancel” option. They should open the progress log, view the last setup session, and look for these errors:



[16:58:04] Entering CAtomMDB::ScInstallCreateSearchApplication

[16:58:04] Creating Microsoft Search application

[16:58:04] Creating search admin component

[16:58:04] Getting the applications interface

[16:58:04] CAtomMDB::ScInstallCreateSearchApplication (f:\df6803\admin\src\udog\exsetdata\components\server\a_mdb.cxx:1975)

Error code 0X80070422 (1058): The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

[16:58:04] Leaving CAtomMDB::ScInstallCreateSearchApplication

[16:58:04] Entering CAtomMDB::ScPauseSearchFullPopulation

[16:58:04] Entering CAtomMDB::ScGetBuildCatalogsInterface

[16:58:04] Creating search admin component

[16:58:04] Getting the applications interface

[16:58:04] CAtomMDB::ScGetBuildCatalogsInterface (f:\df6803\admin\src\udog\exsetdata\components\server\a_mdb.cxx:2253)


[16:58:04] Leaving CAtomMDB::ScGetBuildCatalogsInterface

[16:58:04] CAtomMDB::ScPauseSearchFullPopulation (f:\df6803\admin\src\udog\exsetdata\components\server\a_mdb.cxx:2352)


[16:58:04] Leaving CAtomMDB::ScPauseSearchFullPopulation

[16:58:04] CAtomMDB::ScRefreshMDBDSObjects (f:\df6803\admin\src\udog\exsetdata\components\server\a_mdb.cxx:835)


[16:58:04] Leaving CAtomMDB::ScRefreshMDBDSObjects

[16:58:04] CAtomMDB::ScRefreshDSObjects (f:\df6803\admin\src\udog\exsetdata\components\server\a_mdb.cxx:627)


[16:58:04] Leaving CAtomMDB::ScRefreshDSObjects



[16:58:04] CBaseAtom::ScReinstall (f:\df6803\admin\src\udog\setupbase\basecomp\baseatom.cxx:1138)


[16:58:04] Service = 'MSExchangeIS' CBaseServiceAtom::ScReinstall (f:\df6803\admin\src\udog\setupbase\basecomp\basesvcatom.cxx:247)


[16:58:04] Leaving CBaseServiceAtom(Information Store Service)::ScReinstall

[16:58:04] CBaseServiceAtom::ScUpgradeFrom2000 (f:\df6803\admin\src\udog\setupbase\basecomp\basesvcatom.cxx:418)


[16:58:04] Leaving CBaseServiceAtom(Information Store Service)::ScUpgradeFrom2000

[16:58:04] mode = 'Upgrade' (61968) CBaseAtom::ScSetup (f:\df6803\admin\src\udog\setupbase\basecomp\baseatom.cxx:841)


The strategy is to look a few lines above the initial error for the calling function. They will see that setup tried to create the MSSearch service. Hopefully, the students will understand that this Exchange 2000 service was disabled, and it must be re-enabled. Once started, they hit the retry button, and the upgrade to Exchange 2003 proceeds.

When you are finished with your troubleshooting and have proceeded through the upgrade past the point of failure, power off the virtual machine and discard changes on the undo drive.

Exercise 2: Turn on the virtual machine located in the “SetupExercise2” folder.

Servername: Z2

Username: MS\Administrator

Password: Password1



This virtual machine is similar to the virtual machine in the first exercise. Practice upgrading and troubleshooting the errors you encounter. You may use the release bits (Ti6844.4) to perform the upgrade.

In this exercise, the disk is near capacity, but not full enough for setup to fail the prerequisite check. The GUI portion of setup should fail without any indication of a true reason. Thus, students have an opportunity to investigate using the progress log. When you are finished with this lab, power off Z2 and discard any changes to the undo drive.

Exercise 3: Upgrading a cluster The purpose of this exercise is to observe the steps required for a rolling upgrade on a cluster. There is nothing “broken” in this configuration.

Power on the cluster nodes 1 and 2 located in the “c:\vms\flats\module 1 - setup*” folder (or it may be called something similar). Please be sure not to start the cluster virtual machines from module #5 (Clustering Lab).

Setup: Each cluster node is also a domain controller. Note: This configuration is meant to optimize lab equipment; it is not a recommended configuration in reality, as cluster nodes should not reside on domain controllers.

1. What build of Exchange Server 2003 is installed? 2. Open cluster administrator 3. Right-click on the EXVS1 group. What new option do you see? 4. Right-click on the system attendant resource. Observe that the same option

is selectable. 5. In the “net name test” cluster group, create a new System Attendant

resource. 6. Open the setup progress log using logparser (located on the desktop).

Although you never ran setup.exe, do you see any changes? 7. Mount the Ti6944.4EntEval.ISO image to the virtual machine. 8. Upgrade each node via rolling upgrade (refer to getting started guide). But

instead of choosing “upgrade” on the component selection screen, choose “reinstall.”



Appendix A: Answers 1.2.4: "The component Microsoft Exchange is set to "Reinstall"

1.2.5: Not really. If we wanted to find out, we'd need to search for the string "Beginning Setup" or patterns of asterisks ("*****") and count the lines they occur.

1.2.6: Nine times

1.2.8: Setup was run on 1/13/2003. This was Exchange 2000 Server release build (4417)

1.2.9: Build 6895. No, it was not successful because this entry does not exist at the end:

CComBOIFacesFactory::QueryInterface (f:\df6895\admin\src\udog\bo\bofactory.cxx:54) Error code 0X80004002 (16386): No interface. Instead, it was probably killed in the middle of a dialog box.

1.2.10: No, this is where we can make use of our "m_str" searches to find server role information. All in the same general area, we find:

DSROLE_PRIMARY_DOMAIN_INFORMATION::DomainNameFlat = "MLABNET" DSROLE_PRIMARY_DOMAIN_INFORMATION::DomainNameDns = "mlabnet.com" DSROLE_PRIMARY_DOMAIN_INFORMATION::DomainForestName = "mlabroot.com"

m_strRootDomain = "mlabroot.com"

In this case, the user is installing to some other domain in the forest (mlabnet.com) that appears to be a root of its own tree. The forest root domain is mlabroot.com.

1.2.11: Not likely to have Exchange 5.5 in the environment, because 55serviceaccountlogin is uninitialized. Furthermore, there are no hrdirprereq* strings anywhere in the log. This is likely a Pure Exchange 2003 or Exchange 2000/2003 admin group. However, this cursory inspection doesn't rule-out the possibility that there might be an Exchange Server 5.5 server in some other admin group in the org.

1.2.13: Yes, setup was successful from seeing this string:

!!!!!!!!!!Setup completed successfully! And a few lines above that, we see many services starting.

1.2.14: The server is not operational because this was a cluster node installation. And as such, no Active Directory objects were created representing the server or its stores. So users will not be able to use it until a virtual server



has been created, which in turn creates the IS resource, in which case the stores can mount. In its present state, no stores are mounted.

1.2.16: No, setup chose its own suitable domain controller for setup:

No user-specified DC; setup has chosen m_strDC = "CRPDALDCS00"

1.2.17: Four administrative groups exist, and we do have perms to read:

[08:28:00] Enumerating all admin groups in the org [08:28:00] Found 4 admin groups [08:28:00] Checking permissions on the admin group: /dc=com/dc=testofamerica/cn=Configuration/cn=Services/cn=Microsoft Exchange/cn=Bank of America/cn=Administrative Groups/cn=ASIA Administrative Group [08:28:00] We have permission ExchAG_Read [08:28:00] We have permission ExchAG_Write [08:28:00] We have permission ExchAG_SetPerms [08:28:00] Checking permissions on the admin group: /dc=com/dc=testofamerica/cn=Configuration/cn=Services/cn=Microsoft Exchange/cn=Bank of America/cn=Administrative Groups/cn=EMEA Administrative Group [08:28:00] We have permission ExchAG_Read [08:28:00] We have permission ExchAG_Write [08:28:00] We have permission ExchAG_SetPerms [08:28:00] Checking permissions on the admin group: /dc=com/dc=testofamerica/cn=Configuration/cn=Services/cn=Microsoft Exchange/cn=Bank of America/cn=Administrative Groups/cn=North American Administrative Group [08:28:00] We have permission ExchAG_Read [08:28:00] We have permission ExchAG_Write [08:28:01] We have permission ExchAG_SetPerms [08:28:01] Checking permissions on the admin group: /dc=com/dc=testofamerica/cn=Configuration/cn=Services/cn=Microsoft Exchange/cn=Bank of America/cn=Administrative Groups/cn=Routing Adminisrative Group [08:28:01] We have permission ExchAG_Read [08:28:01] We have permission ExchAG_Write [08:28:01] We have permission ExchAG_SetPerms [08:28:01] Final set of permissions: 0XF0C0E0E0

1.2.18: A and C. (B is not an answer because the first Exchange 2003 server install had already performed its marker checks)

1.2.19: False. The number of atoms running varies, depending on the scenarios detected, and which options the installer chooses from the component picker.



Acknowledgments Microsoft Employee Vincent Yim

Max Vaysburg, Ross TenEyck, Alexander MacLeod, Gwen Zierdt, Bryan Atwood

KB article 823145 XADM: Exchange 2003 Server Setup and Installation Top Support

Issues

Module 1: Setup Changes - gattner.namegattner.name/simon/public/microsoft/MS Exchange/70-284...

Documents

Transcript of Module 1: Setup Changes - gattner.namegattner.name/simon/public/microsoft/MS Exchange/70-284...