Objects

An object is the basic unit in Active Directory. It is a distinct named set of attributes that
represents something concrete, such as a user, printer, computer, or application. Attributes
are the characteristics of the object; for example, a computer is an object, and its
attributes include its name and location, among other things. A user is also an object. In
Exchange, a user’s attributes include the user’s first name, last name, and e-mail address.
User attributes also include Exchange-related features, such as whether the object can
receive e-mail, the formatting of e-mail it receives, and the location where it can receive
e-mail

Group Types

Windows 2003 Active Directory supports the following two group types:

• Security Groups – Used for assigning permissions for directory

objects and resources such as shared folders and printers. Security
groups are also used for assigning right to users, for example by
using Group Policies.
• Distribution Groups – Used for creating e-mail distribution lists (ie.
for MS Exchange server). It allows a user to send e-mail to all the
members by using a single address.

You can change the group type from security to distribution, or vice versa,
if the domain functional level is set to Windows 2000 native or Windows
2003. Group types cannot be changed if the domain is running in Windows
2000 mixed mode.

Group Scopes

A group scope defines from which domain from which members can be
added and in which domain, tree, of forest, rights and permissions can be
assigned to a group. When you create a new group, it will be a security
group with global scope by default. You can modify the group scope if the
domain functional level is set to Windows 2000 native or Windows Server
2003. Changing a group scope in Windows 2000 mixed mode domains is
not possible.

Windows 2003 Active Directory supports the following three group scopes:

• Domain Local – Used for assigning permissions within the local

domain only. A domain local group can contain user accounts and
 global and universal groups with from any domain, and other
domain local groups from the same domain. A domain local group
can be changed to a universal group only if it does not have other
domain local groups as its members.
• Global – Used for assigning permissions throughout the entire forest.
A global group can only contain user accounts and global groups
from the same domain the global group is in. If the domain is
running in Windows 2000 Mixed mode, you can add only user
accounts to a global group. A global group can be changed to a
universal group if it is not a member of another global group.
• Universal – Used for assigning permissions throughout the entire
forest. A universal group can contain user accounts, computer
accounts, and global and universal groups from any domain in the
forest. Security type universal groups can be created only when the
domain functional level is set to Windows 2000 native or Windows
Server 2003. Opposite to domain local and global groups, universal
groups are replicated to every global catalog in the entire forest. A
universal group can be changed to a domain local group at any time.
A universal group can be changed to a global group only if it does
not have other universal groups as its members.

When you assign permissions to all the users in the Sales department,
for a shared resource, i.e. Printer1, you should create a domain local
group for the sales department, i.e. SalesPrinters, and assign it
permissions for Printer1. Then you should group the users into a global
group, i.e. Sales, and add the global group to the domain local group. A
universal group is particularly useful when the group needs to contain
members from multiple domains. Universal groups should be members
of domain local groups, and have global groups as their members.
http://www.jrksoftware.com/articles/70-292/managing-groups-in-
windows-2003.html

DNS concept and how it works

DNS uses a distributed database that implements a hierarchical naming
system. This naming system enables an organization to expand its
presence on the Internet and enables the creation of names that are
unique both on the Internet and on private TCP/IP-based intranets.

By using DNS, any computer on the Internet can look up the name of
any other computer in the Internet namespace. Computers running
Windows Server 2003 and Microsoft® Windows® 2000 also use DNS to
locate domain controllers and other servers running Active Directory.

Domain Name System (DNS) is a distributed database system for

managing host names and their associated Internet Protocol (IP)
addresses. Using DNS means that people can use simple names, such as
"www.jkltoys.com" to locate a host, rather than using the IP address.
 DNS servers can work together to map all domain names to their IP
addresses. DNS servers working together is what allows computers to
communicate across the Internet.
Understanding zones
DNS data is divided into manageable sets of data called zones. Zones
contain name and IP address information about one or more parts of a
DNS domain. A server that contains all of the information for a zone is
the authoritative server for the domain. Sometimes it may make sense
to delegate the authority for answering DNS queries for a particular
subdomain to another DNS server. In this case, the DNS server for the
domain can be configured to refer the subdomain queries to the
appropriate server.

DNS zone types

You can use iSeries(TM) DNS to define several types of zones to help you manage
DNS data:

Primary zone
Loads zone data directly from a file on a host. A primary zone may contain
a subzone, or child zone. It may also contain resource records such as
host, alias (CNAME), address (A), or reverse mapping pointer (PTR) records.

Note: Primary zones are sometimes referred to as "master zones" in other

BIND documentation.

Subzone
A subzone defines a zone within the primary zone. Subzones allow you to
organize zone data into manageable pieces.
Child zone
A child zone defines a subzone and delegates responsibility for the
subzone data to one or more name servers.

Alias(CNAME)
An alias defines an alternate name for a primary domain name.

Host
A host object maps A and PTR records to a host. Additional resource
records may be associated with a host.

Secondaryzone
Loads zone data from a zone's primary server or another secondary server.
A secondary server maintains a complete copy of the zone for which it is a
secondary.
Note: Secondary zones are sometimes referred to as "slave zones" in other
BIND documentation.
Stubzone
A stub zone is similar to a secondary zone, but it only transfers the name
server (NS) records for that zone.

Forwardzone
A forward zone directs all queries for that particular zone to other servers

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic
=/rzakk/rzakkconceptparent.htm

File Replication Services:

File Replication service (FRS) replicates system policies and logon
scripts stored in System Volume (SYSVOL) and replicates data for
Distributed file system (Dfs).
File Replication Service (FRS) is used for synchronizing the SYSVOL shared
folders on domain controllers and for synchronizing DFS link targets on
servers running Windows 2000 and Windows Server 2003. If you are using
Windows Server 2003 R2 and want to keep folders synchronized, we
recommend using DFS Replication.
Windows 2000 domain controllers and servers use FRS to replicate
system policy and logon scripts for Windows 2000 and down-level
clients. You can also use FRS to replicate files and folders between
Windows 2000 servers that host the same fault-tolerant Distributed
File System (DFS) root or child replicas.

Ntfrsutl
See a snapshot view of the FRS internal state with this tool that ships
with Windows Servver 2003 and is available in
%systemroot%\system32. You must have an understanding of the
internal operation of FRS to effectively use this tool.

• FRSDiag
Use this tool to easily gather FRS related information from specific
servers and perform processing on the collected data to detect common
failure conditions.

Kerberos -- a security system that authenticates users. Kerberos

doesn’t provide authorization to services or databases; it establishes
identity at logon, which is used throughout the session. The Kerberos
protocol is the primary authentication mechanism in the Windows
2000 operating system.

Active Directory directory service provides both logical and physical

structures for network components.
Logical structures are

• Domains A group of computers that share a common directory

database.

• Domain trees One or more domains that share a contiguous

namespace.

• Domain forests One or more domain trees that share common

directory information.

• Organization units A subgroup of domains that often mirrors the

business or functional structure of the company.

Physical structures are

• Subnets A network group with a specific IP address range and network

mask.

• Sites One or more subnets; they're used to configure directory access

and replication.

Disaster Recovery

Normal Steps Boot in Directory Restore Mode.

Performing an authoritative restore

After the data has been restored, use Ntdsutil.exe to perform the
authoritative restore. To do this, follow these steps:
1. At a command prompt, type ntdsutil, and then press ENTER.
2. Type authoritative restore, and then press ENTER.
3. Type restore database, press ENTER, click OK, and then click Yes.

Restoring a subtree
Frequently, you may not want to restore the whole database because of
the replication impact this would have on your domain or forest. To
authoritatively restore a subtree within a forest, follow these steps:
1. Restart the domain controller.
2. When the Windows 2000 Startup menu is displayed, select Directory
Services Restore Mode, and then press ENTER.
3. Restore the data from backup media for an authoritative restore. To
do this, follow these steps:
a. In Directory Services Restore mode, click Start, point to Programs,
point to Accessories, point to System Tools, and then click Backup to
start the Windows 2000 Server Backup utility.
b. Click Restore Wizard, and then click Next.
c. Select the appropriate backup location, and then make sure that at
least the System disk and System State containers are selected.
d. Click Advanced, and then make sure that you restore junction
points. If you do not use the Advanced menu, the restore process will
not be successful.
e. In the Restore Files to list, click Original Location.
f. Click OK, and then complete the restore process. A visual progress
indicator is displayed.
g. When you are prompted to restart the computer, do not restart.

4. At a command prompt, type ntdsutil, and then press ENTER.

5. Type authoritative restore, and then press ENTER.
6. Type the following command, and then press ENTER:
restore subtree ou=OU_Name,dc=Domain_Name,dc=xxx

Note In this command, OU_Name is the name of the organizational unit

that you want to restore, Domain_Name is the domain name that the
OU resides in, and xxx is the top-level domain name of the domain
controller, such as "com," "org," or "net."
7. Type quit, press ENTER, type quit, and then press ENTER.
8. Type exit, and then press ENTER.
9. Restart the domain controller.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q241594

How to use the Install from Media feature to promote Windows Server
2003-based domain

1. Installing a Windows Server 2003-based domain controller in each

