ExchangeServer ch5

The Expert's Guide for
Exchange 2003
Preparing for, Moving to, and Supporting
Exchange Server 2003
by Steve Bryant
v
Books
Contents
Chapter 5 Multiple Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Why Multiple Directories Exist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
AD as Your Directory Foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Forests and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Multiple Directories and Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Single Exchange Organization Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Separate Exchange 2003 and Exchange 5.5 Organizations . . . . . . . . . . . . . . . . . . . . 85
Separate Exchange 2003 Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Exchange 2003 and Foreign Mail Systems — Short Term . . . . . . . . . . . . . . . . . . . . . 88
Lotus Notes/Domino Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
SMTP for Message Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Establish Separate Internet Domains for Notes and Exchange . . . . . . . . . . . . . 91
Establish Subdomains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Split the Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Installing and Tweaking the Notes Connector . . . . . . . . . . . . . . . . . . . . . . . . . . 94
GroupWise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
MIIS 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
LDIF Import and Export Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Reviewing Your Multiple Directory Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Next: Outlook Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
83
Chapter 5:
Multiple Directories
Pure homogeneous environments exist in the dreams of network designers but not usually in the
real world. Even if your environment is pure Microsoft and the latest in Active Directory (AD)
technologies, you might have chosen to configure your domains in separate forests for security and
partitioning reasons. If you use Lotus Notes/Domino or GroupWise – or expect to run multiple
Exchange organizations for any length of time – this chapter is certainly for you. And, although
understanding the underlying connections between directories can certainly aid in migration projects,
I won’t discuss migration in this chapter. Instead, I explore the options available for running separate
directories for extended periods of time.
Why Multiple Directories Exist

It’s not uncommon for organizations, particularly larger ones, to have more than one directory.
Customer Relationship Management (CRM) systems, sales automation tools, messaging systems, data-
base applications, and authentication systems rarely use the same directory. This situation creates
additional administrative overhead in contact management, group calendaring, and task management.
The good news is that AD can provide a directory foundation you can leverage for other
systems. Both hardware and software vendors have aligned themselves with Microsoft to leverage
AD as their directory structure. You too can leverage AD for your specific application – whether it’s
creating Lightweight Directory Access Protocol (LDAP) queries to look up information or writing ADSI
scripts to either populate or extract data from AD.
AD as Your Directory Foundation

Suppose you’ve decided that AD is the right structure for you, and your company has integrated your
applications and systems into AD. Now, let’s complicate that idea with the notion that your company
has merged with another, and your counterparts have done the same thing. The good news is that
you can connect AD forests as federated forests with cross-forest trusts. In addition, you can cross-
certify Microsoft Certification Authorities (CAs) so that you can use certificates universally for
encryption and smartcard use. In fact, running multiple forests within a company shouldn’t disrupt
authentication, file and printer sharing, development projects, or systems management.
Forests and Security

One of the most important areas to address is security. You can’t obtain true security if the domain
you need to secure is part of a single forest. Although I discussed this principle in Chapter 2, I
mention it again because my Microsoft peers and the company’s product groups continue to
broadcast that message. If you’re concerned that administrators in your organization have different
administrative approaches or could disrupt your business through an intentional or accidental act, you
should consider designing your AD with multiple forests.
Brought to you by Quest Software and Windows & .NET Magazine eBooks
84 The Expert’s Guide for Exchange 2003
If you’re concerned about how to physically and logically protect your domain controllers (DCs),
you should also consider multiple forests. Within a single forest, for example, a domain administrator
could potentially run a script that creates a million mailboxes on his or her local server. This massive
import would affect the performance and stability of your network, your Global Catalog (GC) server,
your DCs, and your Outlook clients. It would also affect client machines’ ability to log on to the
system and remote Outlook users’ ability to download the address book.
Needless to say, a more blatant intentional attack could do even more damage. To share the
same forest, you must trust the other administrators and their security practices. To begin your
consideration of multiple forests, download and read the Microsoft white paper “Multiple Forest
Considerations.” This extensive document provides much more information than I can offer in a
single chapter. To download the white paper, go to http://www.microsoft.com/downloads
/details.aspx?FamilyID=b717bfcd-6c1c-4af6-8b2c-b604e60067ba&DisplayLang=en. For additional
reading, Quest Software has published a whitepaper on multi-forest configurations that is available at
http://wm.quest.com/products/collaborationservicesexchange/. Choose the “Best Practices for
Designing a Secure Active Directory: Multi-org Exchange Edition” whitepaper. Although this
whitepaper is free, you’ll need to register to download it.
Multiple Directories and Exchange