domain where you will be performing IFM promotions.
2. Performing a system state backup from a Windows Server 2003-
based domain controller in each domain where you will be performing
IFM promotions.
3. Restoring the system state backup to the local drive of each
Windows Server 2003-based computer that you want to promote. The
restored system state backup must be from a domain controller in the
same domain that the new domain controller will be promoted in.
4. Promoting the domain controllers that you installed in step 1 by
using the Active Directory Installation Wizard.

DCPROMO /ADV
http://support.microsoft.com/?id=311078

Installing and Configuring CA

---------------------------------------
To install Certificate Services, follow these steps:

=====================================

1. Click Start, point to Settings, and then click Control Panel.

2. Double-click Add/Remove Programs.
3. Click Add/Remove Windows Components.
4. Click to select the Certificate Services check box.
You may receive the following warning message:
After installing Certificate Services, the computer cannot be renamed
and the computer cannot join or be removed from a domain. Do you
want to continue?
Click Yes, and then click Next.
5. Specify the mode to use for Terminal Services, and then click Next.

Note Microsoft recommends that you leave Terminal Services in

Remote Administration mode on a server that is running Small
Business Server 2000.
6. Select the type of certification authority (CA) that the server will be.
Unless there is another CA in the domain, click Enterprise Root CA.
7. Enter the CA Identification information, and then click Next.
8. Select a location for the certificate database and log files, and then
click Next.
You receive the following warning message:
Internet Information Services is running on this server. You must stop
this service before proceeding. Do you want to stop the service now?
Click OK.
9. Click Finish
If you do not already own a certificate from an Internet security
provider, assign a new certificate to the Web site that is hosting OWA.
To do this:
1. Click Start, point to Programs, point to Administrative Tools, and
then click Internet Services Manager.
2. Expand the server object, right-click Default Web Site, and then click
Properties.
If a Web site other than Default Web Site is hosting OWA, open the
properties for that Web site instead of the properties for Default Web
Site.
3. Click the Directory Security tab, and then click Server Certificate.
4. On the first page of the Web Server Certificate wizard, click Next.
5. Click Create a new certificate, and then click Next.
6. Click Send the request immediately to an online certification
authority, and then click Next.
7. Accept the default name for the new certificate, and then click
Next.
8. Type the name of your organization and the name of your
organizational unit, and then click Next.
Typically, the organization name is the name of your organization, and
the organizational unit name is the name of your division or
department.
9. In the Common name box, (For example mail.benchmarkfunds.com)
type the registered FQDN of the server that is running Small Business
Server 2003, and then click Next.
10. Type the geographical information for the certificate, and then
click Next.
 11. Click the CA to process the request, and then click Next.
By default, the CA that you created in the "Install Certificate Services"
section is selected.
12. Review the Certificate Request Submission text, and then click
Next.
13. Click Finish.
14. Click View Certificate to view the properties of the certificate.
15. Click OK to close the properties of the certificate.
16. Click OK, and then close Internet Information Services (IIS).

Intraforest Migration

Intraforest migration does not require any special domain

configuration. The account you use to run ADMT must have enough
permissions to perform the actions that are requested by ADMT. For
example, the account must have the right to delete accounts in the
source domain, and to create accounts in the target domain.

Intraforest migration is a move operation instead of a copy operation.

These migrations are said to be destructive because after the move,
the migrated objects no longer exist in the source domain. Because
the object is moved instead of copied, some actions that are optional
in interforest migrations occur automatically. Specifically, the
sIDHistory and password are automatically migrated during all
intraforest migrations.

Interforest Migration

ADMT requires the following permissions to run properly:

• Administrator rights in the source domain.

• Administrator rights on each computer that you migrate.
• Administrator rights on each computer on which you translate
security.

Before you migrate a Windows 2000-based domain to a Windows Server

2003-based domain, you must make some domain and security
configurations. Computer migration and security translation do not
require any special domain configuration. However, each computer
you want to migrate must have the administrative shares, C$ and
ADMIN$.

The account you use to run ADMT must have enough permissions to
complete the required tasks. The account must have permission to
create computer accounts in the target domain and organizational
unit, and must be a member of the local Administrators group on each
computer to be migrated.
To install the password migration DLL:

1. Log on as an administrator or equivalent to the computer on

which ADMTv2 is installed.
2. At a command prompt, run the ADMT KEY sourcedomainpath [*
| password] command to create the password export key file
(.pes). In this example, sourcedomain is the NetBIOS name of
the source domain and path is the file path where the key will
be created. The path must be local, but can point to removable
media such as a floppy disk drive, ZIP drive, or writable CD
media. If you type the optional password at the end of the
command, ADMT protects the .pes file with the password. If you
type the asterisk (*), ADMT prompts for a password, and the
system will not echo it as it is typed.
3. Move the .pes file you created in step 2 to the designated
Password Export Server in the source domain. This can be any
domain controller, but make sure it has a fast, reliable link to
the computer that is running ADMT.
4. Install the Password Migration DLL on the Password Export
Server by running the Pwmig.exe tool. Pwmig.exe is located in
the I386\ADMT folder on the Windows Server 2003 installation
media, or the folder to which you downloaded ADMTv2 from the
Internet.
5. When you are prompted to do so, specify the path to the .pes
file that you created in step 2. This must be a local file path.
6. After the installation completes, you must restart the server.
7. If you are ready to migrate passwords, modify the following
registry key to have a DWORD value of 1. For maximum
security, do not complete this step until you are ready to
migrate.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\AllowPas
swordExport

http://www.petri.co.il/active_directory_migration_tool_usage_w2k_wi
ndows_2003.htm

DHCP Superscope

A superscope is an administrative grouping of scopes that can support

multiple logical IP subnets on the same physical subnet. Superscopes
contain a list of member scopes that can be activated together. You
cannot configure scope-level properties on superscopes; you must
configure these on the member scopes.
A superscope allows a DHCP server to provide leases from more than one
scope to clients on a single physical network.
Dhcp database filename dhcp.mdb
%systemroot\system32\dhcp\
Microsoft KB articles 325473
We can use dhcp exportimport utlility to migrate the dhcp database.
We cannot use dhcpexim tool export import the DHCP database in
windows 2003.
Netsh dhcp server export c:\dhcp.txt

Domain Functional Level

Windows 2000 mixed (Default)

• Supported domain controllers: Microsoft Windows NT 4.0,

Windows 2000, Windows Server 2003 Windows 2000 native

Windows 2000 mixed

• Supported domain controllers: Windows 2000, Windows Server

2003

Windows Server 2003 interim

• Supported domain controllers: Windows NT 4.0, Windows Server

2003

Windows Server 2003

• Supported domain controllers: Windows Server 2003

Forest Functional Level

Windows 2000 (default)

• Supported domain controllers: Windows NT 4.0, Windows 2000,

Windows Server 2003
Windows Server 2003 interim

• Supported domain controllers: Windows NT 4.0, Windows Server

2003. See the "Upgrade from a Windows NT 4.0 Domain" section
of this article.

Windows Server 2003

• Supported domain controllers: Windows Server 2003

Nesting groups

Using nesting, you can add a group as a member of another group. You
nest groups to consolidate member accounts and reduce replication
traffic.

Nesting options depend on whether the domain functionality of your

Windows Server 2003 domain is set to Windows 2000 native or
Windows 2000 mixed. Groups in domains set to the Windows 2000
native functional level or distribution groups in domains set to the
Windows 2000 mixed functional level can have the following members:

• Groups with universal scope can have the following members:

accounts, computer accounts, other groups with universal scope, and
groups with global scope from any domain.

• Groups with global scope can have the following members: accounts
from the same domain and other groups with global scope from the
same domain.

• Groups with domain local scope can have the following members:
accounts, groups with universal scope, and groups with global scope,
all from any domain. This group can also have as members other
groups with domain local scope from within the same domain.

Security groups in domains set to the Windows 2000 mixed functional

level are restricted to the following types of membership:

• Groups with global scope can have as their members only accounts.

• Groups with domain local scope can have as their members other
groups with global scope and accounts.
Security groups with universal scope cannot be created in domains
with the domain functional level set to Windows 2000 mixed because
universal scope is supported only in domains where the domain
functional level is set to Windows 2000 native or Windows Server 2003
.

NTLM

The NTLM protocol was the default for network authentication in the
Windows NT 4.0 operating system. It is retained in Windows 2000 for
compatibility with down-level clients and servers. NTLM is also used to
authenticate logons to standalone computers with Windows 2000.
Computers with Windows 3.11, Windows 95, Windows 98, or Windows
NT 4.0 will use the NTLM protocol for network authentication in
Windows 2000 domains. Computers running Windows 2000 will use
NTLM when authenticating to servers with Windows NT 4.0 and when
accessing resources in Windows NT 4.0 domains.*

NTLM uses a challenge-response mechanism for authentication, in

which clients are able to prove their identities without sending a
password to the server. It consists of three messages, commonly
referred to as Type 1 (negotiation), Type 2 (challenge) and Type 3
(authentication). The protocol continues to be supported in Windows
2000 but has been replaced by Microsoft Kerberos as the
default/standard.

Authoritative and Non- Authoritative

The Authoritative Restore feature allows an administrator to select specific