Now that I’ve created the context for multiple directories, let’s discuss their impact on Exchange.
Because AD forests can’t be truly merged – and share configuration and schema containers – they
can’t share the same Exchange organization. This inability to share the same Exchange organization is
highly significant because Exchange collaboration features require the same forest.
The Outlook client pulls the address book from the GC servers, and because the GC is specific
to a given forest, the GC can’t and won’t contain detailed mail information for another forest. To
open another user’s calendar using Outlook, the calendar owner must be listed in your Global
Address List (GAL), and both mailboxes must be in the same Exchange organization. In truth, a
separate Exchange organization provides about as much collaborative functionality as a foreign mail
system such as Notes or GroupWise. To “connect” the systems, you need a connector – and that
connector will somewhat limit functionality.
Single Exchange Organization Scenario

Suppose that your company indicates that multiple forests are required for security and autonomy
reasons, but the company also requires full functionality from Outlook and Exchange Server. One
solution is to have multiple forests “share” the same Exchange organization. (In this scenario, the
forests aren’t truly sharing the Exchange organization because Exchange information isn’t replicated to
them, and they don’t provide address book lookups.)
Here’s how this approach works: You establish a forest to house the Exchange environment.
You can create this “Exchange forest” with a single-domain, single-forest configuration. You create
an AD user in this organization for every mailbox your company requires. Moreover, you create all
mailboxes in this organization. By using trusts, you can delegate each mailbox in this forest to an AD
account in another forest. You can then disable the actual AD accounts in the Exchange forest, as
Figure 5.1 shows.
Chapter 5 Multiple Directories 85
Figure 5.1
Single Exchange forest environment
Steve Bryant
Steve Bryant
Division A Forest Division B Forest
Exchange
Servers
Exchange Forest
Although the design of this scenario seems fairly simple, this approach requires that DNS be
replicated among the forests because the Outlook clients will need to locate GCs in the Exchange
forest. Moreover, it requires that you locate the GC servers for the Exchange forest near the users to
provide efficient access to the address book.
These requirements give the Exchange forest scenario a higher initial cost than other solutions.
However, the ongoing cost of this design is less than the ongoing cost of some other scenarios
because you don’t need to license or manage any third-party connectors for synchronization. The end
result of this configuration is full and complete functionality of Outlook and Exchange because all
mailboxes and Exchange servers are in the same forest and all share the same GC.
Separate Exchange 2003 and Exchange 5.5 Organizations

Microsoft has extended support for Exchange 5.5 until December 31, 2005. Many companies
will probably continue to wait until the last moment to migrate from that environment. I have several
customers who suggest they’ll hold out because Exchange 5.5 currently meets their needs and/or
they currently can’t budget for AD and Exchange Server 2003 client licenses. For them, I include the
following scenario, which relies on the Active Directory Connector (ADC) beyond its designed
purpose, but satisfies this scenario’s need for inter-organizational support nicely.
The ADC that ships with Exchange Server 2003 provides directory synchronization between
Exchange 2003/Exchange 2000 and Exchange 5.5 environments. The connection’s purpose is to
provide directory synchronization during a migration to populate the AD with mailbox information
from Exchange 5.5, but you can use it for long-term connection purposes, as I’ll discuss in some
detail.
The ADC functionality is useful for Exchange 5.5 upgrades, as I discussed in the previous
chapter, and it supports a reorganization as well – if you’re moving to a brand new Exchange 2003
organization. It’s this functionality that provides inter-organizational support. In this scenario,
configuration is much like what I covered in the previous chapter except for the selections you
make in the Inter-Org Agreement Properties dialog box, which Figure 5.2 shows.
Figure 5.2
Inter-Org Properties dialog box
The ADC recipient agreement is the mechanism that synchronizes Exchange 5.5 and Exchange
2003 objects. The agreement lets you perform this synchronization across organizations. Although the
ADC was designed to support migrations from Exchange 5.5 environments, you can (though it isn’t
fully recommended) use the ADC for long-term connectivity between the two organizations. Through
the connection agreements (CAs) you gain a single address book with no implications for DNS. The
only requirement is that the ADC server has the necessary network connection with both the
Exchange 5.5 and the Exchange 2003 environments.
The net result of this configuration is simply a single address list. Mailboxes in one organization
are copied into the other organization to “combine” the different address books. Calendar information
can’t be delegated nor can Outlook Web Access (OWA) servers be shared. Message routing doesn’t
involve any site connection or formal mail connector. Instead, each system considers users on the
other systems to be on “foreign” systems. You must configure the users accordingly. SMTP is the
most commonly used transport for multi-organizational configurations – with separate SMTP domains
used for each organization.
Separate Exchange 2003 Organizations