objects or subtrees of objects from an archived Active Directory database
and restore them to a domain controller. Note that doing so causes Active
Directory replication to replicate this restored state (the System State) of
objects, overwriting the copies currently held on all domain controllers
within the domain. The restored objects receive a USN greater than the
current set of domain objects.

If a nonauthoritative restore is performed by using the Windows Backup

utility, the domain controller will contain the settings and entries that
existed in the Domain, Schema, Configuration, and optionally the Global
Catalog Naming Contexts when the backup was performed. Partial
synchronization (replication) from other replicas within the enterprise then
update all naming contexts hosted on the domain controller, overwriting
the restored data.
Windows 2003 supports six types of trusts (although the OS doesn't
support all types for all forest modes):

Tree-root trust--Windows 2003 automatically creates a transitive, two-way

trust when you add a new tree-root domain to an existing forest. Tree-root
trusts let every domain in different trees in the same forest implicitly trust
one another.

Parent-child trust--Windows 2003 automatically creates a transitive, two-

way trust when you add a child domain to an existing domain. This trust
lets every domain in a particular tree implicitly trust one another.

Shortcut trust--When domains that authenticate users are logically distant

from one another, the process of logging on to the network can take a long
time. You can manually add a shortcut trust between two domains in the
same forest to speed authentication. Shortcut trusts are transitive and can
either be one way or two way.

External trust--Administrators can manually create an external trust

between domains in different forests or from a Windows 2003 domain to a
Windows NT 4.0 or earlier domain controller (DC). External trusts are
nontransitive and can be one way or two way.

Forest trust--When two forests have a functional level of Windows 2003,

you can use a forest trust to join the forests at the root. An administrator
can manually create a two-way forest trust that lets all domains in both
forests transitively trust each other. Forest trusts can also be one way, in
which case the domains in only one of the forests would trust the domains
in the other forest. Multiple forest trusts aren't transitive. Therefore, if
forest A has a forest trust to forest B and forest B has a forest trust to
forest C, forest A does not implicitly trust forest C.

Realm trust--An administrator can manually create a realm trust between a

Windows 2003 domain and a non-Windows Kerberos 5 realm. Realm trusts
can be transitive or nontransitive and one way or two way.

Process of Logging On

CTRL+ALT+DEL is pressed, name and password entered, and local or domain logon is
indicated.
If the logon is local, the name and password are checked against the local database. If the
logon is a domain logon, the name and password are encrypted into a key, and timestamp
information is encrypted. This information is sent to the Windows 2000 domain controller
with an authentication request.
The domain controller decrypts the information and checks for a valid timestamp. If the
timestamp is valid, two Kerberos tickets are made and encrypted with the password. The
tickets are sent back to the client computer. The tickets are:
User session key - Used to log on.
User ticket - Used to get other Kerberos tickets for accessing other domain resources.

The client decrypts the tickets and uses the session key to log on.

• The user initiates logon by pressing Ctrl+Alt+Del. This is called the

Secure Attention Sequence. It wakes up Winlogon and displays the
logon credentials window defined in Gina.dll. This foils any Trojan
horse programs that might get in ahead of the operating system and
nab a user's password.
• The user enters an account name and password and selects a
domain in the Domain field of the logon window. As an alternative,
the user could enter a User Principal Name (UPN) in the format
[email protected]. Either name format results in the same actions
on the part of the security system.

UPN Versus Domain\Name Logon Format.A persistent rumor in the

Windows administrator community asserts that entering a username and
domain in Winlogon results in a classic NTLM authentication, whereas
entering a UPN results in a Kerberos authentication. Unlike the
protestations of a certain ex-president, there is absolutely no truth to this
rumor. If the local computer has authenticated in an AD-based domain, the
user will be authenticated using Kerberos regardless of the logon format.
The only difference between using domain\name\password and a UPN is
that the UPN requires a query to a Global Catalog server to extract the
username and domain. Windows Server 2003 and XP clients cache the
results of this query in case a GC server is not available.

• Winlogon takes the user's credentials and passes them to the Local
Security Authority Subsystem, LSASS, which hashes the user's
password using MD4 and then works with the Kerberos package to
authenticate the user.
• The Kerberos package takes the user's password hash and uses it to
construct a TGT request that contains the preauthenticator (a
timestamp encrypted with the user's password hash). (This
transaction does not require Netlogon at either the client or the
domain controller.)
• The KDC service at the domain controller receives the TGT request. If
the user's name exists, the service obtains the user's password hash
from Active Directory and uses it to decrypt the preauthenticator.
• If the KDC fails to decrypt the preauthenticator, or if the timestamp
indicates that it has been replayed or is out of the acceptable time
skew, the authentication fails. The KDC sends a logon failure
notification to the client.
 • If the KDC accepts the preauthenticator as genuine, it gets help from
LSASS to create a PAC for the user. It places the PAC in the
authentication data field of the TGT and returns it inside a reply
message to the user. The TGT is encrypted with the password hash
of the krbtgt account. The entire reply is encrypted with the user's
password hash.
• The Kerberos client decrypts the reply and caches the session key
and TGT in memory, not on disk. It turns the PAC over to LSASS.
• The LSASS uses the information in the PAC to build a local access
token for the user. (It adds the SIDs of any machine local groups that
have the user as a member and any local security policies that apply
to the user.)
• When the TGT expires (the default Time-To-Live is 10 hours), the
client obtains a new TGT from the KDC. This happens transparently
with no service interruption unless no domain controller is available,
in which case the client loses access to the domain until a domain
controller can be made available.

At this point, the console logon is complete. Winlogon passes control

over to Userinit, which downloads and processes Registry-based group
policies and then fires off the Explorer shell in the user's security
context. Any subsequent processes spawned by the user get the user's
access token.

DNS Works Name Resolutions:

1. The client passes a forward lookup query for www.microsoft.com to its

local name server.

2. The local name server checks its zone database file to determine whether
it contains the name-to-IP address mapping for the client query. The local
name server does not have authority for the microsoft.com domain, so it
passes the query to one of the DNS root servers, requesting resolution of
the host name. The root name server sends back a referral to the com name
server.

3. The local name server sends a request to a com name server, which
responds with a referral to the Microsoft name server.

4. The local name server sends a request to the Microsoft name server.
Because the Microsoft name server has authority for that portion of the
domain namespace, when it receives the request, it returns the IP address
for www.microsoft.com to the local name server.

5. The local name server sends the IP address for www.microsoft.com to the
client.

6. The name resolution is complete, and the client can access

www.microsoft.com.

Exchange
Link State Information
Exchange 2000 determines the route that a message takes based on a least-
cost algorithm. Each Exchange 2000 Server computer has a map of the entire
messaging topology of which it is a member. This map, which is represented in
the link state table, is updated regularly and is propagated to all the servers in
the topology, so that each server can determine not only the most inexpensive
route to deliver a message, but also whether all the connectors that comprise
the route are functioning.

The link state table is used on each Exchange 2000 Server computer to store
link state information that is propagated by a link propagation protocol called
the Link State Algorithm (LSA). The link state table is used to evaluate the most
suitable route for message given cost and availability information. The link state
table is only present in memory and is rebuilt from scratch every time the
server is restarted.

The LSA propagates the routing status of the messaging system in close to real
time to all Exchange 2000 Server computers in the system. This has the
following advantages
• Each Exchange 2000 Server computer can determine the best routing option
at the source and therefore avoid sending a message on a path on which a
downstream link is disabled.
• Messages do not bounce between servers because each Exchange 2000 Server
computer can determine whether alternate or redundant links are up or down.
• Message looping problems are eliminated.

Back to the top

How the Link State Recovers

After a link is marked as down, the original routing continues to retry the
connection at 60-second intervals. Even though no message is waiting to
transfer, the routing continues to try to contact the destination server. After a
connection is re-established, the routing notifies the local routing group master
that the connection is available, and the routing group master notifies all
servers in the routing group and routing master servers in other routing groups
that the connection is available.

Routing Group Masters

Link state information is most effective when multiple routing groups are
configured in an organization, particularly if redundant paths are available.
Each routing group has a master server that is fed link state information from
different sources. The master keeps track of the link state data and propagates
that data to the rest of the servers in the routing group. The master is normally
the first server that is installed in the routing group, but you can change the
master in Exchange System Manager; navigate to the routing group, click
Members, right-click the server, and then click Set as Master. When a non-
master server receives new link state information, the non-master server
immediately transfers the link state information to the master, so that other
servers can receive the information about the routing change.

Exchange Mail flow

Step-by-Step Exchange 5.5

• The client composes a message to an external SMTP address.

• After he or she sends the message, it goes to the user's outbox on the
server.

• The Information Store looks at the message and determines whether

the recipient is local or external, in which case the message needs to go
to another server.

• After it is determined that the recipient is external, the message is

flagged for the MTA to pick it up.

• After the MTA picks up the message, it looks at the destination

address. The MTA then looks at the GWART (or Routing Table) to
determine which IMS to route the message to based on the rules of
routing.

• After the route is determined and the message has been routed to the
appropriate server within the Exchange organization, the message is
placed into the MTA's queue for the IMS on the appropriate server.
• The MTA then moves the message from that queue to the MTS-OUT
queue for the Internet Mail Service. At this point, the MTA's job is done.