Although the ADC is great for connecting to Exchange 5.5 systems, it can’t combine two ADs. To
make that connection, you need more than the ADC. You can find third-party tools that connect ADs
by creating entries from one system in the other.
Technically, you could accomplish the connection manually by creating SMTP contacts in each
system to represent mailboxes in the other. The problem with a manual process lies in the necessary
updates and deletions. Therefore, administrators prefer an automated method.
Microsoft has provided the necessary connection functionality in a product called the Identity
Integration Feature Pack (IIFP) for Microsoft Windows Server Active Directory, which is subset of the
Microsoft Identity Integration Server (MIIS) 2003. If you need to “combine” the global addresses for
multiple forests, IIFP is your solution, as Figure 5.3 illustrates.
Figure 5.3
IIFP
Exchange Exchange
Servers Servers
Server Running
Identity Integration Feature
Outlook Clients Pack Outlook Clients
Steve Bryant
Brian Veal
Steve Bryant Brian Veal
Division A Forest Division B Forest
A single server running IIFP can create contacts for multiple organizations in either a meshed or
a hub-and-spoke configuration. IIFP creates contacts to represent mailboxes in other organizations.
You can use either SMTP or X.400 to route the mail, but that configuration is within Exchange Server
2003. IIFP and MIIS 2003 perform the directory synchronization only – they don’t handle the mail
flow.
To install and run IIFP, you must run Windows Server 2003 Enterprise Edition and Microsoft
SQL Server 2000 with Service Pack 3 (SP3). The installation process itself is fairly simple, and most
people can usually complete it in a few hours. As with all network changes, you should read the
documentation that you get when you download IIFP, and test it thoroughly in a lab. The process
includes setting up IIFP and installing management agents in each forest. When you configure IIFP,
keep in mind that
• you must have management agents for both forests
• you should always encrypt LDAP traffic
In addition to the setup steps I mention above, you’ll need to identify the connection filters,
including their projection rules, attribute flow, and provisioning and de-provisioning options. The
process might seem daunting at first, but some great walkthroughs are included with the product.
Read IIFP_2003_GAL_synchronization.doc to get a thorough background knowledge of the
product, then use IIFP_2003_GAL_synchronization_Step_By_Step.doc, which comes with the IIFP
when you download the package from http://www.microsoft.com/downloads/details.aspx?FamilyID
=d9143610-c04d-41c4-b7ea-6f56819769d5&DisplayLang=e, to perform a trial connection in the lab.
After that, you should be ready to begin a pilot in your own environment.
The benefits of using IIFP include the following:
• You get a “free” solution for merging two AD forests to provide GAL synchronization.
• Microsoft fully supports this approach as a long-term solution for GAL synchronization.
• You can leverage the knowledge you gain about this tool when you use MIIS 2003.
IIFP does not include free/busy or calendar synchronization so users will still have difficulty
scheduling meetings. However, third-party solutions are available that provide free/busy
synchronization.
Keep in mind that IIFP is designed to manage identities across ADs. It will work for Exchange
Server 2003 and Exchange 2000 with both the AD and Active Directory Application Mode (ADAM).
Exchange 2003 and Foreign Mail Systems – Short Term

Users have learned over the years that a single email system probably won’t emerge from the many
that are available. At the Microsoft Tech-Ed and LotusSphere conferences, you’ll hear different
opinions about which of the two mail system dominates and why. However, organizations use many
other systems, including Novell’s returning heavyweight GroupWise, OpenMail, TAO, and other POP
and IMAP systems. Microsoft has created tools to assist with migration and short-term coexistence
with Lotus and GroupWise and tools to assist with the migration from POP and IMAP servers.
Some companies that have used these connectors to migrate email have noticed the technical
advantages of connecting directories with these tools. However, the rich collaboration the companies
gain is tainted by the fact that because the tools weren’t designed for long-term use, their stability and
redundancy sometimes comes into question. I’ll cover the Notes and GroupWise connectors to
illustrate their strengths and weakness.
Lotus Notes/Domino Connector