• The IMS picks up the message from the MTS-OUT (also known as
Outbound Waiting Conversion) queue and streams the message data to
IMAIL in the information store. IMAIL does content-conversion to convert
the message from MDBEF format to SMTP Multipurpose Internet Mail
Extenstions (MIME) or UUencode format.

• After content-conversion is complete, the message is written to the

\Imcdata\Out directory as an 8-digit alphanumeric file name. An entry
is added to the \Imcdata\Queue.dat file. It states that there is a message
now waiting to be delivered, lists the host for which it's destined, and
displays the current status of the message.

• The IMS then reads in the message from the \Imcdata\Out to get the
destination host name.

• If the destination host name is known or if the IMS is set to forward all
mail to a certain host, then the IMS looks to see if this is a host that it
recognizes via the EMAIL DOMAINS lists. If not, it does a domain name
system (DNS) lookup to resolve the host name to an IP address.

• At this point, the IMS makes a connection on port 25 to the destination

host (or the mailer responsible for the destination host) and initiates the
RFC 821 command structure.

• After delivery is complete, the entry for this message is removed from
the \Imcdata\Queue.dat file and the IMS resets for a new message to the
same host or closes the connection if there are no more messages for this
host.

Exchange 2000 Mail flow

SMTP is the Internet standard for transporting and delivering electronic
messages.
The Windows SMTP service is a component of Internet Information Services (IIS)
and runs as part of Inetinfo.exe. Exchange 2000 relies on the Windows 2000
SMTP service as its native transport protocol; therefore Exchange uses SMTP to
route all internal and external messages.
When Exchange is installed, it modifies the SMTP service by extending
the underlying SMTP functionality. Exchange extends SMTP functionality
by:
• Moving management of the SMTP service (by means of SMTP virtual
servers) from the IIS administrative console to Exchange System
Manager.
• Implementing support for link state information. Exchange uses link
state routing to determine the best method for sending messages
between servers, based on the current status of messaging
connectivity and cost.
• Extending SMTP to support the command verbs used to support link
state routing and other Exchange functionality. The following
commands are added when Exchange is installed:
− X-EXPS GSSAPI
− X-EXPS=LOGIN
− X-EXCH50
− X-LINK2STATE
For a list of all the SMTP commands and their definitions, see
“SMTP Commands and Definitions” in Chapter 8.
• Setting up an Exchange Installable File System (IFS) store driver to
allow message retrieval from and delivery to the Exchange store.
• Setting the disk location where messages are queued to
\exchsrv\mailroot\vs 1\pickup. This is the location of the first SMTP
virtual server on the Exchange server. If you add a second SMTP
virtual server, a new location (\exchsrv\mailroot\vs 2\pickup) is
created.
• Implementing support for advanced queuing. Exchange enhances the
queuing capabilities of Windows 2000. The advanced queuing engine
handles underlying transport functions in Exchange.
• Enhancing message categorization. Message categorization is a
process performed by the message categorizer, a component of the
advanced queuing engine. The message categorizer sends lightweight
directory access protocol (LDAP) queries to the global catalog server to
retrieve configuration information stored in Active Directory. The
message categorizer retrieves recipient policy information and
Exchange virtual server information to enable message delivery. It
uses this information to validate the recipient address, to verify that
message limits are not exceeded, and to ultimately determine how the
message is delivered using Exchange routing and SMTP.

Receiving Internet Mail

• If the following conditions exist, an Exchange 2000 server can receive
Internet mail in its default configuration:
• There is a constant connection to the Internet.
• The external DNS servers for your domain must have mail exchanger
(MX) resource records pointing to your mail servers. Your ISP or the
administrative contact for your domain may need to set this up for
you. For information about how to verify your MX records, see “Using
Nslookup to Verify DNS Configuration” in Chapter 5.
• Your mail server must be accessible to other servers on the Internet.
For information about how to verify that your mail server can be
accessed on the Internet, see “Using Telnet to Ensure Internet
Accessibility” in Chapter 5.
• Your recipient policies must be set up correctly. To receive Internet
mail, you must have a recipient policy configured that contains an
address space matching the SMTP domain. Also, your Exchange
organization must be responsible for delivering mail to this address
 (this is the default setting). For example, to accept Internet mail for
[email protected], you must have a recipient policy that contains
@example.com. However, there are some exceptions to this rule; for
example, you can create a connector that allows relaying to a
specified domain. For information about how to configure your
recipient policies, see “Configuring Recipient Policies” in Chapter 5.
• Inbound Internet mail flows through an Exchange 2000 server in the
following manner: (For detailed information about internal transport
mechanisms, see “Understanding the Internal SMTP Transport
Mechanisms” in Chapter 8.)

1.The sending SMTP server queries DNS to locate the IP

address of the recipient’s SMTP mail server.
2.The sending SMTP server then initiates a conversation on
the recipient’s SMTP server (on port 25). On an Exchange
gateway, the recipient’s SMTP server is the SMTP virtual
server that is configured to accept inbound Internet mail.
3.Ideally, the inbound SMTP server only accepts the incoming
message if it is destined for a recipient of its SMTP mail
domain. These recipients are defined in the recipient policies
(unless the server is open to relay, which is strongly
discouraged).
4.When the message is accepted, the SMTP virtual server
uses the transport mechanisms within Exchange to
determine the method for delivering the message. Exchange
locates the recipient in Active Directory and determines which
server in the Exchange organization will deliver the message.
For detailed information about the internal components of
SMTP, see “Understanding the Internal SMTP Transport
Mechanisms” in Chapter 8.
5.Finally, the SMTP virtual server uses its internal transport
mechanisms to deliver the message to the appropriate
Exchange server.

Sending Internet Mail

Assuming that there is a constant Internet connection, there
are two basic methods Exchange uses to send Internet mail:
• Use DNS directly to contact the remote mail server.
• Route mail through a smart host that assumes responsibility for DNS
name resolution and mail delivery.
• Before each of these methods is described in detail, you should have a
general understanding of how outbound mail flows in an Exchange
organization.
• Outbound Internet mail flows through an Exchange 2000 server in
the following manner. (For detailed information about internal
transport mechanisms, see “Understanding the Internal SMTP
Transport Mechanisms” in Chapter 8.)
 1. An internal user sends a message to a recipient in a remote
domain.
2. To determine whether the recipient is local or remote, the
SMTP virtual server on the sender’s Exchange server uses
internal transport functions to query the global catalog server
for the recipient address. If the recipient’s address on the
message is not in a recipient policy, it will not be stored in
Active Directory; therefore, Exchange would determine that
the message is destined for a remote domain.
3. If necessary, the Exchange server delivers the message to
the appropriate SMTP virtual server.
4. The SMTP virtual server uses its IIS metabase information
to determine the method for delivering a message to a remote
domain.
5. The SMTP virtual server on the Exchange server then does
one of two things:
• Uses DNS to look up the IP address for the target domain, and then
attempts to deliver the message.
• Forwards the message to a smart host that assumes responsibility for
the DNS resolution and delivery.

Routing Groups
Routing determines how messages flow between servers
within your MicrosoftExchange organization and to users
outside of your organization.

Types of Routing Components

• Routing components make up the topology and the routes that
are used to deliver mail internally and externally. Routing relies
on the following components that you define within your routing
topology:
• Routing groups Logical collections of servers that are used to
control mail flow and public folder referrals. Routing groups share
one or more physical connections. Within a routing group, all servers
communicate and transfer messages directly to one another.
• Connectors Designated paths between routing groups, to the
Internet, or to another mail system. Each connector specifies a
one-way path to another destination.
• Link State Information Information about routing groups,
connectors, and their configurations that is used by routing to
determine the most efficient delivery path for a message.
• Internal routing components Internal routing components, in
particular, the routing engine, that provide and update the routing
topology for Exchange servers within your organization. For more
information about internal routing components.
DSADIAG
Exchange 2000 uses the DSAccess API to communicate
with Active Directory.
DSAdiag.exe is a utility that lists the domain controllers,
global catalog servers, and the configuration domain controller
that the DSAccess API attempts to contact on behalf of
Exchange. The status of the connection is displayed in the
output (Up, Down, Fast, Slow, In Synch). If DSAccess is
having trouble communicating to a particular domain
controller or global catalog server, it fails over to a different
Active Directory server.

When you use DSAdiag.exe, you can manually force server

discovery. DSAdiag.exe must be copied into the \Program
Files\Exchsrvr\Bin folder. Open a command prompt and
change the folders to \Bin. When you type dsadiag and press
ENTER, two options are displayed: • DSAdiag 1 : This option
displays the domain controller, global catalog server, and the
configuration domain controller list.
• DSAdiag 2 : This option forces Topology Rediscovery, which
rediscovers the topology of the domain controller, global
catalog server, and the configuration domain controller.
For example, if a global catalog server has been taken down
for maintenance and brought back online again, and
DSAccess has not realized that the server is available once
more, you can use the DSAdiag 2 option to force the server to
rediscover the available servers. DSAdiag enumerates the list
of Active Directory servers that the DSAccess API reports, it
does not issue its own Lightweight Directory Access Protocol
(LDAP) requests to the Active Directory servers.

The following text is an example of the output that you receive

when you use the DSAdiag 1 option: D:\Program
Files\Exchsrvr\BIN>dsadiag 1
.......
Working DC's:
UP FAST DOWN InSync Name
X X X <hostname.domain.com>
Working GC's:
UP FAST DOWN InSync Name
X X X <hostname.domain.com>
Config DC: <hostname.domain.com>
Done

NLTEST
Nltest.exe can be used to test the trust relationship between a
computer running Windows that is a member of a domain and a
domain controller where its machine account resides. NLTEST can
also verify the trust between the ADCs in a domain and their RDC. In
domains where an explicit trust has been defined, NLTEST can test
the trust relationship between all domain controllers in the trusting
domain and a domain controller in the trusted domain.
Nltest.exe is a very powerful command-line utility that can be
used to test trust relationships and the state of domain
controller replication in a Windows NT domain. A domain
consist of domain controllers in which there is a single primary
domain controller (PDC) and zero or more backup domain
controllers (BDC).

Sample Output Obtained by Typing "NLTEST.EXE" Without the

Quotes
C:\NTRESKIT>nltest
Usage: nltest [/OPTIONS]
/SERVER:<ServerName> - Specify <ServerName>

/QUERY - Query <ServerName> netlogon service

/REPL - Force replication on <ServerName> BDC
/SYNC - Force SYNC on <ServerName> BDC
/PDC_REPL - Force UAS change message from <ServerName>
PDC
/SC_QUERY:<DomainName> - Query secure channel for
<Domain> on <ServerName>
/SC_RESET:<DomainName> - Reset secure channel for
<Domain> on <ServerName>
/DCLIST:<DomainName> - Get list of DC's for <DomainName>
/DCNAME:<DomainName> - Get the PDC name for
<DomainName>
/DCTRUST:<DomainName> - Get name of DC is used for trust of
<DomainName>
/WHOWILL:<Domain>* <User> [<Iteration>] - See if <Domain>
will log on <User>
/FINDUSER:<User> - See which trusted <Domain> will log on
<User>
/TRANSPORT_NOTIFY - Notify of netlogon of new transport
/RID:<HexRid> - RID to encrypt Password with
/USER:<UserName> - Query User info on <ServerName>
/TIME:<Hex LSL> <Hex MSL> - Convert NT GMT time to ASCII
/LOGON_QUERY - Query number of cumulative logon attempts
/TRUSTED_DOMAINS - Query names of domains trusted by
workstation
/BDC_QUERY:<DomainName> - Query replication status of
BDCs for <DomainName>
/SIM_SYNC:<DomainName> <MachineName> - Simulate full
sync replication
/LIST_DELTAS:<FileName> - display the content of given change
log file
/LIST_REDO:<FileName> - display the content of given redo log
file
Additional Comments and Descriptions of the Nltest.exe Switches
/SERVER:<ServerName>: Remotes the Nltest.exe command to
the specified server. If this switch is not specified, the command
is run from the local computer.
/QUERY Queries the local or specified server for a healthy secure
channel to a domain controller, and the status of Directory
Services replication with the PDC. This is very helpful in
determining the general status of the Netlogon service.
/REPL Force partial synchronization of the local or specified
BDC.
/SYNC Forces a full, immediate synchronization of the local or
specified BDC.
/PDC_REPL The specified PDC forces a change message to all
BDCs.
/SC_QUERY:<DomainName> Verifies the secure channel in the
specified domain for a local or remote workstation, server, or
BDC. This can be run for a PDC if an explicit trust relationship
exists between two domains and the trusted domain is specified.

/SC_RESET:<DomainName> Resets the secure channel between

the local or remote workstation, server, or BDC. This can be run
for a PDC if an explicit trust relationship exists between two
domains and the trusted domain is specified.

/DCLIST:<DomainName> Lists all the domain controllers, PDC,

and BDCs in a given domain.

/DCNAME:<DomainName> Lists the primary domain controller

for a given domain.

/DCTRUST:<DomainName> Queries and tests the secure

channel every time the command is executed. Specify the domain
for the local or remote workstation, server, or BDC. This can be
run for a PDC if an explicit trust relationship exists between two
domains and the trusted domain is specified.

/WHOWILL:<Domain><User> Queries the domain and indicates

which Domain Controller has the account in their local user
account database. This is very useful in determining if a given
domain controller contains the user account. If the username
specified is that of the currently logged on user, the user's
current password is NOT sent to the domain controller. This is
helpful in determining if duplicate accounts exist across several
domains.

/FINDUSER:<User> Queries explicit trusted domains for the user

specified. This is very useful when determining what trusted
domain controller or what trusted domain out of several trusted
domains will authenticate a user's credentials when a Domain
name is not specified in the Server Message Block (SMB) packet.
Many down-level clients, such as Windows for Workgroups
version 3.1 and the real-mode redirector in Windows 95, do not
specify a domain name.

/USER:<UserName> Displays many of the attributes for the

specified user account that are maintained in the user account
database.

/LOGON_QUERY Specifies the number of attempted logon

queries at the console, or over the network.

/TRUSTED_DOMAINS Displays a list of explicit trusted domains.

/BDC_QUERY:<DomainName> List the backup domain

controllers in the specified Domain and provides the state of their
synchronization.

/LIST_DELTAS:<FileName> List information from the

Netlogon.chg file specifying changes to the user account
database.

Recovery Storage group:

In versions of Exchange Server that are earlier than Exchange

Server 2003, you must configure a separate Microsoft Active
Directory directory service forest on a recovery server if you want
to mount another copy of a production Exchange database or to
mount a different version of a production Exchange database.
With the Recovery Storage Group feature in Exchange Server
2003, a separate recovery computer is not required in certain
situations when you want to recover data from a mailbox store.
After you create a Recovery Storage Group, and after you add one
or more databases to it, you can either restore online backup
sets or you can copy offline database files to the Recovery
Storage Group. To extract or to merge data from recovered
 databases in the Recovery Storage Group to a mailbox in a
regular storage group, use the Exchange Server 2003 version of
Microsoft Exchange Mailbox Merge Wizard (Exmerge.exe).

To use a Recovery Storage Group, the Active Directory topology of

the Exchange Server 2003 computer must be intact and must be
in the same state as when the copy of the database was made.
This means that the mailbox or the mailboxes that you want to
recover must not be deleted or purged from the system, or moved
to a different database or to a different server.

The Recovery Storage Group feature is not intended for use in

disaster recovery operations that involve multiple servers or
multiple storage groups. It is intended as a substitute in
situations where previously, an alternative forest recovery server
was required. Use the Recovery Storage Group feature in
recovery situations where both the following conditions are true:
• The logical information in Active Directory about the storage group and
its mailboxes is intact and unchanged.

• You want to recover data from a single mailbox, a single database, or a

group of databases that are in a single storage group. For example, you
can use a Recovery Storage Group to recover items that were deleted
and purged from a user's mailbox, or you can use a Recovery Storage
Group to restore or to repair a copy of an alternative database while
another copy of the database remains in production.

How a Recovery Storage Group Is Different from a Regular Storage

Group
A Recovery Storage Group is a specialized storage group that can exist
with regular storage groups. Although a Recovery Storage Group is
similar to a regular storage group, Recovery Storage Groups differ
from regular storage groups in the following ways:
• All protocols except MAPI are disabled. This means that you cannot
send mail to or receive mail from a mailbox store that is in a Recovery
Storage Group. However, you can use the Exmerge.exe tool to access
mailboxes to recover data.
• You cannot connect user mailboxes in a Recovery Storage Group to
user accounts in Active Directory. The only supported method that
you can use to access mailboxes in a Recovery Storage Group is by
using the Exchange Server 2003 version of the Exmerge.exe tool.
• You cannot apply system and mailbox management policies to a
Recovery Storage Group.
• Online maintenance and defragmentation do not run against
databases in the Recovery Storage Group.
• You must manually mount databases in the Recovery Storage
Group. You cannot configure the databases to automatically mount in
Exchange System Manager.
• You cannot change path locations or move data files after a Recovery
Storage Group is created because those actions are not supported. If
you want to change the location of the files in a Recovery Storage
Group, you have to delete and then re-create the Recovery Storage
Group.
• You can only recover mailbox stores to a Recovery Storage Group.
You cannot restore a public folder store to a Recovery Storage Group
because that action is not supported. The methods that you use to
recover a public folder store in Exchange Server 2003 are the same
methods that you use in Exchange 2000 Server.
• You can restore any private mailbox store from any computer that is
running Exchange Server 2003 or Exchange 2000 Service Pack 3 (SP3)
or later to a Recovery Storage Group, if the computer that contains the
private mailbox store and the computer that contains the Recovery
Storage Group are both located in the same administrative group.

Note When you restore a mailbox store to the Recovery Storage Group,
the mailbox store is upgraded to the version of the mailbox store that
currently is running on the computer. This means that you must
upgrade the original computer to the version of Exchange that is
running on the computer where the Recovery Storage Group is located
before you can copy the databases back to the original computer. For
example, if you restore a mailbox store from a computer that is
running Exchange 2000 Server SP3 to a Recovery Storage Group that
is stored on a computer that is running Exchange Server 2003, you
must upgrade the original computer to Exchange Server 2003.