As I mentioned before, Lotus Notes/Domino isn’t going away anytime soon. In fact, the strength of
Notes/Domino as a development platform has helped it establish a foothold in companies as their
business practices become linked with the technology. Having said that, many faithful Notes shops
have decided that the Outlook collaborative client and the Exchange messaging environment are ideal
for their organizations.
These shops want to keep their applications on Notes/Domino, at least until their developers
have been retrained and the applications ported. Their challenge is to maintain both directories
during and after the move and to maintain a synchronized directory for the collaborative applications
that will be left behind.
Exchange 2003, Exchange 2000, and Exchange 5.5 all ship with the Notes connector tools. The
Notes connector contains both a directory synchronization feature and a message conversion tool.
The administrator creates an Exchange 2003 server to act as the “connector server,” then installs the
Notes client on the server to provide the necessary APIs required to connect to the Lotus
Notes/Domino server. These APIs let the Exchange 2003 server use a predetermined Lotus Notes ID
to connect to the Notes environment. The Exchange 2003 server can then pull and push directory
updates and deliver and receive email by monitoring a specific Mail.box file on the target Notes
server.
n Note Exchange Server 2003 SP1 now supports connections to Domino 6.x servers, including the
latest Domino 6.51 server.
From a directory standpoint, the Notes connector server creates AD accounts or contacts to
represent the Notes users in the Names and Address book. From the Notes side, the Exchange users
appear to be on another Notes server within the Notes enterprise. The result is that each set of email
users appears in the other server’s mail directory. This configuration has some additional benefits as
well:
• Rich-text messages are supported, including meeting requests, message formatting, and stationery.
• You can install the calendar connector, which is part of the Notes connector, to add a
calendaring component that will provide free/busy information across systems.
• Although group entries are created in the opposite system, the membership isn’t. In other words,
you’ll have an entry for the group in each directory, but the entry is a contact, not an actual
group.
Keep in mind, however, that this tool’s purpose is to create a directory link so that you can
migrate users from one system to another. The assumption is that you’ll use the connector less and
less as you move users – and finally not at all. Because the connector not only synchronizes the
directory but also routes the email between the systems, it represents both a potential bottleneck and
a single point of failure.
d Caution
If you consider using the Notes connector long term, remember that it represents both a
potential bottleneck and a single point of failure.
Messages bound for the Exchange environment are stored in Notes format on the Notes server in
a special routing mailbox. The Exchange Server that runs the Notes connector then collects the mes-
sages at set intervals and converts the messages from Notes format to Outlook rich text. If the Notes
connector server goes down, loses the connection, or otherwise fails, you have no mail routes
between the two environments, as Figure 5.4 shows. That potential failure makes the Notes connector
not the best long-term solution for directory synchronization.
Figure 5.4
Notes connector
Notes connector
Exchange Site Exchange Site Notes Domain Notes Domain

Site D Site A Notes Notes
Mail flow and

directory updates between
the systems will only use the
connector. If the connector
is down or inoperative, no
Exchange Site Exchange Site email will pass Notes Domain Notes Domain
Site C Site B Notes Notes
SMTP for Message Transport

By contrast, SMTP is a great message transport in a heterogeneous environment. Major software
and service vendors, including Microsoft and Lotus/IBM support SMTP. If you offload the message
transportation to SMTP, the system can separate directory updates and mail flow, as the diagram in
Figure 5.5 shows.
Figure 5.5
SMTP message transport
Notes connector
Exchange Site Notes Domain

Site A Notes

Site D Notes
SMTP
Exchange Site Only directory updates uses Notes Domain

Site C the connectors and Notes
connector servers. Email flow
uses SMTP
Site B Notes
By using SMTP as your message transport, you can potentially set up each server to route email
independently. Doing so eliminates the single point of failure that using the Notes connector creates.
Fortunately, you have multiple options for this task. I’ve tested the following options and used
them in production environments. The first option is to use one Internet domain for Notes and
another for Exchange.
Establish Separate Internet Domains for Notes and Exchange
Perhaps your company is comprised of individual companies. In such a case, the Notes environment
can collect Internet email for Company1.com and the Exchange environment can collect email for
Company2.com, as Figure 5.6 shows. The use of separate Internet domains is the safest and easiest
solution to configure.
Figure 5.6
Separate Exchange and Notes domains
Internet
Company2.com Company1.com
Exchange Notes
Environment Environment
Establish Subdomains
You can establish subdomains (by using an internal partitioning scheme) to identify each email
system. For example, you could use Notes.company.com internally to identify the Notes users and
Exchange.company.com (also internally) to identify the Exchange users. If you take this approach, the
areas of concern you’ll encounter are (1) the internal naming structure and (2) the processing of
inbound email. Many companies that use this strategy have a virus scanner or other SMTP server that
scans and relays inbound email, as Figure 5.7 shows.
Figure 5.7
Internal subdomains for the Exchange and Notes environments
SMTP Mail Relay/ Virus Scanner

Internet
exchange.company.com notes.company.com
Exchange Notes
A mapping table on the SMTP mail relay/virus scanner server would receive email messages for
steve@company.com, look up the internal address of steve@exchange.company.com, and route the
email messages to the Exchange servers for processing.
You can also set up a relay server to modify outbound email messages. If steve@exchange
.company.com sends an email message, the SMTP relay server would strip exchange from the address
so that someone in the outside world would see steve@company.com as the reply address.
One drawback of this approach is that the necessary mapping tables often require manual
updates. The primary benefit of the approach is the ease with which multiple internal servers can
share the domain name. I’ve worked with customers who have Exchange, Notes, GroupWise, and
various SMTP servers sharing the same domain by creating an internal partitioning scheme such as
the one just described.
Split the Domain
Splitting the domain is tricky, but it provides a seamless border between multiple systems. In essence,
the Exchange server will forward unresolved email messages to the Notes system and vice versa, as
Figure 5.8 shows.
Figure 5.8
Splitting the domain
Internet
Company.com Company.com
Unresolved
Email relays
Exchange Notes
Several Microsoft TechNet articles describe this process from the Exchange perspective, and
similar documents on IBM’s Web site help you configure the process for Notes. The routing process
works as follows:
1. Either system might receive an inbound email message that isn’t resolved to a local mailbox or
person document.
2. The server forwards the unresolved message to the IP address on the other mail system that you
specify in the configuration document or SMTP settings.
3. The message is either delivered or the system creates a non-delivery report (NDR).
The drawback of this option is that the alternate system will create NDRs. Many NDRs burden
systems, allow administrators less control, and “announce” the server name and the email system in
use. Also, this configuration is slightly more difficult to set up and support. This option also doesn’t
support as many internal system types as the use of subdomains. The benefit is that everyone in the
company can share the same Company.com address for internal and external messages.
Installing and Tweaking the Notes Connector