You can use the Exmerge.exe tool to move or to copy mailbox data
between servers regardless of the version of Exchange Server that is
running on the computers.
• By default, data is restored to the existing Recovery Storage Group
on the computer.
• If you restore multiple databases to a Recovery Storage Group, all
databases that you add to the Recovery Storage Group must be from
the same storage group.
• You can only have one Recovery Storage Group on a computer.
• You can only have one Recovery Storage Group per two-node cluster,
regardless of the number of Exchange virtual servers that are present.
For clusters that contain more than two nodes, each Exchange virtual
server can have its own Recovery Storage Group.
• Recovery Storage groups cannot be used to restore Exchange
backups that were performed using third-party software that supports
the Volume Shadow Service in Microsoft Windows Server 2003.
Recovery Storage Groups can be used only to restore backups
performed by an Exchange-aware backup application. Backup
snapshots that were taken by using Volume Shadow Service can be
restored only by using Volume Shadow Service.
http://support.microsoft.com/kb/824126/
Messaging Dial Tone Recovery Strategy

With the "Messaging Dial Tone" strategy, you can restore e-mail service more
quickly to users, and you can restore their previous data as it becomes
available. You first reset an Exchange database by removing the current
database files to create a temporary, blank, "dial tone" database. Users can log
on to this database to send and to receive mail. New, empty mailboxes are
created in the "dial tone" database when users log on. Because the new
mailboxes have the same values for the msExchMailboxGUID attribute in the
"dial tone" database as in the original database, you can use the Exmerge.exe
tool to transfer data between the original database and the temporary “dial
tone” database.

When the "dial tone" database is set up and is running, you can restore or
repair the original database in the Recovery Storage Group. When the restore or
the repair operation is complete, dismount both database, and then swap the
database files between the original storage group and the Recovery Storage
Group. By doing so, users can access their previous data, but users cannot
access new items. To restore access to new items, use the Exmerge.exe tool to
transfer data from the "dial tone" database to the original database.

Some features that are new in Exchange 2003 are:

Volume Shadow Copy Service for Database Backups/Recovery Mailbox

Recovery Center

Recovery Storage Group

Front-end and back-end Kerberos authentication

Distribution lists are restricted to authenticated users

Real-time Safe and Block lists

Inbound recipient filtering

Attachment blocking in Microsoft Office Outlook Web Access

HTTP access from Outlook 2003

cHTML browser support (i-Mode phones)

xHTML (Wireless Application Protocol [WAP] 2.0) browser support

Queues are centralized on a per-server basis

Move log files and queue data using Exchange System Manager

Multiple Mailbox Move tool

Dynamic distribution lists

1,700 Exchange-specific events using Microsoft Operations Manager

(requires Microsoft Operations Manager)

Exchange Ports
• A partial list of the ports your Exchange server might use is included
below
• 21 FTP
• 23 Telnet
• 25 SMTP
• 53 DNS
• 80 HTTP
• 88 Kerberos
• 102 X.400
• 110 POP3
• 119 NNTP
• 135 RPC
• 137 - NetBIOS Session Service
• 139 - NetBIOS Name Service
• 143 IMAP4
• 379 LDAP (SRS)
• 389 LDAP
• 443 HTTP (SSL)
• 445 - NetBIOS over TCP
• 465 SMTP (SSL)
• 563 NNTP (SSL)
• 636 LDAP (SSL)
• 691 LSA
• 993 IMAP4 (SSL)
• 994 IRC (SSL)
• 995 POP3 (SSL)
• 1503 T.120
• 1720 H.323
• 1731 Audio conferencing
• 1863 - MSN IM
• 3268 GC
• 3269 GC (SSL)
• 6001 Rpc/HTTP Exchange Store
• 6002 HTTP Exchange Directory Referral service
 • 6004 Rpc/HTTP NSPI Exchange Directory Proxy service/Global
Catalog
• 6667 IRC/IRCX
• 6891 - 6900 - MSN IM File transfer
• 6901 - MSN IM Voice
• 7801 - 7825 - MSN IM Voice

Can I have multiple Exchange 2003 organizations in a

single forest?
No. Only a single E2K3 organization can exist within a
single forest. Delegation of administration within the
organization can be accomplished using OUs in AD and
Administrative/ Routing Groups in the Exchange system
manager.

Can an Exchange 2003 organization span multiple

forests?
No. All domains in a forest share a common schema and
the Exchange organization exists within this configuration
naming context. The GC, which provides the Global Address
List is populated only with items within the forest.

Administrative and Routing Group:

===============================
• An Administrative Group is a collection of Exchange objects that are
grouped together for the purposes of permission management. The
collection of Administrative Groups defines the administrative
topology of an organization. An Administrative Group can contain
zero or more policies, routing groups, public folder trees, monitors,
servers, conferencing services, and chat networks.

• A Routing Group is a collection of "well-connected" Exchange Server

computers. Messages sent between any two servers within a Routing
Group are routed directly from source to target. Full mesh, 24x7
connectivity is assumed. Any messages sent from a server in one
Routing Group to a server in another Routing Group must be routed
to a bridgehead in the source Routing Group and over to a bridgehead
in the destination Routing Group.

Exchange Virtual directory

Exadmin: This directory provides Web-based administration of the HTTP Virtual

Server. Among other things, it’s used to administer public folders from within the
Exchange System Manager. It’s also possible to make custom third-party applications
communicate with the Exadmin folder. This folder is only configured for Integrated
Windows authentication access
Exchange: The Exchange directory provides mailbox access to OWA clients. By default,
this folder is configured with Basic and Integrated Windows authentication access. The

Active Directory (AD) domain name is also specified

ExchWeb The ExchWeb folder provides most of the OWA control functionalities. By
default, this folder has anonymous access enabled, but don’t let this setting fool you. The
subfolder BIN that contains the controls is set to basic and Integrated Windows
authentication (see Figure 5.3). Also note that this folder is viewable through only the IIS
Manager and not the Exchange System Manager.
Microsoft-Server-Activesync: This directory provides support for wireless
synchronization (Activesync) by Microsoft Pocket PCs, smartphones, and the like. The
folder is by default set to basic authentication and the default AD domain .

OMA: The OMA folder provides Web-based mailbox access to Pocket PCs,
smartphones, and the like. The folder is set by default to basic authentication and default
domain \
 Public: The Public folder provides users with access to the Public folders. This folder is
set by default to basic and Integrated Windows authentication and the default AD domain

Authentication Methods

By default, the authentication method for accessing OWA is basic and/or Integrated
Windows authentication, but actually there are five different authentication methods that
can be used to validate your OWA users:

• Anonymous access: Enabling anonymous connections allows HTTP clients to

access resources without specifying a Microsoft Windows 200x user account.
 Passwords for anonymous accounts are not verified; the password is only logged
in the Windows 200x Event Log. By default, anonymous access is not enabled.
The server creates and uses the account IUSR_computername.
• Integrated Windows authentication: The Integrated Windows authentication
method is enabled by default (except on front-end servers). This authentication
method also requires HTTP users to have a valid Windows 200x user account and
password to access information. Users are not prompted for their account names
and passwords; instead, the server negotiates with the Windows 2000 security
packages installed on the client computer. This method allows the server to
authenticate users without prompting them for information and without
transmitting unencrypted information across the network.
• Digest authentication: Digest authentication works only with Active Directory
accounts. It’s quite secure because it sends a hash value over the network rather
than a plaintext password, as is the case with basic authentication. Digest
authentication works across proxy servers and other firewalls and is available on
Web Distributed Authoring and Versioning (WebDAV) directories. To use this
form of authentication, your clients must use Internet Explorer 5.0 or later.
• Basic authentication: Basic authentication transmits user passwords across the
network as unencrypted information. Although this method allows users to access
all Exchange resources, it is not very secure. To enhance security, it is strongly
advised that you use SSL with basic authentication to encrypt all information. We
will show you how to enable Secure Socket Layer (SSL) on your OWA virtual
directories in the next section.
• .NET Passport authentication: .NET Passport authentication allows your site’s
users to create a single sign-in name and password for easy, secure access to all
.NET Passport-enabled Web sites and services. .NET Passport-enabled sites rely
on the .NET Passport central server to authenticate users rather than hosting and
maintaining their own proprietary authentication systems. However, the .NET
Passport central server does not authorize or deny a specific user’s access to
individual .NET Passport-enabled sites. It is Web site’s responsibility to control
user permissions. Using .NET Passport authentication requires that a default
domain be defined. You probably know the .NET Passport authentication method
from services such as

Migrating from Exchange Server 5.5 to Exchange Server 2003

In general there are two ways for moving to Exchange Server 2003.
The first is to upgrade an existing Exchange 5.5 environment by running an
inplace upgrade.
Another way is to migrate the Exchange directory service to Active Directory
and then implementing an Exchange Server 2003 environment.
Step 1

a) Implement and deploy Active Directory on Windows Server 2003 and all
your Global Catalog Server are Windows Server 2003.

b) Update WINNT 4.0 SP6a and Exchange Server 5.5 with Service Pack 3 or
higher.

c) Create trust relation ship between Windows 2003 AD and WINNT 4.0
Domain.