Because the process is involved, the next few pages give you the details you need to modify the
Notes connector. However, before you modify it, you need to install it. Begin by installing the Notes
connector on a server using the default settings. Even if you have a very small server, don’t fret. I
have Pentium-class machines with less than 128MB running the connector for address books with
more than 6000 names.
Because you won’t use the connector for mail routing, a server failure means only that the
directories aren’t current. Keep this factor in mind when you specify hardware for your connector,
but do use a separate server. Don’t put the connector on a mailbox server or any other server that
you can’t reboot during the day.
Next, verify that mail and directory updates can use the connector without problems. Then, stop
the Notes connector and navigate to the Dxanotes and Dxamex folders. (You can find these folders
under Exchsrvr/Connect or Conndata on your Exchange Server/Notes Connector server.)
These folders contain the configuration files for the connector. Copy the folders to a safe place
somewhere else on the system. Next, open the Dxamex folder and look at the files that handle
imports into Exchange.
In the Amap.tbl file, which Figure 5.9 shows, add an entry for the SMTP addresses. The entry to
be added is shown in boldface type. As noted in the figure, if you aren’t using SNADS, you also
should delete the SNADS line.
Figure 5.9
Changes to the Amap.tbl file
AMAP.TBL
DN 256 Obj-Dist-Name
TA 256 Target-Address
ACCOUNT 32 Assoc-NT-Account
COMPANY 64 Company
DEPARTMENT 64 Department
FULLNAME 128 Display-Name
FIRSTNAME 64 Given-Name
ALIAS 64 Mail-nickname
OFFICE 64 Physical-Delivery-Office-Name
LASTNAME 64 Surname
NOTESADDR 128 Proxy-Addresses(NOTES:)
USNCreated 12 USN-Created
Initials 6 Initials
Title 32 Title
Phone 20 Telephone-Office1
MobilePhn 20 Telephone-Mobile
Fax 20 Telephone-Fax
ZIP 16 Postal-Code
Pager 20 Telephone-Pager
SNADSADDR 20 Proxy-Addresses(SNADS:) Delete This line
SMTPAddr 128 Proxy-Addresses(SMTP:) Add This line
In the Mapnotes.tbl file, which Figure 5.10 shows, replace the Fullname= and TA= lines with the
code in boldface type that follows each.
Figure 5.10
Changes to the Mapnotes.tbl file
MAPNOTES.TBL
Alias = ISEQUAL( ShortName, “”, SUBSTR
( FullName, 1, 64 ), ShortName )
FullName = ISEQUAL( ShortName, “”, X500
( FullName, “CN” ), X500
( LastName “, “ FirstName, “CN” ) )
TA = “SMTP:” ISEQUAL( MailAddr, “”, ISEQUAL
( SMTPAddr, “”, Replace
( Strip( FullName, “;”, “L”, “R” ), “ “, “_” ) “%” Replace(
Strip( MailDomain, “;”, “L”, “R” ), “ “, “_” ) “@company.com”,
SMTPAddr ), MailAddr )
DN = UNID
FirstName = FirstName
LastName = ISEQUAL( LastName, “”, ISEQUAL(
FirstName, “”, X500( FullName, “CN”), “” ) ,
LastName)
Company=Company
Department = Department
Office = Location
Initials = Initials
The new Fullname= line places the Notes entries into the Exchange environment as Last Name,
First Name. If you want to leave the setting as First Name Last Name, replace the TA= line only and
leave the Fullname= entry unchanged.
The TA= line is the most important component because it replaces the Notes information with
SMTP-specific information. This line builds the Internet address that will be used for each entry. The
TA= line pulls this information from the Notes address field that already exists. In the Mapnotes.tbl
file, change the company.com address to the address you want to use for the Notes environment.
Next, you modify the files that control moving data from the Exchange environment into the
Notes environment. Navigate to the Dxanotes folder and open the Amap.tbl and Mapmex.tbl files.
In the Amap.tbl file, which Figure 5.11 shows, add the single SMTPAddr line to include the use
of an SMTP address as well as the additional lines shown in boldface type.
Figure 5.11
Changes to the Amap.tbl file
AMAP.TBL
FULLNAME 220 FullName 1
MAILDOMAIN 31 MailDomain 2
COMPANY 64 CompanyName NULL
DEPARTMENT 64 Department NULL
FIRSTNAME 64 FirstName NULL
LASTNAME 64 LastName NULL
LOCATION 128 Location NULL
SHORTNAME 64 ShortName NULL
UNID 64 $$UNID NULL
DN 256 $$DN NULL
USNCreated 16 $$USN
Initials 6 MiddleInitial NULL
Title 32 JobTitle NULL
Phone 20 OfficePhoneNumber
MobilePhn 20 CellPhoneNumber
Fax 20 OfficeFAXPhoneNumber
Resource 20 ResourceFlag
CALDOM 32 CalendarDomain
MAILSRV 32 MailServer
SMTPAddr 128 InternetAddress Add This line
MailAddr 128 MailAddress Add This line
MailSys 4 MailSystem Add This line
Finally, in the Mapmex.tbl file, you make one modification in the FullName= line and add the
three additional entries in boldface type. By default, the Exchange users will appear to be in a
separate domain from the Notes users. To make the directories appear as one, you can modify the
FullName (i.e., distinguished name – DN) to match others in the environment. In this environment,
the DN is in the format Steve Bryant/Company, so I modified the connector to use the same format
for imported users, as Figure 5.12 shows.
Figure 5.12
Changes to the Mapmex.tbl file
MAPMEX.TBL
FullName = FirstName “ “ LastName “/COMPANY”
MailDomain = Trim( Strip( NotesAddr, “@”, “L” ), “B” )
ShortName = Alias
LastName = ISEQUAL( LastName, “”, FullName, LastName )
FirstName = FirstName
Company = Company
Department = Department
Location = Office
UNID = HASH( DN )
USN = USNCreated
DN = DN
Initials = Initials
CALDOM = Trim( Strip( NotesAddr, “@”, “L” ), “B” )
MailDomain = NOTESDOMAIN Add this line
MailAddr = Trim(SMTPAddr, “B”) Add this line
MailSys = “5” Add this line
In the example that Figure 5.12 shows, I added fields to make the directory appear seamless. The
line beginning with MailDomain= ensures that SMTP is used and that no external Notes domain is
involved. Replace NOTESDOMAIN with the Notes domain name you use in your environment.
Because you’re forcing an entry in the mail domain field, the Exchange sites don’t need to install or
run the Notes Addressing DLL on their servers.
You add the required lines MailAddr and MailSys to identify the type of Notes person document
to create and indicate how the address will be created. The result is a person document with an
SMTP address for routing only. After you modify the settings, restart the Notes connector service.
Because the mapping fields load during the service startup, you’ll need to stop and start the service
after each change.
I won’t pretend this process is a cakewalk. It takes me a couple of days to create a new
connection this way, but it’s easy to test, and you learn the results of your work fairly quickly. Be
prepared to stop and start the service often. Change the event logging on the service to Medium –
so you can watch the event logs for errors. (By default, event logging is set to “off.”)
Also, be prepared to delete all entries and resync. To make the delete-and-resync process easier,
create a local recipient container in the Exchange system for the imported Notes accounts and use a
separate Names and Addresses file in Notes for the imported Exchange addresses. I encourage you to
build your mapping files in a test environment because if you make a mistake with the mapping
fields, a directory sync will litter the event log with errors and potentially delete entries that the
connector has already created.
n Note As cool as this tweaking is, Microsoft Product Support Services (PSS) won’t provide much
support for this configuration. In fact, should directory synchronization fail, PSS will probably
ask that you reinstall the connector or overwrite the mapping files. If support is important to
you, you should take a serious look at MIIS 2003, which I cover in more detail at the end of
this chapter. MIIS 2003 supports the same level of field mapping and manipulation, but it
Microsoft designed it to work in that capacity and PSS supports it fully. Finally, be aware that
the Notes connector doesn’t support rich text in this, but it does support HTML-formatted
messages. Calendar invitations, free/busy, encryption, and any other features that would
provide rich text or formatting won’t work. What you gain, however, is stability.
GroupWise
The technologies and procedures for GroupWise directory synchronization and message formatting
are nearly identical to the Notes/Domino processes. The connector for Novell GroupWise
synchronizes specific Novell GroupWise mailbox information to the AD and visa versa. As with the
Notes connector, you should create a separate Exchange Server 2003 server to run the connection.
Also as with the Notes connector, mapping tables control which fields in the Novell directory
map to corresponding fields in AD. Because of this structure, you can also manipulate the way the
entries are created and maintained in the systems.
To install the GroupWise connector, you must first verify connectivity to the Novell network by
installing the Novell NetWare Client for Windows (or the Novell Directory Services – NDS – client,
depending on the version of NetWare you use) on the Exchange connector server.
On the Novell side, you must install the Novell GroupWise API Gateway on one of the Novell
servers and configure a foreign GroupWise domain for your Exchange 2003 organization using the
NetWare Administrator program. Using the recipient policies, you can configure different proxy
addresses for different groups of people and install separate GroupWise connectors to spread the
load and reduce the impact of a connector failure.
MIIS 2003
In the scenarios I’ve described in this chapter, I’ve identified the specific directory synchronization
options for the various versions of Exchange as well as foreign directories. You’ve probably noticed
that each process I mentioned is specific to that task and that none of the scenarios I’ve mentioned
thus far has abilities beyond the predefined task.
In other words, until now, I haven’t described the “silver bullet.” Microsoft began to consider the
connection concerns in the late 1990s and worked on a metadirectory project that would support
connections with multiple disparate directories for address list synchronization, account management
and provisioning, and even password synchronization.
Microsoft Identity Integration Server 2003 (MIIS 2003, formerly Microsoft Metadirectory Services
(MMS)) is Microsoft’s newest and most powerful metadirectory offering. MIIS 2003 supports far more
than the few directories mentioned so far. The following list indicates the range of MIIS 2003’s
support:
• AD
• ADAM
• Attribute value pair text files
• Delimited text files
• Directory Services Markup Language (DSML)
• Fixed-width text files
• GALs (Exchange)
• LDAP Directory Interchange Format (LDIF)
• Lotus Notes/Domino 4.6 and 5.0
• Microsoft Windows NT 4.0 domains
• Microsoft Exchange 5.5 Bridgeheads
• Exchange 2003, Exchange 2000, Exchange 5.5
• SQL 2000 and SQL 7 and databases
• Novell eDirectory v8.6.2 and eDirectory v8.7
• Oracle 8i and Oracle 9i databases
• SunONE/iPlanet/Netscape Directory
• IBM Informix, DB2, dBase, Microsoft Access, Microsoft Excel, OLE DB through SQL Data
Transformation Services (DTS)
If you want to synchronize address lists from Exchange 2003, Exchange 2000 and Exchange 5.5
organizations, and Notes/Domino, multiple and/or LDAP directories – MIIS 2003 offers a better
solution than running all the connectors I’ve mentioned previously.
MIIS 2003 is a powerful metaverse product – and it isn’t free. It’s a production-quality, heavy-duty
server product that supports very granular replication of directory objects. MIIS 2003 requires SQL
Server 2000 Enterprise SP3 on the back end, and you’re encouraged to install Visual Studio .NET for
any custom extension work you might need. By using management agents, you can control which
fields of which objects are replicated to the metaverse. And, once within the metaverse, you can
control which fields and objects are copied back to the individual directories.
MIIS 2003 is a complicated product that requires some knowledge of AD and the directories
you want to synchronize – and some development skills in compiling specific management agents.
Moreover, the terminology used to describe MIIS 2003’s setup and management will be foreign to
many administrators and will take some getting used to. For more detailed information about MIIS
2003, go to http://www.microsoft.com/miis.
LDIF Import and Export Scripts

Finally, I’d like to mention that you can script the management of objects within AD. You can use
LDIF scripts as well as comma separated value (CSV) files to export information from the AD. In
addition, you can use specifically formatted files either in LDIF or CSV formats to import information
into AD. I covered the syntax for LDIF scripting in the previous chapter, but I wanted to mention it in
this one as well.
Reviewing Your Multiple Directory Options

Many tools are available to help you maintain a single address list for your company. Non-Exchange
systems can also share the address book and provide collaboration with users whose mailboxes are
located on Exchange servers.
When you design a long-term coexistence solution, you should understand the protocol
implications as well as the “moving parts” necessary for directory synchronization. Manual directory
updates probably don’t provide the best long-term solution. Even LDIF scripts could become
cumbersome after some time, especially if you must deal with deletions and edits to existing records.
As we mentioned before, different “flavors” of MIIS can help you solve your directory
synchronization needs, but MIIS is not the only choice available.
1. Custom Code – Nothing is stopping you from writing your own directory synchronization tool.
AD allows both reading and writing with LDAP. Do a quick search for LDAP and ADSI at
http://msdn.microsoft.com and you will find many code samples to do just that. Moreover, LDIF
and even CSV files can be exported and imported on regular schedules to establish and maintain
the single global address list.
2. IIFP is available from Microsoft as a free download. It does a good job of “merging” two AD
forests to provide GAL synchronization. Moreover, it is fully supported as a long-term solution for
GAL synchronization
3. SimpleSync, a product available from CPS Systems at http://www.cps-systems.com/, has been
around for several years and also provides an excellent tool for synchronizing LDAP directories
(e.g., AD, Notes, Exchange, and iPlanet.
4. HP (formally Compaq, formally DEC) also has an enterprise-level synchronization tool called
LDAP Directory Synchronization Utility (LDSU). This tool was originally written to support the
company’s large in-house move to Exchange 2000 and has a large customer base.
5. MIIS, discussed MIIS in detail earlier in this chapter, is fully supported by Microsoft and provides
a great deal of functionality, but with complexity.
6. Aelita Collaboration Services for Exchange, from Aelita now part of Quest Software, is the one
tool that offers the most for Exchange collaboration among different forests and Exchange
organizations. The two largest advantages of this product are its ability to synchronize over SMTP
and to provide free/busy information across Exchange organizations.
Next: Outlook Deployment

In Chapter 6, I’ll discuss Outlook deployment, including performance over slow links, installation
scripting, and profile management. I’ll also cover mobile implementations of Outlook and
collaborative integration with other applications.
One of the strongest new features of Outlook is its ability to work over slow links. Outlook’s
new level of compression and synchronization dramatically affects both performance over slow links
and overall server load. By understanding the improvements in Outlook 2003, you can better design
systems that span slow links.
Outlook 2003 also offers improved privacy, antivirus capability, junk email filtering, compression,
synchronization, overall performance, and stability. In addition, Outlook 2003 is closely matched
with the new OWA versions. In Chapter 6, I’ll discuss the new features and their impact on your
enterprise – including the newly added support for smart phones and mobile devices.

ExchangeServer ch5

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ExchangeServer ch5

Hochgeladen von

Copyright:

Verfügbare Formate

The Expert's Guide for

Why Multiple Directories Exist

AD as Your Directory Foundation

Forests and Security

Multiple Directories and Exchange

Single Exchange Organization Scenario

Division A Forest Division B Forest

Separate Exchange 2003 and Exchange 5.5 Organizations

Separate Exchange 2003 Organizations

Steve Bryant Brian Veal

Division A Forest Division B Forest

Exchange 2003 and Foreign Mail Systems – Short Term

Lotus Notes/Domino Connector

Exchange Site Exchange Site Notes Domain Notes Domain

Mail flow and

SMTP for Message Transport

Exchange Site Notes Domain

Exchange Site Notes Domain

Exchange Site Only directory updates uses Notes Domain

SMTP Mail Relay/ Virus Scanner

Installing and Tweaking the Notes Connector

LDIF Import and Export Scripts

Reviewing Your Multiple Directory Options

Next: Outlook Deployment

Das könnte Ihnen auch gefallen