d) Give Permission for Administrators account on organization, site and

configuration of Exchange 5.5 server.

e) Install the ADMT tool to migrate the user SID and Passwords. Before
migrating the SID the windows should be raised to Native mode.

Step2
a) Login as Enterprise Administrator account run the Exchange
Forestprep and Domain prep on the Domain controller.
b) Setup.exe /forestprep and setup.exe /domainprep.
c) Install and configure the ADC connector, Configure the appropriate
connection agreements for public and private folders. Synchronies
the Exchange 5.5 directory services with windows Active directory
Service.
d) Run the exchange stepup with setup.exe.
e) Move the Mailbox from exchange 5.5 to Exchange 2003 server with
Move wizard mailbox or from ADUC.
 f) Moving the connectors
g) Rehoming the Public folders
Step 3
a) Changing the IMC from exchange 5.5 to Exchange 2003
b) Changing the MX pointer.
c) Removing the Exchange 5.5 from the network.

What is first? ADMT or ADC and Why?

ADMT is first.

Run ADMT to create active user accounts in Active Directory:

You should select the option for migrating security identifiers (SIDs) to
ensure that ADMT adds the source account's SID to the new target
account's SID history (SIDHistory) attribute. (In the next step, Migration
Wizard uses the SID to match mailboxes to accounts.) However, to migrate
SIDs, the target Exchange 2003 domain must be in native mode.

Use Migration Wizard to migrate mailboxes.

If you migrated SIDs when you ran ADMT, Migration Wizard uses the SID
to match mailboxes to the new accounts and then converts the accounts
to mailbox-enabled user accounts. If you did not migrate the SIDs in the
first step, Migration Wizard cannot match a mailbox to an account and
instead creates a disabled user account to associate with the mailbox.
Note
As an alternative to using ADMT, you can follow the standard process for
upgrading from Windows NT Server version 4.0 to Windows Server 2003.
Following this process preserves the SID

To migrate SIDs, the target Windows domain must be in native mode. The
SIDHistory attribute exists in the domain schema only if the Windows
domain is in native mode.

http://www.microsoft.com/technet/prodtechnol/exchange/guides/PlanE2k3M
sgSys/504334e5-6ba1-474b-a37c-976553f8d79a.mspx?mfr=true
SIDHistory and SID transalation

SIDHistory :-ADMT migrates the Windows NT accounts associated with

Exchange 5.5 mailboxes to Active Directory and then creates new Active
Directory users. ADMT then populates the SIDHistory attribute for each
new user.

SID transalation :-When you perform a resource domain migration to

Windows Server 2003, you must run the Security Translation Wizard to
translate the security information about resources from the source domain
to the target domain. If you must perform the migration from
workstations other than the master workstation to correctly translate the
security principals on various resources, you must either copy the
Protar.mdb database from the master workstation to the alternative
workstations or use a SID mapping file.

http://support.microsoft.com/kb/326480/

Permissions required to run the Exchange 2000 Server Migration Wizard

• To successfully bind to the Exchange 5.5 directory service and the

information store, give the Administrator account Administrator rights
over the Organization, Site, and Configuration containers. You must enter
the account name and password, as well as the source server name on the
Migration Destination window in the Migration wizard.

• To successfully import directory information and mail data into Windows

2000 Active Directory and the Exchange 2000 information store, add the
account that is used to run the Migration wizard to the Domain
Administrators group and the Exchange Administrator group.

ADClean Command

ADClean.exe is a command-line tool that helps you find and merge

duplicate accounts. By default, ADClean is installed in the
SystemRoot\Program Files\Exchsrvr\Bin folder.

NTDSNoMatch

NTDSNoMatch is a utility to identify any mailboxes that are not associated

with a Specific user account by the ADC.
For the first time that you replicate an ADC recipient Connection
Agreement, Exchange 2000, 2003 creates disabled users in Active
Directory by default if it cannot match a mailbox to a user.
What Exchange migration does

The Migration Wizard performs the following tasks:

• Migrate all mailbox information to the new Exchange mailboxes,
including the following data: • Inbox
• Drafts
• Sent Items
• Calendar
• Tasks
• Custom folders that were created by the mailbox owner
• Contacts

• Create new user accounts in Active Directory (if they do not already
exist) based on the Exchange 5.5 accounts in the source organization.
• Migrate X.400, Simple Mail Transfer Protocol (SMTP), cc:Mail, Microsoft
Mail, and other e-mail addresses into the e-mail addresses attribute of the
new user account in Active Directory.
• Convert Active Directory contacts to mail-enabled user accounts in
Active Directory (if these contacts have been created with the Active
Directory Connector) when you migrate from Exchange 5.5. If a contact
has been manually created in the target Active Directory and a mailbox
that has the same alias is migrated, a new disabled user account with a 1
appended to the name is created in Active Directory. The original contact
remains unchanged. Only contacts that are created by the ADC are
converted into mail-enabled user accounts by the Migration Wizard.
• Update Exchange 2000 Server or Exchange Server 2003 group
membership when you migrate from Exchange 5.5. However, Exchange 5.5
distribution lists are not migrated. For example, if a distribution group in
Active Directory contains contacts, during a migration procedure these
contacts may be converted to user accounts that are turned off, and the
distribution group in Active Directory is updated to reflect this change.

What Exchange migration does not do

The Migration Wizard is not designed to perform the following tasks: •

Clean up or remove mailboxes in the source organization. The original
mailboxes in the source organization continue to receive messages after
the migration process is complete. You must delete the original mailboxes,
or configure other recipients that point to the new mailboxes that are
hosted in the target Exchange organization.
• Migrate custom recipients. The Migration Wizard creates contacts from
custom recipients.
• Preserve ACLs. The Migration Wizard does not preserve ACLs to other
mailboxes or public folders. If after migration, a mailbox owner updates
their profile to refer to the new mailbox in the target Exchange
organization, they will no longer be able to connect to mail resources in
the original (source) Exchange 5.5 organization.
• Migrate mailboxes in the same organization. The source organization
from which you migrate mailboxes must be different from the target
organization. For example, you cannot migrate mailboxes from an
Exchange 5.5 source server that is in the same organization as the
Exchange target computer.

Note However, you can use the Migration Wizard to migrate information
from an Exchange 5.5 organization that is in the same forest as the target
Exchange organization, but has not yet joined the target Exchange
organization. For example, the source Exchange 5.5 servers may be
running on Microsoft Windows 2000 Server-based computers in an Active
Directory forest that also contains the target Exchange organization. As
long as the migration source and target organizations have different
names, you can use the Migration Wizard to import information.
• Migrate personal mail archives or personal address books. For
information about how to migrate personal mail archives or personal
address books, see the Exchange 2000 Server or the Exchange Server 2003
online documentation.
• Migrate distribution lists. You can use either of the following two
methods to migrate Exchange 5.5 distribution lists: • Convert the
distribution list to a public folder, and then migrate the public folder.
• Export the distribution list, and then use the LDIFDE or CSVDE
command-line utilities to convert them.

• Migrate Inbox rules. After you use the Migration Wizard to migrate
mailbox information, the mailbox owners must re-create their Microsoft
Outlook Inbox rules.
• Migrate public folders. You can migrate public folders by exporting them
to .pst files or by using the Inter-organization replication utility.

Disk defragmentation involves rearranging data on a server's hard disks to make the files
more contiguous for more efficient reads. Defragmenting your hard disks helps increase
disk performance and helps ensure that your servers that run Exchange run smoothly and
efficiently.

The transaction logs are some of the most crucial files when it comes to a
working Exchange server. Microsoft Exchange Server uses transaction logs as a
disaster recovery method that can bring a Exchange database back to a
consistent state after a crash. Before anything is written to the EDB file, it is
first written to a transaction log. Once the transaction has been logged, the data
is written to the database when convenient.

Until a transaction is committed to the database, it is available from memory

and recorded in the transaction logs. This is why you will see store.exe use up
to 1GB of memory after the Exchange server has been in use for a while. After
an Exchange server is brought back up after a crash, the checkpoint file points
to the last committed transaction in the transaction logs which are then
replayed from that point on. This form of write-ahead logging is important for
you to know.

There are four types of transaction logs:

• E##.log is the current transaction log for the database. Once the log file
reaches 5MB in size it is renamed E#######.log and a new E##.log is
created. As with the checkpoint file the ## represents the Storage Group
identifier. While the new E##.log file is being created you will see a file
called Edbtmp.log which is a template for Exchange server log files.
• E#######.log are the secondary transaction logs. They are numbered
sequentially starting with E0000001.log using the hexadecimal
numbering format and are 5MB in size.
• Res1.log is a reserved log file that is limited to 5MB in size. When the
disk has run out of space, transactions are written to this log file while
you work on clearing up space on the disk.
• Res2.log is another reserved log with the same function

Between Servers in the Same Routing Group

Messages routed between servers in the same routing group use SMTP as their transport.
The steps involved in routing a message between two servers in the same group are
slightly more complicated than on a single server:

1. Since the message is not intended for local delivery, the message is passed to the
routing engine.
2. Once in the routing engine, the message is parsed against the Domain Mapping
and Configuration table and then placed in the outgoing SMTP queue for the
destination server.
3. The sending server looks up the recipient’s home directory in Active Directory,
conducts a DNS lookup for the MX record associated with the destination server
on which the recipient’s mailbox is stored, and then creates a TCP connection to
that server.
4. The message is transmitted to the destination server.
5. Once the destination server receives the message, it processes it in different ways
depending on the destination of the message. If it determines that the message
goes to a recipient in its local store, it follows the procedure discussed in the
previous section. If it determines that the message goes to a different server or
outside the organization, the above process is repeated to route the message to the
correct server.
Between Routing Groups

Messages routed between servers in multiple groups incur the use of a bridgehead server
at each end of the connector. The steps involved in routing messages between servers in
different routing groups are as follows (see Figure 2.6, where the solid line represents the
flow of messages and the dashed line represents queries):

1. Since the message is not intended for local delivery, the message is passed to the
routing engine.
2. The routing group information is gathered from the configuration naming context
of Active Directory.
3. The link-state information is consulted to determine the best routing path.
4. The message is passed to the bridgehead server.
5. The bridgehead server passes the message to the destination bridgehead server in
the other routing group.
6. The receiving bridgehead server passes the message to the destination server in its
group.
7. The message is brought into the destination server via the SMTP service and
placed in the Local Delivery queue.
8. The message is taken out of the queue by the store.exe process and associated
with the recipient’s inbox.
1. In the 2080 event logged by DSACCESS, what does "out-of-site" mean?

Out of site means servers in a different site which the exchange server is trying to query.
It is the next adjacent site determined by AD site membership. If there are two adjacent
sites of the same cost, then it's GC's in both or all of those sites.

2. What are the size limits around Exchange databases in Exchange 2003 SP 2 ?

75 GB

3. How can I see which clients are logging in to my Exchange servers, and in particular
which versions are logging in?

Browse to server in ESM and click on logons under server name.

4. What Operating Systems are supported by Exchange 2003 SP 2?

Windows 2003 standard, enterprise,

[Wilcox, Rob] Windows 2000 SP 4, or Windows 2003. It is

PREFERRRRRRRRRRRRRRRED to have SP 1 for Windows 2003.

5. When applying an Exchange 2003 service pack, which servers should you apply the
update on first?

Connector servers

Front End Servers.

6. What happens if you delete the mailbox which is being used for Message Journalling
in Exchange 2003?

All journalled emails are lost, messages will try reach the journal and queue will build on
servers…. Guessing. ALL mail will queue, in messages awaiting directory lookup. And
yes all previously journaled mail is deleted, but deleted mailboxes are kept for 30 days.

7. If I select 1000 mailboxes to perform a move mailbox on… how will Move Mailbox
in ESM do that? And how does it differ from older versions?

Can’t remember technical way to explain it

[Wilcox, Rob] Multi-threaded… is what I was looking for.

8. What does the process of database verification in snapshot/hot-backups do?

THE ESE process verifies against the database for the checksum and integrity.

[Wilcox, Rob] checksum, yes.

9. Does the STM file get touched by online maintenance?

No.

10. What are the criteria for using the 3 Gb switch?

Well to allocate 1 GB to Kernel and 3 GB for store process.

[Wilcox, Rob] the criteria is that if you a Gb or MORE of RAM use /3 Gb

1) What processes will remove transaction logs?

Ie what operations do I need to perform to clear them up
1. Back up
2. cut and copy of files to another folder.

2) What is the purpose of online maintenance ?

It removes any folder/message aging. Make sure the space available within the database, by
removing aging is available for the next data within the database file.

3) When might I see a -1018 error ?

This is logged when the store has a bad data in it.

4) What happens if I turn on circular logging, on a storage group ? Why is it not recommended ?
It overwrites the transaction logs and as result restore from online backup will be impossible

5) In a cluster what is the single point of failure, and how can you overcome that?
???

6) On an Exchange server, why do you want to run it on a machine with the /3Gb switch ?
/3gb switch is applied when u have physical more than 1 Gb and this will apply the 3GB to
application and 1 Gnb to kernel.

7) How do Exchange 2000 servers communicate to other servers in the same routing group ?

RPC??

8) How many storage groups, and stores can I have on an Exchange 2000 Standard Edition Server? And
on Enterprise ?
Standard - 1 storage group Enterprise 4 storage groups
5 stores in each storage
9) What’s the best method of virus scanning an Exchange 2000 server?

Exclude all exchange folders and iis folders.

10) What have I forgotten to do if my SMTP connector restriction aren’t working ? ie I restrict a connector so
that only members of the messaging team can send mails over it, but when I check there are tons of other
mails going over it too… what have I forgotten to do?
1) What processes will remove transaction logs?
i.e. what operations do I need to perform to clear them up
To clean up transaction log file one option is to take full backup, and second one is
check through eseutil /mk command.

2) What is the purpose of online maintenance ?

It will clear the white space form database, once online maintance will get through u
will get some idea to defrage database. Means once u will defrage data base u will
get idea how much free space u will get.

3) When might I see a -1018 error ?

I have to check… no idea
I think its jet error.will tell u later

4) What happens if I turn on circular logging, on a storage group ? Why is it not recommended ?
Once u turn it on, it will overwite transaction log files. So if ur database will get crash u will not get
up to date data. When u make it off, every 5mb new transaction log file will get generated.once u
tke backup, it will purge and committed to databse, so while restoring databse, u will get up to
date data.
5) In an Exchange cluster what is the single point of failure, and how can you overcome that?

6) On an Exchange server, why and when do you want to run it on a machine with the /3Gb switch ?
Exchange 2k3 support 4GB of RAM. /3gb switch will give virtual memory to the server. Mean if u
have 2gb ram and u will put /3gb switch it will free up memory virtually for exchange operation, in
short it speed up ur performance

7) How do Exchange 2000 servers communicate to other servers in the same routing group ?

Need to check

8) How many storage groups, and stores can I have on an Exchange 2000 Standard Edition Server? And
on Enterprise ?
1 storage group and five mailbox store

9) What’s the best method of virus scanning an Exchange 2000 or Exchange 2003 server?
U can use third party tools like Mcafee group shield and trend micro, and Antigen. Some of them
have mailbox scan facility.

10) If I set up restrictions on my SMTP connectors, and later find out that lots of mails are still going through
the restricted connector, how do I start troubleshooting this?
That’s due to relay. U have to check SMTP relay option. Its happen if ur exchange server open for replay.

11) What does forestprep do ?

In simple language, it will expand schema for support of application like exchange. Better to check theory of
forestprep.read it on MS site.

12) Which task copies protocol settings from Active Directory in to the metabase on the local machine?
No idea,, have to check
13) How would you recommend a maximum database size in Exchange 2000 or Exchange 2003 ?
For enterprise server it support 16TB, only thing is ur h/w should compatible for the same.

14) During installation where does setup record it’s actions, successes and failures ?
While installing exchange 2003, one setup file .txt will get create in C: drive on root folder. Each and every
step u can get it from that file.its always recommended to check that during installation.

15) Approximately how many address lists can you have in an Exchange organisation ?
No idea.. have to check

16) Name 3 places that you can set the maximum message size which can be sent or received in Exchange
I think u can get this option on message delivery option on root of exchange organization.

17) What functions take place during an Online Backup with regards to transaction logs ?
Online backup commit all transaction log file to physical database and then purge all files.

18) What is the purpose of the checkpoint file ?

It will check all log files, once it will reach to 5mb size, new file will get genetraed,

19) Does Outlook use the streaming file ?

Streaming files are generally used for OWA. But need to check again.

20) How would you physically recover white space in the database, and how would you check how much
whitespace there actually is in an Exchange database ?
Same online defrage shows white space size and run eseutil /g to defrgmant database. During defragment
database shuld be in dismount mode. If customer is not ready for down time, then simple do a move mailbox
wizard. This will create new database.

31) I have a bunch of POP3 and IMAP4 clients running against my Exchange 2000 server, when I upgrade
the server to Exchange 2003, what do I need to be careful about?
No idea.. need to check

32) In a brand new forest at which point in the installation process do I specify my organisation name?
When u start installation of exchange u will find this option.

33) How is mailbox manager implemented in Exchange 2000 (and Exchange 2003)?
It’s a task which u can define by right cliking mailbox store. But still need to check.

34) How many nodes can I have an Exchange 2003 / Windows 2003 Enterprise Edition cluster ?
Exchange 2003 cluster supports up to 8 nodes.

35) On a 4 node Exchange 2003 cluster how many Exchange Virtual Servers can I create? How many can
I run on each node ?
No idea.. need to check

36) How can you use Outlook 2003 and Exchange 2003 to connect over the internet ?
Use RPC over HTTP and use outlook using cache mode.u can find this option on profile settings to enable
rpc/http.

37) To install Exchange 2003 System Manager on a workstation, what are the prerequisites?
System should be XP,2003

38) What’s the purpose of Exchange 2000/3 System Policy (created in Exchange System Manager)
U can use this in many ways like email address creation(first anme. Last [email protected])

39) Describe the purposes of the default recipient policy.

It will create email address and replicate to all other servers in domain.
40) How many MTA’s are there in a 4 node cluster with Active nodes, and 1 passive?
No idea..need to check